Guided defense lab

Data Provenance

A guided exercise on judging provenance evidence and lineage quality: authoritative metadata versus payload claims, delivering component versus author, derived-artifact lineage, mixed-source contributors and unknown origin recorded as unknown.

Conceptual simulationAdvanced15 minutes2026-09-27

Conceptual simulation

This exercise uses authored, deterministic examples with fictional names and neutral synthetic content. It calls no tools, APIs, agents or models, and it does not predict how any real model or system behaves.

Step 3 of 63/6

Learning objectives

Separate authoritative provenance metadata from source or trust claims inside payload text.
Record the delivering connector or tool separately from the actual author or contributor of a field.
Preserve source, resource, version and transformation lineage for derived artifacts, backward and forward.
Keep the full contributor set for mixed-source derivations instead of inheriting the most trusted input's label.
Record missing origin as unknown and leave its downstream handling to consuming policies.
Distinguish provenance evidence from trust, truth, authorization, information flow decisions and instruction authority.
Explain why model output can describe or cite a source but never becomes the authoritative provenance record.
Recognize that hashes and signatures support integrity or origin under their trust model, not semantic safety.

Prerequisites

Data Provenance defense article (recommended)
Trust Boundaries and Model Context lab (recommended)

Choose a scenario

Each fictional scenario shows payload content and, separately, what the application recorded about sources, contributors and transformations. You judge whether a candidate provenance record is valid evidence - not whether the content is trusted and not whether anything may execute.

Payload claim promoted to metadataA synthetic document uploaded to a fictional knowledge base contains the human-readable line "source: trusted-policy-library". The ingestion step copies that line into the provenance envelope, although the upload was made by an external contributor.Tool delivery versus field authorshipA trusted support connector returns fictional ticket T-204. The record names the connector as delivering component and records that the requester_comment field was written by external customer customer-417.Complete derived lineageFictional PDF P-3 version 3 is parsed by parser 2.4. Chunk 7 is combined with chunks 5 to 8 into summary S-19, which is cached and later retrieved into a run.Collapsed mixed-source summarySummary S-44 is built from internal policy document POL-9 and an externally supplied customer note N-31. The derived record lists only POL-9 as source and copies its internal classification.Unknown origin recorded as unknownLegacy note L-77 was imported by import job imp-2019. No reliable original author or source exists beyond the job and record ID. The note text mentions a department, but nothing authoritative confirms it.

Provenance path

Content enters through a connector or import job, may be transformed into derived artifacts, and is described by an authoritative provenance record. Consuming policies such as information flow control and authorization are separate.

Source or contributorVariable content->
Connector / import jobSystem component->
Payload contentVariable content->
Transformation componentsSystem component->
Authoritative provenance recordSystem component->
Consuming policies (IFC, authorization - separate)System component

Payload content and model output

What the content says or what a model writes about it. It is not provenance evidence.

Document header text
source: trusted-policy-library
Document body
Neutral synthetic guidance about office opening hours.

Application-recorded provenance evidence

Connector, storage, resource and version, contributors, import, capture and transformation records, kept on a separate plane from the payload.

Connector and storage: upload-connector-2 into kb-store-east, bucket external-submissions
Resource: doc D-512, version 1
Uploader / contributor: external contributor ext-contrib-88
Capture record: cap-512, captured 2026-09-20 by upload-connector-2