Provenance, recorded.

First, every element in the model records which mechanism produced it, with the mechanism's family and a version. Second, abstention is a recorded outcome, not a silent failure: an element the engine cannot support is kept, with its provenance, and marked as abstained. Everything else in this note follows from those two ideas.

The note is written for a technical reader evaluating an approach to requirements traceability, provenance or conformance checking. It is conceptual. It does not publish the schema. It describes the model well enough for a technical reader to decide whether the mechanism is serious, and it states what has not been measured.

The two ideas are structural rather than stylistic. A pipeline that reports only a result cannot show which mechanism produced it, and a pipeline that discards hard cases cannot show how much of the corpus it actually read. The record and the abstention are how a reviewer gets a denominator instead of a demo.

Every element carries five provenance fields. They are required, not optional, and the model does not admit an element that lacks them.

The fifth field is the one that changes the review conversation. A model that silently drops what it cannot read looks clean. A model that records the drop shows the reviewer where to look. Validation checks that abstention is consistent with confidence, and that a location is in the form its method requires.

Two details matter more than they look. First, location is not free text. The form follows the method: a page and section for a text method, a cell for a spreadsheet, a record identifier for a structured export. A location that cannot be checked against the artifact manifest is a defect in the record, not a formatting preference. Second, confidence is producer evidence. It is not the probability that the assertion is true, and it is not comparable across methods unless a calibration procedure says it is. The record is careful about what it claims.

An artifact record sits above the element and carries the document's URI, a SHA-256, its page count, and the ingestion tool and version. Each accepted change to an element is recorded in an append-only log as an explicit patch, with the editor, the reason and a timestamp. The log records review edits. It does not promote an element to a different method, and it does not make the element anonymous.

The method field is not free text. It is one of five families, each with a version:

1. Rules. A deterministic parser or check, named and versioned.
2. Language model. A model, named and versioned.
3. Vision model. A model, named and versioned.
4. OCR. A tool, named and versioned.
5. Human gold. A human author or an adjudicated reference, named and versioned.

This note does not name a model, a parser, a tool, an author or a version. Those values live in the record and belong there. The point of the family field is attribution: when an element's confidence changes, or when a downstream answer changes, the record can name the mechanism that changed instead of describing the system as one box.

A method family is not a quality claim. A rule can be wrong. A language model can be wrong. A human can be wrong. The field says who produced the assertion, not whether the assertion is true.

Versioning is what makes the field useful over time. A record that says "a language model" cannot be reproduced. A record that names a family and a version can be compared with last quarter's record, and a change in the output can be set against a change in the mechanism. This note does not name the versions because the version values belong in the record; the requirement is that the record carries one, not that this page advertises it.

The families also constrain what a reviewer can reasonably ask. A rule set can be inspected and re-run. A model can be evaluated and pinned. An OCR tool can be compared against a sample. Human adjudication can be attributed to a named author. Each family supports a different kind of question, and the record lets a reviewer ask the right one instead of asking the whole pipeline to be trustworthy at once.

Validation runs five rule families over the model, plus graph-integrity checks:

Graph integrity checks the relationships the element model asserts: that a relation's endpoints exist and that the model's typed graph is internally consistent. A failing check is a finding about the record, not a judgement about the source document.

The model is also typed: 22 element kinds, 12 relation types and 14 document types. That typing is what makes a check possible in the first place. A bag of paragraphs cannot be checked for reference integrity, because it has no references to check.

Validation is not a spell-check over the source. It is a check over the record: does the provenance point at a real artifact, is it complete, do the typed values hold, and does the graph agree with the indexes? A failing check is a finding about the model. It does not tell the reviewer that the source document is wrong, and it must not be described as if it does. That distinction is why a validation record is attached to the model rather than folded into a score.

The example is illustrative. It shows the shape of the record, not a measured result, and it uses placeholder method values because this note does not publish the schema or name the implementation.

A submitted requirement set contains this sentence on page 14, section 3.2:

The system shall record each approval with the approving official and a timestamp.

The engine records it as an element:

element: REQ-014
  kind: requirement
  provenance:
    artifact_id: appendix-c
    location: page 14, section 3.2
    method: rules:<parser>:<version>
    confidence: 0.86            # illustrative value, not a measured result
    abstention: false

A second element resolves a cross-reference to "Appendix D, clause 4.2". Appendix D is not in the submitted set. The engine does not drop the element and does not guess at the missing clause. It records the element with an abstention:

element: REQ-021
  kind: cross-reference
  provenance:
    artifact_id: appendix-c
    location: page 19, section 4.1
    method: rules:<parser>:<version>
    confidence: 0.31            # illustrative value, not a measured result
    abstention: true

A reviewer reading the record sees two things a document-only review would hide: every assertion names the mechanism that produced it, and the unsupported cross-reference is visible as a recorded abstention rather than as a blank space. The reviewer can accept the element, edit it (which records an explicit patch and a reason), or leave it abstained. The point is that the state of the record is visible either way.

The example also shows why a confidence value is not a verdict. The abstained element has a value, and the value is low, but the record does not rely on the reader interpreting a number. It marks the abstention explicitly. A reviewer can disagree with the value and still see the state of the element. That separation is deliberate: the score is producer evidence, and the abstention is the decision the record makes available.

Nothing in the example is a measurement result. The values are illustrative, the identifiers are placeholders, and the method strings name a family and a version slot. The example is here to show the shape of the record, not to imply that a corpus has been scored.

Suppose a run reports precision of 0.94 on extracted requirements. The figure is a ratio over the elements the run accepted. Abstained elements are outside that denominator. If the engine abstains on the hard part of a corpus and answers the easy part, the ratio can look strong while the reader learns little about the corpus. The same ratio can move when the accepted set moves, without the model improving or degrading.

That is arithmetic, not a claim about any particular system. A precision figure is a statement about answered elements unless the abstention rate and the element count travel with it. Precision without abstention measures the answered subset; it does not measure the corpus. The pair, with coverage stated, is the smallest honest instrument.

Our design rule follows: precision is reported beside the abstention rate, beside the element count, on a held-out set. The set size is chosen from the resolution the claim needs, not from a convention. No target figure is promised, and no accuracy figure is claimed on this page. Extraction accuracy on real documents is unmeasured; this note publishes the instrument, not a result.

A report that carries precision must also carry its coverage: how many documents were submitted, how many the run read, and how many it refused or abstained on, with the reason. A report without coverage cannot show whether a high ratio came from reading most of the corpus or from declining the hard part. Coverage is a field the report would carry, not a number this note invents. The same rule applies to a comparison: both runs report coverage, or the comparison is not interpretable.

The same logic applies to a comparison between methods. A method change that raises precision while raising abstention has not obviously improved; a method change that leaves precision flat while cutting abstention has. Without both numbers, the comparison cannot say which happened. The verdict is a comparison of records, not a leaderboard of scores.

A technical buyer can inspect the record without receiving the schema. The review shell loads one document and shows the elements with their provenance, so the buyer can see the shape of the record on real material. The validation output and the acceptance log are readable in the same session; a change to an element appears as a patch, not as a new row, and the reason is recorded beside it. The engine processes one document set at a time, so the inspection is of one set at a time. Portfolio-scale review is work to be done, not a capability this note claims.

That is the honest demonstration. A buyer who needs to see the implementation can ask for it in a technical conversation. A buyer who wants a schema document to read has a different requirement, and this note does not meet it.

This note does not publish the schema. A conceptual model is enough to establish that the mechanism is serious; the implementation is the asset, and a buyer who needs to see it can examine it directly.

It does not claim extraction accuracy on real documents, because that has not been measured. It does not claim a deployed customer system to monitor. It does not claim a standard: a standard needs adopters, and this is one implementation of a method. It does not claim a certification or an accreditation. PDF is out of scope by design, and the engine handles one document set at a time; portfolio-scale validation and a documented integration API are work to be done.

What it does claim is the record: every element names its source, its location, its method, its producer's confidence and whether it was abstained. A reviewer can check that record. That is the part worth reading the note for.

Read the capability page for the company record.

Amyn Porbanderwala · Founder and Principal, HARBOR Initiative LLC · 4 November 2026 · ap@harborgovcon.com