Document Extraction Triage Demo

This demo uses synthetic demonstration data to make the Decision-PGA idea more concrete. The setting is a familiar document extraction workflow: an AI system proposes or reviews an extracted field, then needs to choose what the workflow should do next.

Imagine a small work queue. One document arrives, the AI reads it, and the workflow has five possible buttons it could press next: accept the extracted value, ask a person to clarify the meaning, retrieve another source, flag the case for review, or defer because the packet is changing underneath the system.

The point is not that Decision-PGA extracts the field. The point is that a Decision-PGA-style diagnostic can describe the shape of uncertainty around which button should be pressed next.

This page uses no patient data, is not clinical validation, and is not a clinical decision support demonstration.

Action Vocabulary

Each synthetic observation is a probability-like vector over five possible next actions:

The fixture is available as JSON: examples/document-triage/demo_cases.json.

Generated diagnostic outputs are also available: examples/document-triage/demo_results.json.

The open-source prototype repository is available at github.com/zmichels/Decision-PGA.

What the numbers stand for

The numbers are not document text. They are the workflow’s repeated estimates of what should happen next after looking at a document situation. In a real system, those estimates might come from repeated model samples, model logprobs, rule checks, OCR perturbations, reviewer votes, or an agent trace. In this demo, they are clean synthetic values so the patterns are easy to see.

You can read each row as one pass through the same case. A row like [0.92, 0.03, 0.02, 0.02, 0.01] says: on this pass, the workflow strongly leans toward accept_extraction. A row like [0.42, 0.45, 0.05, 0.05, 0.03] says: on this pass, the workflow is split between accepting and asking for clarification.

Decision-PGA does not judge the document itself. It reads the group of rows as a cloud of next-action evidence, then asks what shape that cloud has.

How to read the matrices

Each row is one synthetic observation: one repeated model sample, score pass, review vote, perturbation, or agent step. The row values are probabilities over the possible next workflow actions, and each row sums to 1.00.

The columns always follow this order:

So the row [0.92, 0.03, 0.02, 0.02, 0.01] means: this observation puts 0.92 probability on accept_extraction, 0.03 on ask_for_clarification, and so on. Decision-PGA reads the full matrix as one probability cloud. It does not diagnose the rows one at a time.

How To Use The Demo

1. Pick a scenario and read the short document story.
2. Look across the rows, not just at one row. Ask whether the same action keeps winning, whether two actions trade places, or whether the evidence is scattered.
3. Compare that human reading with the generated diagnostic state.
4. Use the mapped workflow action as the practical interpretation.

The useful experience is the contrast between cases. A stable invoice due date and a missing attachment can both involve uncertainty, but they should lead to different next actions. The demo is designed to make that difference visible.

Live Diagnostic Workspace

Choose a case, inspect or edit the probability rows, then run the same kind of diagnostic that a CLI, notebook, MCP tool, or agent wrapper would pass to the prototype. The live runner stays entirely in your browser. It does not call a model, upload data, or contact a server beyond loading this page’s synthetic fixture.

The easiest way to use it is human-first: read the document situation, look at which action columns are winning across rows, then click Run diagnostic and compare your intuition with the generated state.

You do not need to type numbers to use the demo. Start with the prebuilt synthetic cases below. The table is editable only so you can poke at the boundary cases after you have a feel for the workflow.

{}

Try one case as a diagnostic payload

This is the shape of the first case as a Decision-PGA diagnostic request. The demo page is static, but this is the same structure a CLI, notebook, MCP tool, or agent wrapper would pass to the prototype.

{
  "source": "probability_cloud",
  "label": "clean_invoice_due_date",
  "labels": [
    "accept_extraction",
    "ask_for_clarification",
    "retrieve_more_context",
    "flag_for_review",
    "defer"
  ],
  "probabilities": [
    [0.92, 0.03, 0.02, 0.02, 0.01],
    [0.91, 0.04, 0.02, 0.02, 0.01],
    [0.94, 0.02, 0.01, 0.02, 0.01]
  ]
}

The generated readout for the full eight-row fixture is:

{
  "state": "stable",
  "recommended_action": "proceed",
  "demo_workflow_action": "accept_extraction",
  "top_labels": ["accept_extraction", "ask_for_clarification", "flag_for_review"]
}

Scenario Summary

The summary uses short action labels to stay readable. The full action names are listed above in the Action Vocabulary and repeated in the scenario readouts. Read the cases from top to bottom: they move from a clean extraction, to a two-choice ambiguity, to missing evidence, to threshold sensitivity, to a sequence that changes over time.

Visual Walkthrough

The overview below connects each synthetic document situation to the mean action probabilities, the top action sequence across observations, the Decision-PGA state, and the workflow action.

What This Demonstrates

These examples are deliberately simple. They show how a workflow can benefit from distinguishing why it is uncertain:

• stable uncertainty can be routed differently from ambiguity;
• ambiguity can be routed differently from missing evidence;
• threshold sensitivity can trigger review without treating the whole task as failed;
• drift can tell an agent to pause and re-evaluate the trajectory.

That is the practical idea behind Decision-PGA as an agent-facing diagnostic: turn a cloud of decision evidence into a state description that helps choose the next workflow action.