DIO/ODI Hub — Manifest, publications, reference artifacts & updates · Application Mappings · Reference Vocabulary
This mapping examines how the authorization obligations described in Constraining the Commit Boundary: A DIO/ODI-Informed Authorization Guardrail for Agentic Entity Resolution can be represented, evaluated, enforced, and audited in a Policy-as-Code architecture. Open Policy Agent (OPA/Rego) and Cedar are documented reference points, not preselected or validated implementations.
Evidence usable for reasoning ≠ evidence eligible to authorize a persistent identity mutation. A policy engine can evaluate the request and conditions supplied to it. That does not, by itself, establish the truth of the identity hypothesis, authenticate evidence, discover all material conflicts, or make the later graph write atomic.
The mapping proceeds from a DIO/ODI-informed contract obligation to a policy representation/evaluation mechanism and the residual conditions required for enforcement. Relations are analytical, not equivalence claims.
| Contract obligation | Policy-as-Code correspondence | OPA / Rego | Cedar | Relation and residual requirement |
|---|---|---|---|---|
| 1. Bind authorization to the proposed mutation. | Represent operation, target, actor or service, and operational scope. | OPA accepts arbitrary structured input and evaluates it against Rego policies. | Authorization request uses principal, action, resource, and context (PARC). | Relevant mechanism The application must define the protected identity-changing actions and targets. |
| 2. Require support for each required proposition. | Carry required claims and claim-specific evidence references. | Rego can inspect structured evidence metadata and return a structured decision. | Claims and evidence metadata can be represented in entity attributes or request context where the application schema permits. | Requires policy modeling Evidence provenance, authenticity, scope, and eligibility need trusted validation. An agent must not self-certify them. |
| 3. Evaluate identity-preserving constraints. | Express configured constraints as predicates over the proposed operation and candidate state. | Rego can evaluate predicates over supplied input and policy data. | Conditions can evaluate attributes of the principal, resource, and context. | Requires policy modeling The domain constraint set and trustworthy candidate-state representation remain application responsibilities. |
| 4. Distinguish breach from unknown evidence. | Preserve PASS, BREACH, and UNKNOWN_EVIDENCE as distinct states. | OPA can return application-defined structured results; the policy and caller define their meanings. | Cedar returns Allow or Deny with diagnostics, including policy evaluation errors; that is not the DIO/ODI multi-state contract. | Requires explicit integration A denial is not necessarily a semantic breach; a missing or erroneous decision must not become authorization. |
| 5. Bind the decision to context and time. | Include observation time, evidence-validity intervals, and relevant context. | These values can be supplied in structured input and inspected by Rego. | Context and entity attributes can supply values for policy conditions. | Requires policy modeling The engine does not independently determine the correct temporal interpretation of identity. |
| 6. Keep policy revision valid at commit. | Record the revision used and check that it is still applicable. | Decision logs can include the associated bundle revision; bundle distribution is eventually consistent. | The host should record an identifier for the exact policy set used; this mapping assumes no built-in commit-time policy lock. | Requires integration Revalidate or reject when the applicable policy has changed. An audit record is not a freshness guarantee. |
| 7. Keep graph state valid at commit. | Bind authorization to a candidate snapshot or expected graph version. | OPA can inspect a version supplied as input but does not make the later graph transaction atomic. | A version can be supplied as context or resource data, but Cedar does not lock the graph store. | Requires integration Re-check the state version at the protected write boundary using a transaction or compare-and-swap. |
| 8. Enforce the decision at the protected write. | Make the write conditional on a valid decision for the same operation. | OPA separates policy decision-making from policy enforcement; the caller/enforcer must act on the result. | The calling application must enforce Cedar's authorization response. | Requires integration Every effect-capable write path must enforce the contract; an alternate route must not bypass it. |
| 9. Preserve audit provenance. | Bind evidence references, request, policy/state versions, decision, and commit outcome. | Decision logs can include input, result, decision ID, and bundle metadata; sensitive fields need deliberate masking. | Decision diagnostics help explain the result; complete evidence/commit linkage remains application-level. | Relevant mechanism Neither engine alone provides the complete evidence-to-commit record described here. |
| 10. Handle unknowns and failures safely. | Define deferral or fail-closed behavior for missing, timeout, unavailable, or erroneous decisions. | The caller must distinguish valid results from undefined results, transport failure, or evaluation error. | Evaluation diagnostics are available; the application defines their effect on the protected operation. | Requires integration UNKNOWN, timeout, and unavailable authorization must not be interpreted as PASS. |
| 11. Do not treat authorization as semantic truth. | Constrain interpretation of Allow/PASS to the encoded policy and supplied input. | OPA returns the result of the queried policy under the current input/policy data. | Allow means a permit policy matched without an applicable forbid decision under Cedar's algorithm. | Not established by the decision Neither result independently proves that the real-world identity relation is true. |
A stable integration contract could carry the proposed mutation, the required propositions and their evidence references, the expected candidate-state version, and the applicable context/policy revision. The following is a conceptual shape, not an OPA or Cedar native schema and not executable policy code:
{
"operation": {
"kind": "identity_merge",
"target": "candidate-graph-mutation",
"scope": "declared-operational-scope"
},
"required_claims": [
{
"proposition": "same_legal_entity",
"evidence_refs": ["evidence-record-1", "evidence-record-2"],
"evidence_state": "application-defined-state"
}
],
"candidate_state": {
"expected_graph_version": "version-id"
},
"authorization_context": {
"observed_at": "timestamp",
"policy_revision": "revision-id"
}
}
The field semantics must be defined by the application. A string such as PASS or an evidence reference is not proof by itself: the authorization path needs trusted validation outputs, controlled provenance, and binding to the candidate operation and state.
Suppose an agent proposes merging two supplier records and assigns its identity hypothesis a confidence of 0.97. The score can guide exploratory reasoning or prioritization, but it is not, by itself, authorization to change the persistent graph.
A DIO/ODI-informed integration asks whether the operation is in scope; every required proposition has eligible claim-specific support; material conflicts are resolved or explicitly block authorization; configured identity-preserving constraints pass; and the policy and graph versions remain valid at the protected commit boundary.
If a required claim lacks eligible support, the outcome may be deferral or UNKNOWN rather than a low-confidence estimate converted into a permit. If the graph version changes after authorization, the earlier decision must not automatically authorize the stale mutation. Even when all encoded conditions pass, Allow means that the configured contract passed against the supplied input; it does not independently prove real-world identity.
This is a derived, non-normative application mapping. OPA and Cedar are distinct systems with different request and decision models. The mapping identifies capabilities and gaps; it does not treat their constructs as interchangeable.
The scope is authorization of a proposed persistent identity mutation. The mapping does not model the full hypothesis-conditioned evidence-acquisition loop, downstream mutation propagation, dependency-aware cascade mitigation, or post-commit identity recovery. It does not claim these problems are solved by adding a policy engine.
External sources document the technical capabilities. The obligation-to-mechanism relations and the residual requirements are the analytical interpretation in this mapping, not claims made by the OPA or Cedar documentation.
Author: Daniel Beránek · ORCID 0009-0004-0050-0264 · License: CC BY 4.0.