Thirteen steps, three go/no-go decisions, one feedback loop that runs forever. This is Compliance by Construction implemented from a standing start — no pattern library, no central approval workflow, no air cover. Expand each step.
Know where decisions actually happen, and what "before" looks like. You publish nothing in this phase.
Two weeks of structured listening. Interview the people who make or break architecture decisions today: delivery leads, the CIO/CTO layer, risk, the PMO — and the five or six senior engineers everyone consults before building anything. The org chart tells you who signs. This tells you who decides. The gap between those two is the diagnosis.
Stakeholder, role, domains influenced. Formal authority versus observed authority. Decision venues — where designs really get shaped, which is rarely the review board. Recurring frictions named unprompted (these seed the standards candidates). Artifacts referenced (these seed the bootstrapper's ingestion list). Deliberately absent: any field for disposition, alliance, or sentiment. You need to know the politics; the schema must have nowhere to write them down.
Exit: every architecture-significant decision type has a named real decider, and you've heard about three candidate bleeding programs from two independent sources each.
Forensics, not opinion. Pull the last ten significant solution designs — however informal, wherever they live. Reconstruct each one's timeline: when design started, when it was submitted to whatever passes for review, when it was approved, how many rework cycles it took, and which production incidents trace back to decisions made in it. Without this, day 90 has nothing to compare against and your practice can never demonstrate value.
A design record per case: program, dates at each stage, venues it passed through, rework count with reasons, incident links, and the artifacts produced. The ten records aggregate into the baseline scorecard — median cycle time, review hours, rework rate — that every later claim is measured against.
Exit: a baseline nobody can dispute, built from their own records.
The organization already has patterns — they live in the systems and in the heads of senior engineers, not in a wiki. Walk the estate with those engineers and catalogue the five to eight shapes that repeat and demonstrably work. You are codifying what exists, not importing what doesn't. Aspirational patterns nobody recognizes get ignored; mined patterns carry their authors' credibility.
Pattern candidates: working name, the problem each solves, observed instances (which systems embody it), the engineers who built those instances (future co-authors), and the standards each pattern implies. Instance evidence matters — a pattern with three live implementations outranks an elegant one with zero.
Find one existing form, sign-off, or review stage that demonstrably adds no value — every organization has several — and remove it, publicly, with the owner's agreement. This is the credibility move: the new architecture leader subtracted friction before adding anything. It buys you the benefit of the doubt for everything that follows.
A review-step register: each step in the current gauntlet, its owner, its stated purpose, its observed value (from the step-2 forensics — did it ever change an outcome?), and a verdict. One entry gets executed now; the register becomes raw material for chartering decision rights in step 7.
The pilot program must be volunteered by its delivery lead — someone who heard what you're doing and asked for it — not conscripted by an executive. Conscripted pilots get sabotaged, politely. If nobody has volunteered, the answer is not to push; it's to keep censusing pain until the pull exists. No pull by day 30 is itself diagnostic data.
The smallest set of artifacts and decision rights that can support generation. The tool stays holstered.
The bootstrapper drafts pattern candidates from the mining evidence; humans curate them into the library. Every pattern is co-authored with the engineers whose systems it came from, and their names go on it. Authorship is the adoption strategy — people don't route around standards they wrote.
The pattern library proper (PAT-001…): problem, solution, use-when, the standards each pattern satisfies, named co-authors, and live instances as evidence. This is corpus v1's first half — written in the structure the generator consumes.
No organization has a pattern library; that's expected — the library is this step's output, not its input. But if the estate itself offers no repetition, drop the grain size: idioms repeat (integration, auth, deployment) even where architectures don't. Where discovery catalyzes a library from scratch, there is a side door: the industry seed library — a regulator-anchored reference corpus for your sector that enters as candidates with priors, never as adopted standards. The bootstrapper matches mined evidence against the seeds and localizes what fits; what doesn't match arrives marked provisional. The rule that keeps the side door honest: seed patterns earn permanent status only through local instance evidence or pilot survival. Cold-start libraries are still born in step 13 — the seed just means they're born faster.
Most organizations carry sixty standards and enforce none. You will carry at most fifteen, chosen by evidence: the bootstrapper ranks candidates by how often each was violated in the last ten designs and what those violations cost. Every standard gets a named owner and a stated reason — a regulatory anchor wherever one exists. A standard without an owner and a reason is a wish.
The standards corpus (STD-001…): normative statement (MUST/SHOULD), owner, reason, regulatory anchor, and the violation history that justified its selection. Corpus v1's second half.
A normative constraint on architectural design decisions — enforced at design time or through a formal exception. Not technical baselines (hardening guides, cipher suites, patch levels — those number in the hundreds and belong in platform policy-as-code, never on the board's agenda), and not conventions (naming, style — advisory, no exception process). One design standard fans out into dozens of baseline rules downstream; the standard governs the decision, the baseline governs the configuration. Ten to fifteen is per governance scope, not forever: as the practice federates, an enterprise core set grows domain extensions — payments, data, cloud — each carrying its own enforced set. Thin is load-bearing. Every standard costs an owner, evidence, and adjudication capacity; more standards than you can enforce is just the binder again.
The operating model on a page: one intake channel for design work, the design record standard (below), an explicit exception path, and — the part most charters omit — a list of what the review board does not review. The board adjudicates exceptions; it does not admire diagrams. Decisions do not float free in separate records: an architecture decision is one entry in the design record's embedded decision log — context, choice, pattern/standard anchor, alternatives rejected. What the charter defines is which decision types are architecturally significant and who owns each.
The decision-rights charter, the design record template, and the exception workflow states (surfaced → classified → mitigations proposed → adjudicated → time-boxed → reviewed). These become the workflow the generator's output routes through.
The typical enterprise solution blueprint is a forty-page ritual written after the decisions: boilerplate sections, dead diagrams, no traceability. The method replaces it with a design record defined as the generator's output contract. The template rule: every section is machine-generatable, machine-checkable, or a recorded human judgment — anything that is none of the three gets deleted. Summary, component architecture anchored to patterns and estate, embedded decision log, generated traceability matrix, exception register, third-party and regulatory touchpoints. Configuration detail lives in pipelines and baselines, never in the document. The document becomes a projection of structured data — which is why it can be born instead of written.
Corpus v1 goes into a git repository on whatever source-control platform the organization already runs — corpus-as-code: markdown and YAML, never a wiki. The mechanics come free: pull requests are the curation workflow, code-ownership maps each standard to its named owner as a merge requirement, automated checks validate corpus integrity, and version history becomes the deviation trajectory. The generation pipeline reads the repo directly. No announcement, no demo, no rollout. Then the retro-test: feed it the requirements from a historical design that caused real pain, and see whether it catches what actually hurt.
The corpus repository itself — patterns, standards, charter, estate inventory — plus the retro-test record: what the generator flagged versus what history shows went wrong. The delta is your tuning list.
Pass means the generated traceability would have flagged the violations that actually caused last year's incidents and rework. Fail means the corpus is missing the standards or patterns that mattered — tune and re-run. You do not approach an executive with a tool that can't catch yesterday's known failures.
One conversation with the sponsor: the baseline numbers, the volunteered pilot, the retro-test result. The ask is deliberately small — that the pilot program's designs route through the new intake. Not an enterprise mandate, not a budget line, not a transformation announcement. Small asks get granted; granted asks build the record that funds big ones.
The pre-read memo: baseline scorecard, pilot scope, the one ask, and the day-90 measurement commitment. Two pages. It becomes the template every subsequent expansion request follows.
One honest end-to-end demonstration on a live program. Published, misses included.
The pilot program's real requirements go through the real flow: grounded generation from corpus v1, standards traceability self-assessment, exceptions surfaced and classified before any human review. The architects on the program work with the output — correcting, extending, judging — which is the point: they move up-stack on a live program, visibly.
The run log: every generation, what was accepted, corrected, or overridden, and time-at-each-stage. Overrides are gold — each one is either a corpus defect or a judgment the method should never automate. The log tells you which.
The board receives the intake package with conformance pre-assembled as evidence and an agenda containing only the exceptions — each classified, with mitigation options and a recommended disposition. The three-hour design walkthrough dies here, in front of everyone, and nobody mourns it.
The intake package format (now the house style), minutes structured as decisions with owners and time-boxes, and the meeting's own metrics: decisions per hour, evidence disputed versus accepted. The board's before/after is part of the day-90 story.
The pilot's numbers against step 2's baseline: cycle time, review hours, rework, exceptions surfaced before review versus discovered in it. Published to the org including what the generator got wrong. One honestly reported miss buys more trust than ten claimed wins — and you will need that trust for the scale decision.
The day-90 scorecard, auto-derived from the run log and the baseline register. Nothing hand-assembled; the practice measures itself, which is itself the demonstration.
Each pilot exception gets a disposition: stale standard (update it), missing pattern (draft it), or genuine one-off (record it). Corpus v1.1 ships from that evidence. This is the loop that runs forever — the practice that stops doing this decays back into the binder it replaced.
The exception disposition log and the corpus changelog — the deviation trajectory over time. This trajectory is the single most fundable chart the practice will ever produce.
A decision memo to the sponsor, priced in people and patterns rather than licenses: scale to the next two programs, adjust the corpus and re-pilot, or stop and say why. All three are legitimate outcomes. A practice willing to recommend "stop" against its own evidence is the practice that gets believed when it recommends "scale."
Running beneath phases one and two. In development.
The diagnostic phases produce evidence — interview notes, review-board minutes, the last ten design documents, the sixty-page standards binder nobody reads. The bootstrapper ingests all of it and assembles corpus v0: de facto patterns extracted from real designs — matched against an industry seed library where one exists, so recognition beats cold extraction — standards candidates ranked by observed violation frequency and cost, and a draft estate inventory. Humans curate; the machine drafts. The generator's biggest adoption barrier — organizations with nothing codified — becomes the first stage of the same pipeline.
Political disposition. The instrument takes decision rights, frictions, and artifacts. Who is hostile, who is allied, and who feels threatened stays in the practitioner's head — by design, the schema has no field for it.
The cohort works through this playbook step by step — with the templates, the schemas, and the instrument behind it.
Join the Waitlist