The problem statement names three families of existing mechanism that come nearest to the problem, and claims that none of them closes it. That claim has to be earned rather than asserted: each mechanism has to be read in its own specification and shown, precisely, where it stops short. This is the first of those readings. Its subject is provenance, and specifically the W3C PROV family of recommendations, the most institutionally serious attempt anyone has made at recording where information came from.
The finding, stated first: the claim holds, and holds in its strongest form. PROV is a vocabulary for recording provenance, not a mechanism for adjudicating it. It performs no assessment, defines no notion of fitness for a purpose, and maps provenance to no permitted action. The one place in the specification that appears to reach toward trust assessment turns out, on reading, to concede the point rather than close it.
What PROV establishes
PROV provides a structured, interchangeable record of the entities, activities, and agents involved in producing a thing, and the relations among them: that an entity was generated by an activity, that an activity used an entity, that one entity was derived from another, that an entity was attributed to an agent. It is, in its own framing, a way to introduce "the provenance concepts without specific concern for how they are applied" (W3C, 2013a). It records what happened. It is descriptive and retrospective, and it defines no point at which a decision is made.
This is visible even at the relation that comes closest to the question of basis. PROV can record that one entity was derived from another, but the specification states plainly that it "does not attempt to specify the conditions under which derivations exist; rather, derivation is considered to have been determined by unspecified means" (W3C, 2013a). Even the derivation relation is a record to be asserted, not a consequence to be computed. Nothing in the model, and nothing in its formal ontology, introduces authorisation, admissibility, decision-making, or reliability. There is no notion of fitness for an intended action anywhere in the family.
The objection that has to be met
The honest challenge to this reading is not the derivation machinery. It is PROV's own definition of provenance:
Provenance is information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness. (W3C, 2013a)
A sceptical reader seizes on this. PROV names trust assessment as the very purpose of provenance. Does that not make it precisely the admissibility mechanism this work claims is missing?
It does not, and the resolution is decisive rather than a matter of degree. The operative words are can be used to form assessments. PROV supplies the input to an assessment it does not itself perform. The overview document confirms this directly: the phrase "describes a potential use of the recorded information by external parties, not an automated function within PROV itself" (W3C, 2013d). The assessment is real, but it is located outside PROV, in the applications, humans, or external systems that consume what PROV provides.
So the definition, far from closing the gap, marks its exact edge. PROV states that provenance feeds trust assessment and then places the assessment beyond its own boundary. The gap this work addresses is precisely that externalised, undefined step. PROV hands over a faithful record and says, in effect, "assess from this." It does not say whether, for the action you are about to take, the basis on record is enough. You cannot derive a permission from a description, and PROV is, by its own account, a description.
Validity is not trust
One further confusion is worth closing off, because it is where a careless argument would try to smuggle admissibility back in. PROV has a companion specification defining when a provenance record is valid. It would be easy to read "valid provenance" as "trustworthy claim." The specification forbids it explicitly: its notion of validity "is closer to logical consistency" than to the ordinary meaning of the word, and a valid instance can describe "completely false events" perfectly consistently (W3C, 2013b). Validity checks that a record is internally well-formed, that its ordering is coherent, that an identifier is not both an entity and an activity. It says nothing about whether the described events occurred or whether the thing described may be relied upon. Valid does not mean reliable, and neither means admissible.
Why this sharpens rather than threatens the gap
Provenance is the nearest and most serious neighbour, and the "isn't this just provenance" objection is the one this work must answer first. The answer is that provenance and admissibility are different questions, and PROV itself draws the line between them. Provenance answers where did this come from. Admissibility answers may I act on it, for this purpose. A complete, valid PROV graph can record with perfect fidelity that a value was generated by a model, and offer no answer whatsoever to whether that value may now be used to energise a circuit. The record is necessary and it is not sufficient, and the step from one to the other is exactly the step PROV declines to take.
The same reasoning disposes of the more recent provenance-shaped work aimed at machine learning, model cards (Mitchell et al., 2019), datasheets (Gebru et al., 2018), and machine-readable model metadata. These enrich the description; they record what data trained a model and what the model is intended for. They are records of the same kind, and they inherit the same answer. Description, however rich, is not permission.
References
Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. and Crawford, K. (2018). Datasheets for Datasets. arXiv preprint arXiv:1803.09010. arxiv.org/abs/1803.09010
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. Proceedings of the Conference on Fairness, Accountability, and Transparency, pp. 220-229. arxiv.org/abs/1810.03993
W3C (2013a). PROV-DM: The PROV Data Model. W3C Recommendation. w3.org/TR/prov-dm
W3C (2013b). Constraints of the PROV Data Model. W3C Recommendation. w3.org/TR/prov-constraints
W3C (2013c). PROV-O: The PROV Ontology. W3C Recommendation. w3.org/TR/prov-o
W3C (2013d). PROV-Overview. W3C Working Group Note. w3.org/TR/prov-overview