Working browser demonstration · synthetic public data
Intelligent Document Intake and Routing Proof Pack
A bounded operational proof package showing how routine document intake can be prepared as a group while duplicates, missing identifiers, and uncertain classification are held for focused human review. The public evidence includes the working demonstration, synthetic record register, browser acceptance matrix, repeatable test suite, operating runbook, and explicit production boundaries.
Proof snapshot
A complete demonstration path from incoming batch to controlled outcome.
The counts are deterministic demonstration evidence, not measured organizational savings.
Before and after
Change the review model, not the responsibility boundary.
The demonstration is designed around proportional control: prepare routine, reversible work efficiently and direct detailed review to uncertainty, incompleteness, duplicates, and unsafe routing conditions.
Every record receives the full intake process.
- Open and inspect the file
- Identify document type and project
- Check for duplicates
- Rename and enter metadata
- Select a destination
- Route the record
- Record what happened
Routine records are prepared together. Exceptions receive focused judgment.
- Preserve the original submission
- Prepare proposed metadata and routing
- Batch-confirm routine records
- Hold duplicates and incomplete records
- Require explicit review for uncertainty
- Route only after all required controls are satisfied
Operating architecture
The control logic is visible from source to outcome.
This is a platform-neutral demonstration architecture. A real implementation would map these stages to approved repositories, permissions, retention rules, connectors, and accountable owners.
Synthetic evidence set
Six fictional records exercise routine work and three distinct exception types.
The synthetic register is public so the demonstration can be inspected without using employer, client, medical, legal, financial, or personally identifying information.
| ID | Scenario | Confidence | Required control | Safe outcome |
|---|---|---|---|---|
| DOC-001 | Known weekly progress report | High | Routine batch confirmation | Prepared for controlled routing |
| DOC-002 | Known vendor invoice | High | Routine batch confirmation | Prepared for controlled routing |
| DOC-003 | Known training record | High | Routine batch confirmation | Prepared for controlled routing |
| DOC-004 | Probable duplicate | High | Individual reviewer decision | Held outside the controlled library |
| DOC-005 | Missing project identifier | Low | Individual reviewer decision | Information request prepared; record remains pending |
| DOC-006 | Uncertain controlling classification | Medium | Explicit classification selection | Cannot route until reviewer confirms classification |
Acceptance evidence
The browser suite verifies both the happy path and the control boundaries.
The automated test executes in the portfolio's configured desktop, tablet, and mobile Playwright projects. The primary end-to-end test also attaches a full-page controlled-outcome screenshot to the Playwright report.
Clean start
Six incoming fictional records appear before any processing state is created.
Routine and exception split
Processing produces three routine records and three exceptions while final routing stays disabled.
Human classification gate
A reviewer cannot resolve the uncertain record without making an explicit classification choice.
Safe duplicate handling
The probable duplicate is held rather than shown as routed into the controlled library.
Missing-data handling
The incomplete submittal remains pending and the workflow records a specific information request rather than inventing a value.
Controlled outcome and reset
Four records are shown as routed, two remain held, and reset returns the demo to its clean starting state.
Operational handoff
The proof pack includes operating and maintenance documentation, not just the interface.
A useful workflow needs repeatability, troubleshooting, change control, and a clear path from demonstration to a separately governed production pilot.
Administrator operating guide
Normal sequence, expected states, automated validation, troubleshooting, change control, and production adaptation checklist.
Open runbook source →Three-minute walkthrough script
A concise public script that shows the problem, batch processing, human review gates, controlled outcome, and production boundary.
Open demo script →Executable browser test
The Playwright spec makes the public behavior reproducible and causes CI to fail if the demonstrated controls drift.
Inspect test source →Production boundary
This is working proof of workflow logic, not a claim that the client implementation already exists.
The demonstration uses deterministic browser state so the review logic can be tested safely and repeatedly. A real pilot would require approved system access, repository ownership, taxonomy, permissions, retention rules, connector security, exception ownership, monitoring, baseline measurements, acceptance criteria, training, and a scale, revise, or stop decision.
Public evidence rule
All demonstration records are fictional. The proof pack is designed to show normal behavior, safe failure, human-review gates, testability, and operating documentation without exposing confidential source material or upgrading expected benefits into measured results.