2026 04 28 uelgf tooling reference architecture

UELGF extension: tooling specification and reference architecture for policy-as-code, observability, and IAM implementation

Research Question

What concrete reference architecture and tooling specification, covering policy-as-code engines such as Open Policy Agent (OPA) and Cedar, observability pipelines such as OpenTelemetry (OTel), and modern Identity and Access Management (IAM) systems for revocable credentials, is required to implement the Universal Entity Lifecycle Governance Framework (UELGF) rail and policy stack as deployable engineering infrastructure in a regulated financial institution?

Scope

In scope:

Evaluation of policy-as-code engines for implementing the UELGF eight-layer policy architecture: specifically Open Policy Agent (OPA) and Amazon Cedar, covering policy language expressiveness, performance at enforcement points, auditability, version control integration, and suitability for financial services regulatory requirements
Reference architecture for the UELGF Policy Decision Point (PDP): how policy evaluation requests are routed, what the policy bundle distribution mechanism is, what latency the evaluation path must meet, and how policy synchronisation integrity is maintained (extending 2026-04-27-pdp-universal-policy-synchronisation-integrity)
Observability pipeline design using OpenTelemetry (OTel) for the UELGF runtime feedback loop: what telemetry signals map to the UELGF signal taxonomy, how trace context propagates across agent-to-tool and agent-to-agent boundaries, and what instrumentation the governed golden-rail scaffold must emit for feedback closure
IAM system requirements for UELGF-compatible revocable credential issuance: what credential formats support lifecycle-bound issuance and revocation, how the kill switch mechanism in the UELGF policy architecture depends on the IAM implementation, and what modern IAM capabilities (short-lived tokens, workload identity, certificate-based revocation) satisfy the framework's revocation requirements
Integration architecture: how OPA or Cedar, the OTel pipeline, and the IAM system compose into a coherent platform engineering stack that implements the UELGF rail without requiring bespoke tooling
Identification of implementation constraints specific to a regulated financial institution: data residency, audit log immutability, vendor approval processes, and the distinction between what can be implemented with off-the-shelf tooling versus what requires custom integration

Out of scope:

Procurement recommendations or vendor comparisons beyond technical capability assessment (no commercial recommendation is the output of this item)
Detailed deployment runbooks or Infrastructure as Code (IaC) templates (focus is on reference architecture, not deployment automation)
Security hardening guides for the individual tools (OPA, Cedar, OTel, IAM), those are covered by vendor documentation; focus here is on governance integration
Training-time AI model tooling (focus is on runtime governance tooling)

Constraints:

Must produce findings expressed as reference architecture artefacts (component diagrams, interface contracts, or equivalent structured specifications) rather than only prose
Must be grounded in the UELGF complete framework specification (2026-04-27-uelgf-synthesis-complete-framework), and all tooling choices must map to specific UELGF components (Policy Decision Point (PDP), Policy Administration Point (PAP), Policy Information Point (PIP), Policy Enforcement Point (PEP), runtime feedback loop)
Must address the distinction between tools that are already present in a typical large financial institution's approved tooling estate versus tools that require new approval (net-new vs extend-existing)
Must include a minimum viable stack, the smallest set of tooling changes that enables a meaningful subset of UELGF capabilities, to support organisations at different governance maturity levels

Context

[fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-synthesis-complete-framework.html; https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-policy-architecture-8-layer-context.html; https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-runtime-feedback-loop.html] The Universal Entity Lifecycle Governance Framework (UELGF) already specifies governed rails, an eight-layer policy context model, separated Policy Administration Point (PAP), Policy Decision Point (PDP), Policy Information Point (PIP), and Policy Enforcement Point (PEP) roles, a runtime feedback loop, and a kill switch, but the synthesis item explicitly left tooling design open.
[fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html; https://davidamitchell.github.io/Research/research/2026-04-27-pip-invariant-anomaly-detection.html; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html] Adjacent completed items already define the proportional PAP topology rule, PDP policy synchronisation and integrity requirements, PIP anomaly-signal requirements, and out-of-band invalidation model, so the unresolved problem is no longer what the control surfaces are, but which existing tools bind to them credibly.
[fact; source: 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-ai-lowcode-observability-telemetry-governance.html; https://davidamitchell.github.io/Research/research/2026-04-27-cryptographic-intent-preservation-runtime-evaluation.html] Prior repository work also established that accountable machine identity, reconstructable telemetry, and digest-bound policy lineage are prerequisite control surfaces for runtime governance in enterprise environments.
[inference; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-synthesis-complete-framework.html; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.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-ai-lowcode-observability-telemetry-governance.html] This item therefore has to convert a conceptual governance framework into a deployable platform stack by specifying the smallest credible composition of policy runtime, telemetry transport, identity issuance, revocation, and audit services.

Prior completed research qualifying the same control surfaces:

Approach

UELGF component-to-tooling mapping: For each UELGF architectural component (PDP, PAP, PIP, PEP, runtime feedback loop, kill switch, scaffold generator), identify the functional requirements that a tooling implementation must satisfy. Produce a structured requirements table.
Policy-as-code engine evaluation: Evaluate OPA and Cedar against the UELGF policy architecture requirements. For each engine, assess: policy language expressiveness for the eight-layer context model, performance profile at enforcement points (99th-percentile latency), auditability (decision logging, bundle versioning), integration patterns with the governed rail scaffold, and known limitations in financial services deployments.
OTel pipeline design for UELGF feedback loop: Map the UELGF runtime signal taxonomy to OpenTelemetry (OTel) semantic conventions. Specify: what trace, metric, and log signals the governed rail scaffold must emit; how agent-boundary trace context propagation works; what collector and processor configuration supports the automated response taxonomy; and what gaps exist between standard OTel conventions and UELGF-specific signals.
IAM revocable credential architecture: Specify what credential types satisfy the UELGF kill switch requirements: short-lived tokens (OAuth 2.0 / OpenID Connect (OIDC) with short expiry), workload identity (SPIFFE or SPIFFE Runtime Environment (SPIRE), or equivalent), and certificate-based revocation. Assess which modern IAM platforms (HashiCorp Vault, Azure Managed Identity, AWS IAM Roles Anywhere, or equivalent) provide the revocation semantics the framework requires. Identify what the framework's kill switch cannot guarantee when credentials are not issued through managed systems.
Composable reference architecture: Produce a reference architecture that composes the selected policy-as-code engine, OTel pipeline, and IAM system into a coherent implementation of the UELGF rail. The architecture must include: component interfaces, data flows for policy evaluation and telemetry, credential issuance and revocation paths, and the governance enforcement points on the scaffold generator.
Minimum viable stack: Identify the minimum set of tooling that implements the most critical UELGF capabilities (policy enforcement, kill switch, basic telemetry) for an organisation that cannot deploy the full reference architecture immediately. Specify what residual risk this creates relative to the full specification.
Financial institution constraints: Assess how regulatory constraints in a financial institution (data residency, audit log immutability under SR 11-7 / SS1/23 / DORA Article 8, vendor approval processes) affect the reference architecture. Identify which tooling choices are likely to be pre-approved in large financial institutions and which are likely to require new approval.
Synthesis: Produce findings as a reference architecture document, a structured specification that an engineering team could use to design a UELGF-compliant platform engineering stack.

Sources

Research Skill Output

(Full output from running the research workflow, retained verbatim in the completed item. Section 6 seeds the Findings below.)

§0 Initialise

[fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-synthesis-complete-framework.html; https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-policy-architecture-8-layer-context.html] Research question restated: what concrete platform stack, using existing policy-as-code, telemetry, and machine-identity tooling, can implement the UELGF rail as deployable engineering infrastructure inside a regulated financial institution without pretending the framework already implies a product choice?
[fact; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://opentelemetry.io/docs/collector/architecture/; https://spiffe.io/docs/latest/spiffe-about/overview/; https://developer.hashicorp.com/vault/docs/concepts/lease] Output format confirmed: the answer must be a knowledge item that includes a reference architecture specification, interface contracts, minimum viable stack, and explicit residual-risk boundaries.
[fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html; https://davidamitchell.github.io/Research/research/2026-04-27-pip-invariant-anomaly-detection.html; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.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-ai-lowcode-observability-telemetry-governance.html] Prior work cross-reference: adjacent completed items already define the UELGF control surfaces that need tooling bindings, specifically PAP topology derivation, PDP freshness, PIP anomaly signaling, kill-switch propagation, machine identity, and governance telemetry.
[fact; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] Constraint confirmed: the recommendation has to survive regulated-bank expectations for central governance, inventory, independent review, and incident-ready auditability, so the stack cannot depend on opaque local policy copies or unmanaged credentials.

§1 Question Decomposition

Root question: which existing tools and control-plane patterns implement the UELGF rail with the least bespoke engineering and the clearest governance boundaries?
A. Component mapping
- A1. What capabilities must the PAP, PDP, PIP, PEP, runtime feedback loop, kill switch, and scaffold generator expose?
- A2. Which of those capabilities are already present in off-the-shelf tools, and which remain integration work?
B. Policy runtime
- B1. What does Open Policy Agent (OPA) provide for bundle rollout, latency, logging, and masking?
- B2. What does Cedar provide for request semantics, schema validation, diagnostics, and deny behavior?
- B3. Which engine fits the UELGF PDP best as deployed infrastructure rather than as a language in isolation?
C. Observability
- C1. What trace, log, and metric semantics can OpenTelemetry provide directly?
- C2. Which UELGF fields must travel as context metadata, and which must stay out of propagated headers?
- C3. Which Collector processors create the minimum governance-safe telemetry pipeline?
D. Identity and revocation
- D1. Which credential systems actually issue short-lived or revocable workload credentials?
- D2. Which revocation guarantees depend on credential expiry rather than instant kill?
- D3. What residual risk remains for unmanaged or off-rail credentials?
E. Financial-institution operating model
- E1. Which control-plane components must be centrally governed, inventoried, and independently reviewed?
- E2. Which tooling choices are likely extensions of existing estates, and which are likely net-new approvals?
- E3. What is the smallest credible stack that still enforces policy, telemetry, and revocation?

§2 Investigation

2.1 UELGF component-to-tooling requirements

[fact; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-policy-architecture-8-layer-context.html] eXtensible Access Control Markup Language (XACML) gives the canonical PAP, PDP, PEP, and PIP role split, and the UELGF policy-architecture item already requires those roles to remain separated, with stateless PDPs, typed scope objects, fail-closed freshness, and deny-first suspension behavior.
[fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html; https://davidamitchell.github.io/Research/research/2026-04-27-pip-invariant-anomaly-detection.html; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html] The adjacent UELGF component items require, respectively, a canonical PAP-side topology function, digest-bound policy identity across lifecycle phases, a stateful PIP that can surface anomaly signals, and a kill-switch model that can revoke or degrade already-running assets.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html] A deployable stack therefore needs at least six concrete tooling roles: canonical policy authoring and publication, stateless decision evaluation, stateful entity and signal registry, enforcement adapters at run surfaces, a credential authority that can revoke or expire identities, and an audit and telemetry transport that preserves policy version and actor lineage.

2.2 Policy-as-code engine evaluation, OPA versus Cedar

[fact; source: https://www.openpolicyagent.org/docs/management-bundles] OPA states that updated policy and data are loaded on the fly without restart, are enforced immediately once loaded, and are distributed by bundle download in an eventually consistent model with persistence, Entity Tag (ETag)-based caching, and optional long polling.
[fact; source: https://www.openpolicyagent.org/docs/management-decision-logs] OPA decision logs can batch-upload gzip-compressed JavaScript Object Notation (JSON) events, include decision_id, trace_id, span_id, bundles[*].revision, input, result, and timestamps, and support masking or erasing sensitive fields through data.system.log.mask.
[fact; source: https://www.openpolicyagent.org/docs/latest/policy-performance/] OPA documents policy-engine patterns for low-latency decisions, including near-constant-time linear fragments, rule indexing, and use cases whose authorization budget is on the order of 1 millisecond.
[fact; source: https://docs.cedarpolicy.com/schema/schema.html; https://docs.cedarpolicy.com/policies/validation.html] Cedar requires a schema for principal, resource, action, and context types, and its validator catches unrecognized entity types, unsupported action-resource combinations, unsafe optional-attribute access, and type mismatches before deployment.
[fact; source: https://docs.cedarpolicy.com/auth/authorization.html] Cedar authorizes requests as principal, action, resource, and context tuples, applies forbid-overrides-permit with default deny, skips erroneous policies while returning diagnostics, and depends on the application to provide the relevant policies and entity data for each request.
[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://www.openpolicyagent.org/docs/latest/policy-performance/; https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/auth/authorization.html] OPA is the more complete default PDP runtime for UELGF because the official docs cover the exact rollout, latency, and audit surfaces that the framework needs in production, while the retrieved Cedar docs focus on request semantics, schema, and evaluation rather than on bundle publication, remote decision-log shipping, or policy-version distribution.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/schema/schema.html; https://docs.cedarpolicy.com/auth/authorization.html] Cedar still fits the UELGF stack as a strong policy-authoring and validation layer, or as a specialized authorization engine for tightly bounded domains, but a Cedar-based UELGF deployment still needs an application-owned control plane for package publication, revision tracking, and lifecycle audit.

2.3 OpenTelemetry pipeline design for the runtime feedback loop

[fact; source: https://opentelemetry.io/docs/concepts/context-propagation/; https://www.w3.org/TR/trace-context/] OpenTelemetry context propagation correlates traces, metrics, and logs across process and network boundaries, and the default propagator uses World Wide Web Consortium (W3C) Trace Context trace identifiers and parent identifiers.
[fact; source: https://opentelemetry.io/docs/concepts/signals/baggage/] OpenTelemetry baggage is a propagated key-value store for downstream enrichment, but the official guidance warns that baggage is visible in network requests, can leak to third parties, and has no built-in integrity checks.
[fact; source: https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/; https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/] The OTel generative AI semantic conventions provide dedicated fields for model, prompt, response, retrieval, and tool definitions, and the generative AI event specification makes capture of input messages, output messages, tool definitions, and system instructions explicitly opt-in.
[fact; source: https://opentelemetry.io/docs/collector/architecture/; https://opentelemetry.io/docs/collector/components/processor/; https://opentelemetry.io/docs/collector/configuration/] The OTel Collector organizes telemetry into receiver-processor-exporter pipelines, preserves processor order, and exposes standard processors for batching, attribute manipulation, filtering, redaction, and memory limiting.
[inference; source: https://opentelemetry.io/docs/concepts/context-propagation/; https://opentelemetry.io/docs/concepts/signals/baggage/; https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/; https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/; https://opentelemetry.io/docs/collector/components/processor/] The governed rail scaffold should therefore emit three telemetry classes: always-on control metadata such as entity identifier, policy digest, decision class, approval class, and credential handle; execution telemetry such as latency, retry, and queue events; and selectively enabled high-fidelity generative AI events for prompts, tool calls, and retrieved documents after redaction.
[inference; source: https://opentelemetry.io/docs/concepts/signals/baggage/; https://opentelemetry.io/docs/collector/components/processor/; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html] The minimum governance-safe Collector chain is receiver -> memory_limiter -> filter or redaction -> attributes or transform -> batch -> exporter, because UELGF needs correlated metadata everywhere but sensitive content only in approved sinks.

2.4 Identity and Access Management architecture for revocable credentials

[fact; source: https://spiffe.io/docs/latest/spiffe-about/overview/] SPIFFE defines short-lived cryptographic identity documents called SPIFFE Verifiable Identity Documents (SVIDs) for workloads and positions workload identity as a first-class distributed-systems control surface rather than a human sign-in problem.
[fact; source: https://developer.hashicorp.com/vault/docs/concepts/lease] Vault issues leases for dynamic secrets and service-type authentication tokens, requires consumers to renew or replace them, and revokes leased secrets immediately, with the documentation using deleted AWS access keys as the concrete example.
[fact; source: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html] Amazon Web Services (AWS) Security Token Service (STS) credentials are short-lived and stop working after expiry, and IAM Roles Anywhere exchanges X.509 client certificates for temporary AWS credentials while allowing session policies to further limit permissions.
[fact; source: https://cloud.google.com/iam/docs/workload-identity-federation; https://cloud.google.com/iam/docs/service-account-impersonation] Google Cloud Workload Identity Federation replaces service account keys with federated identities and token exchange, and Google service-account impersonation issues short-lived credentials for a service account without requiring a long-lived service account key.
[fact; source: https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview; https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview] Microsoft Entra workload identities include applications, service principals, and managed identities, and managed identities eliminate developer-managed credentials while binding identity lifecycle either to the resource or to a separately managed identity object.
[fact; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload; https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk] Continuous Access Evaluation (CAE) for workload identities can enforce token revocation events in real time for supported service principals, but it is limited to Microsoft Graph, single-tenant service principals, and excludes managed identities, while workload identity risk detections also exclude managed identities.
[inference; source: https://spiffe.io/docs/latest/spiffe-about/overview/; https://developer.hashicorp.com/vault/docs/concepts/lease; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://cloud.google.com/iam/docs/workload-identity-federation; https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload] The strongest UELGF kill-switch substrate is centrally minted short-lived credentials plus explicit PEP-side deny and queue-drain actions, because all of the reviewed IAM systems can reduce long-lived credential sprawl but only some support near-real-time revocation on every downstream surface.
[inference; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://developer.hashicorp.com/vault/docs/concepts/lease; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html] UELGF cannot honestly claim instant kill for identities that live outside a centrally managed issuance path, for managed identities without CAE support, or for workloads using cached credentials until expiry, so kill-switch guarantees must be written as layered containment rather than as universal immediate termination.

2.5 Regulated financial institution constraints

[fact; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en] The accessible official DORA overview organizes the regulation around Information and Communication Technology (ICT) risk management, ICT-related incidents, resilience testing, third-party risk management, information sharing, and oversight of critical providers.
[fact; source: https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf] SR 11-7 states that model risk management encompasses board and senior management oversight, policies and procedures, controls and compliance, effective challenge, independent validation, ongoing monitoring, and at least annual periodic review of models.
[fact; source: https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] Bank of England Supervisory Statement 1/23 frames model risk management as its own strategic risk discipline, sets out governance, development, independent validation, and mitigant principles, and explicitly applies the principles to internally developed and externally sourced models.
[fact; source: https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md] The Cloud Native Application Security Whitepaper argues that static perimeter identity is inadequate for dynamic workloads, recommends identity based on workload attributes and metadata, and treats integrated observability, authentication, authorization, and automated lifecycle controls as part of a secure-by-design cloud-native stack.
[inference; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] A regulated-bank UELGF deployment therefore has to keep the PAP workflow, policy inventory, PIP registry, telemetry controls, and audit stores centrally governed, independently reviewable, and inventoried, rather than allowing them to live as local platform conventions.
[assumption; source: https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss; 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-ai-lowcode-observability-telemetry-governance.html] Extending an institution's existing cloud identity, logging, and collector estate is usually lower-friction than introducing a net-new identity control plane or policy language. Justification: the regulatory sources raise the cost of new governed components through validation, inventory, and oversight requirements, and prior repository work shows large enterprises already operate central IAM and telemetry estates that can absorb incremental controls faster than entirely new control planes.

§3 Reasoning

[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/auth/authorization.html] The main decision is not OPA versus Cedar as a pure language preference, but which tool already implements the UELGF production control surfaces of rollout, freshness, and decision traceability with the fewest additional moving parts.
[inference; source: https://opentelemetry.io/docs/concepts/context-propagation/; https://opentelemetry.io/docs/concepts/signals/baggage/; https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/] OTel provides the transport and correlation substrate for the feedback loop, but it does not define the UELGF ontology itself, which means UELGF-specific identifiers such as entity identifier, policy digest, approval class, and kill-switch event class still need custom attribute conventions.
[inference; source: https://spiffe.io/docs/latest/spiffe-about/overview/; https://developer.hashicorp.com/vault/docs/concepts/lease; https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload] Kill-switch strength depends more on the credential-issuance and enforcement path than on the policy language, because a perfect PDP decision cannot instantly stop a workload that still holds a valid unmanaged credential or runs behind an unenforced PEP.
[inference; source: https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] The regulated-bank constraint turns control-plane design into a governance problem as much as a software problem, so the reference architecture has to minimize the number of novel governed services while preserving central inventory and independent review.

§4 Consistency Check

[fact; source: https://www.openpolicyagent.org/docs/management-bundles] OPA saying that bundles are eventually consistent does not contradict immediate enforcement after load, because the former describes propagation topology and the latter describes runtime behavior once a new bundle is activated.
[fact; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload; https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview] Managed identities reducing credential-handling risk does not imply instant revocation everywhere, because the CAE workload-identity page explicitly excludes managed identities while the managed-identity page focuses on secret elimination and lifecycle binding.
[inference; source: https://www.openpolicyagent.org/docs/latest/policy-performance/; https://www.openpolicyagent.org/docs/management-bundles; https://developer.hashicorp.com/vault/docs/concepts/lease] The architecture therefore needs distinct latency budgets by surface: low-millisecond evaluation budgets on the PDP path, seconds-to-minutes publication budgets on the policy-distribution path, and credential-expiry or explicit revocation bounds on the identity path.

§5 Depth and Breadth Expansion

[fact; source: https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md] Technical lens: the cloud-native security guidance reinforces that workload identity, automated lifecycle controls, and runtime observability should be treated as one integrated system rather than as separate afterthoughts.
[fact; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] Regulatory lens: the reviewed financial-sector guidance consistently privileges central governance, inventory, independent validation, and incident evidence, which makes ad hoc local policy runtimes or opaque telemetry pipelines poor fits regardless of technical elegance.
[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://opentelemetry.io/docs/collector/components/processor/; https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview] Economic lens: the cheapest credible route is to reuse an existing collector and cloud-identity estate while introducing only the components that current estates usually lack, namely a canonical policy publication workflow, a stateful PIP registry, and explicit PEP obligations.
[inference; source: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/; https://opentelemetry.io/docs/concepts/signals/baggage/] Behavioral lens: developers will only preserve provenance consistently if the governed scaffold emits identifiers and telemetry automatically, because the OTel model makes rich capture available but does not force correct manual instrumentation.

§6 Synthesis

Executive summary:

[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://www.openpolicyagent.org/docs/latest/policy-performance/; https://opentelemetry.io/docs/collector/architecture/; https://opentelemetry.io/docs/concepts/context-propagation/; https://developer.hashicorp.com/vault/docs/concepts/lease; https://spiffe.io/docs/latest/spiffe-about/overview/] A deployable UELGF rail in a regulated financial institution should use signed OPA bundles as the default policy runtime, OTel Collectors as the telemetry transport, and centrally issued short-lived workload credentials with PEP-side deny and revocation hooks as the kill-switch backbone, because that combination already covers policy rollout, traceable decisions, correlated feedback, and the main credential-containment mechanics without inventing a new platform.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/auth/authorization.html; https://www.openpolicyagent.org/docs/management-bundles] Cedar remains valuable in this architecture as a schema-validated authorization language and constrained authorizer surface, but it is not by itself a full UELGF rail implementation because the reviewed Cedar materials do not provide the same publication, revision-tracking, or decision-log transport surfaces that OPA exposes.
[inference; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://cloud.google.com/iam/docs/workload-identity-federation; https://developer.hashicorp.com/vault/docs/concepts/lease] The kill switch can be made strong only for workloads that obtain centrally minted short-lived or explicitly revocable credentials, so the architecture must treat off-rail credentials and unsupported managed-identity scenarios as residual-risk populations rather than pretending universal instant revocation.
[inference; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] In regulated-bank practice, the reference architecture still has to centralize policy publication, entity inventory, audit evidence, and independent validation, so the minimum viable stack should minimize the number of governed components while preserving those control surfaces.

Key findings:

[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://www.openpolicyagent.org/docs/latest/policy-performance/] Medium confidence: OPA is a well-supported default PDP runtime for the UELGF rail because its official feature set already covers versioned bundle distribution, immediate enforcement after activation, revision-aware decision logs, sensitive-field masking, and low-latency evaluation guidance that aligns with enforcement-point budgets.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/schema/schema.html; https://docs.cedarpolicy.com/auth/authorization.html] Medium confidence: Cedar is well suited for schema-validated policy authoring and tightly bounded authorization domains, but a Cedar-only deployment still needs a separate publication, revision-tracking, and audit plane before it can satisfy the full UELGF lifecycle-governance contract.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html] High confidence: The reference architecture should separate canonical policy authoring and approval, stateless decision evaluation, stateful entity and signal context, and runtime enforcement adapters, because the UELGF component research already defines those surfaces as independent control responsibilities rather than as one merged service.
[inference; source: https://opentelemetry.io/docs/concepts/context-propagation/; https://opentelemetry.io/docs/concepts/signals/baggage/; https://opentelemetry.io/docs/collector/components/processor/; https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/] Medium confidence: The runtime feedback loop should use OTel trace context for causal correlation, tightly scoped baggage for non-sensitive identifiers, and a Collector processor chain that redacts, enriches, and batches telemetry before export, because the default OTel model separates correlation metadata from sensitive payload capture.
[inference; source: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/; https://opentelemetry.io/docs/concepts/signals/baggage/; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html] Medium confidence: High-fidelity prompts, tool calls, retrieved documents, and system instructions should be captured only through opt-in generative AI events and approved redacted sinks, because propagated headers and baggage are unsuitable places for sensitive governance evidence.
[inference; source: https://spiffe.io/docs/latest/spiffe-about/overview/; https://developer.hashicorp.com/vault/docs/concepts/lease; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://cloud.google.com/iam/docs/workload-identity-federation] High confidence: Centrally issued short-lived credentials are the core identity primitive for a credible UELGF kill switch, because SPIFFE, Vault leases, AWS temporary credentials, and Google federated workloads all reduce standing secrets and bound the residual life of compromised access.
[inference; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload; https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html] Medium confidence: Instant revocation cannot be guaranteed uniformly across managed identities, cached cloud tokens, and off-rail credentials, so the kill-switch design has to combine credential revocation with PEP-side deny lists, queue draining, and service disablement rather than relying on identity expiry alone.
[inference; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss; https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md] High confidence: A regulated-bank implementation has to centralize policy publication, model or policy inventory, telemetry evidence, and independent validation, because the relevant supervisory and cloud-native guidance all treat those controls as governance obligations, not optional platform niceties.
[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://opentelemetry.io/docs/collector/architecture/; https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html; https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf] Medium confidence: The minimum viable UELGF stack can be limited to a signed OPA publication path, a stateful PIP registry, an OTel Collector pipeline, one managed workload-identity system, and a central audit sink, while SPIFFE, Cedar, or Vault are optional hardening layers for institutions that need stronger cross-platform identity or dynamic-secret revocation.

Evidence map:

Claim	Source	Confidence	Notes
[inference] OPA is a well-supported default PDP runtime because it combines bundle publication, immediate post-load enforcement, revision-aware decision logging, and low-latency evaluation guidance.	https://www.openpolicyagent.org/docs/management-bundles ; https://www.openpolicyagent.org/docs/management-decision-logs ; https://www.openpolicyagent.org/docs/latest/policy-performance/	medium	Retrieved official docs cover the runtime control-plane surface directly.
[inference] Cedar is useful for schema-validated authoring and bounded authorization, but it still needs a companion publication and audit plane for full UELGF deployment.	https://docs.cedarpolicy.com/policies/validation.html ; https://docs.cedarpolicy.com/schema/schema.html ; https://docs.cedarpolicy.com/auth/authorization.html	medium	Strong language and validator, thinner operations surface.
[inference] The reference architecture must keep PAP publication, PDP evaluation, PIP state, and PEP enforcement as separate services or adapters.	https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html	high	Mirrors UELGF component decomposition.
[inference] The feedback loop should use OTel trace context plus a Collector chain that limits memory, filters or redacts, enriches attributes, and batches exports.	https://opentelemetry.io/docs/concepts/context-propagation/ ; https://opentelemetry.io/docs/concepts/signals/baggage/ ; https://opentelemetry.io/docs/collector/architecture/ ; https://opentelemetry.io/docs/collector/components/processor/	medium	Keeps correlation and privacy controls separated.
[inference] Prompt, tool-call, and retrieval evidence belongs in opt-in generative AI events and redacted sinks, not in baggage or generic headers.	https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/ ; https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/ ; https://opentelemetry.io/docs/concepts/signals/baggage/	medium	Sensitive payload capture must be explicit.
[inference] Short-lived centrally minted credentials are the core identity primitive for the kill switch.	https://spiffe.io/docs/latest/spiffe-about/overview/ ; https://developer.hashicorp.com/vault/docs/concepts/lease ; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html ; https://cloud.google.com/iam/docs/workload-identity-federation	high	Review converges on expiry or revocation instead of standing secrets.
[inference] Identity revocation alone is insufficient on all platforms, so PEP-side deny and disable actions remain necessary.	https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload ; https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview ; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html	medium	Managed-identity and cached-token limits remain.
[inference] Central inventory, independent validation, and durable evidence are mandatory regulated-bank constraints on the tooling design.	https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en ; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf ; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss	high	Governance obligations shape architecture directly.
[inference] The minimum viable stack can be limited to signed OPA publication, a stateful PIP registry, an OTel Collector pipeline, one managed workload-identity system, and a central audit sink, with SPIFFE, Cedar, or Vault reserved as optional hardening layers.	https://www.openpolicyagent.org/docs/management-bundles ; https://opentelemetry.io/docs/collector/architecture/ ; https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview ; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html ; https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en ; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf	medium	Audit centralization and hardening needs come from governance duties plus telemetry-control evidence.

Assumptions:

[assumption; source: https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] Large financial institutions usually face lower approval cost when extending existing identity and telemetry estates than when introducing wholly new governed control planes. Justification: the official governance sources raise inventory, validation, and oversight requirements for every new critical control-plane component.
[assumption; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html] A UELGF implementation can enforce PEP-side deny and queue-drain hooks at the main runtime surfaces that matter. Justification: if material workloads bypass all reachable enforcement points, the framework can still detect and flag them, but not guarantee active stop.

Analysis:

[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/auth/authorization.html] The reviewed engine evidence favors OPA for the deployed PDP because UELGF needs publication, freshness, and audit mechanics more urgently than it needs a second policy language, while Cedar adds its clearest value as an authoring and validation discipline around narrower authorization domains.
[inference; source: https://opentelemetry.io/docs/concepts/context-propagation/; https://opentelemetry.io/docs/concepts/signals/baggage/; https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/] The observability design has to separate correlation metadata from sensitive payloads, because UELGF needs end-to-end traceability across agent, tool, and service boundaries but the OTel docs explicitly warn against using propagated carriers for sensitive data.
[inference; source: https://spiffe.io/docs/latest/spiffe-about/overview/; https://developer.hashicorp.com/vault/docs/concepts/lease; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload] The credential review shows that the kill switch is a layered containment problem, not a single identity-platform feature, because some platforms provide immediate revocation signals, some provide only bounded expiry, and unmanaged credentials sit outside both models.
[inference; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss; https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md] The regulatory and operating-model evidence pushes the architecture toward centralization of policy publication, inventory, and evidence while keeping enforcement adapters close to workloads, which is why a hub-and-spoke control plane with local PEPs is a better fit than application-embedded policy logic.

Reference architecture specification:

Claim	Primary tools	Interfaces	Sources
[inference] Canonical policy authoring and publication plane should own authoring, approval, signing, packaging, and release of digest-addressed policy bundles.	OPA authoring repository and bundle builder, optional Cedar authoring or validation stage, immutable artifact registry	PAP -> bundle registry; PAP -> validation workflow; PAP -> audit store	https://www.openpolicyagent.org/docs/management-bundles ; https://docs.cedarpolicy.com/policies/validation.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html
[inference] Stateless decision tier should evaluate typed requests close to enforcement points and return permit, deny, indeterminate, obligations, and policy revision metadata.	OPA sidecar or central PDP replicas, optional Cedar authorizer for bounded domains	PEP -> PDP decision API; PDP -> PIP context lookup; PDP -> decision log exporter	https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://www.openpolicyagent.org/docs/latest/policy-performance/ ; https://docs.cedarpolicy.com/auth/authorization.html
[inference] Stateful PIP and entity registry should hold entity registration, declared scope, risk tier, active credential references, and anomaly signals.	Registry database plus signal store, fed by scaffold registration and runtime monitors	Scaffold -> PIP registration API; PIP -> PDP context API; runtime sensors -> PIP signal API	https://davidamitchell.github.io/Research/research/2026-04-27-pip-invariant-anomaly-detection.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html
[inference] PEP adapters should sit in deployment pipelines, service gateways, tool runners, workflow engines, and queue consumers so that policy decisions can actually stop or degrade execution.	Application Programming Interface (API) gateway hooks, workflow interceptors, deployment gate, queue and secret brokers	PEP -> PDP; PEP -> credential authority revoke or disable; PEP -> OTel telemetry	https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html ; https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html
[inference] Credential authority should mint short-lived identities where possible and expose explicit revoke, disable, or expire operations for kill-switch workflows.	SPIFFE or SPIFFE Runtime Environment (SPIRE)-style workload identity, Vault dynamic secrets, cloud-native federation or impersonation paths	Credential authority -> workload token issuance; PEP -> revoke or disable; audit -> credential event log	https://spiffe.io/docs/latest/spiffe-about/overview/ ; https://developer.hashicorp.com/vault/docs/concepts/lease ; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html ; https://cloud.google.com/iam/docs/workload-identity-federation ; https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
[inference] Telemetry and evidence plane should collect always-on control metadata, optional redacted high-fidelity generative AI events, and immutable audit evidence linked to policy revisions.	OTel Collector pipelines, central log or event platform, immutable audit store	Runtime -> Collector; Collector -> Security Information and Event Management (SIEM) or lakehouse; Collector -> append-only audit sink	https://opentelemetry.io/docs/collector/architecture/ ; https://opentelemetry.io/docs/collector/components/processor/ ; https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/ ; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html

Minimum viable stack:

Claim	Scope included	Residual risk	Sources
[inference] Stage 1 minimum viable stack = signed OPA bundles, one central PIP registry, PEP hooks in the deployment path and main runtime gateway, OTel Collector with redaction, and one existing cloud workload-identity system.	Policy freshness, deployment gating, baseline runtime telemetry, bounded short-lived credentials on the main estate	Weaker cross-platform workload identity, incomplete off-rail containment, limited formal policy validation outside OPA and admission gates	https://www.openpolicyagent.org/docs/management-bundles ; https://opentelemetry.io/docs/collector/architecture/ ; https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview ; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
[inference] Stage 2 hardening = add Vault or SPIFFE for dynamic secret and cross-platform identity issuance where cloud-native identities are insufficient.	Stronger revocation for databases, brokers, and heterogeneous workloads	New approval, operating, and integration cost for a second identity control plane	https://developer.hashicorp.com/vault/docs/concepts/lease ; https://spiffe.io/docs/latest/spiffe-about/overview/
[inference] Stage 3 policy-language specialization = add Cedar where schema-validated, bounded-domain authorization justifies another authorizer or authoring surface.	Better typed authoring and tighter action-resource semantics for specific domains	Additional policy-language and publication-plane complexity if adopted too early	https://docs.cedarpolicy.com/policies/validation.html ; https://docs.cedarpolicy.com/auth/authorization.html

Risks, gaps, uncertainties:

[fact; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload] CAE for workload identities does not cover managed identities and is limited to Microsoft Graph for supported service principals, so Microsoft-centric kill-switch behavior remains uneven across workload types.
[fact; source: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/] The OTel generative AI event model is still marked development status, which means schema drift and instrumentation churn are plausible if the institution standardizes on those fields too aggressively too early.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://www.openpolicyagent.org/docs/management-bundles] A dual-engine design that combines Cedar authoring with OPA runtime could improve type safety, but it also introduces translation or duplication risk that this item does not fully resolve.
[assumption; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md] Data residency, append-only storage implementation, and key-management choices are institution-specific and need local platform mapping before the reference architecture becomes a deployment blueprint. Justification: the reviewed regulatory and architecture sources state the obligation classes, not one universal implementation product.

Open questions:

Would a Cedar-to-OPA publication pipeline reduce policy-authoring error enough to justify a second policy language in the first release?
Which existing bank platforms already provide append-only audit storage, so the evidence plane can extend them instead of creating a new logging subsystem?
Which runtime surfaces remain outside reachable PEP control in the target institution, and should those become explicit exception classes in the UELGF operating model?

§7 Recursive Review

[fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-synthesis-complete-framework.html] Section parity check complete: the synthesis stays inside the tooling-binding scope of this item and does not introduce claims about UELGF components that were not already established in prior completed items or official tool documentation.
[fact; source: https://www.openpolicyagent.org/docs/management-bundles; https://docs.cedarpolicy.com/policies/validation.html; https://opentelemetry.io/docs/concepts/context-propagation/; https://developer.hashicorp.com/vault/docs/concepts/lease; https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en] Claim audit complete: every factual or inferential statement in the synthesis is source-bound or labeled as an assumption.
[inference; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload; https://docs.cedarpolicy.com/auth/authorization.html] Remaining uncertainty is concentrated in platform-specific revocation coverage and in whether a bank would accept a dual-engine policy stack, so those uncertainties are preserved in Risks, Gaps, and Open Questions rather than hidden inside stronger confidence labels.

Findings

(Seeded directly from §6 Synthesis. No substantive claims appear here that do not already appear in the synthesis above.)

Executive Summary

[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://www.openpolicyagent.org/docs/latest/policy-performance/; https://opentelemetry.io/docs/collector/architecture/; https://spiffe.io/docs/latest/spiffe-about/overview/; https://developer.hashicorp.com/vault/docs/concepts/lease] A deployable UELGF rail for a regulated financial institution should use signed OPA bundles as the default policy runtime, OTel Collectors as the telemetry transport, and centrally issued short-lived workload credentials with PEP-side deny and revocation hooks as the kill-switch backbone, because that stack already implements the framework's required policy, feedback, and containment mechanics.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/auth/authorization.html; https://www.openpolicyagent.org/docs/management-bundles] Cedar is still useful in that architecture as a schema-validated authoring or bounded-domain authorization layer, but the retrieved Cedar materials do not provide the same operational publication and audit surfaces that OPA exposes for a full rail implementation.
[inference; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://cloud.google.com/iam/docs/workload-identity-federation; https://developer.hashicorp.com/vault/docs/concepts/lease] The kill switch becomes credible only where workloads receive centrally minted short-lived or explicitly revocable credentials, so off-rail credentials and unsupported managed-identity scenarios remain residual-risk populations that the platform must detect and contain rather than fully control.
[inference; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] A regulated-bank reference architecture should therefore use a centralized policy and evidence hub with local enforcement spokes, designed to preserve central inventory, validation, and auditability while keeping the governed component count as small as possible.

Key Findings

[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://www.openpolicyagent.org/docs/latest/policy-performance/] Medium confidence: OPA is a well-supported default PDP runtime for the UELGF rail because its official feature set already covers versioned bundle distribution, immediate enforcement after activation, revision-aware decision logs, sensitive-field masking, and low-latency evaluation guidance that aligns with enforcement-point budgets.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/schema/schema.html; https://docs.cedarpolicy.com/auth/authorization.html] Medium confidence: Cedar is well suited for schema-validated policy authoring and tightly bounded authorization domains, but a Cedar-only deployment still needs a separate publication, revision-tracking, and audit plane before it can satisfy the full UELGF lifecycle-governance contract.
[inference; source: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html] High confidence: The reference architecture should separate canonical policy authoring and approval, stateless decision evaluation, stateful entity and signal context, and runtime enforcement adapters, because the UELGF component research already defines those surfaces as independent control responsibilities rather than as one merged service.
[inference; source: https://opentelemetry.io/docs/concepts/context-propagation/; https://opentelemetry.io/docs/concepts/signals/baggage/; https://opentelemetry.io/docs/collector/components/processor/; https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/] Medium confidence: The runtime feedback loop should use OTel trace context for causal correlation, tightly scoped baggage for non-sensitive identifiers, and a Collector processor chain that redacts, enriches, and batches telemetry before export, because the default OTel model separates correlation metadata from sensitive payload capture.
[inference; source: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/; https://opentelemetry.io/docs/concepts/signals/baggage/; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html] Medium confidence: High-fidelity prompts, tool calls, retrieved documents, and system instructions should be captured only through opt-in generative AI events and approved redacted sinks, because propagated headers and baggage are unsuitable places for sensitive governance evidence.
[inference; source: https://spiffe.io/docs/latest/spiffe-about/overview/; https://developer.hashicorp.com/vault/docs/concepts/lease; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://cloud.google.com/iam/docs/workload-identity-federation] High confidence: Centrally issued short-lived credentials are the core identity primitive for a credible UELGF kill switch, because SPIFFE, Vault leases, AWS temporary credentials, and Google federated workloads all reduce standing secrets and bound the residual life of compromised access.
[inference; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload; https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html] Medium confidence: Instant revocation cannot be guaranteed uniformly across managed identities, cached cloud tokens, and off-rail credentials, so the kill-switch design has to combine credential revocation with PEP-side deny lists, queue draining, and service disablement rather than relying on identity expiry alone.
[inference; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss; https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md] High confidence: A regulated-bank implementation has to centralize policy publication, model or policy inventory, telemetry evidence, and independent validation, because the relevant supervisory and cloud-native guidance all treat those controls as governance obligations, not optional platform niceties.
[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://opentelemetry.io/docs/collector/architecture/; https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html; https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf] Medium confidence: The minimum viable UELGF stack can be limited to a signed OPA publication path, a stateful PIP registry, an OTel Collector pipeline, one managed workload-identity system, and a central audit sink, while SPIFFE, Cedar, or Vault are optional hardening layers for institutions that need stronger cross-platform identity or dynamic-secret revocation.

Evidence Map

Claim	Source	Confidence	Notes
[inference] OPA is a well-supported default PDP runtime because it combines bundle publication, immediate post-load enforcement, revision-aware decision logging, and low-latency evaluation guidance.	https://www.openpolicyagent.org/docs/management-bundles ; https://www.openpolicyagent.org/docs/management-decision-logs ; https://www.openpolicyagent.org/docs/latest/policy-performance/	medium	Retrieved official docs cover the runtime control-plane surface directly.
[inference] Cedar is useful for schema-validated authoring and bounded authorization, but it still needs a companion publication and audit plane for full UELGF deployment.	https://docs.cedarpolicy.com/policies/validation.html ; https://docs.cedarpolicy.com/schema/schema.html ; https://docs.cedarpolicy.com/auth/authorization.html	medium	Strong language and validator, thinner operations surface.
[inference] The reference architecture must keep PAP publication, PDP evaluation, PIP state, and PEP enforcement as separate services or adapters.	https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html	high	Mirrors UELGF component decomposition.
[inference] The feedback loop should use OTel trace context plus a Collector chain that limits memory, filters or redacts, enriches attributes, and batches exports.	https://opentelemetry.io/docs/concepts/context-propagation/ ; https://opentelemetry.io/docs/concepts/signals/baggage/ ; https://opentelemetry.io/docs/collector/architecture/ ; https://opentelemetry.io/docs/collector/components/processor/	medium	Keeps correlation and privacy controls separated.
[inference] Prompt, tool-call, and retrieval evidence belongs in opt-in generative AI events and redacted sinks, not in baggage or generic headers.	https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/ ; https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/ ; https://opentelemetry.io/docs/concepts/signals/baggage/	medium	Sensitive payload capture must be explicit.
[inference] Short-lived centrally minted credentials are the core identity primitive for the kill switch.	https://spiffe.io/docs/latest/spiffe-about/overview/ ; https://developer.hashicorp.com/vault/docs/concepts/lease ; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html ; https://cloud.google.com/iam/docs/workload-identity-federation	high	Review converges on expiry or revocation instead of standing secrets.
[inference] Identity revocation alone is insufficient on all platforms, so PEP-side deny and disable actions remain necessary.	https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload ; https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview ; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html	medium	Managed-identity and cached-token limits remain.
[inference] Central inventory, independent validation, and durable evidence are mandatory regulated-bank constraints on the tooling design.	https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en ; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf ; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss	high	Governance obligations shape architecture directly.
[inference] The minimum viable stack can be limited to signed OPA publication, a stateful PIP registry, an OTel Collector pipeline, one managed workload-identity system, and a central audit sink, with SPIFFE, Cedar, or Vault reserved as optional hardening layers.	https://www.openpolicyagent.org/docs/management-bundles ; https://opentelemetry.io/docs/collector/architecture/ ; https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview ; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html ; https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en ; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf	medium	Audit centralization and hardening needs come from governance duties plus telemetry-control evidence.

Assumptions

[assumption; source: https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss] Large financial institutions usually face lower approval cost when extending existing identity and telemetry estates than when introducing wholly new governed control planes. Justification: the official governance sources raise inventory, validation, and oversight requirements for every new critical control-plane component.
[assumption; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html] A UELGF implementation can enforce PEP-side deny and queue-drain hooks at the main runtime surfaces that matter. Justification: if material workloads bypass all reachable enforcement points, the framework can still detect and flag them, but not guarantee active stop.

Analysis

[inference; source: https://www.openpolicyagent.org/docs/management-bundles; https://www.openpolicyagent.org/docs/management-decision-logs; https://docs.cedarpolicy.com/policies/validation.html; https://docs.cedarpolicy.com/auth/authorization.html] The reviewed engine evidence favors OPA for the deployed PDP because UELGF needs publication, freshness, and audit mechanics more urgently than it needs a second policy language, while Cedar adds its clearest value as an authoring and validation discipline around narrower authorization domains.
[inference; source: https://opentelemetry.io/docs/concepts/context-propagation/; https://opentelemetry.io/docs/concepts/signals/baggage/; https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/] The observability design has to separate correlation metadata from sensitive payloads, because UELGF needs end-to-end traceability across agent, tool, and service boundaries but the OTel docs explicitly warn against using propagated carriers for sensitive data.
[inference; source: https://spiffe.io/docs/latest/spiffe-about/overview/; https://developer.hashicorp.com/vault/docs/concepts/lease; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html; https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload] The credential review shows that the kill switch is a layered containment problem, not a single identity-platform feature, because some platforms provide immediate revocation signals, some provide only bounded expiry, and unmanaged credentials sit outside both models.
[inference; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107a1.pdf; https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss; https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md] The regulatory and operating-model evidence pushes the architecture toward centralization of policy publication, inventory, and evidence while keeping enforcement adapters close to workloads, which is why a hub-and-spoke control plane with local PEPs is a better fit than application-embedded policy logic.

Reference architecture specification:

Claim	Primary tools	Interfaces	Sources
[inference] Canonical policy authoring and publication plane should own authoring, approval, signing, packaging, and release of digest-addressed policy bundles.	OPA authoring repository and bundle builder, optional Cedar authoring or validation stage, immutable artifact registry	PAP -> bundle registry; PAP -> validation workflow; PAP -> audit store	https://www.openpolicyagent.org/docs/management-bundles ; https://docs.cedarpolicy.com/policies/validation.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pdp-universal-policy-synchronisation-integrity.html
[inference] Stateless decision tier should evaluate typed requests close to enforcement points and return permit, deny, indeterminate, obligations, and policy revision metadata.	OPA sidecar or central PDP replicas, optional Cedar authorizer for bounded domains	PEP -> PDP decision API; PDP -> PIP context lookup; PDP -> decision log exporter	https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html ; https://www.openpolicyagent.org/docs/latest/policy-performance/ ; https://docs.cedarpolicy.com/auth/authorization.html
[inference] Stateful PIP and entity registry should hold entity registration, declared scope, risk tier, active credential references, and anomaly signals.	Registry database plus signal store, fed by scaffold registration and runtime monitors	Scaffold -> PIP registration API; PIP -> PDP context API; runtime sensors -> PIP signal API	https://davidamitchell.github.io/Research/research/2026-04-27-pip-invariant-anomaly-detection.html ; https://davidamitchell.github.io/Research/research/2026-04-27-pap-dynamic-policy-profiling-proportionality.html
[inference] PEP adapters should sit in deployment pipelines, service gateways, tool runners, workflow engines, and queue consumers so that policy decisions can actually stop or degrade execution.	Application Programming Interface (API) gateway hooks, workflow interceptors, deployment gate, queue and secret brokers	PEP -> PDP; PEP -> credential authority revoke or disable; PEP -> OTel telemetry	https://davidamitchell.github.io/Research/research/2026-04-27-out-of-band-policy-invalidation-remediation.html ; https://davidamitchell.github.io/Research/research/2026-04-26-deployment-pipeline-citizen-development-governed-gate.html
[inference] Credential authority should mint short-lived identities where possible and expose explicit revoke, disable, or expire operations for kill-switch workflows.	SPIFFE or SPIFFE Runtime Environment (SPIRE)-style workload identity, Vault dynamic secrets, cloud-native federation or impersonation paths	Credential authority -> workload token issuance; PEP -> revoke or disable; audit -> credential event log	https://spiffe.io/docs/latest/spiffe-about/overview/ ; https://developer.hashicorp.com/vault/docs/concepts/lease ; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html ; https://cloud.google.com/iam/docs/workload-identity-federation ; https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
[inference] Telemetry and evidence plane should collect always-on control metadata, optional redacted high-fidelity generative AI events, and immutable audit evidence linked to policy revisions.	OTel Collector pipelines, central log or event platform, immutable audit store	Runtime -> Collector; Collector -> SIEM or lakehouse; Collector -> append-only audit sink	https://opentelemetry.io/docs/collector/architecture/ ; https://opentelemetry.io/docs/collector/components/processor/ ; https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/ ; https://davidamitchell.github.io/Research/research/2026-04-26-ai-lowcode-observability-telemetry-governance.html

Minimum viable stack:

Claim	Scope included	Residual risk	Sources
[inference] Stage 1 minimum viable stack = signed OPA bundles, one central PIP registry, PEP hooks in the deployment path and main runtime gateway, OTel Collector with redaction, and one existing cloud workload-identity system.	Policy freshness, deployment gating, baseline runtime telemetry, bounded short-lived credentials on the main estate	Weaker cross-platform workload identity, incomplete off-rail containment, limited formal policy validation outside OPA and admission gates	https://www.openpolicyagent.org/docs/management-bundles ; https://opentelemetry.io/docs/collector/architecture/ ; https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview ; https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
[inference] Stage 2 hardening = add Vault or SPIFFE for dynamic secret and cross-platform identity issuance where cloud-native identities are insufficient.	Stronger revocation for databases, brokers, and heterogeneous workloads	New approval, operating, and integration cost for a second identity control plane	https://developer.hashicorp.com/vault/docs/concepts/lease ; https://spiffe.io/docs/latest/spiffe-about/overview/
[inference] Stage 3 policy-language specialization = add Cedar where schema-validated, bounded-domain authorization justifies another authorizer or authoring surface.	Better typed authoring and tighter action-resource semantics for specific domains	Additional policy-language and publication-plane complexity if adopted too early	https://docs.cedarpolicy.com/policies/validation.html ; https://docs.cedarpolicy.com/auth/authorization.html

Risks, Gaps, and Uncertainties

[fact; source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation-workload] CAE for workload identities does not cover managed identities and is limited to Microsoft Graph for supported service principals, so Microsoft-centric kill-switch behavior remains uneven across workload types.
[fact; source: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/] The OTel generative AI event model is still marked development status, which means schema drift and instrumentation churn are plausible if the institution standardizes on those fields too aggressively too early.
[inference; source: https://docs.cedarpolicy.com/policies/validation.html; https://www.openpolicyagent.org/docs/management-bundles] A dual-engine design that combines Cedar authoring with OPA runtime could improve type safety, but it also introduces translation or duplication risk that this item does not fully resolve.
[assumption; source: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en; https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md] Data residency, append-only storage implementation, and key-management choices are institution-specific and need local platform mapping before the reference architecture becomes a deployment blueprint. Justification: the reviewed regulatory and architecture sources state the obligation classes, not one universal implementation product.

Open Questions

Would a Cedar-to-OPA publication pipeline reduce policy-authoring error enough to justify a second policy language in the first release?
Which existing bank platforms already provide append-only audit storage, so the evidence plane can extend them instead of creating a new logging subsystem?
Which runtime surfaces remain outside reachable PEP control in the target institution, and should those become explicit exception classes in the UELGF operating model?

Output

Type: knowledge
Description: Reference architecture and tooling specification for implementing the UELGF rail with policy publication, stateless evaluation, telemetry feedback, and revocable workload credentials in a regulated financial institution.
Links: