4.8 KiB
Approval, reversibility, sensitivity — policy model
Canonical context: MASTER_OPERATING_PROMPT.md. This file is the operational reference for classifying work before it ships. Expanded topics: README.md.
Approval class (A)
| Class | Who signs off | Typical examples |
|---|---|---|
| A0 | None | Read-only discovery, local drafts, internal notes |
| A1 | Manager / lead | Staging config, non-prod feature flags, routine refactors behind flag |
| A2 | Function head + legal/finance as needed | Billing, contracts, data retention, permission model changes |
| A3 | Executive / board | Irreversible commitments, major market launch, regulated disclosures |
Reversibility class (R)
| Class | Reverse | Typical examples |
|---|---|---|
| R0 | Automatic | Feature flag off, revert commit, rollback migration (if designed) |
| R1 | Limited ops effort | Revert deploy, disable integration, compensate with credits |
| R2 | Costly / painful | Customer-visible data already acted on, partial external commitments |
| R3 | Irreversible or binding externally | Signed terms, regulatory filing, money movement, public statement |
Rule of thumb: R2/R3 require explicit HITL (human-in-the-loop) or committee path before execution-plane runs.
Reversibility vs approval (cross-check)
| Reversibility | Typical minimum approval | Notes |
|---|---|---|
| R0 | A0–A1 | Auto or lead sign-off per team policy |
| R1 | A1 | Revert still needs accountable owner |
| R2 | A2 | Legal/finance/functional head as appropriate |
| R3 | A3 | Exec/board path for binding or public commitments |
Higher sensitivity (below) can raise the required approval even when reversibility is R0–R1 (e.g. S3 bulk export is never A0).
Sensitivity class (S)
| Class | Data |
|---|---|
| S0 | Public / low sensitivity |
| S1 | Internal operational |
| S2 | Confidential / commercial |
| S3 | Regulated / highly sensitive / personal / board |
Rule: No S2/S3 across tools, providers, or LLM endpoints without policy review and routing (e.g. local/private inference where required).
Sensitivity vs action class
| Data / context | Default action class | Approval note |
|---|---|---|
| S0 | Class A possible | Still follow repo conventions |
| S1 | Class A for read-only; Class B for writes affecting others | Team policy |
| S2 | Class B minimum for export, integration, or model routing | No silent tool/provider hops |
| S3 | Class B minimum; often A2–A3 | No LLM or third-party tool without explicit routing review |
Actor type
human | observer_agent | recommender_agent | executor_system | automated_workflow
Observers and recommenders do not commit. Executors and workflows act only through execution plane paths with policy metadata.
Action classes (ship discipline)
- Class A — Auto-allowed: maps, docs, tests generation, lint, read-only analysis.
- Class B — Approval required: prod config, public publish, customer messages, migrations, RBAC, release promotion, external APIs.
- Class C — Forbidden: exfiltration, bypass protections, silent destructive changes, disabling gates, claims without evidence.
Mapping A / R / S to Class A / B / C
| Pattern | Class | Rationale |
|---|---|---|
| Read-only discovery, local drafts, unit tests, lint | A | No durable external commitment |
| R2/R3 or external side effect (message send, contract, money, public URL) | B or blocked until A met | Execution plane + HITL |
| R3 with inadequate A (e.g. board doc at S3 with A1 only) | C (do not ship) | Policy violation |
| Any claim of “done” without tests/logs/artifact | C | Evidence discipline |
| S2/S3 sent to new vendor, model, or MCP without review | B minimum | Data residency and tool governance |
Executor systems and automated workflows may only perform Class A actions autonomously where policy explicitly allows; otherwise they enqueue or pause for approval.
Evidence pack (minimum)
For Class B and any R2/R3 decision: sources, assumptions, timestamps/freshness, compliance notes where relevant, alternatives, rollback/compensation, provenance score, pointers to tests or run artifacts.
A decision memo without an evidence pack is incomplete.
GitHub governance (surface)
See github-and-release.md for the full model. Summary: protected main, required reviews and checks, CODEOWNERS as team scales, secret scanning and dependency review, OIDC for deploy keys where possible, environment promotion (dev → staging → canary → prod).