Decision Trust

Decision Trust finds which unresolved evidence can still change a vendor decision—including combinations that matter only together—using Nutrient DWS grounding and human review.

Comment

Inspiration

Business decisions do not fail only because evidence is missing or conflicting.

They also fail when every unresolved issue is treated as equally important.

A document workflow can correctly identify several unanswered questions, yet the real decision question is different:

Which unresolved evidence can still change the outcome?

Decision Trust explores that question in a bounded vendor-selection scenario.

Its decision-admission logic evaluates unresolved issues against an explicit scenario contract, including whether issues matter individually or only when considered together.

That distinction matters because two uncertainties may each be harmless alone but still become outcome-changing in combination.

It also means that not every unknown must disappear before a scoped decision can proceed. If an unresolved issue can no longer change the outcome, it can remain visible without retaining the power to block that decision.

For this hackathon, I used synthetic vendor-selection documents.

Vendor A's proposal states a 30-day termination term, while its governing contract states 180 days. The declared exit requirement is 90 days or less.

The demonstrated workflow connects decision materiality to reviewable source evidence:

Outcome-sensitive uncertainty → Nutrient DWS grounding → human review → deterministic recomputation → scoped result

The goal is not to automate every business decision.

It is to demonstrate a narrower idea:

Only unresolved evidence that can still change the outcome should retain blocking power.

What it does

Decision Trust identifies which unresolved evidence can still change a scoped vendor decision, including combinations that matter only together.

The application begins with Vendor B leading, while the selection remains in HUMAN_REVIEW.

The decision logic evaluates unresolved issues against the declared scenario rules rather than treating every warning as equally blocking.

In the demo, unresolved issues are tested both individually and jointly.

Neither issue changes the outcome alone, but their combined unresolved state can still flip the selection.

That joint-outcome check is what initially keeps the decision in HUMAN_REVIEW.

In the demonstrated scenario, Vendor A has conflicting termination evidence:

  • Proposal: 30 days
  • Governing contract: 180 days
  • Declared exit requirement: ≤90 days

Nutrient DWS performs the live document operation that grounds the relevant statements back to their original PDF pages.

The reviewer can inspect that source evidence and confirm that the governing contract states 180 days.

Decision Trust then recomputes the scoped result under the declared rule.

Because 180 days exceeds the 90-day requirement, Vendor A no longer satisfies the declared exit condition.

The demonstrated state changes from:

HUMAN_REVIEW → PROCEED

with:

Vendor B — PROCEED

SOC 2 evidence remains unresolved after this transition, but once Vendor A fails the governing 90-day exit requirement, resolving SOC 2 can no longer restore Vendor A to the selected outcome.

Decision Trust therefore distinguishes between:

  • an issue that is still unresolved, and
  • an issue that is still capable of changing the decision.

That is the core mechanism demonstrated by the prototype.

PROCEED applies only to this scoped vendor-selection result.

It does not authorize contracting, onboarding, payment, security approval, or any other downstream action.

How we built it

Decision Trust is a small web application built around a real Nutrient DWS document-processing path and a deterministic, scenario-specific decision-admission layer.

The demonstrated flow is:

Synthetic PDF documents → outcome-materiality check → Nutrient DWS grounding → source inspection → human review → deterministic recomputation → scoped result

Nutrient DWS is load-bearing in the workflow.

It processes the included proposal and contract PDFs and returns inspectable source information including:

  • Extracted text
  • Page location
  • Bounds
  • Confidence

Those grounded sources are exposed to the reviewer instead of asking the reviewer to trust an unsupported AI summary.

The responsibilities remain deliberately separate:

  1. Nutrient DWS grounds document evidence to its source.
  2. Decision Trust evaluates whether unresolved evidence can still affect the scoped decision under the declared scenario contract.
  3. The human reviewer inspects the evidence and confirms the governing term.
  4. Decision Trust deterministically recomputes the scoped result.

Nutrient DWS establishes where the evidence came from. Decision Trust determines what reviewed evidence means for the declared decision boundary.

The prototype uses:

  • Python
  • JavaScript
  • HTML / CSS
  • REST APIs
  • Nutrient DWS Data Extraction
  • Synthetic procurement documents

The implementation also includes:

  • Provider-failure handling
  • Fail-closed review prerequisites
  • Source and replay information
  • Focused contract and decision tests
  • A local browser workflow
  • Explicit scenario and capability boundaries

The current prototype is intentionally scenario-specific.

It demonstrates one controlled vendor-selection contract rather than claiming to be a generic procurement platform, autonomous decision engine, or production-ready approval system.

Challenges we ran into

The hardest problem was not extracting text from PDFs.

The harder problem was deciding what unresolved evidence should still have the power to stop a decision.

A conventional document workflow can flag every conflict and ask a person to clear every warning.

Decision Trust instead needed to preserve a stricter distinction:

  • Is the evidence unresolved?
  • Can resolving it still change the outcome?
  • Can multiple individually non-flipping issues become material together?

That required keeping several responsibilities explicit.

Nutrient DWS grounds evidence to the original documents.

The human reviewer confirms the governing evidence.

The decision layer applies the declared scenario contract and recomputes whether the remaining uncertainty can still affect the result.

Another challenge was keeping the demonstration reproducible without hiding important behavior behind a polished interface.

The final workflow therefore keeps the source PDFs inspectable and uses explicit provider-failure behavior instead of silently fabricating successful results.

We also kept the prototype deliberately narrow.

This is a bounded demonstration using synthetic procurement documents, not a general-purpose autonomous decision system.

Accomplishments that we're proud of

The most important accomplishment is a complete, inspectable causal path from unresolved evidence to a scoped decision transition.

The demo shows:

  • A current leader that cannot yet proceed
  • Unresolved issues tested individually and jointly for their potential effect on the outcome
  • A joint unresolved state that can still flip the selection even when neither issue does so alone
  • Live Nutrient DWS processing of the source PDFs
  • Grounded proposal and contract statements
  • Original source-page inspection
  • A visible HUMAN_REVIEW state
  • Human confirmation of the governing 180-day term
  • Application of the declared 90-day rule
  • Deterministic recomputation of the scoped result
  • A final Vendor B / PROCEED state
  • SOC 2 evidence that remains unresolved without continuing to block the decision once it can no longer change the outcome

The key idea is not simply that the system found conflicting documents.

It is that the application can distinguish between:

unresolved uncertainty

and

outcome-changing uncertainty

The application also fails closed when review is attempted before the required source grounding is available.

During the hackathon, I built the localhost application, live Nutrient DWS integration, source-review workflow, human-review interaction, decision-admission logic, provider-failure handling, scoped recomputation, focused tests, and reproducible judge-facing source package.

Technical validation

The demonstrated path is deliberately bounded and testable.

  • Nutrient DWS performs live extraction and source grounding, preserving page location, bounds, and confidence for review.
  • The tests cover request construction, source parsing and replay, decision behavior, the fail-closed review prerequisite, and the explicit scenario boundary.
  • Repository validation recorded 100/100 passing tests.
  • The disclosure-minimized judge-facing export is intentionally smaller and independently replays the 36/36 focused core tests included in that package.
  • With a Nutrient credential, the judge-facing package can exercise the complete live HTTP path against the included synthetic PDFs.

The judge-facing source package is a disclosure-minimized safe subset for reproducing the bounded public demonstration.

It is not presented as the complete private repository or as evidence of a generic decision engine.

What we learned

This project reinforced two distinctions in AI-assisted document workflows.

The first is:

Correctly extracting a statement is not the same as establishing what that reviewed evidence means for a decision.

Source grounding makes the evidence inspectable.

Instead of accepting an AI-generated summary, the reviewer can return to the source and confirm the governing term.

The second distinction became even more important:

Unresolved does not necessarily mean decision-blocking.

A remaining uncertainty should block a scoped decision only while resolving it can still change the outcome.

That also means unresolved issues cannot always be evaluated independently.

Two issues may each appear non-material alone while becoming outcome-changing when considered together.

Human-in-the-loop design is therefore most useful when the human action is specific and consequential.

In this demo, the reviewer does not click a generic Approve button.

The reviewer confirms a specific governing contract term, and that reviewed evidence changes the deterministic decision state.

Feasibility

Decision Trust is aimed at teams making bounded vendor decisions from documents that may be incomplete, contradictory, or governed by different levels of authority.

A practical first product wedge is vendor selection and vendor-risk review, where proposal, contract, security, and compliance evidence can disagree.

For example, a proposal may promise one termination condition while the governing agreement specifies another.

A procurement or vendor-risk team needs more than extraction.

It needs to know:

  1. where the conflicting evidence came from,
  2. which source governs,
  3. whether the unresolved issue can still change the selection, and
  4. when the remaining uncertainty is no longer material to that scoped decision.

The current prototype proves one bounded termination-term decision contract.

A production version could extend the same approach through configurable decision policies, additional document structures, persistent review state, authentication, and integrations with procurement or vendor-risk workflows.

Those capabilities are future product directions.

No customer deployment, generic decision-engine capability, or production readiness is claimed by the current hackathon prototype.

What's next for Decision Trust

The next step is to test the decision-admission approach across additional independent vendor-review scenarios.

The most important question is not whether more features can be added.

It is whether the same outcome-materiality logic remains useful across different document structures and decision boundaries.

Future work may explore:

  • Additional vendor-review scenarios
  • More document types
  • Configurable decision policies
  • Broader testing of individual and joint uncertainty
  • Persistent review and audit state
  • Additional source-grounding workflows
  • Stronger replay and verification interfaces
  • Authentication and workflow integrations

The current hackathon prototype deliberately stays narrow.

Its purpose is to demonstrate one end-to-end idea clearly:

Ground the evidence. Determine what can still change the outcome. Review what still matters.

Built With

Share this project:

Updates

Submission history