The three disciplines closest to this work, data provenance, policy enforcement, and software attestation, are the ones most likely to be offered as already solving its problem. Each is a mature body of practice with standards, tooling, and deployment at scale. Each, examined in its own terms, turns out to certify or decide something other than a claim's basis for action, and each marks its own boundary in its own founding literature. Taken together they define the gap precisely, because they surround it: provenance records where a value came from, policy decides whether an action is permitted, and attestation certifies that a process was followed. None of the three judges whether the value a system is about to act on is well enough founded to act on. That judgement falls between them. These are the first three mechanisms of Figure 1, and this section establishes for each, in its own founding literature, that it sits where the figure places it.
Provenance records lineage; it does not adjudicate it
Provenance is the discipline of recording the history of a piece of data: the entities, activities, and agents that produced it. Its standardised form, the W3C PROV data model, is explicit that provenance is a representation used to form a downstream judgement, not the judgement itself. PROV describes provenance as information that can be used "to form assessments about [data's] quality, reliability or trustworthiness" (W3C, 2013a); the assessment is made by someone else, later, on the strength of the record. The field's founding survey draws the boundary in the same place. Provenance, in its originating account, is "the equivalent of a logbook", built for closed systems where a workflow has full control over what it records, and extended to the web precisely to carry lineage across the boundary between systems that classical provenance could not (Moreau, 2010). The nearest provenance comes to adjudication is retrospective auditing, checking a recorded history against rules after the fact, which presupposes that the provenance is authentic and is concerned with what already happened rather than with whether a prospective action is warranted. The independent e-science survey states the division of labour without ambiguity: provenance supplies a history "that will allow the user to apply their own metrics to determine if the data is acceptable" (Simmhan et al., 2005). The record informs; the user decides.
The strand of provenance closest to machine learning does not close this gap either. Model cards and datasheets document a model or dataset's intended and out-of-scope uses, its evaluation, and its known limitations (Mitchell et al., 2019) (Gebru et al., 2018). This is genuinely closer, because it speaks about use rather than mere lineage. But it is documentation at the level of the model, authored once, addressed to a human choosing whether to deploy. A datasheet's note that a dataset is unsuitable for a purpose is guidance to a person; it is not a representation carried with an individual output that says whether that output's basis suffices for the action now being taken on it. Even the provenance work that reaches toward fitness-for-use stops at describing the artefact, not adjudicating its individual claims.
Policy decides permission; it presupposes the basis
Policy engines answer a different question: given a request, is it permitted. The mature model here is attribute-based access control, in which a decision point evaluates rules over the attributes of a subject, resource, action, and environment (NIST, 2014). Modern policy-as-code tooling such as the Open Policy Agent and its Rego language, and the older XACML standard, are engines for exactly this evaluation (Open Policy Agent, n.d.) (OASIS, 2013). They are content-neutral by design: they enforce whatever rules they are given over whatever attributes they are supplied. That design is their strength and the precise location of what they do not do. Someone must define the attributes and the rules that say which actions those attributes warrant, and that definitional work, deciding what basis suffices for what action, is presupposed by the engine rather than performed by it. The ABAC standard is revealing on exactly this point: it allows a confidence or assurance measure to be supplied as an attribute and factored into a decision, but it does not produce one. There is a slot for a basis measure in the model, and the model does not fill it. Policy can enforce an admissibility rule if one is authored and if the basis is measured and supplied, but authoring that rule and measuring that basis is the work, not the enforcement of it.
Attestation certifies process; not the correctness of its output
Software attestation certifies that an artefact was produced by a declared process. The in-toto framework secures a software supply chain by requiring that each step be performed by an authorised party and that the chain of steps match a signed layout (in-toto, n.d.), and its research paper is explicit that its guarantees are about layout integrity, artefact-flow integrity, and step authentication, that is, about the process, not the correctness of what each step produces (Torres-Arias et al., 2019). Its own threat model makes the boundary concrete: it defends against a product "for which not all steps have been performed", including as the result of an honest mistake, but a step performed by the authorised functionary is trusted in its output. The SLSA framework, which grades supply-chain integrity in levels, is likewise a threat model for tampering and provenance of the build, not a judgement of whether the built artefact's behaviour is sound (OpenSSF, 2023). In-toto's own motivation contains a passage strikingly close to this work's language, complaining that tool information is often "not appropriately utilized or even shown to clients who can make decisions about the state of the product they are about to utilize" (Torres-Arias et al., 2019). But the remedy it proposes is to make the record of the declared process complete and visible; it verifies that the process was followed as specified. It does not represent whether a claim the process emitted has a basis sufficient for the action a consumer will take on it. It is a genuine cousin of this work, and it stops at the integrity of a declared process, one boundary short of the admissibility of a claim.
The gap the three define
The three disciplines fail to supply admissibility in three different ways, and the pattern across them is the point. Provenance describes a value's history and hands the trust judgement to a later reasoner. Policy enforces a permission rule and presupposes the basis the rule would need. Attestation certifies that a process ran as declared and trusts the output of each authorised step. These are not all the same kind of mechanism, and the difference matters: provenance and attestation are integrity mechanisms, recording and certifying handling, while policy is an evaluation and enforcement mechanism that decides over whatever semantics it is supplied. What unites them is not their kind but their common silence on one question: none, at the point of action, judges whether a particular value's basis suffices for the particular act. Two record and certify a value's handling; the third enforces a rule but presupposes the semantics of basis the rule would need. This is not an oversight that a further increment of any of the three would repair. Provenance that recorded more, policy that evaluated more attributes, and attestation that verified more steps would each be more of what they already are, and none would cross the line from integrity to admissibility. The gap is defined not by what these fields lack but by what they were built to do, and admissibility sits in the space they jointly enclose and none occupies. The rest of the review shows that the same boundary recurs in every neighbouring field, which is the evidence that the gap is structural rather than a local absence in these three.
References
W3C (2013a). PROV-DM: The PROV Data Model. W3C Recommendation. w3.org/TR/prov-dm
Moreau, L. (2010). The Foundations for Provenance on the Web. Foundations and Trends in Web Science, 2(2-3). doi.org/10.1561/1800000010
Simmhan, Y. L., Plale, B. and Gannon, D. (2005). A Survey of Data Provenance Techniques. Indiana University TR IUB-CS-TR618. scholarworks.iu.edu
Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D. and Gebru, T. (2019). Model Cards for Model Reporting. FAT* 2019. arXiv:1810.03993. arxiv.org/abs/1810.03993
Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daume III, H. and Crawford, K. (2018). Datasheets for Datasets. arXiv:1803.09010. arxiv.org/abs/1803.09010
NIST (Hu, V. C., et al.) (2014). Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST SP 800-162. doi.org/10.6028/NIST.SP.800-162
Open Policy Agent (n.d.). Open Policy Agent: Documentation. openpolicyagent.org/docs/latest
OASIS (2013). eXtensible Access Control Markup Language (XACML) Version 3.0. OASIS Standard. docs.oasis-open.org/xacml/3.0
in-toto (n.d.). in-toto Attestation Framework: Specification. github.com/in-toto/attestation
Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola, R. and Cappos, J. (2019). in-toto: Providing farm-to-table guarantees for bits and bytes. USENIX Security 2019. usenix.org
OpenSSF (2023). Supply-chain Levels for Software Artifacts (SLSA): Threat Model, v1.0. slsa.dev/spec/v1.0/threats