Exercise 9: The Practice

What you are producing

The second-largest exercise — about 4.5 hours — and the one that most directly serves the goal of making architectural work something an organisation can run rather than something one person does.

Five artifacts for Lintel:

1. An ADR set capturing the significant decisions from Exercises 3–7, written retroactively
2. An HLD for the AI support platform
3. An architecture proposal in template form, ready to submit
4. A documentation structure serving both onboarding and retrieval
5. A process proposal — minimum governance for six months, with what you would delay

The first artifact is meant to be uncomfortable

You are recovering reasoning for decisions you made, a few weeks ago. Expect to find at least one whose justification you can no longer fully reconstruct. That discovery is the point of the exercise — if your own reasoning decays in weeks, nothing from three years ago survived at all.

Before you start

Gather your artifacts from Exercises 3–7: the style selection and roadmap, the AI stack selection, the agent design and its bounds, the unit-economics model and the evaluation plan — and Exercise 7’s defect list. The ADR set is a recovery exercise on that body of work.

You will also need Exercise 8’s organisational analysis and stakeholder influence map — the process proposal has to be sized for the organisation you actually read.

Artifact 1 — The ADR set

Roughly eight records, in the five-field template.

1. List the decisions. Work through Exercises 3–7 and write down every choice that constrained a later one. You should land near eight; fewer means you are recording outcomes rather than decisions.

2. Apply the granularity test to each. Does it constrain other decisions? Would someone reasonably propose the opposite in a year? Drop the ones that fail both, and note what you dropped — consistent granularity is a rubric item.

3. Write the context in the past tense of the time. The constraints as they were when you decided, not as they are now that you know more.

4. Write the consequences, negatives included. If a record has no negative consequences, you have not finished it. Two of your decisions have organisational negatives rather than technical ones — those count and they are the stronger entries.

5. Add the reversal condition to each: what would have to become true for this to be revisited.

6. Number them, set statuses, and chain any supersessions. At least one of your Exercise 7 defects should produce a superseding record rather than an edit to the original.

Include one honest “no rationale found”. The existing service boundaries are the natural candidate, and one reconstructed record about the extraction pattern as a whole is the right scope rather than twenty individual ones.

Artifact 2 — The HLD

Container level, and the rubric constraint is the hard part: readable by someone who has not read Modules 1–8.

What belongs

• Each container and its responsibility, in one sentence
• The boundaries, and what crosses them
• External dependencies and what they are relied on for
• The constraints that shape the whole system, stated without assumed context
• Pointers to the ADRs for every “why”

What does not

• Implementation detail — thresholds, caps, chunk sizes, cache durations
• The reasoning itself, which lives in the records
• Anything that will be stale in a month
• Any term this guide invented, unless defined in one line on first use

The test

Hand it to somebody technical who knows nothing about the project. Ask them to describe the system back to you. What they get wrong is what the document does not say.

If nobody is available, read it as a stranger and flag every sentence that assumes something — jargon, context, or a decision they have not seen.

State the owner and the revision trigger in the document. An HLD without them decays into the actively-misleading case, which is worse than not writing it.

Artifact 3 — The architecture proposal

The template, plus one filled instance.

Six fields: the problem in business terms, the options, the recommendation, what you are asking for, by when, and who decides. Exercise 8’s justification pack maps straight onto it.

Fill it for one real decision — the sensible choice is whatever your Exercise 7 defect list left unresolved, since that is a decision genuinely still open.

Artifact 4 — The documentation structure

Where each artifact lives, what triggers its revision, and what is published outward.

The rubric item to design for deliberately: the structure must let an agent retrieve a specific decision’s rationale. Demonstrate it rather than asserting it —

• Name one decision, and trace how a fragment about it would be found.
• Show that the fragment is interpretable alone: does its context section carry the constraint that makes it make sense?
• Say how stale content is filtered. Every document needs a status for this to work at all.
• Name the redundancy you are paying for on purpose — which constraint is repeated, where, and why that is worth it.

Artifact 5 — The process proposal

Six months, sized for roughly 140 engineers with no existing practice and no mandate.

1. Months 1–2: what you do yourself, requiring nobody’s permission.

2. Months 3–4: what you offer, with worked examples.

3. Months 5–6: the one expectation and the one standard you would introduce. The standard should remove a boring choice, not an interesting one.

4. The deferrals, each with a reason about sequence and size rather than value. Name at least four.

5. The review criteria, enumerated explicitly — without that, review cannot be distributed to anyone.

6. The capacity argument. Run the arithmetic for eighteen teams and apply the generation multiplier. Your conclusion should name what the numbers justify and what they do not.

Include the culturally specific adjustment. Exercise 8’s antipattern assessment of how failure is handled here should change what you introduce in the first six months, and saying so explicitly is the difference between a process proposal and a generic one.

Rubric

Six items:

1. Consequences, including negativesEvery ADR states them. A record with only benefits is a sales document.

2. Consistent granularityNo mix of trivial and civilisation-scale decisions in one set.

3. The HLD reads from coldSomeone who has not read Modules 1–8 can use it.

4. Retrievable rationaleThe structure would let an agent find a specific decision's reasoning.

5. Sized for 140, not an enterpriseThe process proposal fits the organisation you actually read.

6. Something is deferred, with a reasonExplicitly named, and the reason is about sequence rather than value.

Self-check

Before you call it done:

• Does any ADR have an empty or all-positive consequences section?
• Did you drop any decisions on granularity grounds, and can you say which?
• Is there at least one superseding record rather than an edited one?
• Does the HLD contain a number that will be wrong in a month?
• Does the HLD name its owner and its revision trigger?
• Can you trace one decision’s rationale through your documentation structure, end to end?
• Does your process proposal name at least four deferrals with reasons?
• Does the capacity arithmetic appear, and does it change any of your governance conclusions?
• Is there one honest “no rationale found” in the set?
• Which of these five artifacts would still be maintained a year after you left? The honest answer tells you which parts of the practice are real and which are only yours.

Check your understanding

Return to the three questions from the start of the module.

1. Name a decision in a system you know whose reasoning exists only in someone’s head. What happens when they leave?
2. When did you last read documentation that was wrong? What did it cost, and would no documentation have been better?
3. If an agent had to find out why a boundary in your system exists, where would it look?

And one more, now that the practice exists.

4. Module 10 is about architecture evolution in the real world — migration, legacy, and decisions taken under constraints nobody chose. Which record in your set do you expect it to supersede first?

---

→ The practice exists. Last, the system’s evolution — and assembling everything into one portfolio. — Exercise 10, after reading Handbook Module 10.