Natural Language Is
The New Ontology
Business logic no longer needs to be translated into rigid configuration before software can act on it.
Palantir's Ontology was the most important architectural idea in enterprise software of the last two decades. It was the right answer for a world where machines couldn't understand natural language, but that world no longer exists.
Ontology solved a real problem: machines couldn't understand how businesses operate unless you translated that understanding into formal structure. Typed objects, defined relationships, deterministic rules. It was expensive, it was rigid, and it required engineers to maintain. But it was the only way to make business logic legible to software.
With models like Opus 4.7 and GPT-5.5, that constraint is gone. LLMs can now interpret natural language business rules with sufficient precision and reliability to execute them directly, in production, on decisions that matter. The data still needs structure. Databases, schemas, APIs aren't going anywhere. What's obsolete is the requirement to encode your business logic, the rules, the decisions, the routing, into that same formal structure before software can act on it.
A Concrete Example
Consider commission calculations at a mid-market industrial company. The rules are intricate: different rates for different job types, one-off overrides for specific individuals, thresholds that change the payout structure, bonuses tied to conditions that the CFO carries around in their head. These rules change every few months.
You could build a configurable UI: dropdown menus for rate tiers, input fields for thresholds, exception tables for individual overrides. You'd spend weeks building it, and the first time the CFO says "actually, for this one person, the rate should be different if the job is in this region and was referred by an existing client," you'd realize your UI doesn't support that level of specificity. So you add more configuration options, making the interface more complex with each iteration. Eventually, you've built a mini-ERP just for commissions, and it still doesn't cover every case.
Or you could write custom code. An engineer encodes every rule as conditional logic, and it works perfectly until the rules change. Now you're filing a ticket, waiting for an engineer, testing, deploying. The person who actually understands the rules is separated from the system by at least one engineer and a deployment pipeline.
Today's models offer an alternative: you describe the commission rules in natural language. The system reads the description and calculates commissions directly. When the rules change, the CFO updates the description. No ticket, no engineer, no deployment. The same person who understands the rules is the person who maintains them, in the same language they use to explain those rules to a new hire.
Systems built on this pattern are running in production today, handling real calculations that affect real paychecks, at a reliability level equivalent to deterministic code.
What Structure Used To Buy You
Ontology was the most ambitious version of a pattern that runs through all of enterprise software. SAP built thousands of configuration tables, requiring specialized consultants who understand the configuration system better than most operators understand their own business. Sage Intacct built sprawling admin panels where rules are expressed as nested dropdowns and conditional checkboxes. ServiceTitan built settings pages that their own implementation teams configure on the customer's behalf.
Each of these attempts to solve the same problem: business logic is specific, edge-case-heavy, and changes constantly. The solution was always some form of structured encoding, a way for the business to express its rules in a format that deterministic software can execute.
Configuration emerged as a specialized skill to resolve this tension. There are entire consulting practices built around knowing which SAP tables to modify. The configuration layer, which was supposed to make software adaptable, became its own source of complexity and cost. And for businesses whose logic doesn't fit cleanly into any product's configuration model, they build custom software, knowing full well that when the business changes in six months, that code will need to be rewritten.
Why Natural Language Changes The Equation
When business logic lives in natural language, the relationship between the business and its software inverts. In the traditional model, the business translates its operations into a format the software understands: structured data, configuration parameters, or code. The software dictates the vocabulary. When natural language is the interface, the business describes how it actually operates, and the software adapts. The business dictates the vocabulary.
Domain experts maintain domain logic. The person who understands the commission rules maintains the commission rules. No engineer as an intermediary. This isn't about cost reduction. It's about removing a translation layer that introduced errors and delays.
Edge cases become trivial. In deterministic systems, every edge case requires a new branch of code or a new configuration option. In natural language systems, an edge case is a sentence. No UI redesign, no code change, no deployment.
Software evolves with the business. When the rules change, the description changes. There's no lag between how the business operates and what the software does.
The system accumulates operational knowledge. Over time, the natural language description becomes a living specification, reflecting not just the rules but the exceptions and refinements discovered through experience. The prompt becomes an institutional asset. No traditional software system produces this as a byproduct.
New Problems, Better Problems
This isn't without trade-offs. Natural language business logic requires versioning, monitoring, guardrails against contradictions, and feedback loops that surface outputs to users so they can verify the system is interpreting their rules correctly.
These are real engineering challenges. They are also dramatically better problems than the ones they replace. Versioning a natural language document is simpler than versioning a complex codebase. Monitoring AI-interpreted rules is more tractable than auditing thousands of SAP configuration tables. Teaching a business user to write clear rule descriptions is easier than teaching them to navigate an ERP's admin panel.
What This Means
The configuration surfaces that enterprise software has spent decades building are legacy interfaces. They were the best available answer to "how does a business express its rules to software?" Natural language is a better answer. Not incrementally better. Categorically better.
The brittleness problem that has plagued custom software is solvable. Custom software has always offered a trade: it does exactly what you need, but it breaks when your needs change. Natural language business logic removes that trade.
The engineer's job shifts from "maintain and update the business logic" to "build the infrastructure that interprets and acts on business logic expressed in natural language." The engineer builds the system once. The business evolves the logic forever.
Ontology was the right abstraction for a world where software couldn't understand natural language. It imposed structure because structure was the only way to make business logic legible to machines. That constraint has disappeared. The structure can now be inferred rather than imposed. And that changes everything about how software gets built, configured, and maintained.
Natural Language Is
The New Ontology
Business logic no longer needs to be translated into rigid configuration before software can act on it.
Palantir's Ontology was the most important architectural idea in enterprise software of the last two decades. It was the right answer for a world where machines couldn't understand natural language, but that world no longer exists.
Ontology solved a real problem: machines couldn't understand how businesses operate unless you translated that understanding into formal structure. Typed objects, defined relationships, deterministic rules. It was expensive, it was rigid, and it required engineers to maintain. But it was the only way to make business logic legible to software.
With models like Opus 4.7 and GPT-5.5, that constraint is gone. LLMs can now interpret natural language business rules with sufficient precision and reliability to execute them directly, in production, on decisions that matter. The data still needs structure. Databases, schemas, APIs aren't going anywhere. What's obsolete is the requirement to encode your business logic, the rules, the decisions, the routing, into that same formal structure before software can act on it.
A Concrete Example
Consider commission calculations at a mid-market industrial company. The rules are intricate: different rates for different job types, one-off overrides for specific individuals, thresholds that change the payout structure, bonuses tied to conditions that the CFO carries around in their head. These rules change every few months.
You could build a configurable UI: dropdown menus for rate tiers, input fields for thresholds, exception tables for individual overrides. You'd spend weeks building it, and the first time the CFO says "actually, for this one person, the rate should be different if the job is in this region and was referred by an existing client," you'd realize your UI doesn't support that level of specificity. So you add more configuration options, making the interface more complex with each iteration. Eventually, you've built a mini-ERP just for commissions, and it still doesn't cover every case.
Or you could write custom code. An engineer encodes every rule as conditional logic, and it works perfectly until the rules change. Now you're filing a ticket, waiting for an engineer, testing, deploying. The person who actually understands the rules is separated from the system by at least one engineer and a deployment pipeline.
Today's models offer an alternative: you describe the commission rules in natural language. The system reads the description and calculates commissions directly. When the rules change, the CFO updates the description. No ticket, no engineer, no deployment. The same person who understands the rules is the person who maintains them, in the same language they use to explain those rules to a new hire.
Systems built on this pattern are running in production today, handling real calculations that affect real paychecks, at a reliability level equivalent to deterministic code.
What Structure Used To Buy You
Ontology was the most ambitious version of a pattern that runs through all of enterprise software. SAP built thousands of configuration tables, requiring specialized consultants who understand the configuration system better than most operators understand their own business. Sage Intacct built sprawling admin panels where rules are expressed as nested dropdowns and conditional checkboxes. ServiceTitan built settings pages that their own implementation teams configure on the customer's behalf.
Each of these attempts to solve the same problem: business logic is specific, edge-case-heavy, and changes constantly. The solution was always some form of structured encoding, a way for the business to express its rules in a format that deterministic software can execute.
Configuration emerged as a specialized skill to resolve this tension. There are entire consulting practices built around knowing which SAP tables to modify. The configuration layer, which was supposed to make software adaptable, became its own source of complexity and cost. And for businesses whose logic doesn't fit cleanly into any product's configuration model, they build custom software, knowing full well that when the business changes in six months, that code will need to be rewritten.
Why Natural Language Changes The Equation
When business logic lives in natural language, the relationship between the business and its software inverts. In the traditional model, the business translates its operations into a format the software understands: structured data, configuration parameters, or code. The software dictates the vocabulary. When natural language is the interface, the business describes how it actually operates, and the software adapts. The business dictates the vocabulary.
Domain experts maintain domain logic. The person who understands the commission rules maintains the commission rules. No engineer as an intermediary. This isn't about cost reduction. It's about removing a translation layer that introduced errors and delays.
Edge cases become trivial. In deterministic systems, every edge case requires a new branch of code or a new configuration option. In natural language systems, an edge case is a sentence. No UI redesign, no code change, no deployment.
Software evolves with the business. When the rules change, the description changes. There's no lag between how the business operates and what the software does.
The system accumulates operational knowledge. Over time, the natural language description becomes a living specification, reflecting not just the rules but the exceptions and refinements discovered through experience. The prompt becomes an institutional asset. No traditional software system produces this as a byproduct.
New Problems, Better Problems
This isn't without trade-offs. Natural language business logic requires versioning, monitoring, guardrails against contradictions, and feedback loops that surface outputs to users so they can verify the system is interpreting their rules correctly.
These are real engineering challenges. They are also dramatically better problems than the ones they replace. Versioning a natural language document is simpler than versioning a complex codebase. Monitoring AI-interpreted rules is more tractable than auditing thousands of SAP configuration tables. Teaching a business user to write clear rule descriptions is easier than teaching them to navigate an ERP's admin panel.
What This Means
The configuration surfaces that enterprise software has spent decades building are legacy interfaces. They were the best available answer to "how does a business express its rules to software?" Natural language is a better answer. Not incrementally better. Categorically better.
The brittleness problem that has plagued custom software is solvable. Custom software has always offered a trade: it does exactly what you need, but it breaks when your needs change. Natural language business logic removes that trade.
The engineer's job shifts from "maintain and update the business logic" to "build the infrastructure that interprets and acts on business logic expressed in natural language." The engineer builds the system once. The business evolves the logic forever.
Ontology was the right abstraction for a world where software couldn't understand natural language. It imposed structure because structure was the only way to make business logic legible to machines. That constraint has disappeared. The structure can now be inferred rather than imposed. And that changes everything about how software gets built, configured, and maintained.
Restoration Rebuttal Automation
Ciridae built custom AI to automate insurance claim rebuttals for a Dallas restoration company, cutting deal cycles 60% and saving 15 hours per contract.
We partnered with a large, PE‑owned Dallas restoration business that relies on insurance claim reimbursement for water, fire, and mold remediation. Insurers frequently reduce or deny line items, which forces a rebuttal process before fair compensation is approved. When we arrived, the CEO was spending roughly 30% of their time building estimates, crafting rebuttals, and emailing adjusters. Contracts often required two to eight rounds of back‑and‑forth before signature, stretching the cycle from initial lead to close to two to three months. Because best‑in‑class restoration margins are only achieved when every detail is defended, the team couldn’t simply move faster by doing less—they needed a way to match the CEO’s precision without consuming the CEO’s week. Our philosophy is straightforward: our AI conforms to your processes, not the other way around.
We began with onsite scoping and captured the CEO’s comparison ruleset in just three hours. We encoded the judgment they use every day—per‑room contents calculations; when carpet removal and pad replacement require waste allowances; pricing defaults that lean on Xactimate; when to flag missing texture or uniform appearance; drywall taping and finishing to ASTM C840; two‑coat paint standards with guidance for new versus existing surfaces; and the use of F9 notes and supplements when adjusters omit items. With the rules captured, we built a comparison engine that automates the entire rebuttals process and mirrors the CEO’s markup. Staff forward adjuster PDFs as email attachments from their existing Gmail workflow. Our system ingests the client’s estimate and the adjuster’s estimate, runs a PDF‑to‑PDF comparison, and uses our LLM to generate negotiation language in the client’s voice. Where the CEO previously spent about three hours reviewing a single estimate, our AI completes the work in around ten minutes, highlighting differences, proposing supplements, and returning a draft response that can be sent as‑is or lightly edited
The impact is immediate and measurable: an average of fifteen hours saved per deal across the two to eight negotiation cycles typical for each contract; a roughly sixty percent reduction in deal process duration, condensing a two‑to‑three‑month cycle to less than one month; and a greater than two percent increase in topline, driven by accelerated cash flow, captured coverage, and leadership freed to focus on growth. Most importantly, we delivered this without new portals or retraining. By encoding the CEO’s rules and returning ready‑to‑send drafts inside Gmail, we scaled the process that worked and made it faster, consistent, and easier to manage across the team. The result is a repeatable rebuttal workflow that preserves the client’s voice while multiplying the CEO’s reach. It feels like turning a trusted playbook into software: the same decisions, the same annotations, and the same outcomes—arriving in minutes instead of hours, and without hiring additional staff.
This will save us so much time, and it’s going to allow us to scale without having to hire more people. Working with Ciridae has been such a fun process for me, and it has cut my time down immensely
CEO of Restoration Business
