Work / 02
DataTrust OS
Is this revenue metric safe to use before anyone acts on it, and if not, what is it standing on?
A governance-aware analytics system where the metric table carries its own reliability context. dbt test results become a trust score, failed tests become incidents with a lifecycle, and a policy decides whether the metric is allowed, usable with caution, or blocked.
May – Jun 2026 · Public repo, CI on every push
- NYC TLC taxi dataraw.yellow_trips in PostgreSQL
- dbt staging + tests12 governance tests on the staging model
- Trust scoringstored per run, so trust has a history
- Incidentsfailed tests become incidents; recurring ones update, not duplicate
- Governance-aware marttrust_score and open_incident_count sit next to total_revenue
- Policy + blast radiusBLOCKED > USE_WITH_CAUTION > ALLOWED, plus downstream impact
- Twelve dbt tests on the staging model covering null critical fields, negative fares, impossible timestamps and records outside the file's month.
- A trust score computed from dbt results and stored in PostgreSQL per run, so the dashboard can show a trend instead of a snapshot.
- Incidents as first-class records with severity, status and detected, last-seen and resolved timestamps.
- A mart that does not only expose revenue. It exposes trust_score, trust_label, open_incident_count and data_reliability_status in the same table.
- YAML policies with precedence, lineage blast-radius analysis, rule-generated incident briefs, a Streamlit command center and Python tests running in CI.
The project exists to show how a governance system behaves when the data is bad. Current example: 9 of 12 tests pass, trust score 0.725 (DEGRADED), and the revenue mart comes out BLOCKED.
An analyst should not have to know a second tool exists to find out the revenue number is unsafe.
Otherwise a single bad file produces a pile of duplicates and the incident count stops meaning anything.
- Planned improvements are written up in the repository's roadmap document.