2026 04 27 uelgf policy architecture 8 layer context

Universal Entity Lifecycle Governance Framework (UELGF): policy architecture, Policy Administration Point, Policy Decision Point, Policy Enforcement Point, Policy Information Point component design, the 8-layer organisational context model, policy independence guarantee, scope boundary mechanism, and kill switch

Research Question

What policy architecture, covering Policy Administration Point (PAP), Policy Decision Point (PDP), Policy Enforcement Point (PEP), and Policy Information Point (PIP), and what 8-layer organisational context model should the UELGF specify to provide architecturally enforced policy independence, a machine-checkable scope boundary mechanism replacing intent-based reasoning, and a kill switch operable at single-entity, entity-class, and entity-type levels?

Scope

In scope:

Formal specification of the four policy architecture components and the architectural mandate for their separation: PAP as authoritative policy source, PDP as stateless evaluator, PEP as runtime enforcement point, PIP as entity registry and runtime signal store
The mechanism by which policy changes in the PAP propagate immediately to the PDP and become active for all entities without any action by entity owners, the policy independence guarantee
The 8-layer organisational context model: Layer 1 Regulatory, Layer 2 Risk Appetite, Layer 3 Values, Layer 4 Strategy, Layer 5 Standards, Layer 6 Patterns, Layer 7 Procedures, Layer 8 Scope, the entity's declared scope boundary
The scope boundary mechanism: how declared scope at scaffold generation is formalised as a machine-checkable specification, how the PDP evaluates whether a specific action is within that scope, and why out-of-scope actions are scope violations requiring escalation rather than simple policy denials
The kill switch mechanism: process for immediate licence-to-operate suspension at single entity, entity class, or entity type and confidentiality, integrity, and availability (CIA) tier levels, with automated consequences including credential revocation, action queue draining, dependency notification, and owner alert
The policy independence guarantee under Layer 1 regulatory change: mechanism by which a new regulatory obligation immediately revokes the licence to operate of any entity whose current behaviour would violate it
The relationship between the 8-layer context model and the CIA governance profile: which layers apply as hard constraints for each CIA tier

Out of scope:

Entity taxonomy and CIA classification, covered by 2026-04-27-uelgf-entity-taxonomy-cia-classification
Rail interface specifications and scaffold generation, covered by 2026-04-27-uelgf-governed-golden-rails
Runtime feedback loop signal processing, covered by 2026-04-27-uelgf-runtime-feedback-loop, though the PEP/PIP interaction is in scope
Foundational principles, covered by 2026-04-27-uelgf-foundational-definitions-principles

Constraints:

The PAP/PDP/PEP/PIP architecture must be specified at sufficient precision to serve as an engineering specification for implementation, not just a conceptual model
The policy independence guarantee must be architecturally enforced, not procedurally relied upon, so the specification must identify the mechanism, not merely state the requirement
The scope boundary mechanism must be machine-checkable: a human intent statement is not sufficient, because the specification must produce a format that a PDP can evaluate deterministically
The kill switch must operate within a defined maximum latency from trigger to effect, and the specification must state the latency requirement and how it is achieved

Context

[fact; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html] The eXtensible Access Control Markup Language (XACML) 3.0 specification defines PAP, PDP, PEP, and PIP as distinct system entities, which makes role separation an external standard anchor rather than a UELGF invention.
[fact; source: https://www.openpolicyagent.org/docs/latest/philosophy/; https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html; https://docs.cedarpolicy.com/] Open Policy Agent (OPA), Amazon Verified Permissions, and Cedar all externalize authorization logic from application code and allow policy updates without recompiling the governed application, which makes them relevant implementation analogues for policy independence.
[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/; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] This item matters because stale, incoherent, or locally overridden policy state would turn every later rail into a weak control surface, and the prior policy-coherence item already established that the decision layer only works if the policy estate is machine-checkable.
[inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-03-16-adaptive-policy-authorization-compliance.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-governance-enforcement-architecture.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] Prior completed research sharpens three adjacent surfaces for this item: dynamic authorization mechanics, layered enforcement placement, and the prerequisite need for coherent machine-readable policy.

Approach

PAP/PDP/PEP/PIP architecture specification: Survey the XACML 3.0 specification, OPA architecture, Cedar, Amazon Verified Permissions, and Azure Policy to produce a formal component specification for each of the four policy architecture components. For each component, specify responsibilities, interfaces, state model, dependency relationships, and failure modes.
Policy independence mechanism: Identify the architectural mechanism that enforces policy independence, meaning that a policy change in the PAP activates for all entities without any entity-owner action. Survey OPA bundle distribution, Verified Permissions template-linked policy propagation, and Azure Policy evaluation cycles. Specify the propagation latency requirement and the mechanism to achieve it.
8-layer context model formalisation: Survey whether existing context models in policy-as-code tooling, including OPA context data, XACML environment attributes, and Attribute-Based Access Control (ABAC) attribute hierarchies, provide structural analogues for the 8-layer model. For each layer, specify the content type, the accountable author, the update cadence, and the precedence rule.
Scope boundary as machine-checkable specification: Survey existing machine-checkable scope representations, including OAuth 2.0 scope strings, XACML attributes, Amazon Web Services (AWS) Identity and Access Management conditions, and Secure Production Identity Framework for Everyone (SPIFFE) workload identity plus SPIFFE Verifiable Identity Document (SVID) credentials, to determine which representations are precise enough for deterministic PDP evaluation. Produce the UELGF scope format and distinguish scope violations from policy denials.
Kill switch mechanism specification: Survey emergency suspension mechanisms including OAuth 2.0 token revocation in RFC 7009, Online Certificate Status Protocol (OCSP), Certificate Revocation List (CRL), and short-lived SPIFFE credentials. Specify the UELGF kill switch as a sequence of operations with latency budget and rollback rules.
Layer 1 regulatory change propagation: Specify the mechanism by which a Layer 1 regulatory change authored in the PAP immediately re-evaluates all active entities and suspends those whose current behaviour would violate the new rule.

Sources

Research Skill Output

Metadata: fallback process from research-prompt.md; the unavailable .github/skills/research/SKILL.md file was not used in this checkout.

§0 Initialise

[fact; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-03-16-adaptive-policy-authorization-compliance.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-governance-enforcement-architecture.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] Prior completed repository work relevant to this item covers dynamic authorization mechanics, layered enforcement placement, and the precondition that policy must be machine-checkable before it can govern reliably at runtime.
[fact; 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/; https://docs.cedarpolicy.com/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/; https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://www.rfc-editor.org/rfc/rfc5280.txt; https://csrc.nist.gov/pubs/sp/800/162/final; https://csrc.nist.gov/pubs/sp/800/207/final] The external source base for this item spans XACML, OPA, Cedar, Verified Permissions, SPIFFE, OAuth revocation, certificate-revocation standards, ABAC, and Zero Trust Architecture.
[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/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] The core design problem is not whether policy can be externalized, because that is already established, but how to specify freshness, scope determinism, and fail-safe revocation strongly enough that policy remains independent from entity-owned lifecycle events.
Metadata: output type = knowledge.

§1 Question Decomposition

A. Architecture definition
- A1. What responsibilities should the PAP, PDP, PEP, and PIP each own?
- A2. Which of those components must be stateful, and which must remain stateless?
- A3. What interfaces must exist between the four components?
- A4. What failure mode should each component surface to the others?
B. Policy independence
- B1. What technical mechanism makes a PAP change take effect without entity-owner action?
- B2. What freshness model is supported by current policy systems?
- B3. What staleness boundary should force fail-safe suspension?
C. Organisational context
- C1. What should each of the 8 layers contain?
- C2. Who authors each layer, and how often should it change?
- C3. What conflict-precedence order should apply between layers?
D. Scope boundary
- D1. What representations are too weak for deterministic scope checking?
- D2. What fields must a machine-checkable scope object include?
- D3. How should the PDP distinguish a scope violation from a policy denial?
E. Kill switch
- E1. Which revocation patterns transfer from OAuth and certificate infrastructure?
- E2. What automatic consequences should follow a kill-switch event?
- E3. What latency budget is defensible for entity, class, and type-level suspension?
F. Regulatory change
- F1. How should a new Layer 1 obligation flow through the architecture?
- F2. How should currently licensed entities be re-evaluated?
- F3. What should happen when the PDP or PIP cannot complete the re-evaluation on time?

§2 Investigation

2.1 Component model: PAP, PDP, PEP, and PIP

[fact; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html] XACML defines PAP as the system entity that creates policy or policy sets, PDP as the system entity that evaluates applicable policy and renders authorization decisions, PEP as the system entity that makes decision requests and enforces authorization decisions, and PIP as the system entity that acts as a source of attribute values.
[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] NIST SP 800-207 defines a closely related logical split between policy engine, policy administrator, policy enforcement point, and supporting data sources.
[fact; source: https://www.openpolicyagent.org/docs/latest/philosophy/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html] OPA and Verified Permissions both externalize decision logic from the governed application, which shows that runtime callers can remain thin while central policy logic changes independently.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.openpolicyagent.org/docs/latest/philosophy/] The UELGF PAP should therefore own only authoring, validation, signing, versioning, approval metadata, and publication of canonical policy bundles, not runtime decision execution.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html; https://www.openpolicyagent.org/docs/latest/philosophy/] The UELGF PDP should remain stateless with respect to policy authoring and entity lifecycle state, loading canonical policy plus request context and returning permit, deny, or indeterminate together with explicit reason codes and required obligations.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/terminology.html] The UELGF PEP should own request interception, submission of a typed decision request to the PDP, enforcement of the returned decision, and execution of mandatory obligations such as queue drain or credential disablement, but it should not compute local policy.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pip-invariant-anomaly-detection.md] The UELGF PIP should be stateful and should hold entity registration records, declared scope, active runtime attributes, current licence state, workload identity references, and high-salience anomaly signals, because those are the values the PDP cannot derive from the request alone.

2.2 Policy independence and propagation mechanics

[fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] OPA states that updated policies and data are loaded on the fly without restart and enforced immediately once loaded, but the bundle copy model is eventually consistent.
[fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] OPA bundle distribution supports entity tag (ETag) based revision tracking, short polling, HTTP long polling, persistence, and signature verification.
[fact; source: https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html] Verified Permissions says updates to a policy template are reflected across all template-linked policies that use that template.
[fact; source: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] Azure Policy applies new or updated assignments after a short delay and then evaluates resources, while standard compliance reevaluation runs once every 24 hours.
[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] Current systems show three propagation patterns: immediate logical propagation inside a managed policy store, rapid but eventually consistent bundle fanout, and slower compliance rescans for broad estate correction.
[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://www.openpolicyagent.org/docs/latest/management-decision-logs/; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pdp-universal-policy-synchronisation-integrity.md] Architecturally enforced policy independence for UELGF therefore requires one canonical signed policy head in the PAP, revisioned publication metadata, push or long-poll distribution to PDP instances, and a PDP freshness guard that refuses to authorize when its active revision is older than the PAP freshness service-level objective.
[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] A defensible latency requirement is two-tiered: the PAP must publish a signed policy revision within 60 seconds of approval, and every online PDP or PEP pair must either activate that revision or mark itself stale and suspend affected entities within 300 seconds, because OPA-style fanout is not truly synchronous but still supports low-minute convergence.

2.3 The 8-layer organisational context model

[fact; source: https://csrc.nist.gov/pubs/sp/800/162/final] ABAC decisions depend on subject, object, operation, and environment attributes, which means policy evaluation already assumes layered context rather than a single flat rule list.
[fact; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html] XACML distinguishes subject, resource, action, and environment attributes, which provides a structural analogue for separating organisation-wide constraints from entity-specific scope.
[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; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] The UELGF 8-layer model should be treated as a precedence stack over the policy vocabulary, not as eight unrelated document shelves, because policy coherence depends on knowing which layer wins when two rules conflict.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-control-plane-architecture-enterprise.md] Layer 1 Regulatory should hold external obligations and prohibitions, Layer 2 Risk Appetite should hold board-approved risk tolerances, Layer 3 Values should hold non-negotiable behavioural principles, and Layer 4 Strategy should hold enterprise objectives that are only valid inside the higher three layers.
[inference; source: https://www.openpolicyagent.org/docs/latest/philosophy/; https://learn.microsoft.com/en-us/azure/governance/policy/overview] Layer 5 Standards should hold reusable control requirements, Layer 6 Patterns should hold approved implementation blueprints, Layer 7 Procedures should hold operational runbooks, and Layer 8 Scope should hold the per-entity declared action envelope.
[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] Conflict precedence should run from Layer 1 down to Layer 8, with the lower layer allowed to specialize but never weaken the higher layer, because otherwise entity scope could override regulation or risk appetite.
[inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-uelgf-entity-taxonomy-cia-classification.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-governance-enforcement-architecture.md] CIA tiering should modulate how much of the stack becomes hard runtime constraint: Layer 1, Layer 2, Layer 5, and Layer 8 must always bind all tiers, while Layers 3, 4, 6, and 7 increasingly move from advisory to hard-constraint status as the tier rises.

2.4 Machine-checkable scope boundary

[fact; source: https://datatracker.ietf.org/doc/html/rfc7009] OAuth 2.0 token revocation is defined over individual tokens and grants, but the RFC does not define a typed action-resource envelope for business scope.
[fact; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html] XACML evaluates access requests over subject, resource, action, and environment attributes.
[fact; source: https://docs.cedarpolicy.com/; https://docs.cedarpolicy.com/policies/validation.html] Cedar requires policies to reason over principals, actions, resources, context, and a schema that validates the permitted entity and action model before runtime.
[fact; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] SPIFFE gives workloads strong machine identity and short-lived credentials, but SPIFFE IDs identify workloads rather than the full set of actions and resources that a workload is allowed to touch.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://docs.cedarpolicy.com/; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] OAuth-style string scopes are too weak for UELGF because they compress complex resource, action, data-domain, and side-effect boundaries into opaque labels, while workload identity alone is also too weak because identity does not encode declared business envelope.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/terminology.html; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html] The UELGF scope boundary should therefore be a typed scope object validated at registration time with at least these fields: entity_id, entity_type, cia_tier, allowed_actions, allowed_resource_classes, allowed_data_domains, allowed_connectors, allowed_side_effect_classes, lifecycle_phase, human_approval_requirements, max_transaction_or_batch_limits, and expiry_or_review_date.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://docs.cedarpolicy.com/policies/validation.html; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] A policy denial occurs when organisational policy forbids a requested action even though the action lies inside the entity's declared scope object, while a scope violation occurs when the requested action is outside that scope object and should be escalated as a registration or misuse defect rather than treated as an ordinary business-rule denial.

2.5 Kill switch and licence suspension

[fact; source: https://datatracker.ietf.org/doc/html/rfc7009] RFC 7009 defines a revocation endpoint through which a client can request invalidation of a refresh token or access token, and the revocation can also invalidate other tokens based on the same authorization grant.
[fact; source: https://www.rfc-editor.org/rfc/rfc6960.txt] RFC 6960 says OCSP is useful when timely revocation information is required and explicitly cites high-value funds transfers and large stock trades as examples.
[fact; source: https://www.rfc-editor.org/rfc/rfc5280.txt] RFC 5280 defines the Certificate Revocation List profile, which is the batch revocation analogue to certificate-status checking.
[fact; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] SPIFFE concepts state that workload private keys and corresponding certificates are short lived, rotated frequently and automatically, and refreshed through the Workload API.
[inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://www.rfc-editor.org/rfc/rfc5280.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] A UELGF kill switch should combine four revocation channels rather than rely on one: immediate licence-state change in the PIP, credential invalidation or non-renewal for workload identity, token or session revocation for live connectors, and queue or scheduler drain for already-enqueued actions.
[inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The operational sequence should be declare suspended -> publish deny record -> revoke or stop renewing credentials -> terminate or drain pending work -> notify dependencies and owners -> require explicit re-licensing for rollback, because the denial must become authoritative before slower credential expiry completes.
[inference; source: https://www.rfc-editor.org/rfc/rfc6960.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The latency budget should be stricter for narrower blast radius and looser for wider fanout: single entity suspension within 60 seconds, entity-class suspension within 180 seconds, and entity-type suspension within 300 seconds, with the fast path achieved by deny-first licence-state publication and the slower path reflecting credential and dependency propagation.
[assumption; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/; https://datatracker.ietf.org/doc/html/rfc7009] The runtime estate can revoke connector sessions or stop renewing workload credentials quickly enough that queue drain and dependency notification become the dominant residual delay. Justification: the standards show revocation and short-lived credentials are feasible patterns, but the exact estate-specific propagation speed depends on implementation choices that are outside the source set.

2.6 Layer 1 regulatory change propagation

[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] Zero Trust Architecture treats authorization as a discrete function and assumes that trust should not be granted permanently based on prior state or location alone.
[fact; source: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] Azure Policy supports reassessment on assignment creation, assignment update, resource update, on-demand scan, and regular reevaluation cycles.
[fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] OPA captures bundle revision in decision logs, which allows a control plane to prove which policy revision produced each decision.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://www.openpolicyagent.org/docs/latest/management-bundles/; https://www.openpolicyagent.org/docs/latest/management-decision-logs/; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] When a Layer 1 regulatory change is approved in the PAP, the PAP should publish a new signed revision, trigger an immediate portfolio re-evaluation job over the active entity registry in the PIP, and require every online PDP or PEP to reject affected actions until the entity's licence status has been recomputed under the new revision.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pdp-universal-policy-synchronisation-integrity.md] The re-evaluation job should not ask entity owners to resubmit or acknowledge anything, because that would collapse policy independence back into entity lifecycle dependence.
[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://csrc.nist.gov/pubs/sp/800/207/final] If the PDP or PIP cannot confirm freshness or recompute a required licence decision within the staleness window, the affected entity must move to suspended_pending_revalidation and the PEP must fail closed for consequential actions.

2.7 Failure handling and auditability

[fact; source: https://www.openpolicyagent.org/docs/latest/management-decision-logs/] OPA decision logs can include decision identifier, query input, result, requester, timestamp, and bundle revision metadata.
[fact; source: https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/terminology.html] Verified Permissions distinguishes determining policies from merely considered policies, which shows the value of returning explicit explanation data with the decision.
[fact; source: https://docs.cedarpolicy.com/policies/validation.html] Cedar validation warns that schema changes can invalidate previously valid policies and that policies which always error or never match do not influence the authorization decision.
[inference; source: https://www.openpolicyagent.org/docs/latest/management-decision-logs/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/terminology.html; https://docs.cedarpolicy.com/policies/validation.html] UELGF decision records should therefore capture the policy revision, determining rules, scope-object revision, licence state, any applied obligations, and whether the decision was a policy denial, a scope violation, a stale-policy fail-closed event, or a kill-switch suspension, because those distinctions matter operationally and regulatorily.
[assumption; source: https://www.openpolicyagent.org/docs/latest/management-decision-logs/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/terminology.html] The estate can route this evidence into a single durable audit repository keyed by entity identifier and policy revision. Justification: the source set proves that decision metadata can be emitted, but not that every target platform already has a unified evidence store.

§3 Reasoning

[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://csrc.nist.gov/pubs/sp/800/207/final] The strongest architecture anchor is the XACML and Zero Trust split of authoring, decisioning, enforcement, and supporting data, because it gives UELGF a standards-backed separation-of-duties model.
[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] The freshest propagation evidence shows that "immediate for all entities" must be operationalized as "no entity owner action and bounded convergence with fail-safe suspension," not as literal global synchrony.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] Scope determinism requires typed schema plus typed request context, so neither plain-language intent nor coarse OAuth-style strings are enough for the UELGF boundary mechanism.
[inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The kill switch has to be deny-first rather than credential-first, because token or certificate propagation alone can never guarantee the sub-minute stop behaviour that the framework needs for high-consequence actions.
[inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pdp-universal-policy-synchronisation-integrity.md] Prior repo work strengthens the conclusion that policy identity, coherence, and freshness are separate problems, and UELGF needs all three solved together rather than treating "current policy" as self-evident.

§4 Consistency Check

[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html] There is no contradiction between OPA's eventually consistent distribution and Verified Permissions' more immediate template-linked propagation, because the first is a distributed-bundle pattern and the second is a managed-policy-store pattern.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] There is no contradiction between requiring typed scope objects and using SPIFFE identities, because SPIFFE identifies the workload and the scope object identifies what that workload is licensed to do.
[inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://www.rfc-editor.org/rfc/rfc5280.txt] There is no contradiction between token revocation, OCSP, and CRLs, because they operate at different revocation surfaces and timescales.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://www.openpolicyagent.org/docs/latest/management-bundles/] The only substantive tension in the evidence is the gap between desired immediacy and distributed-system convergence, and the fail-closed freshness guard resolves that tension more safely than pretending distribution is synchronous.

§5 Depth and Breadth Expansion

[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] Technical lens: the most important technical choice is to make policy freshness and licence freshness explicit state variables, because otherwise stale but syntactically valid decision paths will look healthy in logs.
[inference; source: https://csrc.nist.gov/pubs/sp/800/162/final; https://docs.cedarpolicy.com/policies/validation.html] Regulatory lens: typed scope and typed policy matter because reviewable governance depends on being able to show exactly which subject, resource, action, and context combinations were permitted or blocked.
[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html] Economic lens: a managed PDP reduces platform work for one authorization subdomain, but UELGF still needs its own PAP, PIP, and revocation plane because enterprise licence-to-operate governance spans more than a single application policy store.
[inference; source: https://www.rfc-editor.org/rfc/rfc6960.txt; https://www.rfc-editor.org/rfc/rfc5280.txt] Historical lens: high-consequence infrastructure has long used layered revocation patterns, so UELGF's kill switch is better viewed as an adaptation of established safety practice than as a novel control invention.
[inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-governance-enforcement-architecture.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-control-plane-architecture-enterprise.md] Behavioural lens: the architecture must assume local teams will otherwise solve urgency by embedding exceptions in lifecycle tooling, so canonical policy publication plus local fail-closed behaviour is as much an anti-workaround design as it is a technical pattern.

§6 Synthesis

[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/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] Executive summary: UELGF should implement policy independence through a canonical PAP that publishes signed policy revisions to stateless PDPs, with every PEP failing closed when policy freshness cannot be proven, because XACML role separation, OPA revisioned bundle fanout, Verified Permissions propagation semantics, and prior repository work all show that local policy ownership is the failure mode to avoid.
[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; https://docs.cedarpolicy.com/policies/validation.html] Executive summary: The 8-layer context model should be a precedence stack in which Layers 1 to 7 are organisational constants and Layer 8 is the per-entity typed scope object, because ABAC and XACML already treat decisions as structured attribute evaluation rather than free-text intent interpretation.
[inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] Executive summary: The kill switch should be deny-first licence suspension plus token revocation, workload-credential invalidation or non-renewal, queue drain, and dependency notification, because revocation standards and short-lived workload identities show that one revocation surface alone is too slow or too narrow.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] Executive summary: A new Layer 1 rule must trigger automated portfolio re-evaluation from the PAP through the PIP registry and into every PDP, with entities moving to suspended pending revalidation if freshness or recomputation misses the time budget.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://csrc.nist.gov/pubs/sp/800/207/final] Key finding (High): The component split should follow the standards model exactly enough that the PAP authors and publishes policy, the PDP evaluates policy, the PEP enforces the returned decision, and the PIP supplies entity and runtime attributes, because both XACML and Zero Trust Architecture use that division to keep decision logic separate from enforcement and supporting data.
[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] Key finding (High): Policy independence is best specified as signed revision publication plus bounded-distribution freshness guarantees rather than literal instantaneous fanout, because distributed PDP estates can converge quickly but not synchronously, and the safe response to missed freshness is automatic suspension rather than silent continued operation.
[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; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] Key finding (High): The 8-layer model should be encoded as an ordered constraint stack where lower layers may specialize but never weaken higher layers, because otherwise entity scope or local procedure could override regulation, risk appetite, or enterprise standards and destroy machine-checkable coherence.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] Key finding (High): The machine-checkable scope boundary must be a typed object covering actions, resources, data domains, connectors, side effects, approval requirements, and limits, because neither workload identity nor coarse string scopes can tell the PDP whether a specific requested action falls inside the registered licence envelope.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://docs.cedarpolicy.com/policies/validation.html] Key finding (High): Scope violations and policy denials must be recorded as different decision classes, because an out-of-scope request signals an entity-registration or misuse defect while an in-scope denial signals a valid organisational prohibition being enforced as designed.
[inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://www.rfc-editor.org/rfc/rfc5280.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] Key finding (Medium): The kill switch should execute as a multi-channel stop protocol with single-entity suspension in 60 seconds, class suspension in 180 seconds, and type suspension in 300 seconds, because deny-first licence publication is fast while credential, queue, and dependency propagation complete on a slightly slower control path.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] Key finding (High): A Layer 1 regulatory update should trigger automatic re-evaluation of all active licensed entities from the PIP registry without owner action, and any entity whose new decision cannot be recomputed inside the freshness window should move to suspended pending revalidation until the new decision is known.
[inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-governance-enforcement-architecture.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-control-plane-architecture-enterprise.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pap-dynamic-policy-profiling-proportionality.md] Key finding (Medium): The architecture should treat CIA tier as a hardening selector over the same policy stack rather than as a separate governance regime, because adjacent repository work shows that layered enforcement, control-plane composition, and proportional PAP logic are strongest when they share one canonical source of truth.
Evidence map:

Claim	Source	Confidence	Notes
[inference] PAP, PDP, PEP, and PIP should remain separate roles.	https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://csrc.nist.gov/pubs/sp/800/207/final	high	Standards-backed logical decomposition applied to UELGF design.
[inference] Policy independence requires signed revision publication, freshness checks, and fail-closed suspension on staleness.	https://www.openpolicyagent.org/docs/latest/management-bundles/ ; https://www.openpolicyagent.org/docs/latest/management-decision-logs/ ; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html ; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pdp-universal-policy-synchronisation-integrity.md	high	Immediate logical change is feasible, but distributed convergence must be bounded and auditable.
[inference] The 8-layer model should be encoded as an ordered constraint stack.	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://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md	high	Layer 8 can specialize, not weaken, Layers 1 to 7.
[inference] The scope boundary must be a typed object, not a coarse scope string or workload identity alone.	https://docs.cedarpolicy.com/policies/validation.html ; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/	high	Deterministic PDP evaluation needs typed resource and action semantics.
[inference] Scope violations and policy denials are different decision classes.	https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://docs.cedarpolicy.com/policies/validation.html	high	Separate classes improve escalation and audit meaning.
[inference] The kill switch should use deny-first licence suspension plus token, certificate, queue, and dependency actions with bounded latency.	https://datatracker.ietf.org/doc/html/rfc7009 ; https://www.rfc-editor.org/rfc/rfc6960.txt ; https://www.rfc-editor.org/rfc/rfc5280.txt ; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/	medium	Exact timing is synthesis-level design, not explicit in a single source.
[inference] Layer 1 regulatory change must re-evaluate all active entities automatically and suspend stale or unrecomputed ones.	https://csrc.nist.gov/pubs/sp/800/207/final ; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers ; https://www.openpolicyagent.org/docs/latest/management-decision-logs/	high	Owner-mediated revalidation would break policy independence.
[inference] CIA tier should harden one shared policy stack instead of creating a second governance regime.	https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-governance-enforcement-architecture.md ; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-control-plane-architecture-enterprise.md ; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pap-dynamic-policy-profiling-proportionality.md	medium	Adjacent repo work is convergent but not a formal external standard.

Assumptions:
- [assumption; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/; https://datatracker.ietf.org/doc/html/rfc7009] The target estate can revoke connector sessions or stop renewing workload credentials quickly enough that the remaining latency is dominated by queue drain and notification. Justification: the standards prove the revocation patterns exist, but they do not guarantee one universal enterprise propagation speed.
- [assumption; source: https://www.openpolicyagent.org/docs/latest/management-decision-logs/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/terminology.html] The target estate can centralize decision evidence by entity identifier and policy revision. Justification: the sources prove rich decision metadata can be emitted, but not that every platform already writes into a single durable evidence store.
Analysis:
- [inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://csrc.nist.gov/pubs/sp/800/207/final] I weighted XACML and Zero Trust most heavily for the core decomposition because they define the cleanest role boundaries and keep policy logic distinct from enforcement.
- [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] I weighted OPA, Verified Permissions, and Azure Policy most heavily for propagation because together they show the real trade-off between low-latency updates, managed policy stores, and estate-wide rescan cycles.
- [inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] I treated schema-validated policy and workload identity as complementary rather than competing mechanisms, because one tells the system who is acting and the other tells it what that actor is licensed to do.
- [inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] I treated the kill-switch timing as medium confidence because the control sequence is well grounded in multiple revocation patterns, but the exact second counts are architectural synthesis rather than quoted requirements.
Risks, gaps, uncertainties:
- [fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] OPA bundle activation is eventually consistent, so any design that promises literal globally simultaneous activation would overstate what the source supports.
- [fact; source: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] Azure Policy includes slower compliance cycles, which means it is a useful analogue for broad corrective governance but not for sub-minute suspension guarantees.
- [assumption; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The proposed kill-switch timings assume short-lived workload credentials and accessible renewal controls.
- [assumption; source: https://docs.cedarpolicy.com/policies/validation.html] The scope-object design assumes the enterprise can model actions, resources, connectors, and side-effect classes in a stable schema.
Open questions:
- [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.cedarpolicy.com/policies/validation.html] What exact compatibility rules should permit a policy revision to reuse a prior entity scope object without forced re-registration?
- [inference; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/; https://datatracker.ietf.org/doc/html/rfc7009] Which runtime connectors in the target estate support immediate session revocation, which support only non-renewal, and which require compensating PEP-side blocks?
- [inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pip-invariant-anomaly-detection.md] How should high-confidence anomaly signals from the PIP interact with the scope-violation path without producing excessive false suspensions?

§7 Recursive Review

Acronym audit: completed for UELGF, PAP, PDP, PEP, PIP, CIA, ABAC, XACML, OPA, AWS, SPIFFE, SVID, OCSP, and CRL.
Claim-label audit: completed across Context, Research Skill Output, Findings, and the Evidence Map.
Remaining uncertainty: exact kill-switch timing and audit-store unification, both already marked as assumptions or medium-confidence synthesis.

Findings

Executive Summary

[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/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] UELGF should implement policy independence through one canonical PAP that publishes signed policy revisions to stateless PDPs, with every PEP failing closed when freshness cannot be proven, because standards and current policy-engine practice support separated roles and bounded revision fanout but do not support safe local override.

[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; https://docs.cedarpolicy.com/policies/validation.html] The 8-layer context model should be encoded as an ordered constraint stack in which Layers 1 to 7 are organisation-wide constants and Layer 8 is a typed per-entity scope object, because deterministic ABAC and XACML-style evaluation requires structured attributes and precedence, not intent interpretation.

[inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The kill switch should suspend licence-to-operate first and then fan out revocation across tokens, workload credentials, pending work, and dependencies, because each revocation mechanism covers a different delay surface and none is sufficient on its own for high-consequence stop authority.

[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] A new Layer 1 rule should trigger automatic portfolio re-evaluation without entity-owner action, and any entity whose new licence decision cannot be recomputed inside the freshness window should move to suspended_pending_revalidation until the architecture can prove compliance under the new revision.

Key Findings

High confidence: [inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://csrc.nist.gov/pubs/sp/800/207/final] The component split should follow the standards model closely enough that the PAP authors and publishes policy, the PDP evaluates policy, the PEP enforces returned decisions and obligations, and the PIP supplies entity and runtime attributes, because both XACML and Zero Trust Architecture rely on that separation to prevent policy logic from collapsing into enforcement code.
High confidence: [inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] Policy independence is best specified as signed revision publication plus bounded-distribution freshness guarantees rather than literal global synchrony, because distributed PDP estates can converge quickly but not instantaneously, and the safe response to missed freshness is automatic suspension rather than silent continued authorization.
High confidence: [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; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md] The 8-layer model should be encoded as an ordered constraint stack where lower layers may specialize but never weaken higher layers, because otherwise entity scope or local procedure could override regulation, risk appetite, or enterprise standards and destroy machine-checkable policy coherence.
High confidence: [inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The machine-checkable scope boundary must be a typed object covering actions, resources, data domains, connectors, side effects, approval requirements, and numeric limits, because neither workload identity nor coarse string scopes can tell the PDP whether a specific requested action lies inside the registered licence envelope.
High confidence: [inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://docs.cedarpolicy.com/policies/validation.html] Scope violations and policy denials must be recorded as different decision classes, because an out-of-scope request signals an entity-registration or misuse defect while an in-scope denial signals a valid organisational prohibition being enforced as intended.
Medium confidence: [inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://www.rfc-editor.org/rfc/rfc5280.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The kill switch should execute as a multi-channel stop protocol with single-entity suspension in 60 seconds, class suspension in 180 seconds, and type suspension in 300 seconds, because deny-first licence publication is fast while token, certificate, queue, and dependency propagation complete on a slightly slower control path.
High confidence: [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers; https://www.openpolicyagent.org/docs/latest/management-decision-logs/] A Layer 1 regulatory update should trigger automatic re-evaluation of all active licensed entities from the PIP registry without owner action, and any entity whose new decision cannot be recomputed inside the freshness window should move to suspended pending revalidation until the architecture can prove compliance under the new revision.
Medium confidence: [inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-governance-enforcement-architecture.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-control-plane-architecture-enterprise.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pap-dynamic-policy-profiling-proportionality.md] The architecture should treat CIA tier as a hardening selector over one shared policy stack rather than as a separate governance regime, because adjacent repository work shows that layered enforcement, control-plane composition, and proportional PAP logic are strongest when they share one canonical source of truth.

Evidence Map

Claim	Source	Confidence	Notes
[fact] PAP, PDP, PEP, and PIP should remain separate roles.	https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://csrc.nist.gov/pubs/sp/800/207/final	high	Direct standards anchor.
[inference] Policy independence requires signed revision publication, freshness checks, and fail-closed suspension on staleness.	https://www.openpolicyagent.org/docs/latest/management-bundles/ ; https://www.openpolicyagent.org/docs/latest/management-decision-logs/ ; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html ; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pdp-universal-policy-synchronisation-integrity.md	high	Distribution can be bounded and audited, not truly synchronous.
[inference] The 8-layer model should be encoded as an ordered constraint stack.	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://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-policy-coherence-machine-checkable-prerequisite.md	high	Layer 8 specializes but never weakens higher layers.
[inference] The scope boundary must be a typed object, not a coarse scope string or workload identity alone.	https://docs.cedarpolicy.com/policies/validation.html ; https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/	high	Deterministic evaluation needs typed request semantics.
[inference] Scope violations and policy denials are different decision classes.	https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://docs.cedarpolicy.com/policies/validation.html	high	Different classes imply different escalation and remediation paths.
[inference] The kill switch should use deny-first licence suspension plus token, certificate, queue, and dependency actions with bounded latency.	https://datatracker.ietf.org/doc/html/rfc7009 ; https://www.rfc-editor.org/rfc/rfc6960.txt ; https://www.rfc-editor.org/rfc/rfc5280.txt ; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/	medium	Exact timings are synthesis-level design.
[inference] Layer 1 regulatory change must re-evaluate all active entities automatically and suspend stale or unrecomputed ones.	https://csrc.nist.gov/pubs/sp/800/207/final ; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers ; https://www.openpolicyagent.org/docs/latest/management-decision-logs/	high	Owner-mediated acknowledgement would break policy independence.
[inference] CIA tier should harden one shared policy stack instead of creating a second governance regime.	https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-governance-enforcement-architecture.md ; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-control-plane-architecture-enterprise.md ; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pap-dynamic-policy-profiling-proportionality.md	medium	Repository cross-reference qualifies this design choice.

Assumptions

[assumption; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/; https://datatracker.ietf.org/doc/html/rfc7009] Assumption: The target estate can revoke connector sessions or stop renewing workload credentials quickly enough that queue drain and notification become the dominant residual delay. Justification: the standards prove the revocation patterns exist, but they do not prove one universal enterprise propagation speed.
[assumption; source: https://www.openpolicyagent.org/docs/latest/management-decision-logs/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/terminology.html] Assumption: The target estate can centralize decision evidence by entity identifier and policy revision. Justification: the sources prove rich decision metadata can be emitted, but not that every platform already writes into one durable evidence store.

Analysis

[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://csrc.nist.gov/pubs/sp/800/207/final] The strongest architecture anchors were XACML and Zero Trust Architecture because both define clean role boundaries and support the claim that policy logic should not live inside every enforcement surface.

[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-templates.html; https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] The propagation conclusion weighs OPA, Verified Permissions, and Azure Policy together because they expose the real design space: rapid signed fanout, managed logical propagation inside a policy store, and slower estate-wide reassessment loops.

[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The scope-boundary conclusion rejects both plain-language intent and identity-only licensing because the evidence shows that schema-validated request semantics and workload identity solve different halves of the determinism problem.

[inference; source: https://datatracker.ietf.org/doc/html/rfc7009; https://www.rfc-editor.org/rfc/rfc6960.txt; https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The kill-switch timing remains medium confidence because the revocation mechanisms are well supported, but the exact second-count service-level objectives are an engineering synthesis rather than a quoted external requirement.

Risks, Gaps, and Uncertainties

[fact; source: https://www.openpolicyagent.org/docs/latest/management-bundles/] OPA bundle activation is eventually consistent, so any UELGF wording that promises literal globally simultaneous activation would overstate what the source supports.
[fact; source: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers] Azure Policy demonstrates useful reassessment triggers, but its slower compliance cycles make it an analogue for broad correction rather than for sub-minute suspension.
[assumption; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/] The proposed kill-switch timings assume short-lived workload credentials and accessible renewal controls.
[assumption; source: https://docs.cedarpolicy.com/policies/validation.html] The typed scope-object design assumes the enterprise can model actions, resources, connectors, and side-effect classes in a stable schema and keep that schema current.

Open Questions

[inference; source: https://www.openpolicyagent.org/docs/latest/management-bundles/; https://docs.cedarpolicy.com/policies/validation.html] What compatibility rules should allow a policy revision to reuse a prior scope object without forcing entity re-registration?
[inference; source: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/; https://datatracker.ietf.org/doc/html/rfc7009] Which connector classes in the target estate support immediate session revocation, which support only non-renewal, and which require compensating PEP-side hard blocks?
[inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-27-pip-invariant-anomaly-detection.md] How should high-confidence anomaly signals from the PIP influence the scope-violation path without producing excessive false suspensions?