Act 4: Implementation

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.