We ship engineers, not software

Every company evaluating AI has heard a version of this story, and many have lived it. The pilot started with real enthusiasm. Licences were bought, a channel was set up, someone ran a lunch-and-learn. Six weeks later the tool sits open in four browser tabs, answering generic questions generically, and the executive who sponsored it has quietly stopped mentioning it. The software worked. The deployment never happened.

The post-mortem, when anyone writes one, lands on the same finding every time: the hard part was left to the customer. Somebody at the company was supposed to gather the SOPs, decide which documents were current, work out who should see what, connect the systems, and teach thirty colleagues what to ask. That somebody had a full-time job already. Enterprise AI's graveyard is full of self-serve deployments that assumed the customer would do the grounding work, and the customer, reasonably, did not. The models in those graves were fine.

The work the product cannot see

The uncomfortable truth about grounded AI is that the decisive work happens before first login, and none of it is visible in the product. Which of four pipeline spreadsheets is real. Which version of the onboarding playbook is current. Who is actually allowed to approve a supplier payment, as opposed to who the three-year-old policy document says. What the company means by the dozen abbreviations everyone uses and nobody defines.

Self-serve pricing pages have a quiet asterisk over all of it. Somewhere between "sign up" and "value", the customer is expected to assemble a clean corpus, adjudicate which documents are current, design a permission model, integrate the systems, and then win the adoption battle across thirty busy colleagues. Each of those is a project. Stacked together they are a programme, and the vendor's involvement in the programme is a help-centre article.

No wizard extracts this. It surfaces in conversation, usually sideways, when an engineer asks a question and two directors give different answers. A vendor who ships software and a setup guide has structurally declared this work to be someone else's problem. We built ARX on the opposite declaration.

What forward-deployed means at Imperium

The engineers who build ARX are the engineers who deploy it. Not an implementation partner working from a certification, not a customer-success team working from a script: the people who designed the Company Ontology's object model are the people sitting with your leadership team, asking which numbers you trust, on site when the work calls for it.

We call this the Forward-Deployed Engagement, and it means Imperium does the grounding work itself. Our engineers model the ontology, seed the Knowledge Fabric, wire the connections to your business systems, write the capability policy, and provision every seat. The first time an employee opens ARX, they land in a workspace that already knows who they are, what their department does, and which systems hold their numbers. The setup burden on each employee is minutes; the setup burden on the company's own staff is close to nothing, because we carried it.

The five phases

The engagement runs in five phases, and the sequence is deliberate: each phase produces the ground the next one stands on.

The five phases, in order, are in the figure below.

Modeling comes first: leadership sessions that produce version one of the Company Ontology, including the unwritten facts no document records. Then seeding, in which SOPs, playbooks, templates and department context are assembled and structured into the Knowledge Fabric, so the company tier is grounded from day one. Wiring follows: the company's real systems are connected and the capability policy is written, down to argument-level rules about who may send what, to whom, within which bounds. Provisioning closes the setup: branded builds are issued and each employee receives a single-use credential that redeems into exactly one seat.

Being on site matters for a reason that has nothing to do with engineering. Adoption is a cultural problem before it is a technical one, and department heads extend trust to people faster than they extend it to software. When the person who modelled your ontology walks the sales floor asking what broke this week, the system stops being "the AI tool" and starts being infrastructure with a phone number. We have watched that shift happen in the first fortnight of an engagement, and no onboarding video has ever produced it.

Phase five is evolution, and it deserves its own paragraph, because it is the phase most vendors would label "support" and quietly staff with a ticket queue. The ontology and the policy are living objects. Companies reorganise, rename products, win clients, lose a department head, adopt a new system. Each of those events is an edit to the model of the company, and the engagement is how those edits keep happening, with history, indefinitely. When our engineers revise your ontology in month nine, nothing has gone wrong. The system is tracking the company, which is what it was designed to do.

The part that does not scale

An investor will notice what this model costs. Engineers on site do not scale the way a signup page scales, and we will not pretend otherwise. At our stage, we consider that a feature of the strategy rather than a flaw in it.

The reasoning is straightforward once you name what actually compounds. A self-serve product accumulates users. A forward-deployed one accumulates understanding: each deployment leaves behind an accurate, versioned model of a real company, a seeded knowledge fabric, a policy that mirrors how that company actually governs itself, and a working relationship with the people who run it. Depth per customer is the asset. It is also the moat, because a competitor can copy a feature list in a quarter, and cannot copy two hundred hours of sitting with your leadership team deciding which numbers are true. The self-serve version of ARX would be ARX without its grounding, which is to say, the product from the graveyard story at the top of this essay. We do not offer one.

Scaling, when it comes, will come from making our own engineers dramatically more productive per engagement, and the arrival of Fable 5.1 in ARX moved that number for us the same week it moved it for our customers. What we will not do is move the grounding work back across the table to the customer. That trade is how the industry got its graveyard.

Accountability has a face

There is a last reason to ship engineers, and it is the one security teams tend to appreciate most. ARX's public documentation makes specific promises: policy is enforced in four independent layers, evidence flows from a gateway rather than from the model's own narration, the customer's content stays in the customer-resident data plane while policy flows down and evidence flows up.

The figure below shows the three planes and which way each flow runs.

A promise in documentation is worth exactly as much as your ability to hold someone to it. When the team that designed the governance also stands in your office, provisioned your seats, and answers when something looks wrong, the promises have a face. That is the standard we think grounded AI deserves, and it is the one we hold ourselves to.

If your company is weighing this class of system, start with what an ontology is and why it comes first, then the ARX page for the whole picture.