32 lines
1.4 KiB
Markdown
32 lines
1.4 KiB
Markdown
# ADR-0032: Evidence-bound production approvals
|
|
|
|
## Status
|
|
|
|
Accepted in M12 on 2026-08-26.
|
|
|
|
## Context
|
|
|
|
Technical probes, Advisor recommendations and engineering integration each prove useful but distinct
|
|
facts. Reusing their labels as production permission would silently reinterpret stale evidence and
|
|
collapse platform readiness into project fitness.
|
|
|
|
## Decision
|
|
|
|
Production permission is a first-class ApprovalRequest bound to an immutable ApprovalPolicy revision
|
|
and a fingerprinted snapshot of exact declared IDs plus database-resolved facts. Policies are
|
|
revisioned. Requests expire, can be revoked and become stale when referenced facts change. Default
|
|
production policy hard-gates security, license, evaluation, resource readiness, rollback and project
|
|
validation. Approval remains separate from execution.
|
|
|
|
## Consequences
|
|
|
|
M11's engineering PASS can coexist with a blocked ExampleVision production request. Old approvals retain
|
|
their interpretation and cannot silently authorize changed artifacts, runtimes, fit or scheduler
|
|
evidence. More records and explicit operator steps are required, but every permission is explainable.
|
|
|
|
## Rejected alternatives
|
|
|
|
- Treating `LAB_READY` or `PROMOTION_ELIGIBLE` as permission: conflates evidence with authority.
|
|
- Storing only a model/capability name: loses exact provenance.
|
|
- Re-evaluating old requests under the latest policy: silently changes historical meaning.
|