triage-pg
A PostgreSQL-native, deliberately simplified fork of triage for temporal machine learning on tabular public-policy data.
triage-pg builds end-to-end early-warning and resource-prioritization models — cohort selection, temporally-correct feature generation, training, prediction, and in-database evaluation — with PostgreSQL as the single substrate, aimed at teaching, consulting, and production monitoring.
Status: v1.5.0 released. The full pipeline runs end-to-end on three real tutorial datasets across all four problem types (including survival) — each with baseline floors — plus in-PG evaluation, fairness auditing, audition, postmodeling diagnostics, a read dashboard + write webapp, and production monitoring. The cloud profile (RDS + S3 + AWS Batch) is live-validated: a full Batch E2E gated the v1.0.0 release. The accepted architecture decisions are audited against the code in docs/adr-conformance.md.
New here? Start at the docs site — or jump straight to the onboarding one-pager · Coming from DSSG triage? The honest side-by-side. (Sources live in the repo under docs/.)
The pipeline
flowchart LR
S[(ontology.*\nyour tables)] --> C[cohort]
C --> L[labels]
S --> F[featurizer\nDFS, as-of joins]
C --> F
F --> M[matrices\nParquet]
L --> M
M --> T[train\ngrid × splits]
T --> P[(predictions\nappend-only)]
P --> E[in-PG evaluation\nmetrics · bias · audition]
E --> D[dashboard + CLI]
P --> MO[monitoring\ndrift · volume · outcomes]
Every artifact along the way (cohort, labels, matrices, models) is content-addressed over its complete input closure — caching, provenance, and GC come from one derivation DAG (docs/derivation-dag.md).
The database schema
triage-pg is two-tier: a small registry control-plane database (projects, users, submissions) routes to one project database per Project, each holding a triage schema. Only predictions and evaluation live in Postgres — matrices are Parquet on local FS / S3. Every built artifact (cohort, labels, matrices, models) is a content-addressed node in the derivation DAG, so caching, provenance, and garbage collection all fall out of the schema below (this is the per-project triage backbone; the derivation/GC and importance edges are elided — see the full ERD).
erDiagram
experiments ||--o{ runs : "attempts"
runs ||--o{ artifacts : "builds"
sources ||--o{ source_versions : "pinned per run"
artifacts ||--o{ cohorts : ""
artifacts ||--o{ labels : ""
artifacts ||--o{ matrices : ""
artifacts ||--|| models : ""
matrices ||--o{ models : "trains"
models ||--o{ predictions : "append-only"
models ||--o{ evaluations : "in-PG metrics"
models ||--o{ bias_metrics : "fairness"
| Cluster | Tables |
|---|
| Lineage / run metadata | experiments, runs, model_groups |
| Artifact derivation DAG | artifacts, artifact_inputs, run_artifacts |
| Source registry & pinning | sources, source_versions, run_source_pins |
| Cohorts & labels | cohorts, labels, protected_groups |
| Matrices & models | matrices, models |
| Predictions | predictions — append-only, range-partitioned on scored_at |
| Evaluation & bias | evaluations, bias_metrics, subsets / subset_members |
| Postmodeling & importances | feature_importances, individual_importances, crosstabs / error-tree tables |
problem_type (classification · regression_ranking · regression · survival) and artifact_kind (cohort · labels · feature_group · matrix · model) are Postgres enums. The full ERD — every foreign-key edge with its ON DELETE behavior (CASCADE / RESTRICT to enforce append-only history / SET NULL) — is in docs/erd.md; the design rationale (registry + per-project split, resolved decisions) is in docs/schema-design.md.
Core contracts
A handful of rules make triage-pg's numbers trustworthy — internalize them before your first run. The Concepts pages explain the why; the short version:
This is the beginning of the README. Read the rest at the original. Read the full README ↗
