Skip to content

2026 04 27 pdp universal policy synchronisation integrity

Jump to bottom
github-actions[bot] edited this page Apr 30, 2026 · 2 revisions

Universal policy synchronisation and integrity: ensuring the Policy Decision Point (PDP) evaluates governed assets against logically identical policy across all lifecycle phases

Research Question

What mechanism ensures that the Policy Decision Point (PDP) evaluates a governed asset against logically identical policy at every lifecycle phase, such that a soft gate in Development and a hard gate in Operation are guaranteed to be derived from the same Policy Administration Point (PAP) source, and a policy change between phases is detected and surfaced rather than silently permitting inconsistency?

Scope

In scope:

  • The synchronisation protocol between PAP and all downstream PDPs across Getting Started, Development, Delivery, and Operation phases
  • Content-addressed policy bundle design: compilation of policy to a deterministic hash, PDP pinning behaviour, PAP version graph maintenance
  • The detection mechanism for in-flight assets whose development-time policy snapshot no longer matches the current Policy Administration Point (PAP) state, the stale-policy continuity failure in which an asset advances under a stale policy snapshot
  • The Delivery pipeline as the mandatory re-synchronisation point: policy diff before promotion from Development to Delivery, promotion failure on material divergence
  • Treatment of policy version as a first-class attribute of asset identity, embedding, carrying, and validating the policy hash at each phase transition
  • Policy versioning protocols: semantic versioning vs content-addressing, version graph structure, rollback and forward-patch behaviour
  • The Language Server Protocol (LSP) as the Development-phase surface for real-time conformance guidance, scoped to its role in the synchronisation architecture rather than its full capability set

Out of scope:

  • Out-of-band policy invalidation for assets already in Operation (covered by RQ3)
  • The PAP mapping function itself (covered by RQ1)
  • Anomaly detection in the Policy Information Point (PIP) (covered by RQ4)
  • Intent preservation and cryptographic binding (covered by RQ5)
  • Jurisdiction-specific legal analysis beyond what is needed to characterise the stale-policy continuity failure as a regulatory risk

Constraints:

  • Depends on RQ1: a defined Policy Enforcement Point (PEP) topology is required to know which PDPs must be synchronised
  • The synchronisation protocol must be implementable without requiring continuous connectivity between PAP and PDPs, and offline and intermittently-connected deployment contexts must be supported
  • The stale-policy continuity failure must be characterised precisely: the research must distinguish silent inconsistency (the dangerous case) from detected inconsistency (the recoverable case)

Context

  • [inference; source: https://davidamitchell.github.io/Research/research/2026-03-22-compliance-scanning-gh-actions.html; https://davidamitchell.github.io/Research/research/2026-03-22-cross-scanner-compliance-evidence-normalisation.html; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] The stale-policy continuity failure is a lifecycle continuity failure: an asset satisfies policy under one development-time snapshot, the Policy Administration Point (PAP) changes before promotion or deployment, and a later Policy Enforcement Point (PEP) evaluates the same asset against a different baseline without an explicit mismatch signal.
  • [fact; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html; https://davidamitchell.github.io/Research/research/2026-03-22-compliance-scanning-gh-actions.html] The Development-phase surface in adjacent work is an LSP diagnostic loop, and the compliance-scanning items already show that heterogeneous gate implementations can produce inconsistent evidence when they are not derived from one shared policy artefact.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://github.com/opencontainers/image-spec/blob/main/spec.md#content-addressability; https://slsa.dev/spec/v1.0/provenance] Treating policy as a formally versioned artefact, from which phase-specific projections are derived and against which phase transitions are checked, is the discipline that converts policy drift from a silent inconsistency into a detectable identity mismatch.

Approach

  1. Stale-policy continuity failure characterisation: Define the failure mode precisely. Enumerate the conditions under which the stale-policy continuity failure occurs silently versus detectably. Survey the compliance scanning and cross-scanner normalisation items for empirical evidence of the symptom.
  2. Content-addressed policy bundle design: Design the content-addressed policy bundle architecture. Define: (a) the compilation from PAP policy to deterministic hash; (b) PDP pinning behaviour; (c) PAP version graph structure; (d) the detection signal when a PDP is operating on a stale hash.
  3. Phase-transition synchronisation protocol: Define the synchronisation protocol for each phase transition. For Development to Delivery: mandatory policy diff, promotion failure on material divergence, definition of "material divergence". For Delivery to Operation: final hash validation before deployment.
  4. Policy hash as asset identity attribute: Define how the policy hash is embedded in the asset's metadata at Getting Started, carried forward through each phase, and validated at each phase transition. Specify what constitutes a policy hash mismatch and the required response.
  5. LSP integration surface: Specify the Development-phase surface: how the Policy-LSP consults the pinned policy snapshot, how it detects PAP divergence in real time, and what signal it surfaces to the developer.
  6. Orphaned snapshot handling: Analyse the state-orphaning risk, analogous to stateless-agent assumption failure across session boundaries, applied to policy snapshots across lifecycle boundaries. Define the recovery protocol for orphaned snapshots.
  7. Synthesis: Produce a synchronisation protocol specification, a version graph schema, and a decision framework for PAP implementors characterising when synchronous vs. asynchronous synchronisation is required.

Sources

Research Skill Output

(Full output from running the research skill, retained verbatim in the completed item. Sections 0 to 5 are the investigation, and Section 6 seeds the Findings section below.)

§0 Initialise

  • [fact; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://csrc.nist.gov/pubs/sp/800/162/final] The question asks for a mechanism that guarantees one PDP evaluates an asset against policy that is logically identical to the policy seen earlier in Development, even when the PAP changes between phases.
  • [fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://github.com/opencontainers/image-spec/blob/main/spec.md#content-addressability; https://slsa.dev/spec/v1.0/provenance] The relevant design primitives available in the retrieved sources are revisioned policy bundles, immutable content digests, signed attestations, and provenance records that can carry digest-bound metadata across lifecycle transitions.
  • [fact; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html; https://davidamitchell.github.io/Research/research/2026-03-22-compliance-scanning-gh-actions.html; https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html; https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] Prior repository work already covers the same control surface from adjacent angles: Development diagnostics, heterogeneous-gate inconsistency, Delivery as promotion gate, machine identity and attribution, policy coherence, and orphaned-state failure.
  • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] The output format should therefore be a synchronisation protocol, a version-graph schema, and a decision rule that uses digest equality as enforcement truth while allowing human-readable release metadata alongside it.

§1 Question Decomposition

  • Q1. What architecture is being synchronised?
    • Q1.1. What do ABAC and XACML say about PAP, PDP, PEP, and PIP roles?
    • Q1.2. Which of those roles create the synchronisation boundary relevant to this item?
  • Q2. What artefact identity mechanism can prove that two phases are using the same logical policy?
    • Q2.1. What do content-addressed systems establish about immutable identity?
    • Q2.2. What do attestation and provenance systems establish about carrying digest identity across steps?
  • Q3. What policy-bundle mechanics already exist for distribution, caching, signing, persistence, and stale revision detection?
    • Q3.1. What does OPA provide directly?
    • Q3.2. What remains a control-plane responsibility above the bundle client?
  • Q4. What precisely makes the stale-policy continuity failure silent, and what makes it detectable?
    • Q4.1. What symptoms already appear in prior repository work?
    • Q4.2. What additional identity data must the asset carry so drift becomes observable?
  • Q5. Where is the mandatory re-synchronisation point?
    • Q5.1. Why is Development insufficient?
    • Q5.2. Why is Delivery the last practical central gate before Operation?
  • Q6. How should Development soft guidance and Operation hard enforcement remain logically identical while still differing in enforcement posture?
  • Q7. What constitutes material divergence, what constitutes a policy hash mismatch, and what is the required response?
  • Q8. How should offline or intermittently connected contexts behave without reintroducing silent inconsistency?
  • Q9. What is the orphaned-snapshot failure mode, and what recovery protocol closes it?
  • Q10. When is asynchronous synchronisation acceptable, and when is synchronous validation required?

§2 Investigation

  • Atomic question Q1, what architecture is being synchronised?

    • Source class, primary: https://csrc.nist.gov/pubs/sp/800/162/final ; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
    • [fact; source: https://csrc.nist.gov/pubs/sp/800/162/final] NIST SP 800-162 defines ABAC as authorization determined by evaluating subject, object, operation, and environment attributes against policy.
    • [fact; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html] XACML defines the PAP as the entity that creates a policy or policy set, the PDP as the entity that evaluates applicable policy and renders an authorization decision, the PEP as the entity that performs access control by making decision requests and enforcing authorization decisions, and the PIP as the source of attribute values.
    • [inference; source: https://csrc.nist.gov/pubs/sp/800/162/final; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html] The synchronisation target is therefore not merely a text file in the PAP; it is the evaluated policy artefact consumed by each PDP and surfaced through each PEP at each lifecycle phase.

  • Atomic question Q2, what can prove logical policy identity across phases?

    • Source class, primary: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ; https://github.com/opencontainers/image-spec/blob/main/spec.md#content-addressability ; https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-addressable-storage
    • [fact; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects] Git is a content-addressable filesystem in which stored content is retrieved by a unique key derived from the content plus header.
    • [fact; source: https://github.com/opencontainers/image-spec/blob/main/spec.md#content-addressability] The OCI image specification describes manifests and layers as content-addressable identities that can be verified by hash.
    • [fact; source: https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-addressable-storage] The OCI distribution specification defines blobs as addressable by digest, tags as mutable pointers to manifests, and subject/referrer relationships as digest-linked associations.
    • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-addressable-storage] Content digest is the strongest equality token for policy identity because it changes when the compiled policy bytes change, whereas tags and semantic labels remain mutable references.

  • Atomic question Q3, how can digest identity be carried across phase transitions?

    • Source class, primary: https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md ; https://github.com/in-toto/attestation/blob/main/spec/v1/resource_descriptor.md ; https://slsa.dev/spec/v1.0/provenance ; https://docs.sigstore.dev/cosign/signing/signing_with_containers/
    • [fact; source: https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md] The in-toto Statement specification requires each subject element to have digest set and states that subject artefacts are assumed to be immutable.
    • [fact; source: https://github.com/in-toto/attestation/blob/main/spec/v1/resource_descriptor.md] The in-toto ResourceDescriptor specification says a descriptor that specifies a digest is assumed to refer to an immutable resource or artefact.
    • [fact; source: https://slsa.dev/spec/v1.0/provenance] SLSA provenance v1.0 defines an in-toto attestation predicate whose subject identifies output artefacts and whose resolved dependencies can carry immutable digests for inputs such as a pinned source revision.
    • [fact; source: https://docs.sigstore.dev/cosign/signing/signing_with_containers/] Sigstore Cosign signs and attests images addressed by digest, and can store a Sigstore bundle as an artefact attached to the digest-addressed subject.
    • [inference; source: https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md; https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] The cleanest lifecycle-carrier for policy identity is therefore an attested asset record whose subject is the governed asset digest and whose predicate includes the canonical policy bundle digest and any phase-projection digest derived from it.

  • Atomic question Q4, what distribution and stale-revision mechanics already exist?

    • Source class, primary: https://www.openpolicyagent.org/docs/latest/management-bundles/ ; https://www.openpolicyagent.org/docs/latest/management/
    • [fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] OPA bundle files may contain a .manifest with a top-level revision string that identifies the bundle revision when the service can serve different revisions of the same bundle.
    • [fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] Services implementing the Bundle Service Application Programming Interface (API) should set the Hypertext Transfer Protocol (HTTP) Etag header to identify the bundle revision, OPA includes that value in If-None-Match, and the service can reply with 304 Not Modified when the bundle has not changed.
    • [fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] OPA supports long polling, can persist bundles locally, and supports bundle-signature verification via the bundles[_].signing configuration.
    • [fact; source: https://www.openpolicyagent.org/docs/latest/management/] OPA management architecture explicitly separates bundle distribution, decision telemetry, agent telemetry through Status, and dynamic configuration, and notes that OPA does not provide a control plane service out of the box.
    • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://www.openpolicyagent.org/docs/latest/management/] OPA already provides the client-side mechanics for revisioned bundle distribution, but freshness comparison against the currently desired control-plane head remains a control-plane responsibility rather than a property of the local bundle client alone.

  • Atomic question Q5, what shows the stale-policy continuity failure symptom in adjacent work?

    • Source class, repository prior work: https://davidamitchell.github.io/Research/research/2026-03-22-compliance-scanning-gh-actions.html ; https://davidamitchell.github.io/Research/research/2026-03-22-cross-scanner-compliance-evidence-normalisation.html ; https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html
    • [fact; source: https://davidamitchell.github.io/Research/research/2026-03-22-compliance-scanning-gh-actions.html] The compliance-scanning item concluded that a single normalized severity field is the wrong abstraction for a heterogeneous scanner estate and that different scanner surfaces naturally produce incompatible semantics.
    • [fact; source: https://davidamitchell.github.io/Research/research/2026-03-22-cross-scanner-compliance-evidence-normalisation.html] The evidence-normalisation item concluded that multi-scanner evidence should be normalized into one shared contract because scanner-native outputs and suppression paths drift apart.
    • [fact; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html] The Policy-LSP item concluded that a headless process can act as a full LSP client and that typed diagnostics are the most precise Development-phase feedback surface.
    • [inference; source: https://davidamitchell.github.io/Research/research/2026-03-22-compliance-scanning-gh-actions.html; https://davidamitchell.github.io/Research/research/2026-03-22-cross-scanner-compliance-evidence-normalisation.html; https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html] The stale-policy continuity failure is the same class of problem at lifecycle scale: when Development and Operation consume policy through different, separately evolving implementations, evidence diverges before anyone can prove whether the underlying rule set is still the same.

  • Atomic question Q6, where is the mandatory re-synchronisation point?

    • Source class, repository prior work: https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html ; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html
    • [fact; source: https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html] The deployment-pipeline item concluded that the Delivery pipeline is the strongest composite programmable release choke point even when it is not the only enforceable control in an estate.
    • [fact; source: https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html] The identity item concluded that consequential non-human actors need their own machine identities and linked audit chains rather than inherited opaque user context.
    • [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html; https://slsa.dev/spec/v1.0/provenance] Delivery is the mandatory re-synchronisation point because it is the last central place where the asset digest, the acting identity, and the claimed policy digest can be checked together before deployment into runtime.

  • Atomic question Q7, what makes drift detectable rather than silent?

  • Atomic question Q8, how should Development and Operation remain logically identical while differing in posture?

    • Source class, repository prior work plus primary standards: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html ; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
    • [fact; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html] The LSP item treats Development as a typed diagnostic surface rather than as a separate authorization regime.
    • [fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html] The adjacent PAP proportionality item argues that one PAP should derive lifecycle-distributed gate topology from shared risk signals instead of authoring unrelated controls per phase.
    • [inference; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html] The way to keep soft Development guidance and hard runtime enforcement logically identical is to compile one canonical decision bundle and emit phase projections that share the same parent digest while differing only in enforcement mode and presentation surface.

  • Atomic question Q9, what should count as material divergence?

    • Source class, primary plus repository prior work: https://semver.org/ ; https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ; https://slsa.dev/spec/v1.0/provenance ; https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html
    • [fact; source: https://semver.org/] Semantic Versioning communicates compatibility intent through MAJOR.MINOR.PATCH semantics, but once a versioned package has been released its contents must not be modified and changed contents require a new version.
    • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://semver.org/; https://slsa.dev/spec/v1.0/provenance; https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html] A digest mismatch is always an identity mismatch, but it should count as material divergence for promotion when the new bundle changes rules, data, or derived decision outcomes over the asset's declared resource, action, and environment envelope and no signed compatibility attestation proves outcome-equivalence, meaning the same decisions over that envelope.

  • Atomic question Q10, what recovery protocol closes the orphaned-snapshot case?

  • Atomic question Q11, when is asynchronous synchronisation acceptable?

§3 Reasoning

  • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://github.com/opencontainers/image-spec/blob/main/spec.md#content-addressability] If logical equality is the thing that matters, the equality token must be content-addressed rather than human-labelled; otherwise two different compiled policies can share one nominal version or one mutable tag.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md] If bundle clients can already pin, cache, sign, and persist policy bundles, the missing control is not distribution itself but lifecycle provenance that carries the exact bundle identity with the governed asset.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://slsa.dev/spec/v1.0/provenance] Delivery is the required resynchronisation point because it is where one central promotion gate can compare current policy head, carried asset provenance, and proposed deployment artefact before Operation begins.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html; https://davidamitchell.github.io/Research/research/2026-04-26-permission-safe-rag-enterprise-information-architecture.html] The stale-policy continuity failure is a continuity bug, so the fix is a reconciliation protocol with explicit mismatch states, not a promise that every phase will always be online at the moment policy changes.
  • [inference; source: https://semver.org/; https://slsa.dev/spec/v1.0/provenance] Semantic version labels remain useful for release communication and compatibility intent, but enforcement truth has to be digest plus signed compatibility evidence rather than semantic version precedence alone.

§4 Consistency Check

  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://git-scm.com/book/en/v2/Git-Internals-Git-Objects] Potential contradiction resolved: OPA's native revision field is implementation-defined and may be a semantic label or commit-like string, so this item treats digest as canonical identity and revision as auxiliary metadata.
  • [inference; source: https://semver.org/; https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-addressable-storage] Potential contradiction resolved: semantic versioning is useful for communicating compatibility classes, but tags and version labels remain mutable references and cannot prove identical content in the way digest references can.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html] Potential contradiction resolved: Development soft gates and Operation hard gates need not be separately authored policies, because one canonical bundle can drive different phase projections and enforcement modes.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html] Potential contradiction resolved: offline operation does not break synchronisation if advancement to Delivery or Operation requires a later synchronous digest check and mismatch surfacing before promotion or deployment.

§5 Depth and Breadth Expansion

  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md] Technical lens: the technically minimal design is a deterministic compile step that emits canonical_policy_digest, one or more phase-projection digests, and a signed attestation binding the asset digest to those policy identifiers.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html; https://davidamitchell.github.io/Research/research/2026-04-26-agentic-ai-regulatory-preconditions-control-failure-assessment.html] Regulatory lens: on governance surfaces already covered elsewhere in the repository, silent policy drift is not merely a tooling defect; it weakens the ability to demonstrate coherent control operation under machine-speed decision making.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html] Economic lens: a synchronisation model that requires constant online connectivity at every phase would create brittle operational cost, so the control should concentrate synchronous validation at the narrowest set of consequential transition points.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-03-22-cross-scanner-compliance-evidence-normalisation.html; https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html] Behavioural lens: if material divergence only appears as informal documentation, developers will route around it; if it appears as typed diagnostics in Development and a blocking mismatch event in Delivery, the system makes the same risk visible at the two phases where users can still act on it.
  • [fact; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-addressable-storage; https://in-toto.io] Historical lens: content-addressed artefacts, digest-linked subjects, and signed provenance are already proven patterns in source control, artefact distribution, and software supply-chain integrity, so this item is composing established integrity primitives rather than inventing a new cryptographic control class.

§6 Synthesis

(This section seeds the Findings below.)

Executive summary:

  • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://www.openpolicyagent.org/docs/latest/management-bundles/; https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md] The strongest mechanism is a content-addressed policy-release model in which the PAP compiles one canonical policy bundle, assigns it an immutable digest, and requires every downstream PDP and asset transition to carry that digest as policy provenance.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html] Development and Operation remain logically identical when the LSP diagnostic surface and the runtime enforcement surface are phase projections of the same parent digest rather than separately authored rules.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] Delivery should be the mandatory promotion-stage re-synchronisation checkpoint, while pre-deployment admission remains the final runtime-bound synchronous check for consequential assets: promotion compares the asset-carried policy digest against the current approved PAP head, blocks on mismatch by default, and only proceeds when a signed compatibility attestation proves outcome-equivalence for the asset's declared evaluation envelope.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] Offline and intermittently connected contexts remain supportable because asynchronous bundle distribution is acceptable between phases, but advancement to consequential phases requires a later synchronous digest-validation step that turns the stale-policy continuity failure into an explicit mismatch event instead of a silent drift.

Key findings:

Evidence map:

Claim Source Confidence Notes
[inference] Canonical policy equality should be defined by content digest, not by mutable names or tags. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
https://github.com/opencontainers/image-spec/blob/main/spec.md#content-addressability
https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md 		high All three source families treat digest identity as the immutable reference.
[inference] Development and Operation should use phase projections of one parent digest. https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html
https://davidamitchell.github.io/Research/research/2026-03-22-cross-scanner-compliance-evidence-normalisation.html
https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html 		medium Prior work shows the diagnostic surface, the heterogeneity failure, and the PAP-side derivation logic, but this architecture remains a synthesis.
[inference] Assets need carried policy provenance including digest-bound identity. https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md
https://github.com/in-toto/attestation/blob/main/spec/v1/resource_descriptor.md
https://slsa.dev/spec/v1.0/provenance 		high Digest-bound subjects and dependencies are the relevant provenance pattern.
[inference] Delivery should be the mandatory promotion-stage re-synchronisation checkpoint, with pre-deployment admission as a separate final synchronous check for consequential assets. https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html
https://slsa.dev/spec/v1.0/provenance
https://docs.sigstore.dev/cosign/signing/signing_with_containers/ 		medium Delivery is the strongest central promotion gate; provenance and attestation carry the comparison inputs, but the checkpoint design remains inferential.
[inference] Material divergence should be evaluated by digest mismatch plus outcome impact over the asset envelope. https://semver.org/
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
https://slsa.dev/spec/v1.0/provenance
https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html 		medium Semantic versioning is informative, but digest and outcome equivalence decide enforceable compatibility.
[inference] Consequential transitions require synchronous validation even if distribution between phases is asynchronous. https://www.openpolicyagent.org/docs/latest/management-bundles/
https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html
https://davidamitchell.github.io/Research/research/2026-04-26-agentic-ai-regulatory-preconditions-control-failure-assessment.html 		medium OPA supports async distribution; adjacent work identifies the transitions where stronger control is required.
[inference] Detectability requires comparing carried asset digest against current required digest, not only local bundle freshness. https://www.openpolicyagent.org/docs/latest/management-bundles/
https://www.openpolicyagent.org/docs/latest/management/
https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html 		medium Status and bundle telemetry exist, but cross-phase reconciliation is still a control-plane design choice.
[inference] Orphaned snapshots should cause quarantine and re-evaluation. https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html
https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md
https://docs.sigstore.dev/cosign/signing/signing_with_containers/ 		medium This is the continuity-failure remedy translated into digest-bound policy provenance.

Assumptions:

  • [assumption; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://git-scm.com/book/en/v2/Git-Internals-Git-Objects] The PAP can compile policy bundles deterministically enough that identical source policy plus identical compile inputs produce identical canonical bundle bytes. Justification: content-addressed equality is only useful if the build step is stable; the retrieved sources establish the value of content identity but do not themselves guarantee one team's compiler determinism.
  • [assumption; source: https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] The estate can issue and verify signed attestations at Delivery and deployment time. Justification: the provenance and signing primitives are available in the retrieved sources, but the repository does not establish that every target platform already supports them operationally.

Analysis:

  • [inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://www.openpolicyagent.org/docs/latest/management-bundles/] The design problem is best separated into decision semantics and distribution semantics, because XACML and ABAC establish the decision architecture while OPA provides bundle transport and revision signalling, so the missing mechanism is the identity bridge between those two layers.
  • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-addressable-storage; https://semver.org/] That bridge should be digest-first and version-second, because semantic versions communicate release intent and compatibility classes to humans while content digests decide whether two policy artefacts are actually the same object.
  • [inference; source: https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md; https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] The asset therefore needs a policy provenance envelope, ideally an attestation whose subject is the asset digest and whose predicate records canonical_policy_digest, phase_projection_digest, signer, issuance time, and relevant evaluation envelope, because that is what makes cross-phase reconciliation possible without re-reading informal history.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] Delivery is the correct mandatory checkpoint because it sits after Development experimentation but before Operation consequences, and because earlier repository work already shows that continuity failures are best handled by an explicit reconciliation step at a durable state boundary.
  • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://semver.org/; https://www.openpolicyagent.org/docs/latest/management-bundles/] The recommended version-graph schema is node = {canonical_digest, semantic_version, parent_digest, phase_projection_digests, signer, created_at, compatibility_class, supersedes_digest} with edges such as supersedes, rollback_of, and compatible_with_subject_envelope. The digest identifies the artefact, while semantic version and compatibility edges explain how operators should reason about change.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html] The synchronous-versus-asynchronous decision rule is therefore narrow: asynchronous bundle distribution is acceptable whenever the consuming phase can pin a verified digest and surface staleness, while synchronous validation is required whenever the next transition would grant broader authority, external effects, or production persistence.

Risks, gaps, uncertainties:

  • [fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] OPA's documented bundle revision is a string chosen by the bundle service, not a guaranteed content hash, so teams that treat revision as equality truth without a canonical digest may still permit silent semantic drift.
  • [assumption; source: https://semver.org/] Semantic compatibility labels can mislead if policy authors claim MINOR or PATCH compatibility for a change that still alters decisions for a specific asset envelope, so compatibility attestations need outcome-based checks rather than label trust alone.
  • [inference; source: https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] The attestation-heavy design increases operational dependency on signing and verification infrastructure, which becomes part of the control surface and a possible new failure point.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] Offline contexts can still accumulate stale digests for long periods, so the system must distinguish "allowed to evaluate locally" from "allowed to advance to consequential phases" rather than assuming offline equality remains trustworthy indefinitely.

Open questions:

  • [inference; source: https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] Which attestation predicate shape is simplest for policy provenance in this repository's target platforms: a custom in-toto predicate, a SLSA byproduct, or an OCI referrer attached to the asset digest?
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html; https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html] How should the asset's declared evaluation envelope be formalised so outcome-equivalence is machine-checkable rather than a human approval note?
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html] What minimum stale-age threshold should force re-evaluation for intermittently connected deployments that can remain offline for extended periods but still need bounded local autonomy?

§7 Recursive Review

  • [fact; source: https://csrc.nist.gov/pubs/sp/800/162/final; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://www.openpolicyagent.org/docs/latest/management-bundles/; https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md; https://slsa.dev/spec/v1.0/provenance] The final synthesis stays within the retrieved evidence: access-control architecture comes from ABAC and XACML, bundle transport and revision signalling come from OPA, immutable identity comes from content-addressed and attestation sources, and lifecycle consequences come from adjacent completed items.
  • [fact; source: https://semver.org/; https://git-scm.com/book/en/v2/Git-Internals-Git-Objects] Every claim about equality versus compatibility distinguishes digest identity from semantic version intent, which resolves the main likely confusion point in this design space.
  • [fact; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html; https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] Adjacent repository items on Development diagnostics, Delivery gates, and continuity failure were checked again before seeding Findings, and their conclusions sharpen rather than contradict this item's synchronisation model.
  • [fact; source: https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-addressable-storage; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] No claim in Findings depends on an inaccessible or dead seeded source, because the final argument is carried by accessible official URLs and published completed-item links.

Findings

(Populated from Section 6 Synthesis above.)

Executive Summary

  • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://www.openpolicyagent.org/docs/latest/management-bundles/; https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md] The strongest mechanism is a content-addressed policy-release model in which the PAP compiles one canonical policy bundle, assigns it an immutable digest, and requires every downstream PDP and asset transition to carry that digest as policy provenance.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html] Development and Operation remain logically identical when the LSP diagnostic surface and the runtime enforcement surface are phase projections of the same parent digest rather than separately authored rules.
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] Delivery should be the mandatory promotion-stage re-synchronisation checkpoint, while pre-deployment admission remains the final runtime-bound synchronous check for consequential assets: promotion compares the asset-carried policy digest against the current approved PAP head, blocks on mismatch by default, and only proceeds when a signed compatibility attestation proves outcome-equivalence for the asset's declared evaluation envelope.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] Offline and intermittently connected contexts remain supportable because asynchronous bundle distribution is acceptable between phases, but advancement to consequential phases requires a later synchronous digest-validation step that turns the stale-policy continuity failure into an explicit mismatch event instead of a silent drift.

Key Findings

  1. [inference] Confidence: high. A canonical compiled policy bundle digest is the only reliable equality token for cross-phase synchronisation, because Git, OCI, and in-toto all show that mutable names and versions cannot prove identical content, while digests can. Sources: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ; https://github.com/opencontainers/image-spec/blob/main/spec.md#content-addressability ; https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md
  2. [inference] Confidence: medium. Development soft guidance and Operation hard enforcement remain logically identical only when both are generated as phase projections from the same parent policy digest, because otherwise the estate reintroduces the heterogeneous-gate inconsistency already observed in adjacent repository work. Sources: https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html ; https://davidamitchell.github.io/Research/research/2026-03-22-cross-scanner-compliance-evidence-normalisation.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html
  3. [inference] Confidence: high. Every governed asset should carry policy provenance as part of its identity record, at minimum the canonical policy digest, phase-projection digest, signer, and evaluation context envelope, because later lifecycle checkpoints cannot detect drift if the asset carries no verifiable memory of the policy it previously satisfied. Sources: https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md ; https://github.com/in-toto/attestation/blob/main/spec/v1/resource_descriptor.md ; https://slsa.dev/spec/v1.0/provenance
  4. [inference] Confidence: medium. Delivery should be the mandatory promotion-stage re-synchronisation point and should fail promotion on policy mismatch by default, because it is the strongest central gate where current PAP state, asset provenance, and deployment intent can still be compared before runtime consequences begin, while pre-deployment admission remains the final synchronous check before runtime execution. Sources: https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html ; https://slsa.dev/spec/v1.0/provenance ; https://docs.sigstore.dev/cosign/signing/signing_with_containers/
  5. [inference] Confidence: medium. Material divergence should mean any digest mismatch that changes rules, policy data, or derived decision outcomes over the asset's declared resource, action, and environment envelope unless a signed compatibility attestation explicitly proves outcome-equivalence for that envelope. Sources: https://semver.org/ ; https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ; https://slsa.dev/spec/v1.0/provenance ; https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html
  6. [inference] Confidence: medium. Asynchronous synchronisation is acceptable for advisory Development feedback and offline evaluation, but synchronous validation is required at promotion and pre-deployment admission for write-capable, privileged, or externally acting assets because those transitions create irreversible or hard-to-reverse consequences. Sources: https://www.openpolicyagent.org/docs/latest/management-bundles/ ; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html ; https://davidamitchell.github.io/Research/research/2026-04-26-agentic-ai-regulatory-preconditions-control-failure-assessment.html
  7. [inference] Confidence: medium. The stale-policy continuity failure becomes detectable only when the control plane compares two independently published identities, the policy digest carried by the asset and the currently approved digest reported or required by the control plane, because local bundle freshness alone does not reveal whether an already-built asset was validated under an older baseline. Sources: https://www.openpolicyagent.org/docs/latest/management-bundles/ ; https://www.openpolicyagent.org/docs/latest/management/ ; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html
  8. [inference] Confidence: medium. Orphaned policy snapshots, where the referenced bundle or attestation can no longer be resolved, should be treated as quarantine conditions rather than grandfathered exceptions, because unresolved provenance breaks both replayability and accountability for the policy state that authorized the asset. Sources: https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html ; https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md ; https://docs.sigstore.dev/cosign/signing/signing_with_containers/

Evidence Map

Claim Source Confidence Notes
[inference] Canonical policy equality should be defined by content digest, not by mutable names or tags. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
https://github.com/opencontainers/image-spec/blob/main/spec.md#content-addressability
https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md 		high All three source families treat digest identity as the immutable reference.
[inference] Development and Operation should use phase projections of one parent digest. https://davidamitchell.github.io/Research/research/2026-03-01-agent-lsp-policy-enforcement.html
https://davidamitchell.github.io/Research/research/2026-03-22-cross-scanner-compliance-evidence-normalisation.html
https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html 		medium Prior work shows the diagnostic surface, the heterogeneity failure, and the PAP-side derivation logic, but this architecture remains a synthesis.
[inference] Assets need carried policy provenance including digest-bound identity. https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md
https://github.com/in-toto/attestation/blob/main/spec/v1/resource_descriptor.md
https://slsa.dev/spec/v1.0/provenance 		high Digest-bound subjects and dependencies are the relevant provenance pattern.
[inference] Delivery should be the mandatory promotion-stage re-synchronisation checkpoint, with pre-deployment admission as a separate final synchronous check for consequential assets. https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html
https://slsa.dev/spec/v1.0/provenance
https://docs.sigstore.dev/cosign/signing/signing_with_containers/ 		medium Delivery is the strongest central promotion gate; provenance and attestation carry the comparison inputs, but the checkpoint design remains inferential.
[inference] Material divergence should be evaluated by digest mismatch plus outcome impact over the asset envelope. https://semver.org/
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
https://slsa.dev/spec/v1.0/provenance
https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html 		medium Semantic versioning is informative, but digest and outcome equivalence decide enforceable compatibility.
[inference] Consequential transitions require synchronous validation even if distribution between phases is asynchronous. https://www.openpolicyagent.org/docs/latest/management-bundles/
https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html
https://davidamitchell.github.io/Research/research/2026-04-26-agentic-ai-regulatory-preconditions-control-failure-assessment.html 		medium OPA supports async distribution; adjacent work identifies the transitions where stronger control is required.
[inference] Detectability requires comparing carried asset digest against current required digest, not only local bundle freshness. https://www.openpolicyagent.org/docs/latest/management-bundles/
https://www.openpolicyagent.org/docs/latest/management/
https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html 		medium Status and bundle telemetry exist, but cross-phase reconciliation is still a control-plane design choice.
[inference] Orphaned snapshots should cause quarantine and re-evaluation. https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html
https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md
https://docs.sigstore.dev/cosign/signing/signing_with_containers/ 		medium This is the continuity-failure remedy translated into digest-bound policy provenance.

Assumptions

  • [assumption; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://git-scm.com/book/en/v2/Git-Internals-Git-Objects] Assumption: The PAP can compile policy bundles deterministically enough that identical source policy plus identical compile inputs produce identical canonical bundle bytes. Justification: content-addressed equality is only useful if the build step is stable; the retrieved sources establish the value of content identity but do not themselves guarantee one team's compiler determinism.
  • [assumption; source: https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] Assumption: The estate can issue and verify signed attestations at Delivery and deployment time. Justification: the provenance and signing primitives are available in the retrieved sources, but the repository does not establish that every target platform already supports them operationally.

Analysis

  • [inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://www.openpolicyagent.org/docs/latest/management-bundles/] The design problem is best separated into decision semantics and distribution semantics, because XACML and ABAC establish the decision architecture while OPA provides bundle transport and revision signalling, so the missing mechanism is the identity bridge between those two layers.
  • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-addressable-storage; https://semver.org/] That bridge should be digest-first and version-second, because semantic versions communicate release intent and compatibility classes to humans while content digests decide whether two policy artefacts are actually the same object.
  • [inference; source: https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md; https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] The asset therefore needs a policy provenance envelope, ideally an attestation whose subject is the asset digest and whose predicate records canonical_policy_digest, phase_projection_digest, signer, issuance time, and relevant evaluation envelope, because that is what makes cross-phase reconciliation possible without re-reading informal history.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] Delivery is the correct mandatory checkpoint because it sits after Development experimentation but before Operation consequences, and because earlier repository work already shows that continuity failures are best handled by an explicit reconciliation step at a durable state boundary.
  • [inference; source: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects; https://semver.org/; https://www.openpolicyagent.org/docs/latest/management-bundles/] The recommended version-graph schema is node = {canonical_digest, semantic_version, parent_digest, phase_projection_digests, signer, created_at, compatibility_class, supersedes_digest} with edges such as supersedes, rollback_of, and compatible_with_subject_envelope. The digest identifies the artefact, while semantic version and compatibility edges explain how operators should reason about change.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html] The synchronous-versus-asynchronous decision rule is therefore narrow: asynchronous bundle distribution is acceptable whenever the consuming phase can pin a verified digest and surface staleness, while synchronous validation is required whenever the next transition would grant broader authority, external effects, or production persistence.

Risks, Gaps, and Uncertainties

  • [fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] OPA's documented bundle revision is a string chosen by the bundle service, not a guaranteed content hash, so teams that treat revision as equality truth without a canonical digest may still permit silent semantic drift.
  • [assumption; source: https://semver.org/] Semantic compatibility labels can mislead if policy authors claim MINOR or PATCH compatibility for a change that still alters decisions for a specific asset envelope, so compatibility attestations need outcome-based checks rather than label trust alone.
  • [inference; source: https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] The attestation-heavy design increases operational dependency on signing and verification infrastructure, which becomes part of the control surface and a possible new failure point.
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-03-18-stateless-agent-assumption-failure.html] Offline contexts can still accumulate stale digests for long periods, so the system must distinguish "allowed to evaluate locally" from "allowed to advance to consequential phases" rather than assuming offline equality remains trustworthy indefinitely.

Open Questions

  • [inference; source: https://slsa.dev/spec/v1.0/provenance; https://docs.sigstore.dev/cosign/signing/signing_with_containers/] Which attestation predicate shape is simplest for policy provenance in this repository's target platforms: a custom in-toto predicate, a SLSA byproduct, or an OCI referrer attached to the asset digest?
  • [inference; source: https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html; https://davidamitchell.github.io/Research/research/2026-04-26-policy-coherence-machine-checkable-prerequisite.html] How should the asset's declared evaluation envelope be formalised so outcome-equivalence is machine-checkable rather than a human approval note?
  • [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-identity-access-management-enterprise.html] What minimum stale-age threshold should force re-evaluation for intermittently connected deployments that can remain offline for extended periods but still need bounded local autonomy?

Output

(Filled in on completion, what was produced as a result of this research.)

Navigation

Home

By Tag

bureaucracy

change-management

coase

constraint-analysis

control-model

decision-rights

delegation

delivery-risk

demand-segmentation

enterprise

exception-handling

execution

flow

flow-design

flow-metrics

governance

governance-patterns

incentives

instability

institutional-economics

leading-indicators

operating-model

organisation

organisational-design

queue-design

queueing

regulated-enterprise

routing

throughput

throughput-risk

transaction-costs

triage

williamson

Clone this wiki locally