Inspiration

Regulated workflows still depend on contracts, notices, claims, IDs, invoices, and other documents where “almost right” is not acceptable. AI can read them quickly, but a production workflow also needs source grounding, exception routing, human accountability, and an audit trail.

EvidenceReady was built to make that boundary explicit: AI does the reading; humans own the decision.

What it does

EvidenceReady turns a document into a controlled evidence pipeline:

  1. Source lock — hashes the selected document with SHA-256 so every review is tied to a specific source.
  2. Nutrient DWS extraction — sends the document through a server-side gateway to the Nutrient DWS Data Extraction API.
  3. Evidence gate — reads typed fields plus confidence/source metadata and surfaces missing evidence as an exception.
  4. Human review — release remains locked until a reviewer confirms source matching, missing-evidence handling, and that no inferred fact was accepted as source evidence.
  5. Audit release pack — exports the source hash, extracted fields, DWS metadata, review checks, timestamps, and explicit human approval as JSON.

Where Nutrient DWS does the heavy lifting

Nutrient DWS performs the core document operation: parsing the uploaded document and extracting the structured schema with confidence and source-grounding metadata. EvidenceReady depends on this result to build its review queue; it is not a throwaway API call.

The live acceptance run extracted a synthetic benefit-review notice with 11 business fields, 95% minimum confidence, page/source references, and correctly surfaced Proof of residence as missing evidence requiring human review.

How we built it

  • Nutrient DWS Data Extraction API for schema extraction and evidence metadata
  • Cloudflare Workers for the production server-side API gateway and secret binding
  • Vanilla JavaScript + HTML/CSS for a dependency-light review interface
  • Web Crypto API for client-side SHA-256 source fingerprints
  • No application database: the demo keeps the API key server-side and does not persist uploaded documents

Challenges

The largest implementation challenge was not calling an AI API; it was preserving a deterministic control boundary around the response. We normalized the real DWS response shape (output.data + output.metadata), separated missing evidence from extracted evidence, and made release impossible until the reviewer completes every required check.

We also hardened deployment behavior: API GET returns 405, empty POST returns 400, unknown routes return 404, API responses are no-store, and security headers deny framing and unnecessary browser permissions.

Accomplishments

  • Real end-to-end Nutrient DWS call verified with HTTP 200
  • Human approval gate verified locked before all three checks
  • SHA-256 provenance and timestamped audit events verified
  • Mobile QA at 390×844 with zero horizontal overflow
  • Production performance observed at LCP 89 ms, TTFB 4 ms, CLS 0.00
  • API key stored only as a Cloudflare Worker secret

Feasibility

The architecture is intentionally small and deployable: a stateless browser UI, a server-side DWS gateway, and portable audit JSON. The same control pattern can support regulated onboarding, claims, compliance evidence, public-service notices, lending packages, or document QA without turning extraction into an automatic business decision.

What’s next

Next iterations would add multi-document cross-checking, configurable review policies, optional DWS Viewer integration for page-level visual verification, signed release artifacts, and organization-specific schemas while keeping the same human-release invariant.

Live demo: https://evidenceready-dws.senih-bayankulu25.workers.dev/

Source: https://github.com/senih25/evidenceready-dws

Built With

  • cloudflare-workers
  • css3
  • document-ai
  • html5
  • human-in-the-loop
  • javascript
  • nutrient-dws
  • rest-api
  • web-crypto-api
Share this project:

Updates

Submission history