Try a small part of the idea
Can you trust the report?
Trace a fictional request, inspect a quality issue, and see how a correction changes the summary.
Synthetic walkthrough
Follow a request.
4 fictional records
Computed in your browser
- 1. SourceFictional request records
- 2. CoreInspect quality rules
- 3. MartSummarize eligible records
Rule: completion-date
- Request
- RQ-101
- Status
- complete
- Created
- 2026-08-03
- Completed
- Missing
- Approved / total authors
- 3 / 3
Use the prepared completion date, August 12, 2026. This changes only the example in your browser.
All source records remain visible, including any that fail a check.
| Request | Workflow | Status | Created | Completed | Approvals |
|---|---|---|---|---|---|
| RQ-101 | Protocol review | complete | 2026-08-03 | — | 3 / 3 |
| RQ-102 | Report review | awaiting approval | 2026-08-07 | — | 2 / 4 |
| RQ-103 | Protocol review | complete | 2026-08-10 | 2026-08-18 | 2 / 2 |
| RQ-104 | Report review | draft | 2026-08-15 | — | 0 / 3 |
Where does RQ-101 go?
- Source record
The fixture preserves the request’s original fields and identifier.
- Core quality check
The completion-date rule fails. The record remains inspectable.
- Illustrative reporting mart
This request is excluded from the report summary until corrected.
The website reduces the architecture to three steps. The actual project also has staging tables, event history, dimensions, and reporting views.
eligible requests
blocked by checks
completed requests
awaiting approval
What this example shows
A record can have a plausible status and still fail a consistency check. This browser example keeps the source visible while excluding failed records from an illustrative report.
These are original fictional fixtures. The example is inspired by the project’s source, core, and reporting boundaries; it does not run the underlying Python or SQL pipeline. No data leaves your browser and no model calls are made.
Download the initial example as JSON · Architecture, evidence, and limitations