Skip to main content

The Inception Cycle

In one line: For a new project or a new bounded context, run one lightweight architecture pass — inception canvas → quality-attribute scenarios → risk-storming (with a security lens) → trust-boundary threat enumeration → fitness functions — gated on the artifacts' presence, before the first feature's full cycle begins.

Do this: When you start a new system or a new bounded context, do not let architecture emerge from the first feature's brainstorm. Spend roughly half a day producing five lightweight artifacts that de-risk structure, NFRs, and security up front — then the feature cycles inherit them.

When it fires (the trigger). The Inception Cycle applies to: a new project; or a new bounded context / major subsystem — a new top-level domain module, a new external-integration class, or a new data-trust boundary. Ordinary features never trigger it. Like the Brainstorm Gate, the trigger is human-asserted; a missed trigger is detectable because the artifacts are absent.

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 silently records risks, places them on the diagram near the affected area, then the group reviews (focusing on risks only one person spotted, or where priority is disputed). The security lens surfaces the trust boundaries that feed artifact 4. It is the lightweight stand-in for a heavyweight ATAM session.
  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 that encodes a quality goal or hypothesis as an automated, commit-time test. This is the one artifact that self-enforces; it admits as a gate under §7 (cost ≈ seconds of CI; mechanism = required CI check; retirement = when its scenario is removed or superseded).

The gate is a presence floor, not a completeness check. 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 (for trust-boundary contexts), and at least one fitness test exists. Substance is not machine-gated here — it rests on the §3.1 second-party-scrutiny threshold, exactly as a design does. The presence floor stops "we skipped architecture entirely"; second-party review stops "we did it perfunctorily."

Composition with Product-Scale Planning (§5.6). For a product-scale (multi-milestone) new project, the Inception Cycle runs once, up front, and feeds §5.6: its quality-attribute scenarios and fitness functions become inputs to §5.6's cross-consistency review, and its threat enumeration informs the gating ADR set. A single-milestone new bounded context runs the Inception Cycle alone. The two never race — inception precedes and supplies planning.

Governance (RFD-style). Inception is not a heavyweight design doc for every decision. Act without a formal artifact when the §2.2 empowerment conditions hold; reserve a numbered, PR-discussed design doc for interface-affecting or controversial decisions, with a lazy-consensus time-box (a 72-hour solo checkpoint, or one week). The canvas and scenarios are the floor; a full design artifact (§3.1) is for the decisions that earn one.

Why: Architecture-by-first-feature-accretion is how NFRs and trust boundaries go ungated — discovered in production, not at design time. For a safety-critical or payments system that is a real hazard. A half-day of lean artifacts, gated on presence and scrutinized by a second party, converts "did we think about structure, NFRs, and threats at all" from hope into a checkable floor — without the big-design-up-front tax that the retired Plan Walkthrough proved nobody completes under throughput pressure.