Policy coherence as a machine-checkable prerequisite

Research Question

Contradictory or outdated policy documents are a chronic governance failure that organisations tolerate because the consequences under human operation are slow-moving. Under agentic operation, agents built in good faith against one policy document will violate another, and will do so repeatedly at machine speed before detection. What does the literature say about policy coherence as a prerequisite for automated enforcement, and does the policy-as-code literature, formal policy specification, Open Policy Agent (OPA) patterns, and invariant registries, provide an applicable framework for ensuring agents operate within a coherent, non-contradictory policy space in a regulated financial institution?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

• Policy coherence is a practical prerequisite for any policy domain delegated to automated enforcement in a regulated financial institution, because policy engines can only enforce, test, and partially verify policies that have been translated into a coherent formal representation. The policy-as-code literature and public production evidence show that centralized, testable, auditable policy layers exist in production, but primarily at authorization and infrastructure-control scope rather than at full enterprise policy-corpus scope. Bounded-scope deployments can still succeed with local typed controls even when enterprise-wide policy-estate remediation is incomplete. The strongest workable version of what this item calls an invariant registry, a definition-needed design label for a machine-readable control catalog plus typed schemas and centrally distributed policy bundles, is a governance pattern rather than a standalone product category. Regulators do not explicitly require that architecture today, but their governance and resilience expectations make it a strong derived precondition wherever agents can act at machine speed.

Key Findings

1. Policy-as-code does not resolve contradictory prose by itself; it becomes useful only after the policy domain being automated has been converted into a coherent, typed representation that an engine can evaluate consistently. Confidence: high.
2. The formal policy-analysis literature demonstrates that structured access-control policies can be checked for conflicts, incompleteness, and unreachable rules, which proves that machine-checkable coherence is technically achievable for formalized policy subsets. Confidence: high.
3. OPA provides a production pattern for centrally managed shared policies, automated policy testing, audit trails, and bundle-based distribution, which makes enforcement logic versioned, testable, and replayable across many systems. Confidence: medium.
4. Cedar adds a stronger formal-verification story through typed schemas, authorization-specific semantics, and verification-guided development, but its guarantees apply to the modeled authorization layer rather than to the upstream policy corpus. Confidence: medium.
5. The closest practical implementation of what this item calls an invariant registry, a definition-needed design label for a centrally owned machine-readable control catalog feeding typed schemas and versioned policy bundles into enforcement engines, is a governance pattern rather than a standalone product with a settled industry definition. Confidence: medium.
6. Public financial-services evidence confirms policy-as-code deployment in regulated institutions such as BNY Mellon, Capital One, and Goldman Sachs, but the public use cases are concentrated in authorization, admission control, and infrastructure governance. Confidence: medium.
7. APRA, DORA, ISO/IEC 42001, and FCA/PRA guidance do not explicitly mandate machine-checkable policy coherence, but their control, governance, and resilience obligations make it a strong derived requirement for machine-speed agentic operations. Confidence: medium.
8. An unclassified or weakly owned policy and data estate does not make narrow policy-as-code deployments impossible, but it does make enterprise-wide policy coherence only partial and makes safe broad agentic deployment difficult to justify without prior remediation. Confidence: medium.

Assumptions

• Assumption: "Invariant registry" is a design shorthand for a machine-readable catalog of non-negotiable controls, schemas, and distributed policy artifacts. Justification: the searched primary sources support the architecture but do not present a settled, authoritative definition under that exact term.

Analysis

• The strongest direct evidence concerns formal access-control policies, not enterprise policy manuals. That evidence is still relevant because it isolates the core technical question: can policy conflicts be detected mechanically once the policy space is formalized? The answer is yes.
• The engineering literature and official documentation then show that modern policy engines can operationalize those ideas through testing, schemas, audit trails, and formal reasoning, but only within the boundaries of the encoded model.
• Production evidence and machine-readable control standards jointly support a realistic operating model for regulated banks: central control catalogs and policy repositories feeding runtime enforcement. What they do not support is the stronger claim that banks have already solved natural-language policy coherence end to end.
• Because the regulatory texts are mechanism-neutral, the conclusion is necessarily inferential rather than explicit: policy coherence is a prerequisite because otherwise the mandated control outcomes are not reliably demonstrable under machine-speed delegation.

Risks, Gaps, and Uncertainties

• One seeded academic source was mislabeled and had to be replaced.
• ISO/IEC 42001 evidence is lower resolution than APRA, DORA, or NIST evidence because only the official public summary was accessible in this runtime.
• Public financial-services case studies confirm deployment, but they do not publish detailed metrics or full governance operating models for whole-enterprise policy coherence.
• The invariant-registry pattern is architecturally credible, but there is uncertainty about how many regulated institutions have formalized it explicitly as a named program rather than as dispersed control catalogs and policy repositories.

Open Questions

• What governance model, ownership model, and change-control process do regulated banks use internally when they attempt to map free-text policy estates into machine-readable authorization or control artifacts?
• What is the minimum viable sequence for moving from prose policies to a typed invariant catalog in a bank with partial data classification and mixed legacy tooling?
• Will supervisors eventually expect firms to provide machine-readable evidence of policy coherence for higher-autonomy systems, even if current texts remain mechanism-neutral?

sources

• [x] Open Policy Agent homepage — - official description of centralized policy management, auditability, and enforcement scope
• [x] Open Policy Agent policy testing — - official testing framework for policy correctness and continuous integration use
• [x] Open Policy Agent Control Plane concepts — - official bundle, source, namespace, and conflict-checking model for centrally managed policy distribution
• [x] Open Policy Agent adopters list — - public production adopters, including financial-services examples
• [x] AWS Cedar overview — - official Cedar overview describing separation of authorization logic, scalability, and analysis support
• [x] Cedar language reference guide — - official Cedar reference describing schema, principals, resources, actions, and context
• [x] Amazon Science: How we built Cedar with automated reasoning and differential testing — - verification-guided development overview from the Cedar team
• [x] How We Built Cedar: A Verification-Guided Approach — - paper reporting model proofs and bug-finding outcomes
• [x] National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Rev. 5 — - official control catalog page, including machine-readable Open Security Controls Assessment Language (OSCAL) publication
• [x] NIST Open Security Controls Assessment Language (OSCAL) — - official machine-readable control catalog initiative for policy-as-code and automated assessment
• [x] APRA CPS 230 - Operational Risk Management — - official APRA prudential standard
• [x] DORA - Regulation (EU) 2022/2554 — - official European Union regulation text
• [x] ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system — - official public summary of the Artificial Intelligence Management System (AIMS) standard
• [x] Bank of England / PRA discussion paper (DP) 5/22 - Artificial Intelligence and Machine Learning — - official United Kingdom discussion paper on how the current regulatory framework applies to AI
• [x] Bank of England / PRA feedback statement (FS) 2/23 - Artificial Intelligence and Machine Learning — - official feedback statement confirming the focus on clarifying existing frameworks rather than imposing new mechanism-specific rules
• [x] PRA supervisory statement (SS) 1/23 - Model risk management principles for banks — - official expectations for strategic governance, policies, procedures, and controls around models
• [x] Bank of New York Mellon (BNY Mellon) InfoQ transcript on OPA-based responsibility management — - practitioner evidence of financial-services use of OPA to centralize entitlement logic
• [x] Ramli 2015 eXtensible Access Control Markup Language (XACML) conflict-analysis paper — - accessible abstract for formal conflict analysis in XACML policy sets
• [x] ar5iv HTML mirror for the Ramli 2015 XACML conflict-analysis paper — - accessible HTML text for the same paper
• [x] Analyzing eXtensible Access Control Markup Language (XACML) policies using answer set programming — - later formal-analysis article and reference hub for access-control policy verification literature
• [x] Basel Committee on Banking Supervision - Principles for operational resilience — - official resilience principles for banks
• [x] Crossref metadata for the seeded Association for Computing Machinery (ACM) Digital Object Identifier (DOI) — - used only to confirm that the seeded DOI resolves to an unrelated paper