Governed delivery · executable evidence · institutional learning
A continuous operating model that connects signals, evidence, RFCs, accountable architectural decisions, living design, production readiness, runtime conformance, and durable organizational memory.
Primary system view
Each stage has an explicit decision question, artifact role, and exit condition. Backward movement is expected whenever evidence invalidates an assumption, design, or implementation.
Decision-artifact chain
The chain prevents one document from becoming an overloaded substitute for research, approval, architecture, implementation, and operations.
Explore whether the idea is worth developing.
Make claims, uncertainty, prototypes, and invalidation conditions visible.
Present a substantial proposal for cross-functional review.
Make the accountable architectural choice.
Preserve the decision, rationale, constraints, and consequences.
Maintain the living implementation truth.
Stage reference
Each stage can send work backward. Rework is routed to the failed assumption, decision, design, implementation, or operating model instead of being hidden inside delivery.
Detect material signals
Is there a material signal worth investigating?
Capture customer, operational, security, accessibility, policy, and platform signals before they are translated into solution requests.
A grounded observation with source, impact, owner, and enough materiality to justify framing.
Define the decision
What outcome or decision are we trying to reach?
Establish purpose, audience, scope, constraints, assumptions, uncertainty, reversibility, and success criteria.
A clear decision boundary and an explicit plan for resolving material uncertainty.
Challenge assumptions
Are the problem model and candidate directions supported by evidence?
Use research, co-design, accessibility participation, threat modeling, representative data, and interrogation prototypes to expose weak assumptions.
Known facts, assumptions, alternatives, invalidation conditions, and remaining uncertainty are visible.
Make the case
Should the organization adopt this substantial proposal?
Present the recommended approach, evidence, alternatives, trade-offs, migration, rollback, operational model, and required reviewers.
The proposal is decision-ready, with material feedback resolved or explicitly preserved.
Commit with accountability
Which option are we committing to, under which constraints?
The accountable decision owner selects an option, defines guardrails, records rejected alternatives, and names reconsideration triggers.
A named, accountable choice exists. Approval ambiguity is removed.
Preserve the rationale
How do we preserve what was decided and why?
Create an immutable decision record that captures context, rationale, consequences, evidence boundary, risks, controls, and supersession links.
The decision can be understood later without reconstructing the original discussion.
Define executable truth
How will the accepted decision work as a complete system?
Translate the decision into living architecture, versioned contracts, behavioral modes, accessibility requirements, operational design, and an evaluation plan.
The system is coherent, implementable, testable, operable, and traceable to the decision.
Implement with traceability
Are we building the accepted design with operational completeness?
Deliver thin vertical increments while keeping requirements, contracts, tests, telemetry, runbooks, and artifact-quality memory connected.
A production candidate exists with executable controls, tests, documentation, and ownership.
Validate in the real medium
Does the implementation satisfy the accepted decision under realistic conditions?
Validate Utility, Usability, Feel, and Trust alongside security, accessibility, resilience, contract, policy, performance, and AI evaluations.
Evidence demonstrates readiness, or failures route back to the correct stage.
Accept production responsibility
Is the system ready to operate safely and reversibly?
Complete the Operational Readiness Review, release manifest, migration, communication, support, rollback, and bounded exception records.
Production ownership, observability, support, recovery, and risk acceptance are explicit.
Observe actual behavior
Does the running system still conform to decisions and commitments?
Use SLOs, telemetry, policy logs, incidents, support feedback, cost, accessibility, model quality, and conformance checks as production evidence.
Operational evidence is visible and deviations have an explicit disposition.
Institutionalize learning
What should be repaired, standardized, or reconsidered?
Convert operating evidence into battle scars, regression fixtures, revised skills, craft-debt remediation, new RFCs, and superseding ADRs.
The product and the organization are measurably better prepared for the next cycle.
Two-speed governance
The full artifact chain is reserved for consequential changes. Routine work stays lightweight. Experiments remain bounded until evidence justifies production authority.
Routine
Established patterns, localized impact, and no material identity, rights, security, or compatibility consequences.
Signal → Brief → Design or contract change → Build → Standard validation → Release → Observe
Governed
Platform, cross-team, identity-sensitive, rights-sensitive, public, regulated, autonomous, or contract-breaking change.
Signal → RFD → Evidence → RFC → ADD → ADR → System Design → Build → ORR → Release → Learning Review
Experimental
Prototype authority is deliberately constrained. Production adoption requires an explicit transition into the governed route.
Signal → RFD → Experiment charter → Bounded prototype → Evaluation report → Stop | Iterate | RFC
Persistent rails
Facts, observations, assumptions, inferences, uncertainty, contradictory evidence, freshness, and source lineage.
Owners, commitments, constraints, dissent, review dates, waivers, dependencies, and supersession history.
Artifact profiles, battle scars, craft debt, failed fixtures, repeated corrections, and validated reusable patterns.
Source versions, build identity, generator version, validations, approvals, evidence boundaries, and released artifacts.
Shared quality language
Systems of record
Confluence preserves organizational context and decisions. Repositories preserve versioned, executable contracts and implementation truth.
| System | Primary responsibility | Representative artifacts |
|---|---|---|
| Confluence | Human lifecycle, review, decision history, ownership, and governance record. | RFDs, RFCs, ADR indexes, ORRs, waivers, learning reviews, review history. |
| Repository | Executable and versioned system truth close to implementation. | System Design, API/event/tool contracts, eval definitions, policy-as-code, tests, infrastructure, release manifests. |
| Operational platform | Runtime state and production evidence. | SLOs, dashboards, traces, policy decisions, cost, incidents, deployment status, conformance findings. |
| Quality memory | Cross-artifact learning and prevention of repeated failure. | Battle scars, craft debt, accessibility findings, regression fixtures, validated patterns. |
Canonical formulation
Sense a material signal. Frame it through a Brief or RFD. Interrogate assumptions. Propose through an RFC. Make the accountable ADD. Preserve it in an ADR. Shape living System Design and versioned contracts. Build with traceability. Prove in the real medium. Establish production responsibility through the ORR. Operate with visible conformance. Evolve through learning reviews, postmortems, and superseding decisions.