Designed for analysts and operations reviewers, Evidence Lab helps work through document-based questions: was a delivery accepted, did a payment arrive, or does a later record correct an earlier one? It brings source documents, AI-assisted analysis and review notes into one place.
A delivery review, in practice
Synthetic walkthrough · Illustrative answers
One parcel. Two different stories.
Was R-204 received by 3 pm?
Conflicting records
One record says delivered; another says refused. Both describe the same parcel before the cutoff.
Follow the sources
[1] Delivery log · 2:10 pm
“R-204 marked delivered.”
[2] Receiving note · 2:20 pm
“R-204 refused at reception.”
My role
I shaped Evidence Lab around a practical question: what helps people make sound judgments from incomplete or conflicting records?
I helped define what reviewers needed to see, which uncertainties to surface, and how to evaluate the results. I contributed initial evidence judgments and tested the workflow in practice, working with AI assistants on implementation, experiments, analysis and documentation.
Three product decisions
- Review needA claim needs checking
Make the reasoning inspectable
I prioritized traceability over a single polished summary. Source passages and original answers stay visible, with review notes kept separate, so a reviewer can check the reasoning and challenge a conclusion.
- Review needThe records disagree
Make uncertainty useful
I chose to distinguish conflict from missing evidence, even when that leaves a question unresolved. The distinction tells a reviewer whether to reconcile competing accounts or look for another document.
- Review needReview takes more than one sitting
Keep review manageable
To keep review manageable, I favored short sessions over a long checklist: at most two questions at a time, with notes that can be saved and restored. Skipping a question never implies agreement.
A trade-off that shaped the product
A paired study compared fixed multi-step search with reading the full document set. Both methods answered the same 32 questions on two previously seen synthetic cases.
Fixed multi-step
Agreement with author labels: 27/32
Relative input tokens: 1×
Full context
Agreement with author labels: 32/32
Relative input tokens: 2.9×
The multi-step search missed decisive records in five questions. Full context matched the author labels in all five, using more input. For small cases, this made it a useful reference.
That result helped set the next priority: make questions and unresolved conditions clearer, while keeping retrieval methods available for comparison. Before adding another retrieval step, check what evidence actually reached the model.
What works today
The local research prototype takes a small document set from intake to answer review. It supports preparing model inputs, importing saved answers, checking source versions and restoring review notes.
Built with Python, model APIs and an HTML/JavaScript review interface.
Technical details and validation
The paired study used 72,062 input tokens for fixed multi-step and 210,823 for full context, with one answer per question per method. Author labels stayed outside model inputs.
The latest new-case workflow passed 118 targeted Python checks and 47 software DOM checks, using three engineering cases, six simulated responses and one matching historical response. These checks cover software behaviour, including parsing, citation binding and recovery.
I confirmed the earlier workbench’s reading, citation, export and note-restoration flow in actual use.