The instantiation section fixed what the library must be faithful to and what it exposes. It did not say how the code is produced or what would establish that it works, and one thing separates that question here from ordinary software practice: the artefact is to be usable by an operational-technology engineer, not only runnable against the evaluation scenarios. This section states how the implementation proceeds and what the setting imposes.
What is inherited from the review, and what is not
One constraint on the implementation comes from the review and is stated first so the rest is not mistaken for it. The review found every surveyed field handing the remaining judgement to a person who could, in principle, ask. The library's defining constraint follows: it must decide without one, which is why no caller-supplied verdict is accepted and no bypass is offered.
Nothing else in this section derives from the review. Build order, testing, and the demands of the operational-technology setting come from the artefact's own structure and from where it is meant to run. Presenting them as inherited would manufacture an authority they do not have.
Build order
The implementation follows the dependency order the design used, for the same reason: what is built first is what everything else is written against. The record and its construction come first, then the methods that read it, then the enforcement point that calls them.
Record construction leads, which inverts the order a reader might expect. The model treats a record as arriving formed, and for the evaluation scenarios it does. For a tool it does not, and building the deciding parts first would produce a library that decides correctly about records nothing in a plant can produce. Building construction first surfaces which fields a real source can supply and which have no counterpart, and that finding is more valuable early than late, because it may change the record.
What establishes that it works
Three things, and they are separate claims.
Faithfulness is established as the instantiation section states: for each settled design decision, an observation that distinguishes an implementation honouring it from one that does not. This is about the artefact demonstrated being the artefact designed.
Correctness is ordinary software testing, and is claimed no more strongly than that. The methods are comparisons over stated fields and set operations over origin sets, both of which admit direct tests. Nothing here claims verification, and the dissertation does not rest on the code being provably correct.
Usability is the claim the scope decision adds, and it is the one this work is least equipped to establish. A library is usable in this setting if an engineer can construct records from what their systems already emit, author demands for the acts they care about, and place the enforcement point on the path without rewriting what carries values now. Those are three separate obstacles, and the honest position is that meeting them is design work not yet done rather than testing work not yet performed. What the implementation can do is make each obstacle concrete: a library that must be handed complete records shows exactly which fields a deployment would have to manufacture.
What the operational-technology setting imposes
Three constraints come from where this is meant to run rather than from what it computes.
A decision at a boundary happens while something waits. The comparison is a conjunction over four axes and a set intersection, which is cheap, but the record must arrive with the claim rather than being fetched, and that is already why independence rides on an origin set rather than a walk through ancestors. The implementation must not reintroduce a fetch that the model was shaped to avoid.
A refusal is an action. In a plant, declining to act has consequences of its own, and a library that refuses silently or fails closed without saying so is not usable. The verdict carries the failing axis and the values compared for this reason, and the enforcement point must surface a refusal rather than absorb it.
The library sits alongside systems that will not be replaced. It consumes rather than implements the checking of whether a vouching still holds, assumes transport, and expects to be called by something that already carries values. An implementation that required a plant to adopt new transport to gain admissibility would have made the discipline conditional on a change nobody will make.