Provenance record (entity, activity, agent — PROV-DM core)
Generated from
pattern-library/registry.json— do not edit by hand; change the registry and runbun run patterns:build.
Category: Derivation & Provenance · Tier: deep · Maturity: proven (verified 2026-10-10 @ 91f61a76-dirty) · Risk: low — mostly columns you already have; the failure mode is pointing provenance at mutable ids
Where a value came from is recorded with the W3C PROV-DM core only: the entity pinned to a revision or content hash, the activity with its transform version, and the agent (human, software or AI, on whose behalf) — with an explicit erasure decision per trail.
When to use: Use when a reader must tell who or what produced a value — AI-drafted vs human-edited fields, published revisions, derived corpora, privileged actions, built binaries.
Requires: postgres
Avoid when
- The data has one author and no derivation — a user's own settings row is its own provenance
- Provenance must be exchanged with outside parties — adopt PROV-O or OpenLineage there instead of this application-level subset
Alternatives
- OpenLineage run/job/dataset events — prefer when a lineage backend consumes pipeline-level events across many jobs
Docs
- docs/blueprint/integrity/derivation.md#provenance-record — The PROV mapping and the seven v10r instances (GitHub · GitLab)
Code
src/lib/server/db/schema/blog/revision.ts— Immutable revisions; author set null on erasure (GitHub · GitLab)src/lib/schemas/image-metadata.ts— fieldProvenance: empty / ai-draft / human per field (GitHub · GitLab)src/lib/server/db/schema/desk/revision.ts— Pre-images with source ai | user; cascade on erasure (GitHub · GitLab)src/lib/types/turn-trace.ts— What a turn had, used and cited (GitHub · GitLab)src/lib/server/db/schema/admin/audit-log.ts— Insert-only; no FK on actor so the trail survives the account (GitHub · GitLab)
Tests
src/lib/schemas/image-metadata.test.ts(GitHub · GitLab)src/lib/server/ai/trace/recorder.test.ts(GitHub · GitLab)src/lib/server/admin/audit-csv.pglite.test.ts(GitHub · GitLab)
Invariants
- Provenance points at a revision or content hash, never only at a mutable id.
- AI and human authorship are distinguished at the field or row where they differ.
- Each trail states its erasure decision in the schema — cascade, set null, or retained without a foreign key.
- Provenance is append-only; a correction is a new record.
Emulation notes
- Start with the three PROV relations (generated by, derived from, attributed to) as columns on the rows you already have; a separate provenance graph store is rarely worth it in an application.
- Make the erasure decision per trail and write it into the foreign key: an audit trail and a draft history have different legal bases, and one blanket rule is wrong for one of them.
Depends on
Machine-readable record: provenance-record in pattern-library/registry.json.