Dataset Provenance Tracking Prompt

This prompt is for governance engineers, ML platform teams, and QA leads who need to create and maintain an audit trail for every example in a golden dataset. It generates a structured provenance record that captures the origin, modifications, approvals, and current status of a single golden example. Use this prompt when you are building a new golden dataset from scratch, onboarding examples from production logs, or retroactively documenting existing test cases. The output is designed to be stored alongside the example in a dataset registry or feature store, enabling downstream compliance checks, debugging when a test case behaves unexpectedly, and demonstrating chain of custody to auditors. This prompt assumes you already have the example content and the metadata about its origin. It does not generate the example itself.

The ideal workflow wires this prompt into a dataset ingestion pipeline. When a new example is proposed—whether from a human annotator, a production log, or a synthetic generator—the system calls this prompt with the raw example, source identifier, and any known modification history. The resulting provenance record is validated against a schema before being committed to the registry. This ensures that every example in the golden set has a machine-readable lineage that can be queried during audits or regression investigations. Do not use this prompt for real-time inference logging or for tracking model outputs in production; it is designed for the static, curated examples that define your evaluation baseline.

Avoid using this prompt when the example's origin is completely unknown and cannot be reasonably inferred. The prompt requires at least a source identifier and a creation timestamp to produce a useful record. If you feed it an example with no metadata, it will generate a low-confidence provenance stub that may fail downstream validation. Also, do not use this prompt as a substitute for a full data catalog or feature store; it produces a single record, not a searchable index. For teams operating under SOC 2, HIPAA, or FDA predicate rules, pair this prompt's output with a human approval step before the provenance record is finalized and the example is admitted to the golden set.

This prompt template generates a structured provenance record for a single golden dataset example. It captures the full lineage of an example—who created it, when, what modifications it has undergone, and its current approval status. Use this when onboarding new examples into your regression suite, when an example has been modified and needs an updated record, or when preparing audit evidence for compliance reviews. The output is designed to be machine-readable for ingestion into a metadata store while remaining human-auditable.

codeCopy
You are a dataset provenance recorder for a golden example registry. Generate a structured provenance record for the example described below. The record must be complete, traceable, and suitable for audit review.

## INPUT
Example ID: [EXAMPLE_ID]
Example Content:
  Input: [EXAMPLE_INPUT]
  Expected Output: [EXAMPLE_EXPECTED_OUTPUT]
  Metadata: [EXAMPLE_METADATA]

## TAXONOMY
Source Type: [SOURCE_TYPE]
Modification History: [MODIFICATION_HISTORY]
Current Approval Status: [APPROVAL_STATUS]
Annotator Identity: [ANNOTATOR_ID]
Reviewer Identity: [REVIEWER_ID]
Dataset Version: [DATASET_VERSION]

## OUTPUT SCHEMA
Produce a JSON object with these fields:
- example_id: string (the provided example ID)
- provenance_record:
  - source:
    - source_type: string (one of: human_annotated, synthetic, production_log, third_party, unknown)
    - origin_timestamp: ISO 8601 string (when the example was first created)
    - origin_annotator: string (who created it)
    - origin_method: string (how it was created, e.g., manual_labeling, template_generation, log_extraction)
  - modifications: array of objects, each with:
    - modification_id: string (unique identifier for this change)
    - timestamp: ISO 8601 string
    - modified_by: string (who made the change)
    - change_type: string (one of: content_update, schema_migration, deprecation, reactivation, correction, augmentation)
    - change_description: string (what changed and why)
    - previous_state_hash: string (hash of the record before this change, or null if first version)
  - approval:
    - current_status: string (one of: draft, in_review, approved, rejected, deprecated)
    - last_reviewed_by: string or null
    - last_reviewed_timestamp: ISO 8601 string or null
    - approval_notes: string or null
  - lineage:
    - parent_example_ids: array of strings (IDs of examples this was derived from, empty if original)
    - derived_example_ids: array of strings (IDs of examples derived from this one, empty if none)
    - dataset_version: string (the dataset version this example belongs to)
  - compliance:
    - contains_pii: boolean
    - pii_redaction_applied: boolean
    - sensitive_content_flags: array of strings (any sensitivity tags, empty if none)
    - retention_policy: string (e.g., permanent, review_quarterly, deprecate_on_schema_change)

## CONSTRAINTS
- All timestamps must be valid ISO 8601.
- If modification history is empty, the modifications array must still be present and empty.
- If no reviewer exists, set reviewer fields to null, not empty strings.
- Do not invent information. If a field's source data is not provided, mark it as null or use the unknown source_type.
- The output must be valid JSON with no trailing commas.

Adaptation notes: Replace each bracketed placeholder with your actual data. The [MODIFICATION_HISTORY] placeholder should contain a structured list of prior changes if available, or be marked as empty. The [SOURCE_TYPE] must match one of the enumerated values in the output schema. If your organization uses a different approval workflow, adjust the approval.current_status enum values accordingly. For teams using a metadata database, map the output JSON fields directly to your provenance table columns. The previous_state_hash field enables cryptographic chain-of-custody verification—use SHA-256 of the serialized prior record if full integrity tracking is required.

What to do next: After generating the provenance record, validate the JSON against your expected schema before storing it. Run a consistency check: the origin_timestamp should be the earliest timestamp in the record, and no modification timestamp should predate it. If the example was derived from other examples, verify that the parent_example_ids reference valid, existing example IDs in your registry. For high-compliance environments, require a human reviewer to sign off on the provenance record before it is committed to the golden dataset. Avoid generating provenance records in bulk without spot-checking a sample for hallucinated modification histories or invented reviewer identities.

This prompt is designed to be called programmatically whenever a new golden example is created, modified, or approved. The harness should treat it as a metadata generation step that runs after the example content is finalized but before the record is committed to the golden dataset repository. The prompt expects structured inputs about the example's origin, and it returns a provenance record that can be stored alongside the example in a database, a JSON file, or a metadata sidecar. Do not use this prompt for real-time user-facing flows; it belongs in internal tooling, admin panels, or CI/CD pipelines where dataset maintainers and governance engineers operate.

Integration pattern: Wrap the prompt in a function that accepts a GoldenExample object and a ProvenanceInput object. The function should: (1) validate that required fields (source, creation_date, annotator) are present and well-formed before calling the model; (2) call the prompt with the serialized inputs; (3) parse the JSON output and validate it against a provenance schema (fields: record_id, source, creation_date, annotator, modifications, approval_status, lineage_chain); (4) on parse failure, retry once with a repair prompt that includes the raw output and the schema; (5) log the full prompt, response, and validation result to an audit log; (6) attach the validated provenance record to the golden example before storage. For high-governance environments, add a human review gate before the provenance record is finalized—especially when approval_status is pending or when the lineage_chain shows more than three prior modifications.

Model choice and tool use: This prompt works well with structured-output modes (e.g., GPT-4o with response_format, Claude with tool-use for schema enforcement). If your model provider supports it, supply the provenance schema as a tool definition rather than relying on free-text JSON instructions. This reduces parse failures. RAG is not required for this prompt because all necessary context is provided in the input; however, if your organization maintains a taxonomy of approved sources or annotator IDs, you can inject that as a lookup before calling the prompt to validate inputs. Storage: Write provenance records to an append-only table with a timestamp and a hash of the golden example content. This creates an immutable audit trail that survives dataset migrations. Retries: If the model returns a provenance record that fails schema validation, retry once with the error message injected into the prompt. If the second attempt also fails, escalate to a human reviewer and log the failure for prompt debugging. Avoid: Do not call this prompt on every read of a golden example—only on create, update, or approval events. Do not use the provenance record as the sole source of truth for example content; always store the example and its provenance as linked but separate records.