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.
Introducing the Ciridae
Ciridae helps enterprises navigate the AI transformation economy where competitive advantage is continuously reborn through intelligent systems.
In the past five decades, humanity has undergone financialization, globalization, and digitalization. These served as powerful tailwinds for human progress and flourishing. But like all great movements, they are approaching their twilight hour. Today, a new era rises on the horizon: transformation.
Humanity has been here before. We've stood at the threshold of transformation and ventured boldly into the horizon. The agricultural revolution, 10,000 years ago, allowed us to settle, accumulate surplus, and build civilization. The industrial revolution, 250 years ago, mechanized production and unleashed unprecedented material abundance. The digital revolution connected the world and democratized information. Each time, those who grasped the moment rewrote the rules of the engagement. Now we stand at another such threshold: the AI revolution.
But unlike its predecessors, this revolution is underpinned by something unprecedented—a radically new form of computing where software writes itself at near zero marginal cost, systems evolve autonomously, and intelligence emerges from data rather than design. We're not just automating tasks or connecting networks. We're creating machines that think, reason, and act. This is a form of computing that doesn't follow instructions but is able to act autonomously. Organizations built for this revolution won't just use intelligence—they will be intelligent.
The implications are staggering. Every assumption that underpins modern enterprise, from how decisions are made to how value is created, becomes obsolete when intelligence is no longer scarce. The organizations that grasp this aren't merely optimizing their existing operations with AI; they're reimagining what an organization can be. They're building entities that learn from every interaction, evolve with every decision, and transform continuously rather than discretely.
This is the transformation economy, where competitive advantage isn't built—it's continuously reborn. Where the question isn't what you are, but what you're becoming.
At Ciridae, we architect these metamorphoses. Our craft is helping enterprises master this discipline of perpetual transformation. We partner end-to-end: from strategy to roadmap, data modernization to agent deployment, workflow redesign to change management. We start with proof, move with velocity, and scale with conviction. Our playbook is pragmatic: align on a business truth; instrument the process; choose the simplest approach that wins; automate the unglamorous 80%; verify, monitor, and iterate. The output is not presentations—it's production systems with P&L impact.
The choice facing every enterprise is both simple and profound: lead this revolution or be consumed by it. History teaches us this pattern—the agricultural revolution left hunter-gatherers behind, the industrial revolution made artisans obsolete, the digital revolution rendered analog enterprises extinct. The AI revolution will divide organizations into two categories: those that transform and those that become history.
The question isn't whether this transformation will happen—it's already begun. The question is whether you'll be among the architects of this new world or merely its artifacts. The twilight of the old era is upon us. The dawn of transformation is here.
