Architecture handbook

An architecture is only useful if a reader can find the part that answers their question. This handbook uses the phases of the Architecture Development Method (ADM) from The Open Group’s TOGAF Standard because many architects already navigate by them. It describes the platform as it stands; it is not a TOGAF deliverable and makes no claim of TOGAF conformance.

How the delivery process relates to the ADM

The platform also runs a delivery process for each bounded piece of work: DEFINE, GENERATE, VERIFY and DEPLOY. That process is not a renamed ADM, and the two do not map one to one. The ADM describes the architecture as a whole and how it changes; the delivery process is the engine inside it that turns one requirement set into evidenced software. DEFINE draws on the thinking of phases A to D for a single piece of work. GENERATE, VERIFY and DEPLOY run under the governance of phase G. What is learned afterwards feeds phase H.

Preliminary

What rules guide the work, and who owns them?

The rules are written down, and each is backed by a mechanism rather than an instruction. “Tooling first” means documentation, then existing tools, then new code; generators are the source of truth and their output is never edited by hand. “Language by runtime” places each capability in the language of the place it runs. “No autonomous deletion” means records classed as orphaned or duplicate are removed only with a documented cause and a named person’s approval. A standards ledger moves each rule from defined, to adopted, to enforced, one scope at a time, so a new rule does not break work already in flight.

The product owner owns the rules. A decision codex records the reasoning behind past decisions, so routine choices follow the same judgement and only real decisions come back to a person.

Requirements Management

How do we know the output matches the agreed need?

Requirements management is at the centre of the ADM and at the centre here. A piece of work leaves DEFINE only when its requirements are specific and testable. At each later exit one more term must hold for every requirement: at GENERATE, code exists for it; at VERIFY, a passing test names it; at DEPLOY, documentation names it too. A requirement marked complete that no passing test references is reported as unevidenced, and the exit is refused. The evidence outranks the declaration in both directions.

A: Architecture Vision

Why change the delivery organisation?

Because generating code faster does not fix what limits a software business: unclear requirements, knowledge held by a few people, and releases nobody can reconstruct. The vision is an AI Operating Model in which people and agents each do the work they suit, under controls built into the process, with progress measured from evidence. A programme owns that vision and measures its efficacy on two dimensions: what was delivered, read from phase transitions, gates and merged code; and what it was worth, read from the financial ledger.

B: Business Architecture

What work do people and agents each own?

People set direction and hold the reserved decisions: committing to build, accepting risk above appetite, signing external commitments, approving destructive operations, and ruling on product questions. Agents do the defined work between those points. Each reserved decision is a named touchpoint in the process, not a general expectation of oversight, so it is clear when the agent must stop and ask.

C: Information Systems Architecture

How are application and business knowledge represented?

Knowledge lives where every session can read it. Catalogues of the data model, business rules, codebase, services and processes are regenerated from the estate itself and checked for freshness before any change is pushed. An artefact registry declares, for each artefact type, the checks it must pass. A shared memory holds dated rulings and lessons, so a session starts with what earlier sessions learned.

Each capability is written in the language of the place it runs: Java inside the ERP, TypeScript for point-of-sale and mobile, JavaScript for the web interface, Python for tooling, and Astro for these sites. The rule stops logic leaking into a parallel implementation that the application cannot call.

D: Technology Architecture

How is the shared environment run and isolated?

One workstream runs on one cloud machine, created and destroyed by tool. No machine holds a key to another; everything they exchange passes through version control, where each machine publishes its state and claims shared work atomically. Every machine pulls the framework every half hour, so a fix committed once reaches the whole fleet.

The product’s own AI is configured, not coded. Each purpose, such as document extraction or chat, has an ordered cascade of models with confidence thresholds, and every call is logged with its tokens and estimated cost. Models are switched by configuration, and a choice is measured first: on 130 internal questions, the chosen model scored 99% against 89% at about a third of the cost per question.

E: Opportunities and Solutions

Which opportunities merit a controlled commitment?

Ideas are captured as proposals before anyone commits to build them, and a proposal becomes funded work only by an explicit ruling from a named person. Before design, an architectural synthesis draws evidence from several sources into one position, so a design starts from what is known rather than from the first plausible answer.

F: Migration Planning

How do existing applications enter the model?

Established code is brought under the same governance as new work, with its specifications and test harnesses, rather than rewritten. Migration of the estate is treated as convergence: every instance moves to the newest release held in version control, never to an intermediate snapshot, and any local divergence is preserved before the instance is advanced.

G: Implementation Governance

What prevents unevidenced changes progressing?

Controls act at three points. Runtime hooks act on every agent action: direct database writes, hand edits to generated files and unsafe shell commands are refused, and the refusal names the sanctioned route. Commit and push gates act on every change. Phase gates act on every exit, some of them judged by a second model reviewing plans and documents. The platform report counts 42 runtime hooks and 126 pre-commit gates, and the records hold more than 18,000 recorded gate runs.

H: Architecture Change Management

How does experience improve the system?

Every friction point found in any session becomes a queued item, claimed atomically, fixed with a test that fails before the fix and passes after it, and closed by the commit that carries the fix. A nightly digest reports what opened and what closed. The tool estate stands at 1,841 registered tools, each reviewed against written standards. The honest limit: the queue currently grows faster than it drains.

Where the evidence stops

Every count on this page comes from the platform’s own records. None has been independently reviewed, and none is a measure of productivity. The architecture is described as it stands in September 2026; parts of it, such as live coordination between sessions on different machines, are planned rather than built.

Applying it elsewhere

The phases are a reading order, not a prerequisite. An organisation can start with requirements management and implementation governance alone: make requirements testable, enforce a small set of rules where the agent acts, and refuse progress without evidence. The other phases become worth the effort once those hold.