system-prompts-and-models-o.../docs/governance/approval-policy.md
2026-04-16 07:58:36 +03:00

89 lines
4.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Approval, reversibility, sensitivity — policy model
Canonical context: [`MASTER_OPERATING_PROMPT.md`](../../MASTER_OPERATING_PROMPT.md). This file is the **operational reference** for classifying work before it ships. Expanded topics: [README.md](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** | A0A1 | 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 R0R1 (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 A2A3 | 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](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).