Inspiration
ML release decisions often fail at the last mile: the model exists, but the evidence around its training data, freshness, ownership, and rollback path is scattered. LineageReceipt turns that evidence into a small, inspectable release decision.
What it does
LineageReceipt reads a model's DataHub lineage, checks deterministic release rules, and produces an immutable receipt. The demo intentionally returns REPAIR when the model owner is missing, the feature set is stale, or no rollback runbook is linked. It then writes the verdict, receipt ID, digest, and gap IDs back to the DataHub ML model custom properties and reads them back for verification.
How it is built
- The React/Vite UI renders a four-node lineage chain: training dataset, feature set, ML model, and production deployment.
scripts/datahub_roundtrip.pyuses the officialacryl-datahubSDK to upsert a synthetic DataHub graph, create a training run with input/output URNs, read the lineage aspects, and persist the decision.engine/release-audit.mjsis a dependency-free deterministic rule engine. The Python adapter mirrors the same canonical payload and digest so the browser receipt and DataHub readback agree.- The repository is public under Apache-2.0 and contains no production data or credentials.
DataHub integration
The proof uses real DataHub entities: datasets, an ML model, a first-class ML model deployment, a DataHub data process instance, and a deployment DataJob. The round-trip evidence is checked against the local DataHub Quickstart before the UI is built.
Challenges and learnings
The hardest part was making the decision auditable instead of merely visual. We had to preserve the exact URNs and then verify the write-back property from DataHub after the mutation. That makes a failed release useful: the receipt names the missing evidence and can be re-run after repair.
OpenAI Build Week / Codex collaboration
LineageReceipt is the Developer Tools entry for OpenAI Build Week 2026. It was created and extended during the July 2026 submission period with Codex and GPT-5.6. Codex drove the implementation loop, browser/CDP verification, and regression checks; GPT-5.6 helped frame the release-evidence problem, shape deterministic rules, and challenge the boundary between REPAIR and approval. The core product, React/Vite UI, DataHub adapter, tests, evidence fixture, and deployment were built for this submission period.
The judge path is intentionally short: open the live demo, inspect four real DataHub URNs and the REPAIR / LR-DC2240 receipt, then run the test/build commands in the public Apache-2.0 repository. The synthetic fixture contains no personal or production data.
What's next
A production adapter would replace the synthetic fixture with environment-scoped credentials, map organization-specific freshness and rollback policies, and add an approval workflow without weakening the deterministic receipt.
Log in or sign up for Devpost to join the conversation.