The spec is executable
Because requirements are written as testable statements and scenarios, the build has a definition of done from the first minute. There is nothing to interpret.
How it works
How software gets built from a conversation, and stays right afterwards.
This page is for the person who will be asked "but how does it actually work?" Outline, the factory behind it, and the platform they both run on, explained without the marketing.
Architecture at a glance
Four stages, one platform underneath all of them.
The same two platforms serve the interview, the build and the running software. Nothing is translated between stages; the spec is the source of truth throughout.
What you say goes to Outline, Outline produces an approved spec, the factory builds and tests from it, and the application runs in your tenant. All three of Outline, the factory and the application query the same data and knowledge platforms through MCP, which is why the software knows what Outline knew and can act on it. A change is described to Outline and goes round again.
Intent to spec
Two models run the interview. One talks, one checks.
Outline's conversation is run by a fast model, so it can keep up with speech. Alongside it, a frontier model reads the whole transcript as it grows, looks for gaps and contradictions, and feeds corrections back into the conversation's context. Frontier models are better at spotting the hole in a spec; they are too slow to talk. So they don't. The split is what lets the interview feel like a conversation and still produce something rigorous.
What it draws on during the interview
| Source | How Outline uses it |
|---|---|
| Your data platform | When you name an entity, a field or a rule, Outline queries the live schema and data through the platform's MCP server and checks what you said against what is there. |
| Your knowledge base | Documents, prior interviews and expert corrections are retrieved so the spec reflects how the business actually works, not only how you remembered it in the moment. |
| Screen mock-ups | High-fidelity screens are generated as the conversation goes and shown to you for confirmation. Design decisions are captured as requirements, with your brand applied from a constitution file. |
What comes out
A specification folder, in Markdown, that any team can read and any agent can build from. Requirements use a structured shell with testable statements, acceptance scenarios in Given / When / Then form, and flows written with their exceptions. Coverage is checked against an established requirements standard so the obvious things are not missed. You own the folder.
Specification format
EARS statements, Gherkin scenarios, Cockburn-style flows, a Volere-style requirement shell, ISO/IEC/IEEE 29148 as the coverage model, serialised as a Spec Kit / Kiro shaped Markdown folder.
Spec to software
The factory builds what was approved, tests it against the spec, and a person signs it off.
The approved specification is the input to an agentic build pipeline. Agents plan the work from the spec, implement it against the platform's APIs and the app kit, and run the spec's own acceptance scenarios as tests. What fails goes back round. What passes is reviewed by an inmydata engineer before release. The pipeline is the same one we use to build our own products, and we measure every build for what was automatic and what needed a hand, then work on the hand.
The platform is already there
The application does not need its own data layer, auth, access control or knowledge retrieval. It gets them from the platform, through the same MCP interfaces Outline used during the interview.
The kit grows
Components, agents and patterns that pass review go into a shared kit. The factory reaches for them first on the next build. Early applications take days; later ones take less.
What a built application is
A web application with its own screens and agents, running on the platform. It reads live operational data through the data platform, retrieves knowledge and expert judgment through the knowledge platform, and acts: raising, approving, routing, reconciling, escalating. It is deployed to a tenant you control, in our cloud or yours.
Data platform
Live operational data, made queryable by software and by models.
The data platform connects to the systems your business already runs on: ERPs, SQL databases and the legacy systems that most AI tooling cannot reach. It presents them through a semantic layer that a model can understand and an application can query in under a second, with row-level security so that every query, human or agent, sees only what its user is allowed to see. It is exposed as an MCP server, so the same interface serves Outline during the interview, the factory during the build, and the finished application in production.
| Capability | What it means in practice |
|---|---|
| Real-time connectors | Change data capture agents and a site agent keep the platform current with the source systems without batch loads. |
| Semantic layer | Tables, fields and relationships carry business names and definitions, so a model asking for "overdue orders" gets the same answer your finance team would. |
| Sub-second queries | Aggregations over large datasets are served from a summarised store, so an agent can ask many questions in the course of one decision. |
| Row-level security | Access rules are applied at the platform, once, and inherited by every application and agent built on it. |
| Runs where you need it | Our cloud, your cloud, or a Windows or Linux server on your premises. |
Knowledge platform
The judgment your experts carry, captured and kept current.
Most of how a business runs is not in any system. It is in the people who know which customer always pays late, which exception is really a warning, and what "urgent" means on a Friday. The knowledge platform captures that through AI-led interviews with your experts and by ingesting the documents you already have, then keeps it in a knowledge base that is retrieved, not just stored.
It is the same machinery Outline uses to understand what to build, and the finished application uses it at run time to decide what a good answer looks like, so the judgment is in the software, not only in the spec. Like the data platform, it is exposed as an MCP server.
| Capability | What it means in practice |
|---|---|
| Expert interviews | An agent interviews your people, by voice, over as many sessions as it takes. It asks follow-ups, resolves contradictions and writes up what it learned for review. |
| Document ingestion | Policies, procedures, wikis and email threads are parsed and indexed alongside what the interviews captured. |
| Hybrid retrieval | Dense and keyword retrieval together, with re-ranking, so an agent gets the passage that answers the question and not the one that merely matches it. |
| A base that learns | Consolidation removes duplicates and contradictions. Gap detection finds what the base should know and doesn't, and asks. Expert corrections are fed back and take precedence. |
How software stays right
Change is the normal case, so the pipeline is built for it.
Three things change under any application: the business, the platform, and the models. The factory treats each as a routine event with a known path, not an incident.
| What changes | What happens |
|---|---|
| The business | You describe the change to Outline. The spec is updated, the delta is built, and the full acceptance suite runs before release, so a change to one requirement cannot quietly break another. |
| The platform | Security patches and platform releases are rolled out across every tenant we manage as a fleet. Each application's own tests run against the new version first. |
| The models | When a better or cheaper model is available, it is packaged and tested against each application's scenarios before it is switched. You get the improvement; you do not get a surprise. |
| Your schema | The data platform's semantic layer absorbs most schema change. Where an application is affected, the factory regenerates and retests the affected parts from the spec. |
| Your knowledge | Expert corrections and new documents flow into the knowledge base continuously, so the judgment in the running application improves without a release. |
This is the part of the model that makes "living software" more than a phrase. The specification is kept as the source of truth, the tests come from it, and anything that moves underneath is checked against it before it reaches you.
Why patching has to run without a personOpen source and security
Built in the open.
We are opening the platform the factory draws on: the data platform and the knowledge platform. You will be able to run them yourself, read the code, and leave with everything intact. What we charge for is the factory and keeping your software right.
Security and data
| Point | Detail |
|---|---|
| Access control | Row- and column-level security enforced at the platform and inherited by every application and agent. |
| Your data | You own it outright. It is deleted automatically shortly after termination. DPA terms are part of the standard terms. |
| Audit | Every query and agent action is logged. Logs are available on request. |
| Certifications | None yet. The platform has been built from the ground up with SOC 2 compliance as a design goal, and we will list certifications here when we hold them, not before. |
| Models | Your choice of provider where the platform allows it; usage billed to your own key where that is how a product works. |
Ask us the hard questions.
Bring your architect. Half an hour on your data, your security model and what the factory can and can't do for you yet.