RFC template

Copy this page into a new RFC and replace the prompts with the actual decision. Adapt the headings to the change and remove sections that do not apply. See the RFC process for review, length, and diagram guidance.

RFC: [Decision or capability]

Status: [Proposed / Implementing / Implemented]
Owner: [Responsible person or team]
Related: [Relevant issue, implementation PR, and existing contracts]

Problem and decision

[Who needs to do what? Describe the current behavior, the gap, and the proposed decision. State the result a caller can observe and why this choice addresses the problem.]

Scope

[Describe the smallest connected result, remaining selected work, and genuine non-goals. Identify material dependencies and assumptions.]

Design

[Name the owners of decisions, state, effects, and cleanup. Describe the actual entry point, the changed interfaces, what is reused, and the request through its result. State relevant permissions, defaults, trust boundaries, failure behavior, and recovery where they constrain an operation. Link existing contracts.]

Architecture

The diagram below is an illustrative shape, not a platform architecture. Replace every node and edge with the actual design. Dashed arrows represent proposed or unconnected paths; use solid arrows only for implemented connections.

---
config:
  theme: base
  htmlLabels: true
  themeVariables:
    fontSize: 14px
    primaryTextColor: "#344054"
    lineColor: "#8B949E"
    edgeLabelBackground: "#FFFFFF"
  flowchart:
    curve: linear
    nodeSpacing: 28
    rankSpacing: 32
    padding: 14
---
flowchart TB
  Caller["<b>Caller</b><br/>Starts the task"]
  Owner["<b>Decision owner</b><br/>Admits the request"]
  Effect["<b>Effect owner</b><br/>Performs the work"]
  Result["<b>Result</b><br/>Observed outcome"]
  Caller -.->|request| Owner
  Owner -.->|admit| Effect
  Effect -.->|report| Result
  classDef actor fill:#F1EEF5,stroke:#A091AD,color:#3A3243,stroke-width:1px
  classDef gate fill:#F7F1E5,stroke:#B3A078,color:#514532,stroke-width:1px
  classDef pending fill:#F3F4F6,stroke:#98A2AE,color:#44505F,stroke-width:1px,stroke-dasharray:4 4
  class Caller actor
  class Owner gate
  class Effect,Result pending
  linkStyle default stroke:#8B949E,stroke-width:1px

Request lifecycle

Replace this illustrative sequence with the actual owners, request, result, and material failure or recovery. Sequence arrows show request and reply direction; state whether the illustrated flow is implemented or proposed in the caption.

sequenceDiagram
  participant Caller
  participant Owner
  participant Dependency
  Caller->>Owner: Request the task
  Owner->>Dependency: Perform admitted work
  alt Work succeeds
    Dependency-->>Owner: Result
    Owner-->>Caller: Observable outcome
  else Work cannot complete
    Dependency-->>Owner: Failure or unknown result
    Owner-->>Caller: Refusal or recovery status
  end

Delivery and verification

[Describe a small step and its real prerequisite.]
[Connect the capability to its supported caller.]
[Name any remaining selected work and qualification.]

[Pair each required outcome with evidence for success and consequential denial, failure, or recovery. State what has run and what remains unverified.]

Alternatives and open decisions

[Explain meaningful alternatives and tradeoffs. For each open decision, name the deciding owner, consequence, and any invariant that remains binding. Omit this section when there are no material alternatives or open decisions.]

References

[Link current behavior, contracts, related proposals, and implementation.]