Appearance
AI Provenance
Two years from now, somebody will ask how a particular mapping, control or observation came to exist. Provenance is what makes that answerable.
What is recorded
Every AI interaction produces a record containing:
| Element | Purpose |
|---|---|
| Action | The specific feature that made the call |
| Task family | The coarse grouping the interaction belongs to |
| Provider | Which AI provider was used |
| Model | Which model |
| Prompt | The exact prompt sent |
| Response | The raw response received |
| Subject | What the call was about — the requirement, control, incident or evidence item |
| Run | Which run or batch it belonged to |
| Confidence | Where the capability produces one |
| Tokens | Prompt and completion token counts |
| Latency | How long the call took |
| Status | Whether it succeeded, and any error |
| Tenant | Which tenant the interaction belongs to |
Stamped at write time, not back-filled
Provenance is part of the immutable record, not metadata added later
The subject and run context are stamped onto the interaction at the moment it is written.
Back-filling provenance afterwards would mean the lineage is a reconstruction, which is exactly what it is supposed to replace. A record whose provenance was added later cannot be relied on to say what it claims.
The mechanism is deliberate: the calling feature declares what it is working on, and the telemetry layer captures whatever is declared as the interaction is recorded. An undeclared context simply produces empty columns — it never produces a guess.
Task families
Interactions are grouped into normalised families, which is the level at which the record is actually useful:
| Family | Covers |
|---|---|
requirement_extraction, obligation_extraction | Regulatory extraction |
control_extraction | Control source ingestion |
mapping | Crosswalk proposal |
design_adequacy | Adequacy checks |
evidence_assessment | Evidence-related analysis |
compliance_determination | Compliance-related drafting |
assurance_rationale | Requirement assurance rationale |
risk_determination, finding_determination | Risk and finding analysis |
policy_analysis | Policy-related analysis |
exception_drafting | Exception justification drafting |
audit_assist | Audit assistance |
inspection_assist, inspection_extraction | Inspection drafting and extraction |
bcm_assist, bcm_scenario_generation | Resilience assistance |
incident_assist, incident_classification, root_cause_analysis | Incident assistance |
other | Anything outside the above |
The action field keeps the raw calling feature; the family is the grouping you would organise an analysis or a review around.
What provenance answers
| Question | Answered by |
|---|---|
| How did this mapping come to exist? | Mapping source ai_suggested, plus provider, model and prompt version on the record |
| Which model produced our extracted controls? | The control_extraction interactions for that document |
| A model version turned out to be poor — what did it produce? | Every interaction recording that model |
| Did a person review this AI output? | The record's approval history, alongside its provenance |
| How much AI usage does this tenant have? | Aggregate token and interaction counts |
| Did an AI call fail silently? | Status and error on the interaction |
Provenance on the artefacts themselves
Beyond the interaction log, the artefacts carry their own provenance fields.
| Artefact | Carries |
|---|---|
| Crosswalk mapping | Mapping source, AI provider, model, prompt version, AI confidence, rationale |
| Extracted requirement | Source document, source location, extracted text, confidence, provenance metadata |
| Extracted control | Source lineage, confidence band recorded on the candidate |
| Inspection candidate | Source document, location, extracted text, original wording, confidence |
| Indicator result | Engine provenance — deterministic, no model involved |
Note the last row
Indicator results carry provenance too, recording the engine and version that computed them. That provenance names no model, because no model was involved. Deterministic computation is provenanced for the same reason AI output is: so it can be reproduced.
Confidence, and what it is worth
Where a capability produces a confidence value, it is recorded. It is worth being precise about what it means.
Confidence expresses how strongly the model matched a pattern. It is not a probability that the output is correct, and it is not evidence.
| Use confidence for | Do not use it for |
|---|---|
| Triaging a review queue | Deciding what needs no review |
| Routing low-confidence items for closer checking | Batch approval above a threshold |
| Identifying where source text was unclear | Justifying an approval decision |
Approving everything above a confidence score reproduces exactly the problem maker-checker exists to prevent.
Tenant isolation
AI interactions are tenant-scoped. Provenance records, prompts and responses belong to the tenant that generated them and are never visible across tenants.
Tenant data is not used to train models. Where a tenant explicitly consents, its interactions may form part of a consented dataset — that is a deliberate, opt-in arrangement, not a default.
See Tenant Data Boundaries and AI Provider Security.
Permissions
| Action | Permission |
|---|---|
| View AI-produced records and their provenance fields | Read access to the record |
| Read the audit trail | audit.read |
| View tenant AI configuration | settings.read |
Platform-level AI activity monitoring is a platform administration capability and is not part of the tenant workspace.
Example
Mapping MAP-2026-0233 — control CTL-2026-0041 mapped to obligation A.8.5 as equivalent.
| Element | Value |
|---|---|
| Mapping source | ai_suggested |
| AI provider and model | Recorded on the mapping |
| Prompt version | Recorded |
| AI confidence | High |
| AI rationale | "Control requires MFA for remote and administrative access to systems classified critical, matching the obligation's scope and mechanism" |
| Proposed | By the Compliance Analyst who ran the pass |
| Approved | By the Compliance Manager, three days later |
| Approval note | "Confirmed against the control text. Scope of 'critical' in the control matches the obligation's definition." |
Eighteen months later, an auditor asks how the bank concluded this control satisfies this obligation.
The answer is a record: an AI pass proposed it with a stated rationale, using a named model at a named prompt version; a named analyst ran the pass; a different named manager verified the rationale against the control text and approved it on a specific date, with their own note.
Nobody has to remember anything.