Skip to main content

The Inception Cycle

In one line: For a new project or a new bounded context, establish a lightweight architecture baseline — inception canvas → quality-attribute scenarios → risk-storming (with a security lens) → trust-boundary threat enumeration → fitness functions — with recorded owner review and check evidence before the first feature's full cycle begins.

Do this: Establish the load-bearing structure, quality goals and trust boundaries before the first feature fixes them by accident. Keep the five artifacts proportionate to uncertainty and risk; feature cycles reuse their selected baseline. A material change triggers targeted impact review, not an automatic rewrite of every artifact or already-authorized task.

When it fires (the trigger). The Inception Cycle applies to a new project or new bounded context / major subsystem — a new top-level domain module, external-integration class or data-trust boundary. Ordinary features within unchanged boundaries reuse inception results. The trigger is human-assessed; an absent artifact is detectable only when a reviewer or configured check examines the applicable scope. Revisit affected assumptions, scenarios and boundaries when they materially change.

The five artifacts (templates in templates/; full reference: appendix-o-inception.md):

  1. Architecture Inception Canvas (inception-canvas.md) — the arc42 one-pager: business case, functional overview, ranked quality goals, architecture hypotheses, technical risks, business context, constraints. "As lean as architecture documentation can ever get"; it transitions to fuller arc42 docs only when the system earns them.
  2. Quality-Attribute Scenarios (qa-scenario.md) — at least three prioritized six-part scenarios (source → stimulus → artifact → environment → response → measurable response measure). The measure is what makes the scenario testable and what a fitness function later asserts.
  3. Risk-storming over a C4-level-1/2 diagram, with a security lens — each participant records risks near the affected area, then the group reviews disagreements and risks others missed. Use the security lens to identify candidate trust boundaries for artifact 4; record coverage gaps. This lightweight reference exercise is not a complete ATAM assessment.
  4. Trust-boundary threat enumeration (threat-enumeration.md) — for new data-trust-boundary contexts: where data crosses trust boundaries and the STRIDE category + mitigation per boundary. This is the per-system threat model — distinct from §15 (which secures the AI collaborator) and from the per-change safety Brainstorm-Gate trigger.
  5. Fitness functions (tests/fitness/) — at least one executable check for a quality goal or hypothesis. Verify actual invocation, nonempty case selection, caught violations and allowed behavior. If admitted as a blocking gate under §7, assess its cost, required-check configuration and retirement condition; a test file alone is not enforcement.

The presence floor is a review obligation, not a shipped detector. Before the first feature of a new bounded context dispatches: the canvas exists, at least three scenarios exist, a risk-storm artifact exists, a threat enumeration exists where applicable, and at least one fitness test exists. The kit supplies templates, not a generic automated presence gate. Record applicability, owner review, selected revisions and actual fitness evidence. Existence does not establish completeness or correct meaning; apply §3.1's scrutiny criteria and preserve unresolved mandatory gaps. An adopter may configure a tested detector without claiming that it proves substance.

Composition with Product-Scale Planning (§5.6). Initial inception precedes and feeds product-scale planning: quality scenarios and fitness functions inform cross-consistency review, and threat enumeration informs the necessary design decisions. A single-milestone context need not run the product-scale procedure. Later discoveries can revise the affected baseline through owner review; coordinate dependent work and preserve its pinned inputs rather than assuming the first architecture remains current forever.

Governance (RFD-style). Keep decision artifacts proportionate, within explicit delegated authority. A team may adopt a time-boxed objection process for already-delegated, low-risk engineering choices. Silence never supplies approval for changed business meaning, access, safety or release. Interface-affecting or controversial decisions require the applicable owner review and an exact recorded outcome; a 72-hour/one-week timer cannot replace that grant. The canvas and scenarios remain the inception floor, with substantive design review under §3.1.

Why: Early, reviewable quality goals and boundaries make structural assumptions visible before implementation spreads them. The intended benefit is less avoidable rework and clearer evidence, not a guaranteed outcome from a fixed workshop duration. Keep the initial pass lean and revise the affected parts when observations challenge it.