docs: record the domain workflow policy decision (and why the sequencing was backwards)

[moonweave]

We investigated adding a layer where a change class (schema migration, dependency change, auth surface, public API contract change, release) maps to required steps. The conclusion was not to build it in that form now, and that conclusion cost four parallel investigations to reach — so it belongs in the repository rather than in a session transcript.

What the record captures

• No authoritative framework prescribes change-class-specific required steps. SSDF differentiates by activity type, SLSA by artifact trust level, ASVS by application risk, ITIL by urgency. What can be cited honestly is narrow: releases (SLSA, Scorecard), dependency changes (SSDF PW.4, published as an OSCAL catalog so task IDs can be referenced rather than invented), API changes (SemVer). Nothing standard requires a "dry run" or a "rollback plan" as a named control.
• DORA argues directly against gating: external approvals correlate negatively with lead time, deployment frequency and restore time, and not at all with change fail rate. A required-steps pre-merge gate reproduces the change advisory board.
• Only one candidate is verifiable from sealed bytes without borrowing a norm: if a dependency manifest is in the bound touched-set, the lockfile must be too — repository self-consistency rather than prescription. The rest reduce to declared checks or are unverifiable.
• Why not now: that single predicate is already reachable via a declared check, and the differentiating capability (proving a declared verification actually executed) was blocked by the evidence substrate — which #204 has since fixed. The sequencing was backwards, not the idea.
• The shape it should take if built later: refutable claims rather than required steps (absence advisory, contradiction blocking); monotone classification re-derived by the verifier from the bound touched-set, so an AI-proposed class can only add obligations; and no shipped default policy — provenance admits only detected or operator-authored, making an ORRO best-practice pack unrepresentable in the schema.
• A revisit trigger, so this is a decision with an expiry condition rather than a permanent no.

Documentation only.

🤖 Generated with Claude Code