MRGI EVIDENCE / WORKFLOW FIELD GUIDE
Prepare a research evidence packet
Make the sources behind a report inspectable without confusing source originals with the distribution copy.
01 / FROM INPUT TO HANDOFF
Follow the decisions.
This walkthrough describes the intended MRGI product behavior. The browser demo illustrates a small part of the workflow; it does not run the complete application.
- 01
Register the collection
- Start with
- A synthetic brief, observations table, and report.
- Work through
- Identify each original and record its hash before creating derived copies.
- Result
- A source register with stable references.
- 02
Select the supporting material
- Start with
- A report passage and its supporting rows or document reference.
- Work through
- Link the passage to the chosen source version and explain the selection.
- Result
- A reviewable evidence-to-claim map.
- 03
Resolve distribution decisions
- Start with
- The source register and any proposed exclusions.
- Work through
- Review the intended audience and redaction decisions; inspect the actual export.
- Result
- An approved distribution set, with the review recorded.
- 04
Verify the handoff
- Start with
- The packet and a separately trusted manifest.
- Work through
- Recompute file hashes and compare them with the trusted record.
- Result
- A mismatch report or a record that the checked bytes match.
02 / INPUTS & INTERCHANGE
What travels with the work.
These are foundation formats and intended handoff contracts. Support and fidelity must be confirmed for each released build.
| Artifact | Role | Review consideration |
|---|---|---|
| Source and distribution documents | Redaction, fonts, annotations, and embedded objects need dedicated validation. | |
| CSV / XLSX | Supporting data snapshots | A workbook requires a known calculation and snapshot policy. |
| DOCX / manifest JSON | Report and verification context | The manifest format is a proposed exchange contract, not a legal signature. |
A deliberate cross-app boundary
Receive an approved Grid snapshot and an Author report, then package their supporting sources.
The intended handoff should identify the selected resource, its version, the destination, and the user’s authorization. A linked application should not inherit unrestricted file access.
Explore the connected applications ↗03 / BOUNDARIES & READINESS
Know what this example establishes.
- No guarantee of immutability for mutable storage.
- No automatic determination of evidentiary truth or legal admissibility.
- Review identities and signatures require a separately implemented trust model.
Development status
A shared evidence library and CLI have an internal prototype. The redesigned application, approval UI, and full cross-app experience shown here are planned.
Before a production release
Validate real-file behavior and platform support, implement the stated authorization and review rules, and document the tested acceptance scope. The interactive website is a product demonstration, not a release candidate for the application.
04 / PRODUCT QUESTIONS
The details that matter.
Does a matching hash prove authenticity?
It proves only that the checked bytes match the trusted digest. Authenticity depends on where the trusted digest came from and who can replace it.
Will this redact customer PDFs in the browser?
This page only demonstrates hashing of synthetic text. Production PDF redaction and output inspection are separate engineering work.
Open-source foundation
PDF parsing, editing, redaction, signature, and automation code exists in the PdfCraft foundation. Those capabilities are the starting point, not an MRGI exclusivity claim. Read the credits and foundation mapping.
Keep exploring Evidence.
Return to the product breakdown or try the local interactive example.