How matching works
Matching is the step between a stack of documents and a defensible answer about whether an application is complete. This is what happens inside it, and where extraction joins.
Reading is a model. Matching is arithmetic on what it read.
Approval is the only step that files anything.
The model reads. The engine decides.
A language model is used for exactly one thing here: reading. It looks at a document and reports what the document says about itself — the descriptor facts printed on the page. Those facts are evidence. They are not a placement, and nothing about where the document belongs is decided by the model.
The binding itself is deterministic. Every key a requirement declares has to be present; values are trimmed and lower-cased; the resulting key set is fingerprinted; and a document binds only when exactly one declared variant produces an identical fingerprint.
A partial read is not a near-match. It is no match. Where the evidence is incomplete, or where two declared variants would both fit, the document is left unassigned for a person to settle. The engine does not break the tie by guessing, because a guess here is indistinguishable from a fact three screens later.
A document is an address, not a record.
Sheaf does not mint an id for a document. Its identity is the span of pages it occupies inside an immutable source file — file_8849:p14-22. Two runs that cut the same pages describe the same document, so there is nothing to reconcile between them.
A later run can re-cut those boundaries. When it does, an existing filing carries over only if the new span sits entirely inside the span that was approved. Partial overlap leaves the requirement open rather than inheriting a decision nobody made about those pages.
Presence is not a decision.
A document arriving is not a requirement being met, and the two are held separately on purpose. What the analyzer produces is a recommendation. What clears a requirement is an approval.
- Recommended
- The analyzer’s suggestion, carrying the document it found and the pages it found it on. Visible, reviewable, and worth nothing to the count.
- Approved
- A person — or a workflow configured to act as one — accepted the placement. This is the filing. Nothing else is.
- Pending
- Filed and waiting on review. It occupies the requirement without clearing it.
- Superseded
- A newer decision at the same address replaced this one. The old decision stays on the record instead of being overwritten, so the trail survives the correction.
- Unassigned
- Read, named and addressable, but matched to no requirement. Kept and reviewable; never counted.
- Missing
- No live approval against a requirement that asks for one. Derived from the absence rather than stored as a state.
Coverage is derived, never stored.
There is no completion field to drift out of date. The counter, the outstanding list and the register all read from one derivation:
- The denominator is what the checklist actually asks for. Blocks Sheaf can recognise but nobody requested are excluded until a document lands on one.
- The numerator counts live approvals only. An analyzer suggestion moves nothing, however confident it is.
- A requirement made of several declared parts clears only when every part is filed. Four of five is zero, not eighty percent.
- Where a requirement accepts alternatives, satisfying one marks its siblings covered rather than leaving them outstanding.
Withdraw an approval and the number moves in the same turn, because the number was never written down.
Where extraction joins.
Reading values out of a document and filing that document are separate events, deliberately:
- Reading needs no approval
- Schema-directed extraction runs against any addressable range — an approved document, a split piece, or an unassigned one nobody has placed yet. You can see what a document contains before deciding where it belongs.
- Filing does
- Approval is what materialises the span into the approved registry as a fixed artifact with its own retained copy of those pages.
Both are keyed by the same page-span address. Re-cut the boundaries and the values stay attached to the pages they came from, rather than orphaning against a document id that no longer refers to anything.
Sheaf never files on your behalf without a rule you configured. Automatic filing is a mode you turn on per workflow, and every decision — human, workflow or agent — is recorded against the actor that made it.