Appendix O — The Inception Cycle (reference)
The full reference for §3.6 The Inception Cycle: the five artifacts, the presence-floor gate, and a worked fitness-function example. Templates live in
templates/(inception-canvas.md,qa-scenario.md,threat-enumeration.md).
When to run it
The Inception Cycle fires for 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 (§3.6). Ordinary features within unchanged boundaries reuse that baseline; they do not repeat the full inception exercise. The initial pass precedes the first feature's full cycle and feeds Product-Scale Planning (§5.6) where applicable. A material change to assumptions, quality goals or trust/integration boundaries triggers review of the affected artifacts and checks. Record the revised baseline and its approval; do not silently apply it to already-authorized work.
The five artifacts
1. Architecture Inception Canvas (inception-canvas.md)
The arc42 one-pager. Eight blocks: business case, functional overview, ranked quality goals, architecture hypotheses, technical risks, business context, organisational constraints, technical constraints. The point is leanness — it is the floor, not a design document. 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 makes the expected outcome testable. Identify the scenario owner, workload and measurement scope; proposed values remain hypotheses until accepted. A measurable sentence alone is not an executed fitness check.
3. Risk-storming (with a security lens)
A collaborative pass over a C4 level-1/level-2 diagram: each participant silently records risks on the diagram near the affected area, then the group reviews — concentrating on risks only one person saw, or where priority is disputed. The security lens is deliberate: it surfaces the trust boundaries that become artifact 4. Risk-storming is the lightweight stand-in for a larger architecture evaluation in this reference workflow, not evidence that a complete ATAM assessment has been performed.
4. Trust-boundary threat enumeration (threat-enumeration.md)
The per-system threat model, required for new data-trust-boundary contexts: where data crosses trust boundaries, and the STRIDE category + mitigation per boundary. Distinct from §15 (which secures the AI collaborator) and from the per-change safety Brainstorm-Gate trigger (§3.1). It answers "what can go wrong at each boundary in this system" at inception and after relevant changes. Record unknown boundaries and mitigation evidence; drawing a boundary or naming a mitigation does not prove coverage or implementation.
5. Fitness functions (tests/fitness/)
At least one executable check that encodes a quality goal or hypothesis as an automated test in the selected runner. A file in this directory does not run or block anything by itself. Record the actual invocation, selected/executed cases, candidate/environment and result. If admitted as a blocking gate under §7, verify the job and effective required-check policy, its measured cost and its retirement condition. Demonstrate a caught violation and an allowed case; scope the claim to the property and paths actually exercised.
The gate is a presence floor
Before the first feature of a new bounded context dispatches: the canvas exists, ≥3 scenarios exist, a risk-storm artifact exists, a threat enumeration exists (for trust-boundary contexts), and ≥1 fitness test exists. This kit supplies templates and this review procedure, not a generic inception-presence detector. The responsible reviewer records applicability and missing artifacts; an adopter may add a tested discovery/presence check, with its coverage and limitations.
Existence does not establish completeness, correct business meaning or effective mitigation. Apply §3.1's scrutiny criteria, resolve accountable owners and record the reviewed revision and outstanding gaps. Run the selected fitness checks and keep failed/unassessed mandatory evidence visible. Review adds evidence; it cannot guarantee architectural quality or grant missing business/release authority.
Worked example — a fitness function from a quality scenario
A QA scenario:
QA-2 — tenant isolation [high]: an authenticated user of tenant A submits a query (stimulus) to the data-access layer (artifact) under normal load (environment); the system returns results (response); response measure: zero rows from any tenant ≠ A, asserted on every query path.
Implement tests/fitness/test_tenant_isolation.py against a declared path inventory and real migrated database. The former all(...) example could pass on empty rows or collect no paths; it did not establish the claimed coverage.
Seed identifiable records for both tenants; use the effective runtime connection role. Assert expected own-tenant records, forbidden cross-tenant reads/writes and absent/malformed-context behaviour. Check the inventory against actual entry points: a path omitted from the inventory is not covered by parametrization. Unknown paths, unavailable database or zero executed cases are unassessed/failure, not a passing invariant. Protect the required CI selection from accidental deselection and test a deliberately broken isolation case.