RFCs should not end in “approved.” They should end in architecture that can be operated, measured, and challenged by evidence.
The durable unit is not the page. It is the decision lifecycle.
Platform AI / Decision governance
Turn technical debate into decisions that ship.
Move from uncertainty to an accountable decision, then prove readiness and validate the result in production.
ExploreProveDecideRun
HOW IT WORKS
The full decision loop, revealed when you need it.
Tap a stage or reasoning principle to understand its purpose, SDLC placement, template, and next step.
DecisionOS
Explore → Prove → Decide → Run
One accountable approverReview informs the decision without turning every participant into a veto point.
Evidence before commitmentArchitecture, AI quality, risk, latency, and cost claims remain testable.
Readiness before releaseApproval does not substitute for ownership, observability, recovery, and support.
Conformance after launchTests, policy, telemetry, and exceptions keep implementation aligned over time.
Documents are not the product.
The product is a repeatable path from uncertainty to an accountable, testable, operational decision.
Triage the decision
Assess reversibility, blast radius, affected contracts, risk, and the required artifact tier.
OUTPUT → decision class + approverExplore the space
Use an RFD when the idea is still incomplete and the team needs to shape the problem before defending a solution.
OUTPUT → RFDPropose the change
State one decision, the evidence, credible alternatives, constraints, trade-offs, rollout, rollback, and success criteria.
OUTPUT → RFC / enhancement proposalTest the assumptions
Attach benchmarks, evaluation datasets, prototypes, cost models, threat analysis, and failure evidence.
OUTPUT → evidence packageResolve material feedback
Classify comments, dispose of objections visibly, and prevent preference from masquerading as a blocking risk.
OUTPUT → review dispositionMake the decision
One accountable approver accepts, rejects, defers, withdraws, or conditionally accepts the proposal.
OUTPUT → decisionPreserve the rationale
Record the choice, consequences, guardrails, conformance rules, and explicit supersession triggers.
OUTPUT → ADRConnect delivery
Link Jira, repositories, contracts, tests, diagrams, dashboards, and implementation milestones.
OUTPUT → executable planProve readiness
Validate ownership, SLOs, runbooks, capacity, auditability, failure modes, rollback, and incident response.
OUTPUT → ORRValidate in production
Compare promised outcomes with actual quality, cost, reliability, risk, adoption, and architectural conformance.
OUTPUT → evidence-driven evolutionUse the right artifact for the question.
Twelve artifacts cover exploration, decision, implementation truth, risk, readiness, migration, and enforcement. Open any term for its full guide and template.
ADD versus ADR
An Architectural Design Decision is the choice itself. The Architecture Decision Record is the durable artifact that preserves that choice, its rationale, and its consequences.
RFD
Request for Discussion
Is this idea worth developing? Use it while the problem and solution space are still fluid.
RFC
Request for Comments
Should we adopt this substantial proposal? Invite structured challenge before committing.
EP
Enhancement Proposal
How does a capability mature from alpha through general availability, deprecation, and removal?
ADR
Architecture Decision Record
What did we decide, why, under which guardrails, and what would trigger reconsideration?
DESIGN
System Design
How does the selected architecture work now? Keep this current as implementation evolves.
CONTRACT
API and Data Contract
What behavior, schemas, compatibility, authorization, and failure semantics can consumers rely on?
EVAL
Experiment and Evaluation Record
What reproducible evidence supports the proposal across quality, latency, cost, safety, and failure?
THREAT
Impact and Threat Assessment
What can fail, be abused, leak, overreach, or create unacceptable organizational risk?
ORR
Operational Readiness Review
Can the owning team safely run, observe, recover, support, and retire the system?
WAIVER
Exception Record
Why is a standard being violated, who accepts the risk, and exactly when does the exception expire?
MIGRATE
Deprecation and Migration Plan
How will consumers move, compatibility end, data transition, and the old capability be safely removed?
CHECK
Conformance Rule
How will tests, policy, telemetry, service catalogs, and review detect divergence from the decision?
Explore every artifact in context.
Each anchor provides the purpose, SDLC placement, and next handoff. The modal adds the full operating detail and a copyable template without leaving the current context.
Explore and decide
Move from uncertainty to an explicit, durable choice.
RFD
Request for Discussion
Explore a consequential idea before the solution hardens.
Use when
The problem matters, but the right approach, scope, or ownership is still uncertain.
SDLC
Discovery and pre-design. It belongs before formal architecture review, vendor commitment, or implementation planning.
Next
Advance to an RFC or Enhancement Proposal, record why the idea was stopped, or split the problem into smaller investigations.
RFC
Request for Comments
Request a concrete decision on a substantial proposal.
Use when
A cross-team, high-impact, costly, risky, or hard-to-reverse change needs explicit review.
SDLC
Architecture and planning. Use it before implementing platform services, public contracts, new trust boundaries, or material AI capabilities.
Next
Record the outcome. Accepted RFCs usually create one or more ADRs, delivery work, risk actions, and readiness gates.
EP
Enhancement Proposal
Govern a platform capability through maturity and retirement.
Use when
A capability needs staged delivery, graduation criteria, compatibility commitments, and long-term lifecycle ownership.
SDLC
Planning through retirement. It spans design, implementation, release, adoption, and deprecation.
Next
Each stage produces delivery milestones, readiness evidence, adoption reviews, and explicit graduation or rollback decisions.
ADR
Architecture Decision Record
Preserve the final decision, rationale, and guardrails.
Use when
A significant architectural choice must remain understandable after the proposal discussion is over.
SDLC
Decision formalization and implementation handoff. Create it after approval and before the decision spreads across teams.
Next
Link current design and conformance checks. If the decision changes, publish a new ADR that supersedes the original.
Design and integrate
Describe the current system and the contracts consumers depend on.
DESIGN
System Design
Explain how the selected architecture works now.
Use when
Engineers, operators, and integrators need a current implementation model rather than historical decision debate.
SDLC
Detailed design, implementation, onboarding, operations, and maintenance.
Next
Drive implementation, test plans, runbooks, contracts, and architecture reviews. Update it when the system changes.
CONTRACT
API and Data Contract
Define what producers and consumers can safely rely on.
Use when
Multiple systems depend on stable behavior, schemas, compatibility, authorization, or failure semantics.
SDLC
Detailed design, integration, implementation, release, and compatibility management.
Next
Generate implementation work, consumer migration, contract testing, version management, and deprecation plans.
Prove and prepare
Establish evidence, bound risk, and validate operational readiness.
EVAL
Experiment and Evaluation Record
Support the decision with reproducible proof.
Use when
Quality, safety, latency, cost, resilience, or AI behavior must be compared across alternatives or releases.
SDLC
Proposal evaluation, qualification, pre-release validation, and regression management.
Next
Feed the RFC, threat assessment, ORR, and change-control process. Failed thresholds trigger redesign or rollback.
THREAT
Impact and Threat Assessment
Identify how the system can fail, be abused, or create harm.
Use when
A change introduces a new trust boundary, sensitive data, external provider, agent action, or consequential user impact.
SDLC
Discovery, design, pre-release review, and material change review.
Next
Add controls to the RFC and design, create test cases, record residual risk, and verify mitigations during ORR.
ORR
Operational Readiness Review
Prove the owning team can run the system safely.
Use when
Implementation is substantially complete and a production release or major expansion needs an operational gate.
SDLC
Pre-release and release. It sits between implementation completion and broad production rollout.
Next
Launch with validation criteria, or create blocking remediation with named owners and dates.
Govern and evolve
Handle deviations, migrations, and continued architectural alignment.
WAIVER
Exception Record
Make a temporary deviation visible, owned, and expiring.
Use when
A team cannot currently comply with an approved standard or decision and needs time-bound risk acceptance.
SDLC
Implementation, release, and operation whenever conformance cannot be achieved on schedule.
Next
Remediate before expiry, renew with new evidence, or change the underlying standard through a new proposal.
MIGRATE
Deprecation and Migration Plan
Move consumers safely and retire the old capability.
Use when
An API, model, provider, schema, service, or platform capability must be replaced or removed.
SDLC
Planning, implementation, release, adoption, and retirement.
Next
Complete migrations, revoke exceptions, verify data and traffic movement, and archive or remove the retired capability.
CHECK
Conformance Rule
Keep implementation aligned with the approved decision.
Use when
An architectural rule or platform standard must remain enforceable after approval.
SDLC
Implementation, release, and operation. It is the continuity layer after approval.
Next
Remediate violations, approve a time-bound waiver, or publish a new proposal when the original rule no longer fits reality.
RFC → ADR is necessary. It is not sufficient.
The classic pair breaks down when it tries to carry organizational authority, AI evidence, production readiness, and ongoing conformance.
No decision threshold
Without tiers, every change becomes bureaucracy—or important changes disappear into Slack and pull requests.
No decision authority
Comments do not create accountability. One person must own the final decision and residual risk.
No feedback disposition
Material objections need a visible outcome: accepted, modified, rejected, deferred, or moved out of scope.
No evidence standard
A successful demo is not an evaluation. AI decisions need representative datasets, baselines, thresholds, and failure analysis.
No launch gate
An accepted architecture can still be impossible to operate. Readiness must be evaluated separately.
No conformance loop
Decisions decay unless code, policy, contracts, telemetry, and review can detect implementation drift.
Make review precise, not political.
Classify feedback by consequence. Require blockers to name the quality attribute, failure scenario, and evidence needed to resolve the concern.
Blocking
A requirement, safety boundary, or quality attribute cannot be met. Must be resolved before approval.
Major
A material risk or trade-off exists. The approver may accept it explicitly with an owner and rationale.
Question
Information is missing or ambiguous. The response should improve shared understanding.
Suggestion
An optional improvement. It should not silently become a veto or an untracked requirement.
Definition of ready for review
- One central decision is stated clearly.
- A single accountable approver is named.
- Alternatives include a credible status quo.
- Claims link to evidence rather than confidence alone.
- Security, AI risk, rollout, rollback, ownership, and success criteria are explicit.
Decision outcomes
Accepted · Accepted with conditions · Rejected · Deferred · Withdrawn · Superseded. Conditional approval must produce owned, dated, tracked conditions—not a vague future obligation.
DACI accountability
Driver: moves the document. Approver: makes the decision. Contributors: provide required expertise. Informed: receive visibility without creating another veto point.
Match process weight to blast radius.
The tiering model prevents architecture theater for small changes while forcing discipline around irreversible, platform-wide decisions.
| Tier | Characteristics | Required artifacts | Review target |
|---|---|---|---|
| T0 · Local | Reversible. One repository. No external contract. | Ticket + pull request | Normal code review |
| T1 · Bounded | One service. Moderate impact. Reversible. | Mini-RFC or ADR | 2–3 business days |
| T2 · Cross-system | Multiple services or teams. API, SLO, security, cost, or data impact. | Full RFC + durable decision record | 5 business days |
| T3 · Strategic | Platform-wide. Hard to reverse. Vendor, regulated data, or agent autonomy. | Enhancement proposal + ADRs + evidence + threat model + ORR | 10 business days + decision review |
| Emergency | Incident containment or urgent compliance action. | Expedited record + exception | Retrospective review on a fixed date |
Mandatory RFC triggers
New platform service, trust boundary, provider, agent permission, public contract, data classification, SLO, multi-team dependency, irreversible migration, or material recurring cost.
Reversibility is the multiplier
The harder a decision is to unwind, the more evidence, explicit ownership, migration planning, and production controls it deserves.
AI changes the evidence burden.
Models, prompts, retrieval, tools, permissions, datasets, and providers can all change system behavior without changing the application code.
Intent
WHYIntended useUsers, workflows, autonomy, prohibited uses
ImpactConsequences, appeal, human oversight
Decision rightsWho may approve risk and change
Evidence
PROVEGolden datasetsRepresentative, versioned, governed
EvaluationQuality, safety, latency, cost
Failure taxonomyKnown limitations and severity
Runtime
CONTROLAuthorizationAt invocation time, not only registration
GuardrailsAllowlist, validation, budgets, approvals
Kill switchModel, prompt, tool, provider revocation
Model and provider profile
Version, region, data terms, context limits, fallback, deprecation, cost assumptions, portability, and change policy.
Evaluation record
Baseline, provenance, metrics, human rubric, acceptance thresholds, results by configuration, and known limitations.
Agentic threat model
Injection, excessive agency, tool misuse, privilege propagation, memory poisoning, supply chain, and denial of wallet.
Make Confluence the visible control plane.
Standard metadata, automated registries, page approvals, Jira linkage, reminders, and status separation turn documentation into an operational system.
Platform AI decision registry
Content Properties Report · Jira linkage · Approval workflow · Automated staleness controls
18OPEN PROPOSALS
7DECISION PENDING
42ACTIVE ADRs
3REVIEW DUE
| ID | Proposal | Governance | Delivery | Risk | Owner |
|---|---|---|---|---|---|
| RFC-AI-023 | Remote MCP authorization model | In review | Not started | T3 | Platform AI |
| RFC-AI-019 | AI gateway routing and fallback | Accepted | In progress | T3 | Core Platform |
| ADR-AI-017 | Signed tool manifests | Current | Released | T2 | Security |
| RFC-DATA-008 | Embedding deletion propagation | Blocked | Not started | T3 | Content Data |
| RFD-AI-031 | Evaluation-as-a-service | Ideation | — | T2 | AI Foundation |
Governance status
Ideation, draft, review open, decision pending, accepted, rejected, deferred, withdrawn, superseded.
Delivery status
Not started, in progress, released, validated, retired. Do not hide implementation state inside approval state.
Document validity
Current, review due, stale, historical. A released decision can still contain outdated operational guidance.
Start with structure. Keep the thinking yours.
Open a focused template from the library, or use the fuller RFC, ADR, and AI-readiness examples below. Progressive disclosure keeps the page scannable.
Complete template library
Open a focused modal, copy the template, then return to the guide or full examples below.
RFC launch template
Proposal, evidence, trade-offs, rollout, and decision.
# RFC-[DOMAIN]-[NUMBER]: [Decision-oriented title] ## Metadata Type · Status · Driver · Approver · Risk tier · Deadline Affected systems · Required reviews · Related work ## Executive summary ## Decision requested ## Current state and problem ## Goals / Non-goals ## Decision drivers and constraints ## Proposed architecture ## Interfaces and contracts ## Data, AI, security, and operations ## Rollout / Migration / Rollback ## Validation and evaluation ## Alternatives considered ## Risks and mitigations ## Material feedback disposition ## Decision and follow-up work
ADR launch template
Decision, rationale, consequences, guardrails, and conformance.
# ADR-[DOMAIN]-[NUMBER]: [Decision as an action] ## Metadata Status · Date · Owner · Approver · Scope Supersedes · Superseded by · Related RFC ## Context ## Decision drivers ## Options considered ## Decision ## Rationale ## Consequences ## Guardrails ## Conformance ## Validation evidence ## Review and supersession triggers ## Follow-up actions
AI readiness template
Intent, evidence, runtime controls, and launch gate.
# AI Evidence + Production Readiness ## System profile ## Intended use and prohibited use ## AI supply chain and versions ## Data profile and lineage ## Evaluation datasets and thresholds ## Human evaluation ## Failure analysis ## Agentic and LLM security testing ## Runtime authorization and guardrails ## Reliability, SLOs, and observability ## Incident response and kill switch ## Release decision ## Conditions and post-launch validation
High-value decisions waiting to be made.
Use these as an initial RFC backlog for foundational AI integrations across content delivery, MCP, knowledge, governance, and observability.
Enterprise model-invocation gateway
Control plane, data plane, routing, fallback, tenant isolation, and portability.
AI platform service tiers and SLOs
Define reliability, latency, support, and cost expectations by workload class.
Remote MCP authentication and authorization
Identity propagation, delegated access, invocation-time policy, audit, and revocation.
Tool registry and lifecycle
Ownership, signed manifests, discovery, approval, versioning, and emergency removal.
Human approval for consequential actions
Define autonomy boundaries, approval UX, timeouts, and recovery.
Content entitlement propagation
Preserve access controls through retrieval, reranking, generation, caching, and citation.
Citation and provenance contract
Standardize source identity, excerpt traceability, confidence, and consumer obligations.
Embedding deletion propagation
Guarantee removal through derived indexes, caches, summaries, and replicas.
Evaluation-as-a-service
Golden datasets, scoring, human review, regression gates, and reusable evidence.
Model onboarding and upgrade policy
Qualification, version pinning, deprecation, regression, fallback, and rollback.
Agentic threat-modeling standard
Injection, excessive agency, tool misuse, memory poisoning, and supply-chain controls.
AI exception and waiver process
Time-bound deviation, residual risk ownership, compensating controls, and expiry.
Distributed tracing semantics for AI
Model, prompt, retrieval, tool, token, cost, quality, and correlation metadata.
AI cost allocation and budgets
Chargeback, tenant attribution, forecast, anomaly detection, and denial-of-wallet controls.
Regional AI deployment and residency
Routing, model availability, failover, content location, and compliance boundaries.
Kill the failure modes before they become culture.
The process fails when it becomes theater, consensus machinery, stale history, or a substitute for evidence.
RFC theater
The decision was already made, but a page simulates consultation.
Correction
Label the proposal as exploratory, preferred-direction, or validation-seeking.
Consensus paralysis
Every reviewer becomes a veto point.
Correction
Assign one approver. Experts identify evidence, risk, and constraints without becoming additional veto points.
Architecture court
Comments become demonstrations of expertise.
Correction
Tie objections to a decision driver, failure scenario, or measurable requirement.
Document by committee
Many authors flatten the narrative into contradictions.
Correction
One driver owns the document. Contributors comment or propose explicit edits.
ADR as meeting minutes
Chronology replaces decision quality.
Correction
Record context, choice, rationale, consequences, guardrails, conformance, and review triggers.
AI evidence laundering
A polished demo is presented as proof.
Correction
Require representative datasets, baselines, thresholds, failure analysis, and reproducible versions.
Unbounded conditional approval
Major concerns become an informal backlog.
Correction
Give every condition an owner, due date, tracking item, and explicit blocking designation.
Confluence-code divergence
The decision cannot be found from the implementation.
Correction
Carry ADR IDs into repositories, service catalogs, API specifications, policies, and runtime metadata.
Operational in thirty days.
Start with live work. Measure friction. Tune the process before scaling it across the platform organization.
Establish the operating model
Define thresholds, lifecycle states, DACI roles, metadata, naming, templates, and the Confluence space.
- Publish decision tiers and mandatory triggers.
- Name the architecture-process owner.
- Create RFC, ADR, evidence, and ORR templates.
Pilot with real decisions
Run one T1, one T2, and one AI-specific T3 proposal through the lifecycle.
- Use actual platform work.
- Track review latency and unresolved ambiguity.
- Do not optimize for a perfect first draft.
Add visibility and automation
Build the registry, reminders, approval conditions, Jira links, stale-document reports, and waiver expiry checks.
- Separate governance, delivery, and validity.
- Flag accepted work without delivery linkage.
- Flag released work without readiness evidence.
Retrospect and codify
Remove ceremonial sections, strengthen missing controls, and publish RFC-0001 as the governing process RFC.
- Measure time to decision.
- Identify duplicate or skipped sections.
- Set the quarterly decision-log review.
Built on primary guidance and proven public processes.
The page synthesizes current standards, operating models, and production-readiness practices. Open the underlying sources for the normative detail.
01Kubernetes Enhancement Proposal templateDesign, test plans, monitoring, rollout, rollback, scalability, troubleshooting, and production readiness.
02AWS Operational Readiness ReviewsChecklist-based production readiness, residual risk, lessons learned, and backlog actions.
03AWS Architecture Decision Record processArchitectural significance, immutable accepted records, and superseding decisions.
04Python PEP 1Standards Track, Informational, and Process proposal types with author responsibility for consensus and objections.
05Rust RFC processSubstantial-change threshold and community design review before implementation commitment.
06Oxide Request for Discussion processEarly-stage ideation, discussion, publication, commitment, and abandonment states.
07NIST Generative AI ProfileTrustworthiness and risk management across AI design, development, use, and evaluation.
08OWASP Top 10 for Agentic Applications 2026Security risks unique to autonomous systems that plan, use tools, and take action.
09Confluence page approvalsRequired reviewers, approval history, decisions, comments, and timestamps.
10Architecture Decision Records communityCore terminology, templates, tools, and decision-log practices.
The north star
Make the decision visible. Make the architecture executable.
Confluence becomes the control plane for intent, ownership, evidence, and accountability. Code, contracts, tests, telemetry, and policy become the delivery plane that proves the decision is real.