Skip to main content

0034: Replace Adoption Levels With Need-Triggered Capabilities

Status: Accepted

Date: 2026-07-22

Context​

STAGE's adoption guide described six numbered levels from Deliver through Scale. Its prose said adoption was incremental and optional, but the structure still implied an ordered maturity path and a terminal state. That conflicted with the normative Earned Infrastructure rule: persistent maps, diagnostics, operations, evidence, and product tools must solve an observed recurring cost, ownership risk, or named consumer need.

The detached visual-rehearsal trial exposed the practical failure. Once a multi-slice capability plan existed, implementing the remaining slices looked like progress even when the resulting contact sheets and external pages did not improve the owner's visual decisions. The useful path was direct production engine review; a project-native gallery remained valid only when it separately served a player, author, or recurring developer job.

This is not specific to visuals. A numbered adoption ladder can similarly cause projects to manufacture maps, agent APIs, test harnesses, receipts, or abstractions because the next level exists rather than because the project needs them.

Decision​

Treat the STAGE delivery loop as the baseline and present every persistent capability as a non-linear, need-triggered option.

  • Do not define project maturity by the number of STAGE artifacts or operations.
  • Do not describe a terminal state of full STAGE adoption.
  • For each optional capability, state the observed trigger and what must not be inferred from adding it.
  • Add capabilities in any order and remove them when their trigger disappears.
  • Keep dedicated agent operations optional. Existing project routes, editor state, repository inspection, logs, and manual operation may be sufficient.
  • Interpret Tool-Mediated as faithful use of authoritative project tools, not a requirement to build custom authoring or inspection surfaces. Interpret Agent-Operable as safe, legible delegated work, not one API per domain.
  • Keep visual captures optional transport for named consumers; direct native observation is the default for a co-located human reviewer.

Practitioner Kernel, mapped-project, operational, and evaluated-reference claims are independent descriptions. They are not cumulative product-quality or architectural-maturity grades.

Consequences​

  • Solo and small projects can use STAGE indefinitely through direct delivery without appearing incomplete.
  • Agents must justify persistent infrastructure from current project evidence, not a generic sequence.
  • Adoption guidance becomes a capability menu rather than a roadmap.
  • A project may be mapped without adding agent operations, or may add one valuable operation without first adopting a map.
  • Maintainers must test routing language for completionist interpretations, especially when introducing numbered slices or staged plans.

Evidence Boundary​

This decision is grounded in same-owner STAGE and Circussy workflow history and the rejected detached visual-rehearsal path. It is a design correction, not evidence that need-triggered adoption improves long-term productivity across independent teams.

Last updated on