This is the second of the near-neighbour readings, and the cleanest. Its subject is the policy engine, the runtime component that decides whether an action is permitted. The dominant modern instance is Open Policy Agent, with its language Rego; the older, standardised lineage is XACML. The objection this rival raises is the most natural of all: Attestable refuses actions on the basis of rules, and a policy engine is a machine for refusing actions on the basis of rules, so surely the machine already exists.
The finding, stated first: the claim holds, and the rivalry dissolves on contact. A policy engine evaluates whatever rules and whatever facts it is given. It supplies neither. To make one refuse False Determinism, you would first have to build the very thing this work is about, and hand it to the engine as input. The policy engine is not a competitor to the contribution. It is where the contribution would run.
What a policy engine establishes
Open Policy Agent describes itself as "a general-purpose policy engine" that lets you "offload policy decision-making from your software" (Open Policy Agent, n.d.). The operative word is general-purpose. When an application needs a decision, it queries the engine and supplies structured data as input; the engine evaluates that input against the rules it has been given and returns a decision. It is, by its own description, "domain-agnostic," so that you "can describe almost any kind of invariant" (Open Policy Agent, n.d., Rego reference). It establishes that a decision was computed according to the rules provided. It says nothing about what those rules ought to be.
This is the one rival that operates at exactly the right moment: a decision made at runtime, at the point of action. That is not a mark against it. It is precisely why it is a candidate for part of the solution rather than a competitor to it. The decision point is right. The decision content is absent.
The engine supplies no meaning
The decisive property is that the engine reasons over meaning it does not itself hold. Its input is "arbitrary structured data." Its language provides no built-in notion of evidence, provenance, trustworthiness, or fitness for an action; if a policy is to reason about such things, the user "must define and supply such attributes as part of their input data" (Open Policy Agent, n.d., Rego reference). The engine is a competent evaluator of facts whose meaning lives entirely outside it, in the data and the rules the user brings.
It also draws a second line worth naming. The engine "decouples policy decision-making from policy enforcement" (Open Policy Agent, n.d.): it computes a decision and returns it, and the application acts on it. So it separates evaluating a decision from enforcing it, and it separates evaluating a decision from authoring the decision's content. Both separations matter here. The engine's scope ends exactly where the user's model of the world begins.
The objection that has to be met
The natural challenge is direct: you could simply write a policy that inspects a claim's basis and admits or refuses the action accordingly. So the mechanism already exists, and there is nothing new to build.
This does not refute the gap. It describes the gap from the other side. To write that policy, you must already possess three things, none of which is a policy:
- a representation of a claim's basis, that this value was measured, that one inferred, that other produced by a model and tested against nothing;
- an inheritance rule, so that a claim derived from others can be no better founded than its weakest ancestor;
- a mapping from basis to permitted action, adequate to prioritise on, not adequate to energise on.
Each of these is a part of the model the policy would evaluate, not the policy itself. The engine can express "refuse if the basis falls below the bar for this action," but only once basis, the bar, and this action have been defined, represented, and supplied to it. That definitional work is the whole of the contribution. Unfolded completely, the objection says: the contribution can be enforced in a policy engine. Which is not a difficulty for the argument. It is the argument's deployment story.
Why this is the cleanest of the three
Provenance and attestation each required showing that a mechanism aimed at a nearby target misses this one. The policy engine does not even aim at a nearby target; it aims at nothing in particular, by design, and waits to be told what to decide. So the rivalry does not need to be defeated so much as clarified into a division of labour. The model, the taxonomy of basis, the inheritance rule, the mapping to action, is the work. The engine is the thing that runs it. Naming the policy engine as the probable place Attestable would be enforced is not a concession; it is the first concrete piece of how the discipline would actually be deployed.
The same reasoning covers the older lineage. XACML, the standardised attribute-based access-control language that policy-as-code succeeded in practice, evaluates policies over the attributes of subjects, resources, actions, and environments supplied to it (OASIS, 2013). It, too, adjudicates supplied attributes and presupposes their meaning. Same answer, in an older accent.
References
OASIS (2013). eXtensible Access Control Markup Language (XACML) Version 3.0. OASIS Standard. docs.oasis-open.org/xacml/3.0
Open Policy Agent (n.d.). Open Policy Agent: Documentation. openpolicyagent.org/docs/latest
Open Policy Agent (n.d.). Rego: Policy Language Reference. openpolicyagent.org/docs/latest/policy-language