ConsentDocs

ConsentDocs turns high-stakes consent documents into source-grounded, deterministic decisions with human review exactly where uncertainty remains.

Comment

30-second judge path

  1. Watch the 2:59 video above for the complete upload → cited DWS extraction → fail-closed decision → human review → audit-chain flow.
  2. Open the live review console to inspect the three decision paths.
  3. Verify the real privacy-safe DWS receipts and setup instructions.

DWS is indispensable here: it converts each PDF into structured evidence with field-level citations; without that grounded response, ConsentDocs refuses to issue a workflow decision.

Inspiration

Most document AI demos stop after extracting plausible text. That is not enough for consent, where a missing withdrawal method or a mismatch between the named party and signature block can invalidate the workflow. ConsentDocs separates fact extraction from decision authority: Nutrient DWS extracts and cites the facts, deterministic local policy decides whether automation is safe, and a human records the final exception decision in a tamper-evident chain.

What it does

  1. Accepts one PDF through a secure server-side upload endpoint.
  2. Sends the in-memory file to Nutrient DWS Data Extraction with a constrained consent schema and citations enabled.
  3. Normalizes party, date, withdrawal, and contact evidence while preserving source page, bounds, match label, and confidence signal.
  4. Fails closed when required evidence is missing, low-confidence, malformed, uncited, or conflicting.
  5. Routes exceptions to a human review console.
  6. Appends approval or rejection, including an explicit rationale, to a SHA-256-linked audit chain.
  7. Exports a privacy-safe audit summary without the source document, API key, or raw provider response.

Where Nutrient DWS does the heavy lifting

Nutrient DWS performs the core PDF-to-structured-evidence operation, including field-level citations; without that grounded response, ConsentDocs deliberately refuses to issue a workflow decision.

How we built it

  • TypeScript and Fastify backend with an in-memory, 10 MiB-limited PDF upload.
  • Nutrient DWS Data Extraction understand mode with citations enabled.
  • Deterministic policy and canonical SHA-256 result hashing.
  • Append-only human review audit chain.
  • Responsive dependency-free review console.
  • Vitest, TypeScript strict mode, GitHub Actions, and production dependency auditing.

Challenges we ran into

Our first conflict test exposed a subtle safety bug: asking for one generic party_name allowed an extraction model to choose one of two conflicting names, hiding the disagreement from policy. We changed the schema to extract the agreement party and signature party separately, then compare them with local deterministic logic. The repeated real run correctly changed from auto_eligible to needs_review.

Accomplishments that we're proud of

  • Real complete, missing-field, and conflict scenarios with public receipts.
  • Upload-to-human-review end-to-end flow verified against DWS.
  • 23 tests, strict type checking, zero production dependency vulnerabilities, and green CI.
  • API key remains server-side and never enters the browser, logs, repository, or public evidence.

What we learned

Grounding is not the same as policy. DWS can faithfully return the evidence it was asked to find, but the schema must expose every fact the business rule needs to compare. Separating the agreement party from the signature party made that boundary explicit. We also learned to keep provider request metadata out of the canonical business hash: the same evidence should produce the same policy result even when request IDs and timestamps change.

Progress and real evidence

ConsentDocs is a working end-to-end system, not a mockup. Three real Nutrient DWS requests prove the decision matrix: complete consent returns HTTP 200 and becomes auto_eligible; a missing withdrawal method returns HTTP 200 and becomes needs_review; conflicting agreement and signature parties return HTTP 200 and become needs_review. Public privacy-safe receipts bind provider request IDs and input hashes to deterministic result and audit hashes. The repository has 23 automated tests, strict TypeScript checks, green CI, and zero known production dependency vulnerabilities.

Feasibility and business path

ConsentDocs is designed as a narrow workflow layer for privacy, legal, and regulated onboarding teams rather than another general document model. A team can keep its existing approval policy, use DWS to convert incoming PDFs into cited evidence, automatically process only policy-compliant cases, and send every missing or conflicting case to one reviewer queue with the relevant evidence already identified.

The initial product is a per-document API plus reviewer workspace. Teams can pilot it with synthetic or approved documents, then add deterministic policy packs for each document type without retraining a model. The same DWS extraction, citation, review, and audit pipeline can expand to vendor agreements, privacy notices, and onboarding forms. No customer, revenue, or time-savings claim is made without production evidence.

What's next for ConsentDocs

  • Overlay DWS bounding boxes directly on rendered PDF pages.
  • Add DWS redaction and signing after human approval.
  • Persist encrypted audit events for multi-reviewer organizations.
  • Add policy packs for vendor agreements, privacy notices, and regulated onboarding forms.

Links

Doctavian challenge evidence

One-line pitch: ConsentDocs is an evidence-gated document operations agent that turns approved structured consent data into repeatable, audit-ready PDFs through Doctavian.

ConsentDocs now carries an approved evidence record through real document generation. Doctavian performs the indispensable template upload, structured-data upload, and PDF generation operations; without a successful Doctavian generation response, the system does not produce or claim a final consent document.

The real run returned HTTP 200 for generation and download, produced a one-page 54,019-byte PDF, and publishes only hashes and status evidence—never credentials, source text, raw provider responses, or reusable document identifiers. The isolated branch passes 31 automated tests and leaves the original Nutrient submission path intact.

Built With

  • doctavian
  • document-generation
  • fastify
  • github-actions
  • nutrient-dws
  • pdf
  • sha-256
  • typescript
  • vitest
Share this project:

Updates