ReleaseProof

Differential Reverification for document-driven approvals, powered by Nutrient DWS.

A document packet changes after a human has already reviewed an exception. Most workflows choose one of two bad defaults: invalidate every prior review and force a complete rereview, or carry the old approval forward because the new file appears similar.

ReleaseProof introduces a narrower control primitive: reprocess the current packet, re-ground the evidence, and preserve prior human authority only when the current evidence remains equivalent under the exact policy frozen when that authority was granted.

If the reviewed evidence changes materially, the old review is invalidated and the packet returns to REVIEW_REQUIRED. If the change is non-material and the reviewed evidence still satisfies the historical policy, the prior review can remain valid.

The invention

The core mechanism is a Frozen Evidence-Equivalence Policy + AuthorityBinding.

Each human review stores not only the decision, but also the rules under which that decision may continue to be valid:

• semantic evidence identity: document, page, field path, normalized value and grounded bounding box;
• a versioned evidence-equivalence policy;
• frozen bbox tolerance;
• normalization version;
• bbox metric version;
• explicit Processor-canonical coordinate-space provenance;
• a cryptographic AuthorityBinding over the review, evidence identities and frozen policy.

This prevents a later runtime from silently broadening tolerances or changing normalization defaults and thereby reinterpreting historical human authority.

Example: a review is granted with bbox tolerance 2.0. Later software defaults change to 10.0. If the evidence moves by 4px, the old review still invalidates because it is evaluated under its own frozen historical policy, not the new runtime default.

Unknown historical policy versions fail closed to REVIEW_REQUIRED. Legacy reviews without a recorded equivalence policy receive no guessed tolerance and require exact historical binding.

What Nutrient DWS does

Nutrient DWS performs meaningful core document operations in the live path - it is not a decorative API call.

The current hosted v2 workflow is:

Processor OCR + flatten → canonical PDF → Data Extraction with grounded metadata → canonical page isolation + page hashes → ReleaseProof reconciliation / human authority → Differential Reverification.

Processor

Nutrient Processor creates the canonical rendition before extraction. OCR and flattening are DWS primitives rather than local replacements. Processor is also used to isolate the evidence-bearing canonical pages for page-level hashes.

Data Extraction

Nutrient Data Extraction runs against the canonical rendition and supplies schema-guided values with provider grounding such as page, bbox, confidence and source evidence. ReleaseProof normalizes that grounded output into deterministic semantic evidence identities.

Bounding boxes are explicitly tied to the Processor-canonical coordinate space, so coordinates from an original/legacy rendition cannot silently compare equal to canonical coordinates.

What ReleaseProof adds

ReleaseProof does not try to replace Nutrient's document processing. Its layer begins after DWS has produced grounded evidence:

• cross-document reconciliation;
• stable logical finding identity;
• frozen human-review validity policy;
• AuthorityBinding;
• page/finding-level blast radius;
• selective invalidation and review reuse;
• deterministic replay and audit evidence.

Hosted end-to-end result

The refactored DWS-native v2 core has now been exercised against the hosted Nutrient services.

Hosted acceptance run: 33296171708

Verified runtime behavior:

• Processor canonicalization - PASS_HOSTED
• Data Extraction - PASS_HOSTED
• canonical page isolation and hashes - PASS_HOSTED
• canonical coordinate-space provenance - PASS_HOSTED
• intentional cross-document Shipment ID mismatch - REVIEW_REQUIRED
• human review with frozen policy - PASS
• non-material document revision - prior targeted authority PRESERVED
• material reviewed-evidence change - prior authority INVALIDATED
• resulting packet state after material change - REVIEW_REQUIRED

This is the key behavioral proof: ReleaseProof does not reuse a human decision because a file merely looks similar, and it does not discard every prior review because any byte changed. It re-evaluates the exact reviewed evidence under the historical rules that governed the original authority.

Page-level blast radius

ReleaseProof uses canonical per-page evidence hashes rather than treating every whole-document byte change as equivalent.

A change on one page can invalidate authority grounded on that page while leaving unrelated reviewed evidence reusable when its semantic identity and frozen policy remain satisfied.

This is useful for re-issued trade packets, procurement documents, finance operations, insurance evidence and other workflows where packets evolve after human review.

Public judge path

Production evidence surface: https://evidencebound-releaseproof-dws.vercel.app

Public source: https://github.com/evidencebound/evidencebound-releaseproof-dws

Useful endpoints:

• /health - current acceptance status
• /api/v2-evidence - hosted DWS-native v2 evidence
• /api/live-evidence - retained historical hosted Nutrient evidence
• /api/demo - controlled review/reverification walkthrough
• /api/evaluation - deterministic comparison results

The production surface intentionally replays retained evidence rather than issuing fresh Nutrient requests whenever a judge or crawler loads the page.

Current accepted Vercel deployment: dpl_8yEDRk4Bwz2meH2vwSzuZTY5UNaM.

Verified engineering progress

• public Apache-2.0 repository;
• Python 3.11 / 3.12 / 3.13 CI - PASS;
• semantic EvidenceIdentity - PASS;
• Frozen Evidence-Equivalence Policy - PASS;
• AuthorityBinding serialization - PASS;
• silent runtime policy-drift protection - PASS;
• unknown-policy fail-closed behavior - PASS;
• legacy exact-binding behavior - PASS;
• page-level blast radius - PASS;
• hosted Processor + Data Extraction v2 core - PASS_HOSTED;
• hosted Differential Reverification - PASS_HOSTED;
• refactored Vercel production judge surface - PASS.

Controlled evaluation

In the retained controlled evaluation, a blanket file/version baseline preserves 0/1 prior reviews after a non-material whole-file revision, while Differential Reverification preserves 1/1 because the reviewed grounded evidence remains equivalent.

When the reviewed evidence itself is materially changed, Differential Reverification preserves 0/1 and returns the packet to REVIEW_REQUIRED.

These are controlled mechanism results, not measured customer productivity or reviewer-time savings.

Why this can become a product

The target user is an operations, compliance or document-review team that repeatedly handles evolving packets after a human has already made a decision.

The recurring problem is not only extracting a document. It is answering a harder operational question:

Which previous human judgments are still valid after the evidence changes?

A product path is:

1. Nutrient-backed document normalization and extraction;
2. claim/finding-level evidence identity;
3. selective human review;
4. frozen review-validity policy;
5. differential invalidation and review reuse;
6. replay/audit receipts;
7. integrations with existing approval and workflow systems.

The commercial hypothesis is reduced unnecessary rereview without carrying stale approvals forward. That hypothesis still requires customer validation; no adoption or productivity claim is made here.

Current limitations and evidence boundary

ReleaseProof does not claim that document extraction is infallible, that corrigibility/alignment is solved, or that the prototype establishes SOC 2, FDA 21 CFR Part 11, ISO certification, legal non-repudiation or other regulatory compliance.

Malformed, missing or unsupported provenance fails closed.

The optional Nutrient Digital Signature /sign path is currently FAIL_HTTP_400 / UNDER NUTRIENT DIAGNOSIS. A dedicated isolated probe reproduced the 400 even with a Processor-produced synthetic canonical PDF, and the diagnostic artifact has been sent to Nutrient Solutions Engineering. This does not affect the hosted v2 Differential Reverification core result above.

The provider-neutral Viewer review projection is implemented and contract-tested, but a hosted Viewer flow is currently UNRUN. We do not claim hosted Viewer execution.

Why the project is memorable

The core idea is simple to state but strict in execution:

A human decision carries its own rules of continued validity.

ReleaseProof makes those rules explicit, versioned, evidence-bound and replayable so a later runtime cannot silently reinterpret historical authority.

Built With

• fastapi
• github-actions
• nutrient-data-extraction-api
• nutrient-dws-processor-api
• python
• vercel