Act 3: The approach

Act 3: The approach

Scene 11: The domain invariants

Look back down the stack. The deeper the layer, the fewer customers need to change it. Almost every customer customises something: in one survey, only 7% changed nothing. Far fewer go deep, and most of what changes sits near the top. Under the business rules are the domain primitives, and they do not vary between customers. Call them the domain invariants. They are where correctness is decided, and what the revenue depends on. The domain invariants are the product's core value. So the architecture needs a layer that holds those invariants, with everything that varies built on top of it. A product's knowledge graph already records the invariants: its capabilities, workflows and entities, and nothing specific to one customer. That is the idea behind semantic engineering.

Scene 12: Invariants plus rules: a domain-specific language

That gives two things to name. The domain invariants are drawn from the knowledge graph and shared by every customer. The business rules differ for each customer. Together, the invariants and the business rules make a domain-specific language. The invariants are its vocabulary, and its grammar says how business rules may combine them: which parts may vary, what values they admit, and which combinations are legal. The multi-tenancy line moves down to sit on the invariants. Below it, shared by every tenant, are the invariants, a compiler for the language, the data platform and the infrastructure. Above the line, per customer, are onboarding, the interface, and each customer's business rules, written in the language. Moving the line down gives up some of the original sharing, which is affordable once the per-customer part is cheap to produce. That leaves one question. Who writes the business rules?

Scene 13: AI agents write the language

AI agents write the business rules. Earlier domain languages stalled partly because the experts had to learn them and write in them. A domain expert states the intent in plain language, and an agent writes it as business rules in the domain's own vocabulary. The model's general knowledge does the translation, so the grammar can stay small: a language with a room primitive needs no bedroom keyword. It also shortens the leap. Going from plain language straight to a narrow configuration schema is a long step, and the model makes it invisibly. The grammar splits it into two shorter steps, with a readable document in between. The agent works with the grammar, worked examples, a validator and a test runner, reached through standard tooling such as the Language Server Protocol and MCP, so it checks its own work. The validator rejects anything malformed, with a location and a reason, and the agent tries again. Functional tests run against cases with known answers, and the compiler turns the result into configuration, screens or API calls, shown back to the expert. A request the language cannot express is refused rather than guessed at. The agent can still be wrong inside the language, which is why the tests carry the weight. An agent working in the language cannot add an API, a table or a code path, so the shared layers stay out of its reach. Agents may later help derive the grammar itself from the knowledge graph; for now, deciding what goes into it is architectural judgement.

Scene 14: Governing the invariants

The invariants below the line change as well, far less often and with far more at stake, because every tenant stands on them. Semantic engineering governs changes to the invariants. The knowledge graph records the application in four linked layers: what it does, how it looks and behaves, how it is organised, and how it is built. Each layer has a named custodian, a person accountable for its accuracy. When an invariant needs to change, agents traverse the graph to find everything the change touches, across every layer, and report the impact before any code is written. Generation agents then work only against what the graph declares, validation agents check the result against the graph, and the change merges only when those checks pass. The graph is updated on every merge, so it stays current. Above the line, the language bounds what each customer can change. Below it, the graph governs what the product can change. Semantic engineering governs the invariants below the line. Dialect engineering governs each customer's language above it.

Act 4: Implementation

Scene 15: Greenfield and brownfield

With the approach defined, how is it implemented? That depends on where a product starts. A greenfield product has nothing running yet, so it can build from the bottom, designing its execution layer and data model to be driven by a document. A brownfield product has customers and revenue on its lower layers, and risk grows with depth, so it works from the top down, following the same journey the customer took. Onboarding comes first, then the interface, then the business rules, later or not at all.

Scene 16: Four recommendations

For a brownfield product, the paper makes four recommendations. Do not staff a screen-by-screen interface programme now, because if the grammar route works, that work will not carry over; fix only the screens that are losing deals. Put the effort into the grammar and the compiler, which are the durable assets. Take onboarding first, because it touches no product code and its value shows in cycle time on the process that gates revenue. Treat any planned re-architecture as the place to design the lower line in.

Scene 17: What would show this wrong

The argument has clear failure conditions: grammar coverage that stalls, semantic errors that survive validation, and a case corpus that proves impractical to build. The site sets out each one.

Scene 18: Close

The two applications behind this argument illustrate both directions of travel. Wadi, a house-design application, is the greenfield case: it was built around its language, an agent writes the documents, and the controls for adjusting a design are generated from them. Its case corpus has not been built yet. On2Go is the brownfield case: an onboarding platform whose customisable language sits above an existing product and compiles to inputs that product already accepts, shown so far on test data. The full argument, with every source, is on the site.

Act 5: The brownfield path, layer by layer

Scene 19: onboarding

The brownfield journey starts where the customer's did, with onboarding. Every step of onboarding draws on the same domain invariants, which the language can represent once and share across the whole journey. Requirements would be stated in the domain's vocabulary, and the agent would write them as a document. The validator would check the configuration against the domain's rules before anything is applied. Customisation and training would draw on the same definitions, so each step works from one description of the domain rather than its own. The same onboarding document drives the data migration, and each failure cites the record and the rule that rejected it. The product itself is untouched, because the document compiles to inputs the product already accepts. For the provider, the knowledge a few specialists held is written into the grammar, and review moves from every attribute toward judging outputs. So far, only the migration step of onboarding has been demonstrated, on test data.

Scene 20: the interface

Next comes the interface, where the customer wanted the product personalised down to the individual user and operable by their own agents. With a grammar of what a screen can be, a screen becomes a document too: which entities it shows, which fields, in what order, with what validation, all checked against the domain's rules. Each tenant's layout, or one user's, is a variation of the screen's document, which the agent can write. In an existing product, the compiler emits those screens as source code at build time, reviewed and deployed through the normal pipeline, so each variation is a build. Composing the interface at run time, per user, needs a platform that accepts a desired-state description, which usually means new platform work. For the provider, there is a fixed cost to build the grammar and the compiler, then a cost per screen that falls as converted screens become worked examples, with close review of the first ones. The evidence supports converting screens at a faster rate, with review still needed. The same language is what a customer's own agent needs to operate the product in the domain's terms.

Scene 21: business rules and invariants

Then the business rules, which a brownfield programme reaches later, if at all. The language expresses each customer's rules in the domain's own terms, over the invariants: which entities exist, how they relate, and which workflows govern them. A customer's variation becomes that customer's own business rules, checked against the invariants, and the shared code stays as it is. The existing APIs may not offer the granularity the language needs, but they already cover a large part of the domain. Deciding what becomes an invariant is architectural judgement.

Scene 22: the deep layers

At the bottom of the stack, the deep layers stay where they are. Few customers' needs reach the deep layers, and those that do carry the most risk. In a brownfield product, the data model, the database and the infrastructure stay shared and unchanged, and an agent working in the language cannot reach them. The needs that do reach this far are handled case by case, and the site sets out how. Where a company already plans to rebuild the layer that applies configuration, that rebuild is the place to design the lower line in, and there the greenfield path begins.

Scene 23: the bill

The journey ends, as it did before, with the bill. The customer's domain document is, in effect, a bill of materials: the capabilities this implementation uses, and how they are put together. The price can follow the customer's document, the way modular physical products are priced: a price for each capability used, plus the work of assembling them for this customer. Packages for common scenarios, priced on their value, sit beside the components. Because the price is computed from the same document the compiler validates, the quote and the implementation cannot drift apart. Assembly becomes a visible, priced service.