TOGAF, applied for real. When the method is load-bearing, not decoration.
An agentic invoice-and-certificate audit platform was designed and built solo, inside a 48-hour technical capability window — governed end to end by one tailored pass through the TOGAF 10 Architecture Development Method. This page is the method’s own audit trail: what TOGAF is, why it fits a build this fast and this money-adjacent, exactly how each phase was used — and, most persuasively, the three places it caught the architect being wrong.
A method for making architecture decisions on the record
TOGAF — The Open Group Architecture Framework, currently the TOGAF Standard, 10th Edition — is the most widely used enterprise-architecture framework in the world. Its core is the Architecture Development Method (ADM): a cycle of phases that runs from establishing principles (Preliminary), through vision, business, information-systems and technology architectures (A–D), into planning and delivering the change (E–F), and then — the part most adopters skip — governing what was built against what was promised (G) and deciding when change is big enough to demand a new cycle (H). Requirements management sits at the hub, feeding every phase continuously rather than running once at the start.
Stripped of its ceremony, TOGAF is three habits with names: write principles you are willing to be constrained by, trace every requirement to evidence, and treat deviation as a governed decision rather than drift. Everything else — the artifacts, the compliance ladder, the architecture contract — exists to make those three habits checkable by someone who was not in the room.
One pass around the wheel, with receipts
Every phase below was actually executed and produced a real artifact — the drawer for each shows what the standard asks, what this project produced (with verified counts), and the receipt: something that phase enforced or caught. The hub is deliberately amber: requirements management never stops.
Three reasons, and one objection answered
The system moves money
An AI platform that audits payment certificates must produce decisions that survive an adjudicator months later. That demands exactly what TOGAF industrialises: principles you can point at, a record of every consequential decision, and a governed line between what was promised and what was built. The prime directive — no model output ever sets a monetary verdict — is principle P01, and its breach is defined as a build failure and a new cycle, not a conversation.
A solo build needs an adversary
Forty-eight hours, one architect, no review board. The classic failure mode is believing your own documentation. The ADM supplies the adversary: a gap register re-run against the code, conformance criteria that can fail, reversal triggers written into decisions before the evidence arrives. Used this way, the method is not paperwork — it is the only reviewer available at 3 a.m.
Honesty needs a vocabulary
“Production-shaped, not production-deployed” is only a defensible claim if something enumerates the difference. TOGAF's gap analysis, transition architectures and compliance ladder give the honest claims somewhere structured to live — 58 recorded gaps, three transition states, and a compliance checklist that admits which checks are mechanical and which are judgement.
Fifteen principles, five of them absolute — click any
Precedence is by number: the lower principle wins a conflict. P01–P05 are integrity principles and are absolute — a change that violates one requires a new ADM cycle rather than a waiver. The test of a principle is whether it ever costs anything; the drawers name what each one changed or forbade.
The day the topology changed: ten services to eleven
Mid-implementation, the vector-store decision (ADR-004, pgvector) was reversed by its own written trigger, adding a dedicated vector database — and colliding with a baseline that said “exactly ten services” was a submission blocker. What happened next is the whole argument for Phase G and H existing. Click each step.
Every phase, with its artifact, its numbers and its receipt
Use the tabs or [ ]. Each panel is drawn from that phase's actual document: what the standard asks the phase to do, what this engagement produced — with counts re-verified on the day of writing — and a visual cut of the phase's own material.
What one governed pass actually produced
The honest edges, stated before anyone finds them
One pass, not a programme
One pass through capability and architecture-development iteration; transition planning compressed; the governance iteration is defined but unexercised. The compliance review is assessed once, before freeze — not continuously.
Target levels, not assessed outcomes
The 30-check compliance checklist records verification method and target conformance level per check. It is a real pass/fail instrument with a stop rule — but the recorded result-set of a full assessment is not in the document, and the document says so.
Tests prove following, not rightness
The strongest self-limitation in the governance file is its own closing risk: “Tests prove that the architecture was followed; they cannot prove it was right.” The eval harness and the seeded scenarios exist precisely because that sentence is true.