Universal policy synchronisation and integrity

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?

Findings

(Populated from Section 6 Synthesis above.)

Executive Summary

• 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.
• 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.
• 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.
• 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: Git content-addressable storage model ; Open Container Initiative (OCI) image specification, content addressability ; in-toto Statement specification
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: Policy-LSP / Guiding Headless Agents, completed item ; Cross-scanner compliance evidence normalisation, completed item ; PAP dynamic policy profiling and proportionality, completed item
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: in-toto Statement specification ; in-toto ResourceDescriptor specification ; Supply-chain Levels for Software Artifacts (SLSA) provenance v1.0
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: Deployment pipeline as governed gate, completed item ; Supply-chain Levels for Software Artifacts (SLSA) provenance v1.0 ; Sigstore Cosign signing 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: Semantic Versioning 2.0.0 ; Git content-addressable storage model ; Supply-chain Levels for Software Artifacts (SLSA) provenance v1.0 ; Policy coherence as a machine-checkable prerequisite, completed item
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: Open Policy Agent (OPA) bundle management ; AI agent identity and access management, completed item ; davidamitchell.github.io
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: Open Policy Agent (OPA) bundle management ; Open Policy Agent (OPA) management architecture ; Stateless-agent assumption failure, completed item
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: Stateless-agent assumption failure, completed item ; in-toto Statement specification ; Sigstore Cosign signing containers

Assumptions

• 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: 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

• 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.
• 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.
• 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.
• 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.
• 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.
• 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

• 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.
• 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.
• 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.
• 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

• 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?
• How should the asset's declared evaluation envelope be formalised so outcome-equivalence is machine-checkable rather than a human approval note?
• 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?

sources

• [x] Policy-LSP / Guiding Headless Agents, completed item — , LSP-like mechanisms as the right architectural pattern for real-time conformance guidance
• [x] Compliance scanning GitHub Actions, completed item — , empirical evidence of heterogeneous gate failure producing inconsistent evidence
• [x] Cross-scanner compliance evidence normalisation, completed item — , cross-scanner inconsistency as the symptom this architecture prevents
• [x] Organisational intent formal specification, completed item — , prior repository argument for treating governing logic as a formally versioned artefact
• [x] Stateless-agent assumption failure, completed item — , state orphaning across session boundaries
• [x] Policy coherence as a machine-checkable prerequisite, completed item — , why machine enforcement depends on a coherent policy artefact
• [x] Deployment pipeline as governed gate, completed item — , why Delivery is the practical resynchronisation checkpoint
• [x] AI agent identity and access management, completed item — , identity and provenance implications for non-human actors
• [x] Permission-safe Retrieval-Augmented Generation (RAG), completed item — , copied-state staleness and propagation-lag analogue
• [x] PAP dynamic policy profiling and proportionality, completed item — , adjacent work on PAP-side gate-topology derivation
• [x] NIST SP 800-162, Guide to Attribute-Based Access Control (ABAC) — , ABAC reference for subject, object, operation, and environment evaluation
• [x] eXtensible Access Control Markup Language (XACML) 3.0 core specification — , authoritative definitions of PAP, PDP, PEP, and PIP
• [x] Open Policy Agent (OPA) bundle management — , revisioned bundle distribution, caching, signing, and persistence
• [x] Open Policy Agent (OPA) management architecture — , control-plane telemetry and bundle/status architecture
• [x] Git content-addressable storage model — , canonical example of immutable content identity
• [x] Open Container Initiative (OCI) image specification, content addressability — , digest-addressed object identity
• [x] Open Container Initiative (OCI) distribution specification, content-addressable storage — , digest-addressed blobs, manifests, and subject/referrer relationships
• [x] in-toto framework overview — , supply-chain integrity model for steps, actors, and order
• [x] in-toto Statement specification — , immutable subject binding by digest
• [x] in-toto ResourceDescriptor specification — , digest semantics for immutable artefacts
• [x] Supply-chain Levels for Software Artifacts (SLSA) provenance v1.0 — , in-toto attestation predicate for subject and dependency provenance
• [x] Sigstore Cosign signing containers — , digest-bound signatures and attestations
• [x] Semantic Versioning 2.0.0 — , human-readable compatibility versioning rules