docs: retire strict_provenance and drop provenance terminology

Match datajoint-python's removal of the strict_provenance runtime
guardrail, and align the docs with the decision to keep provenance
terminology out of DataJoint's own documentation. DataJoint implements
the relational workflow model — data integrity, consistency, lineage,
and reproducibility; provenance is a platform-level compatibility concern
documented separately.

- Rename reference/specs/provenance.md -> trace.md; rewrite it as the
  spec for the upstream read surface (Diagram.trace + self.upstream),
  removing the strict_provenance section entirely and reframing the
  "read/write boundary" in lineage/reproducibility terms.
- about/whats-new-23.md: reframe the "provenance trinity" as the
  trace + self.upstream pair; drop the strict_provenance subsection and
  adoption step; retarget links to trace.md and the make() contract.
- mkdocs.yaml: nav "Provenance Trace & Strict Provenance" -> "Upstream Trace".
- Sweep "provenance" from the conceptual and tutorial pages (index,
  about/index, relational-workflow-model, normalization,
  comparison-to-workflow-languages, schema-as-workflow-specification,
  data-pipelines, faq, and three tutorial notebooks), replacing it with
  "lineage"/"reproducibility"/"traceability" as fits each context.

Author: dimitri-yatsenko

mkdocs.yaml

@@ -123,7 +123,7 @@ nav:
               - Staged Insert: reference/specs/staged-insert.md
               - Cascade: reference/specs/cascade.md
               - AutoPopulate: reference/specs/autopopulate.md
-              - Provenance Trace & Strict Provenance: reference/specs/provenance.md
+              - Upstream Trace: reference/specs/trace.md
               - Job Metadata: reference/specs/job-metadata.md
               - Object Store Configuration: reference/specs/object-store-configuration.md
           - Deployment:

src/about/index.md

@@ -18,7 +18,7 @@ Key characteristics:
 - **Automatic dependency tracking** — Foreign keys encode workflow dependencies
 - **Built-in computation** — Imported and Computed tables run automatically
 - **Data integrity** — Referential integrity and transaction support
-- **Reproducibility** — Immutable data with full provenance
+- **Reproducibility** — Immutable data with full lineage
 
 ## History
 

src/about/whats-new-23.md

@@ -1,22 +1,19 @@
 # What's New in DataJoint 2.3
 
-DataJoint 2.3 introduces the **provenance trinity** — `Diagram.trace`, `self.upstream`, and `strict_provenance` — which together turn "a computed row can be traced to the exact upstream rows it came from" from a convention into something the framework helps construct and check. It also ships the **SparkAdapter Codec Protocol** for typed rendering to Spark-native types, **`dj.deploy.set_replica_identity`** for PostgreSQL change-data-capture, and a **cascade fix** for Part-of-Part and renamed-foreign-key chains.
+DataJoint 2.3 adds a first-class **upstream read surface** — `Diagram.trace` and `self.upstream` — which make "a computed row derives only from its declared upstream inputs" easy to follow inside `make()` and easy to query afterward. It also ships the **SparkAdapter Codec Protocol** for typed rendering to Spark-native types, **`dj.deploy.set_replica_identity`** for PostgreSQL change-data-capture, and a **cascade fix** for Part-of-Part and renamed-foreign-key chains.
 
-> **Upgrading from 2.0, 2.1, or 2.2?** No breaking changes. Everything here is additive, and `strict_provenance` defaults to off — existing pipelines run identically.
+> **Upgrading from 2.0, 2.1, or 2.2?** No breaking changes. Everything here is additive — existing pipelines run identically.
 
 > **Citation:** Yatsenko D, Nguyen TT. *DataJoint 2.0: A Computational Substrate for Agentic Scientific Workflows.* arXiv:2602.16585. 2026. [doi:10.48550/arXiv.2602.16585](https://doi.org/10.48550/arXiv.2602.16585)
 
 ## Overview
 
-DataJoint's provenance guarantee rests on the convention that `make(self, key)` reads only from declared upstream dependencies and writes only to `self` (and its Parts). The framework has always *defined* this boundary but never *checked* it: a `make()` could `fetch()` from any table, making the dependency invisible to the foreign-key graph and silently breaking the provenance claim downstream.
-
-The 2.3 trinity closes that loop with three pieces designed as a unit:
+A computed row is reproducible only when `make(self, key)` reads only from its declared upstream dependencies and writes only to `self` (and its Parts). DataJoint 2.3 makes that read/write boundary easy to follow — and the resulting data lineage easy to query — with two features designed as a unit:
 
 1. **`Diagram.trace()`** constructs the upstream view as a first-class query object.
 2. **`self.upstream`** exposes that view ergonomically inside `make()`.
-3. **`strict_provenance`** checks (best-effort) that nothing else is read or written.
 
-## The Provenance Trinity
+## Upstream Trace and `self.upstream`
 
 ### `Diagram.trace()` — the upstream mirror of `cascade`
 
@@ -48,31 +45,13 @@ class Spectrum(dj.Computed):
         self.insert1({**key, "spectrum": compute_spectrum(samples, rate)})
 ```
 
-Construction is lazy — the SQL fires only when you access an ancestor and fetch. Outside `make()`, accessing `self.upstream` raises a clear error. Even without `strict_provenance`, it's a pure ergonomic win over `(Recording & key).fetch1(...)`.
-
-### `strict_provenance` — an opt-in runtime guardrail
-
-Setting the flag makes the provenance boundary checked at runtime:
-
-```python
-dj.config["strict_provenance"] = True
-```
-
-When enabled, inside a `make()`:
-
-- **Reads** of tables outside the declared-ancestor set (plus `self` and its Parts) raise `DataJointError`.
-- **Writes** to anything other than `self` and its Parts raise `DataJointError`.
-- **Key consistency** is checked: rows inserted into `self`/Parts must carry primary-key values consistent with the current `key`.
-
-`strict_provenance` is an **operational** flag — a property of how a deployment runs, not of the schema. It's a **best-effort development guardrail**, not an airtight boundary: it observes access through the DataJoint Python client and is designed to surface *accidental* undeclared dependencies (turn it on in staging, fix what it flags). Comprehensive enforcement across every access path is handled on the DataJoint platform, which combines these runtime checks with agentic review of `make()` source in its code-deployment CI/CD. See the [Provenance Specification](../reference/specs/provenance.md) for the exact enforcement model and its documented limits.
+Construction is lazy — the SQL fires only when you access an ancestor and fetch. Outside `make()`, accessing `self.upstream` raises a clear error. It's a pure ergonomic win over `(Recording & key).fetch1(...)`, and it keeps the read inside the declared upstream — which is what makes the result reproducible. See the [make() reproducibility contract](../reference/specs/autopopulate.md#43-the-make-reproducibility-contract) for the full rule set.
 
-### Adopting the trinity incrementally
+### Adopting `self.upstream` incrementally
 
-1. Upgrade to 2.3 — the APIs are available; `strict_provenance` stays off.
+1. Upgrade to 2.3 — the new APIs are available; existing code is unaffected.
 2. Use `self.upstream` in new `make()` implementations.
-3. Migrate existing `make()` reads from `(Upstream & key).fetch(...)` to `self.upstream[Upstream].fetch(...)`.
-4. Enable `strict_provenance=True` in staging and fix the undeclared dependencies it surfaces.
-5. Enable in production.
+3. Migrate existing `make()` reads from `(Upstream & key).fetch(...)` to `self.upstream[Upstream].fetch(...)` — no semantic change, but the read is now visibly confined to the declared upstream.
 
 ## SparkAdapter Codec Protocol
 
@@ -113,7 +92,7 @@ It is PostgreSQL-only (raising a clear error on other backends), idempotent at t
 
 ## See Also
 
-- [Provenance Specification](../reference/specs/provenance.md) — `trace`, `self.upstream`, and `strict_provenance` in full
+- [Upstream Trace Specification](../reference/specs/trace.md) — `Diagram.trace` and `self.upstream` in full
 - [SparkAdapter Codec Protocol](../reference/specs/spark-adapter.md) — typed rendering to Spark-native types
 - [Deployment Operations](../reference/specs/deploy-operations.md) — the `dj.deploy` module
 - [Cascade Specification](../reference/specs/cascade.md) — propagation rules shared with `trace`

src/explanation/comparison-to-workflow-languages.md

@@ -35,7 +35,7 @@ rather than competing with it.
 | Foreign-key integrity | — | — | Enforced |
 | Computation specification | Workflow file (CWL/SMK/NF) | Task functions in code | `make()` declared in schema |
 | Execution order | Step DAG in workflow file | Task DAG in code | Foreign-key DAG in schema |
-| Provenance recording | Reconstructed from run logs | Task-level run history | Structural (FK chain) |
+| Lineage recording | Reconstructed from run logs | Task-level run history | Structural (FK chain) |
 | Drift detection | Out of scope | Out of scope | Cascade on upstream change |
 | Query interface | Filesystem + ad hoc | Task metadata UI | Five-operator algebra |
 | Retry / idempotence | Step-level rerun | Task-level retry | Per-entity, key-driven |
@@ -59,7 +59,7 @@ top priorities.
 What these systems share is what they decline to specify: a formal
 data-structure layer. There are no typed schemas across pipeline stages,
 no foreign keys binding intermediate results, no algebraic query surface
-over what the pipeline has produced. Provenance is reconstructed from run
+over what the pipeline has produced. Lineage is reconstructed from run
 logs and filenames rather than enforced by structure. Entity-level lineage
 — which subject or sample or session produced a result — is implicit in
 directory conventions and scatter patterns rather than declared. Drift in
@@ -112,7 +112,7 @@ structure.
   the team is prepared to write its own catalog or lineage layer
   separately.
 - **Choose DataJoint** when the data and the computation cannot cleanly
-  separate, when provenance, lineage, and integrity must be structural
+  separate, when lineage and integrity must be structural
   rather than reconstructed, and when agents need a single machine-readable
   model of the pipeline.
 - **Use both.** DataJoint inside an Airflow, Argo, or Prefect orchestration

src/explanation/data-pipelines.md

@@ -6,7 +6,7 @@ A **scientific data pipeline** extends beyond a database with computations. It i
 - Integrates diverse tools for data entry, visualization, and analysis
 - Provides infrastructure for secure, scalable computation
 - Enables collaboration across teams and institutions
-- Supports reproducibility and provenance tracking throughout
+- Supports reproducibility and data lineage throughout
 
 ## Pipeline Architecture
 
@@ -46,7 +46,7 @@ This dual structure ensures that both code dependencies and data dependencies fl
 This constraint is fundamental to DataJoint's design. It ensures:
 
 - **Unidirectional data flow** — Data enters at the top and flows downstream
-- **Clear provenance** — Every result traces back to its inputs
+- **Clear lineage** — Every result traces back to its inputs
 - **Safe deletion** — Cascading deletes follow the DAG without cycles
 - **Predictable computation** — `populate()` can determine correct execution order
 
@@ -148,7 +148,7 @@ Throughout this process, the schema definition remains the single source of trut
 
 ## Comparing Approaches
 
-The pipeline approach requires upfront investment in schema design. Compared to a file-based approach where data structure is implicit in filenames, dependencies are encoded in scripts, and provenance must be tracked manually, a DataJoint pipeline makes all of those explicit in the schema — and pays the investment back in reproducibility, query power, and collaboration as projects scale.
+The pipeline approach requires upfront investment in schema design. Compared to a file-based approach where data structure is implicit in filenames, dependencies are encoded in scripts, and lineage must be tracked manually, a DataJoint pipeline makes all of those explicit in the schema — and pays the investment back in reproducibility, query power, and collaboration as projects scale.
 
 For a detailed structural comparison against file-based workflow systems (CWL, Snakemake, Nextflow) and task orchestrators (Airflow, Argo, Prefect, Dagster), and for guidance on when the two layers complement rather than substitute each other, see [Comparison to Workflow Languages](comparison-to-workflow-languages.md).
 
@@ -160,7 +160,7 @@ Scientific data pipelines extend the Relational Workflow Model into complete dat
 - **DAG Structure** — Unidirectional flow of data and dependencies
 - **Object-Augmented Schemas** — Scalable storage with relational semantics
 
-The schema remains central—defining data structures, dependencies, and computational flow. This pipeline-centric approach lets teams focus on their science while the system handles data integrity, provenance, and reproducibility automatically.
+The schema remains central—defining data structures, dependencies, and computational flow. This pipeline-centric approach lets teams focus on their science while the system handles data integrity, lineage, and reproducibility automatically.
 
 ## See Also
 

src/explanation/faq.md

@@ -149,7 +149,7 @@ A **lakehouse** merges data lake flexibility with data warehouse structure, opti
 - Data integrity and reproducibility
 - Traceability within structured scientific datasets
 
-DataJoint can complement lakehouse architectures—using object storage for large files while maintaining relational structure for metadata and provenance.
+DataJoint can complement lakehouse architectures—using object storage for large files while maintaining relational structure for metadata and lineage.
 
 ## Does DataJoint Require SQL Knowledge?
 

src/explanation/normalization.md

@@ -239,7 +239,7 @@ class HousingAssignment(dj.Manual):
 3. **Join efficiency** — Normalized tables with proper keys enable efficient
    joins through the workflow graph
 
-4. **Clear provenance** — Each table represents a distinct workflow step,
+4. **Clear lineage** — Each table represents a distinct workflow step,
    making data lineage clear
 
 ## Summary

src/explanation/relational-workflow-model.md

@@ -66,7 +66,7 @@ above illustrates.
 | **Row semantics** | True proposition | Entity instance | **Workflow artifact** |
 | **Foreign keys** | Referential integrity | Relationship | **Execution order** |
 | **Computation** | Not addressed | Not addressed | **Declared in schema** |
-| **Provenance** | Not addressed | Not addressed | **Structural** |
+| **Data lineage** | Not addressed | Not addressed | **Structural** |
 | **Implementation gap** | High | High | **None** |
 
 ## A semantic interpretation, not a departure
@@ -77,7 +77,7 @@ primary and foreign keys, normalization, and the query algebra keep
 their classical meaning. The model adds four readings on top:
 
 - Tables also represent **workflow steps**.
-- Rows also represent **workflow artifacts**, carrying provenance to their inputs.
+- Rows also represent **workflow artifacts**, traceable to their inputs.
 - Foreign keys also prescribe **execution order** — the dependency graph *is* the pipeline DAG, enforced by the database.
 - **Computed and Imported tables carry their own `make()` methods**, declaring derivation logic in the schema itself rather than in an external workflow file.
 
@@ -98,8 +98,8 @@ alongside DataJoint.
 
 ## Substrate consequences
 
-Because dependencies are declared before any computation runs, provenance
-and lineage become **properties of the substrate**, not artifacts assembled
+Because dependencies are declared before any computation runs, lineage
+and reproducibility become **properties of the substrate**, not artifacts assembled
 after the fact. Every row in `Segmentation` is reachable by foreign key
 from the exact `AverageFrame` and `SegmentationParam` that produced it;
 cascade deletes remove dependent results when their inputs become invalid.
@@ -165,7 +165,7 @@ at the workflow step the table represents*. A `Session` table holds
 attributes known when the session is entered (date, experimenter,
 subject); analysis parameters determined later belong in Computed tables
 that depend on `Session`. The discipline prevents tables that accumulate
-attributes from different workflow stages, obscuring provenance and
+attributes from different workflow stages, obscuring lineage and
 complicating updates.
 
 ### Entity integrity
@@ -209,7 +209,7 @@ incompatible designs.
 | Foreign keys enforce consistency | Foreign keys prescribe execution order |
 | Updates modify state | Computations create new states |
 | Schemas organize storage | Schemas specify pipelines |
-| Queries retrieve data | Queries trace provenance |
+| Queries retrieve data | Queries trace lineage |
 
 ## Further reading
 

src/explanation/schema-as-workflow-specification.md

@@ -112,8 +112,8 @@ The `make()` method is the typed function the schema declares from
 upstream key to artifact: it receives the primary key of one entity,
 fetches its inputs by query, produces the result, and inserts exactly
 one row. Each inserted row records the git hash of the `make()` source
-that produced it — code provenance is part of the schema's structural
-footprint, not an audit artifact bolted on afterward. The
+that produced it — the identity of the code that produced each row is part of
+the schema's structural footprint, not an audit artifact bolted on afterward. The
 [Computation Model](computation-model.md) page covers the full `make()`
 / `populate()` contract, including the three-part pattern for long
 computations.
@@ -128,7 +128,7 @@ with a well-defined primary key, so any expression is itself a valid
 operand for the next operator. Entity integrity is preserved under
 composition. This is what lets the schema be both a specification and a
 queryable object — the same algebra that retrieves data also traces
-provenance and derives the key source for the next `populate()`. See
+lineage and derives the key source for the next `populate()`. See
 [Query Algebra](query-algebra.md) and
 [Semantic Matching](semantic-matching.md) for operator semantics and
 the lineage-based join rule that prevents accidental matches on

src/index.md

@@ -7,7 +7,7 @@
 
 ## About DataJoint
 
-**DataJoint** implements the [Relational Workflow Model](explanation/relational-workflow-model.md)—a data model where your database schema defines an executable data pipeline. Tables represent workflow steps, foreign keys encode dependencies, and the system handles job management, parallel execution, and provenance tracking. [Object storage](explanation/data-pipelines.md#object-augmented-schemas) integration enables seamless handling of large scientific data.
+**DataJoint** implements the [Relational Workflow Model](explanation/relational-workflow-model.md)—a data model where your database schema defines an executable data pipeline. Tables represent workflow steps, foreign keys encode dependencies, and the system handles job management, parallel execution, and data lineage. [Object storage](explanation/data-pipelines.md#object-augmented-schemas) integration enables seamless handling of large scientific data.
 
 ![pipeline](images/pipeline.svg){: style="width:100%;max-width:1100px;"}