A client asks a Canadian firm why a figure in a deliverable says what it says. The firm has the deliverable, the source documents, a model that produced a draft, and an approval record. It has, in other words, everything required to answer, distributed across four systems that share no common identifier, and reconstructing the chain takes two days of someone's time.
Key Takeaway
A production AI system constantly creates a record of itself, as source tables, model versions, prompts, responses, access events and approvals accumulate around every workflow, and whether they can still be read together when an audit or incident begins depends on traceability. Lineage captures three things: provenance, meaning where data originated; transformations, meaning what changed along the way; and ownership, meaning who made each decision. The frameworks cited most often are foreign to Canada: the EU AI Act's Article 10 sets data-governance requirements for high-risk systems, and Articles 12 and 13 concern decision traceability, while the NIST AI Risk Management Framework Playbook calls for documenting sources, origins, transformations, dependencies, constraints and metadata. No Canadian equivalent is in force. But the professional obligation already exists independently: financial reporting accuracy depends on being able to trace reported figures to source systems with an auditable chain, and an AI-produced figure entering a financial statement inherits that requirement without any new regulation being needed.
The Real Problem
One source states the situation more precisely than the rest of the literature, and the whole article follows from it.
It observes that a production AI system is constantly creating a record of itself, with source tables, model versions, prompts, responses, access events and approvals accumulating around every workflow, and that whether they can still be read together when an audit or incident begins depends on traceability. It adds that AI systems constantly generate a trail of data, decisions and interactions, but that without traceability the evidence quickly fragments[1].
The word that matters is fragments. The failure being described is not absence of records; it is dispersal of records that individually exist.
This distinguishes the present article from the incident forensics discussion earlier in this series, which concerned artefacts that are genuinely transient and cannot be captured after the fact. Here the artefacts are usually persisted somewhere. The document management system holds the source. The model platform holds the request and response. The accounting system holds the posting. The workflow tool holds the approval. Each is retained, often for years.
What is missing is the capacity to assemble them into a single account of how one output came to say what it says. That is a different problem with a different and cheaper remedy, and the remedy is the subject of the section on join keys below.
Provenance, Transformation, Ownership
The anatomy of lineage, which is more than a record of where data came from.
One source defines the end-to-end record as capturing provenance, meaning where data originated; transformations, meaning what changed along the way; and ownership, meaning who made each decision[2].
The third component is the one a professional services firm should attend to most, and it is routinely omitted from technical implementations, which concentrate on the first two.
In a Canadian finance or advisory context, ownership is attribution. Who selected the source document. Who set the parameter. Who chose among the options the system presented. Who approved. A lineage record that shows a figure flowed from a source through a transformation, without recording whose judgment shaped it, answers a technical question and not a professional one.
That matters because the questions actually asked after the fact are rarely purely technical. A client asks who decided. A regulator asks on whose authority. An insurer asks who exercised judgment. None of those is answered by a data flow diagram.
Our recommendation is that any lineage design for professional work treats ownership as a first-class field rather than as metadata, and that the field records a person rather than a system account, for the reasons the segregation of duties article in this series set out.
The Records A System Creates
The inventory, which is useful as a checklist.
One source lists the records that a traceable system depends on being able to connect: data lineage, model lineage, prompt and response logs, access history, documentation, bills of materials and incident records, noting that each captures a different part of the lifecycle. It describes data lineage specifically as tracing a feature, column or document back to its upstream source including the transformations that changed it, giving the example of tracing an income-derived feature in a credit-risk model back to a source table, a transformation job, a quality check and a training data snapshot[1].
It defines the overall capability as the ability to connect the data, model versions, prompts, outputs, access events, approvals and incident records behind a system so teams can reconstruct how it was built, changed and used[1].
Two observations for a mid-sized Canadian firm reading a list of that length.
Most of these already exist without anyone having created a lineage programme. Access history is in the identity system, approvals are in whatever tool routes them, and prompts and responses are in the model platform if logging is enabled, which the incident article argued it should be.
And the item most firms genuinely lack is documentation of the system itself: what it does, what it was configured to do, and what changed when. That is the record that turns a collection of logs into an explanation, and it is the one nobody is assigned to maintain.
The Join Key Nobody Designs
The central practical argument of this article, offered as our own analysis.
If the records exist and the problem is that they fragment, then the question is what would allow them to be read together. The answer is a shared identifier, and the reason firms cannot assemble their evidence is that each system generates its own.
Follow a single item of work through a typical Canadian professional workflow. The document arrives and receives a document identifier. It is processed and the extraction platform assigns a job identifier. A model request is made and the platform assigns a request identifier. An entry is posted and the accounting system assigns a transaction identifier. An approval is recorded and the workflow tool assigns its own reference.
Five identifiers, five systems, no relationship between them recorded anywhere. Each system can answer questions about its own domain completely, and no system can answer a question that crosses two.
The remedy is a correlation identifier: a single value generated once at intake and carried into every subsequent record as an additional field. It does not replace the local identifiers, and it does not require any system to change how it works internally. It requires only that each system be willing to store one extra value and that whatever writes to it passes the value along.
Two properties make this worth doing early. It is inexpensive at design time and effectively impossible retroactively, which is the same structural point the incident article made about logging: the decision that determines whether a question can be answered is taken before anyone asks it. And it converts a two-day reconstruction into a query.
We would treat the presence or absence of a correlation identifier as the single most informative question about a firm's AI traceability posture, ahead of any question about tooling.
Two Directions Of Traceability
A distinction the material does not draw explicitly and which determines what a lineage design must support. This section is our own analysis.
Traceability is usually discussed in one direction: given an output, what produced it. That is the question asked when a client queries a figure or an auditor selects a sample, and it is the question a lineage diagram naturally answers.
The other direction is the one that matters when something is wrong: given that this source, this configuration or this document version was defective, which outputs are affected.
The two are not symmetric in difficulty. The backward question can be answered by following pointers from a single output. The forward question requires an index over every output produced, keyed by the inputs each consumed, which is a materially different data structure.
The incident article in this series identified the scoping question, meaning which outputs were affected, as the one most organisations cannot answer and which determines whether a remediation is targeted or covers everything produced in a period. The forward direction is precisely that capability.
The practical consequence is that a firm should test its lineage against the forward question rather than the backward one. Pick a source document at random, and ask which deliverables consumed it. If the answer requires opening deliverables one at a time, the forward capability does not exist, however good the backward trace looks.
Training Lineage Is Not Your Problem
An important scoping point, because most of the available literature addresses a question a Canadian firm does not face.
The dominant framing in this material concerns training data. One source describes lineage for large language models as the end-to-end record of how data flows from original sources through collection, filtering, deduplication, preprocessing and augmentation before entering training, used to debug model behaviour, satisfy regulatory audits, detect bias propagation and reproduce training runs[2]. The framework requirements cited concern training, validation and testing datasets[3].
All of that is directed at organisations that build models. Almost no Canadian accounting, advisory or mid-market finance function does.
The lineage question that a firm consuming a model actually faces is different: which documents were supplied to the model for this particular output, and what did it produce from them. That is retrieval lineage, and it is the artefact the incident article identified as decisive for grounded workflows, because an output can be perfectly faithful to the wrong document and the failure is invisible unless the retrieval is recorded.
We consider this a genuine gap in the practitioner literature. The lineage discussion is written by and for the model-building end of the market, and the far larger population of model consumers inherits a framework aimed at someone else's problem.
The translation for a Canadian firm is to read every reference to training data lineage as, for their purposes, retrieval lineage, and to record for each output which sources were retrieved, in what version, and at what time.
Classical Lineage Assumes Columns
A tooling mismatch that explains why off-the-shelf products often disappoint in professional services.
The established form of lineage is column-level. One vendor describes mapping from source tables through transformation jobs to dashboards and feature pipelines in a unified view[4], and another notes that off-the-shelf tools cover standard connectors while custom engineering is needed for proprietary pipelines that no catalogue natively traces[5].
Column-level lineage was built for a world of tabular data moving through defined transformations, where a field in a report can be traced to a field in a source table through a sequence of joins and calculations. In that world every step is expressible as a relationship between named columns.
A finance AI workflow is not shaped like that. A scanned agreement is not a table. An extraction produces fields from a region of a document. A generated paragraph draws on several retrieved passages. A professional judgment selects among candidate treatments. None of those steps is a column-to-column mapping, and a tool that models the world as columns cannot represent them.
The consequence for a Canadian firm evaluating lineage tooling is to establish what unit the tool traces before assessing its features. If the unit is a column and the workflow is a document, the tool will trace the parts of the process that were never the problem.
Our own view is that the workable unit for professional work is the assertion: a statement in a deliverable, traced to the sources that support it and the person who accepted it. That is closer to how an auditor thinks about evidence than to how a data catalogue thinks about tables.
The Unstructured Requirement
Confirmation that the field recognises the gap, reported from a secondary source.
One source reports that the 2026 Gartner Magic Quadrant for data and analytics governance explicitly requires platforms to trace lineage across structured data, unstructured data, machine learning models and AI-generated outputs, and that spending on AI governance platforms is projected to reach 492 million dollars in 2026[5].
We report both figures at second hand and have not accessed the underlying analyst material.
The significant part is the inclusion of unstructured data and AI-generated outputs as things a governance platform must trace. That is an acknowledgement that column-level lineage is insufficient, and it indicates the tooling category is moving toward the problem rather than having solved it.
The same source frames the practical question well: not whether to implement lineage, but how deep it needs to go, and where off-the-shelf tools can cover the standard flows versus where custom engineering is needed[5].
For a mid-sized Canadian firm the honest answer is usually that no affordable tool traces its actual workflow end to end, and that the correlation identifier described above delivers most of the practical benefit at a small fraction of the cost of a governance platform.
The Canadian Position
Where a Canadian reader actually stands, since the material is written for other jurisdictions.
The regimes cited across these sources are the EU AI Act, DORA, GDPR, CCPA, PDPA, BCBS 239, SOX and Basel III and IV, together with regulators in Australia, Malaysia, Indonesia and the Philippines requiring provenance documentation as part of model risk and data governance frameworks[4].
None of those is Canadian. Canada has no equivalent AI statute in force, and this publication has examined the Canadian model risk position separately, which applies to federally regulated financial institutions rather than to businesses generally.
A Canadian firm reading that list should not conclude the requirement does not apply to it, for two reasons developed in the section below on the existing obligation.
It should equally not conclude that it must implement a European compliance programme. The specific documentary artefacts those regimes require are addressed to their own supervisory processes, and building to them without a legal reason is expensive and produces evidence nobody in Canada will ask for.
The proportionate position is to build the traceability that answers the questions Canadian clients, auditors and courts actually ask, which is a narrower set, and to note that a firm serving European clients or operating in those markets may acquire the fuller obligation through its customers rather than through Canadian law.
A Timing Conflict Worth Noting
A disagreement across sources that is itself instructive.
One source states that the EU AI Act requires documented provenance for high-risk systems with enforcement beginning August 2026[2]. Another describes the Act as effective August 2024[4]. A third cautions explicitly that official EU sources should be used carefully, noting that one official timeline lists 2 August 2026 for the majority of the rules and for high-risk rules under one annex, while the Commission's own page notes a political agreement dated 7 May 2026[3].
Penalty figures also differ, with one source citing a range and another citing a maximum expressed as an amount or a percentage of global turnover[6][4].
We are not going to resolve the position of a foreign statute from secondary commentary, and we would not advise anyone to rely on this article for it.
The finding worth carrying away is the third source's warning. If practitioner sources disagree this visibly about the commencement of a prominent regime, then a Canadian firm being told that a regulation requires something from a given date should establish the position from the instrument rather than from commentary, and should be especially cautious where the commentary is published by a party selling compliance tooling.
The Framework Boards Reach For
The more relevant reference point for a North American organisation, reported as the source describes it.
One source records that the NIST AI Risk Management Framework Playbook calls for documenting data provenance including sources, origins, transformations, dependencies, constraints and metadata, and that the NIST Generative AI Profile calls for transparency policies documenting the origin and history of training data and for tracking provenance of training data and metadata. It observes that for United States organisations, NIST is the de facto baseline that boards and auditors reach for first[3].
The relevance for Canada is indirect and real. The framework is voluntary, it is not Canadian, and it is nonetheless the most commonly recognised structure in North American practice, which makes it a defensible organising choice for a firm that wants a named framework without a regulatory mandate. The incident response article in this series reached the same conclusion about the same framework for a different purpose.
The six elements listed are also a usable checklist independent of any framework. Sources, origins, transformations, dependencies, constraints and metadata is a reasonable set of questions to be able to answer about any input feeding a professional deliverable.
We note that the Generative AI Profile items concern training data, which returns to the scoping point above: a firm consuming a model should read those requirements as applying to the material it supplies rather than to a corpus it did not assemble.
Decision Records
An emerging pattern reported with appropriate caution about its source.
One source, discussing two articles of the European regime, states that they establish an expectation that AI-assisted decisions be traceable, interpretable and governed through structured processes, representing a shift away from output-focused systems toward evidence-driven operations, so that the question is no longer whether a system performs well but whether its decisions can be explained, validated and justified when required. It describes organisations building dedicated decision-record layers on top of existing systems, and characterises these as establishing the evidence layer that makes AI usage defensible under scrutiny[7].
That source names a vendor as an illustrative example and includes an explicit disclosure that any platform mentioned is illustrative and that organisations should evaluate multiple solutions, and it discloses that it incorporates practitioner-informed insights[7]. We credit the disclosure and still treat the piece as commercially oriented.
The underlying idea survives its packaging and is worth stating plainly. A decision record is a deliberate artefact created at the point of decision, recording what was decided, on what basis, by whom, and what alternatives were considered. It is not a log, because logs record events rather than reasoning.
For a Canadian professional firm this is a familiar concept under a different name. A file memorandum is a decision record. The observation the material makes is that AI-assisted work generates decisions without generating memoranda, and that the evidence layer therefore has to be created deliberately rather than emerging as a by-product of how the work is done.
The Obligation You Already Have
The argument that makes this a Canadian topic despite the absence of Canadian AI regulation, and it is our own.
One source notes, in listing regimes, that financial reporting accuracy depends on being able to trace reported figures to source systems with an auditable chain[4].
That proposition is not a feature of any AI regulation. It is the basis of financial reporting and assurance as practised in Canada and everywhere else, and it long predates any of this.
The consequence is straightforward. A figure produced with AI assistance that enters a financial statement, a tax filing, or a client deliverable is subject to the same expectation as a figure produced any other way: that it can be traced to its support. Nothing about the method of production relaxes that.
So a Canadian firm does not need the EU AI Act to have a traceability obligation. It has one already, arising from professional and reporting requirements, and the relevant question is whether its AI workflows satisfy an obligation that predates them.
Framed that way the analysis is simpler and the urgency is greater. The question is not whether to build for a future regulation but whether the firm can currently do, for AI-assisted work, what it has always been able to do for manual work: show the chain from the number to its support, and say who was responsible for each link.
Our observation is that many firms cannot, and that the gap opened without anyone deciding to accept it, because the manual chain was implicit in the working papers and the automated chain was never made explicit anywhere.
Lineage Capture Should Not Be Manual
A design principle from the material, with a reason that goes beyond efficiency.
One source advises ensuring minimal human intervention in managing lineage, and that where intervention exists it should itself be traceable. It also recommends regular internal and external assessment of the data architecture to confirm it supports metadata management at scale[6]. Another notes that modern catalogues provide automated lineage extraction capturing transformations without manual documentation[2].
The efficiency argument is obvious. The integrity argument is stronger and less often made.
Manually maintained lineage is a description of a system rather than a record produced by it. It reflects what someone believed the flow to be at the time they documented it, and it decays as the system changes, silently, in the direction of describing a configuration that no longer exists. The drift article in this series described exactly that decay for validation evidence.
Automatically captured lineage is a by-product of execution and therefore describes what actually happened, which is what evidence has to be.
The practical instruction for a firm without a governance platform is to prefer any mechanism that records the chain as a consequence of the work being done, over any mechanism that requires someone to write down what the chain is. The correlation identifier qualifies; a maintained diagram does not.
Completeness And Retention
Two governance decisions that determine whether the evidence is there when required.
One source recommends versioning datasets at each stage using content hashes, connecting lineage to model registries so the full chain from source data to model behaviour is traceable, and establishing governance policies defining completeness requirements and retention periods[2].
Completeness and retention are worth separating because firms tend to decide one and not the other.
Completeness asks what proportion of the chain must be captured for the record to be usable. A partial chain that omits one step is frequently worse than no chain, because it invites a conclusion the evidence does not support.
Retention asks how long. For a Canadian professional firm the answer should be aligned to whatever period governs the underlying work, which is generally longer than a technology platform's default log retention. A model platform retaining requests for ninety days is not aligned to a file retained for seven years, and the mismatch will surface at the worst moment.
The content hash recommendation deserves a note for professional work. Hashing a source document at intake produces a cheap, verifiable statement that the document relied upon is the document held, which is exactly the assurance a firm wants when a client later produces a different version.
A Worked Case: Which Version Did We Read
A Canadian advisory firm responding to a client query on a deliverable issued four months earlier. The reconstruction illustrates the mechanics rather than reporting a specific engagement.
The client disputes a figure and produces a version of the underlying agreement that differs from the firm's understanding. The question is which version the firm's analysis was based on.
The firm has the deliverable, the document library, the model platform's logs and the approval record. Every artefact exists. None shares an identifier with any other, so establishing which document version was retrieved for that specific output requires matching by timestamp and inference, which produces a probable answer rather than a demonstrated one.
Had a correlation identifier been stamped at intake and carried through, the query would return the document version, the retrieval event, the model request, the response, the approver and the posting in one result.
Had the source been hashed at intake[2], the firm could demonstrate rather than assert that the version it holds is the version it read.
And had the retrieval been recorded at all, the firm would know which passages were supplied to the model, which is the artefact that distinguishes a faithful summary of the wrong document from an unfaithful summary of the right one.
None of the three required a governance platform. All three required a decision taken before the work began.
What To Do
Stamp one correlation identifier at intake and carry it everywhere. This is the single highest-value action here, it is cheap at design time, and it is effectively impossible to apply retroactively.
Test the forward direction, not the backward one. Pick a source at random and ask which deliverables consumed it. If that requires opening deliverables one by one, the capability you need for remediation scoping does not exist.
Record retrieval, not training. You did not build the model. What you need is which documents were supplied for each output, in what version and when.
Treat ownership as a first-class field. Whose judgment shaped the output, recorded as a person. The questions asked afterwards are rarely purely technical.
Hash sources at intake. It converts an assertion that you read a particular version into a demonstration.
Align retention to the engagement, not the platform default. A ninety-day log against a seven-year file is a mismatch that will surface at the worst moment.
Prefer captured lineage over documented lineage. A maintained diagram describes what someone believed; a by-product of execution describes what happened.
Check what unit a lineage tool traces before assessing it. If it traces columns and your workflow moves documents, it will trace the parts that were never the problem.
Build to the obligation you already have. Tracing reported figures to source with an auditable chain is a professional requirement that predates AI, and AI-assisted figures inherit it.
Verify any regulatory date from the instrument. Sources disagree visibly about the commencement of the most cited regime, and several are published by parties selling compliance tooling.
The Limits Of This Analysis
Several caveats matter. The sources here are almost entirely commercial: vendors of data catalogues, governance platforms, cloud data services and compliance tooling, all with an interest in organisations concluding they need such products. Regulatory characterisations of the EU AI Act, DORA, BCBS 239, SOX, Basel and the various Asia-Pacific regimes are reported at second hand and were not verified against the instruments; the sources disagree about the Act's commencement and its penalty levels, and we have reported the disagreement rather than resolving it. None of the regimes discussed is Canadian and no Canadian AI statute is in force. The Gartner figures on platform requirements and market spending are reported at second hand from a vendor blog and the analyst material was not accessed. The join key argument, the two-directions distinction, the training versus retrieval scoping point, the assertion-level unit proposal, the existing-obligation argument and the worked case are our own analysis rather than findings in the cited material. This article does not address data classification, privacy obligations where personal information flows through these systems, records retention law, Canadian assurance standards on audit evidence, or model explainability techniques, several of which this publication addresses separately. Nothing here is legal advice or a substitute for professional guidance on records and evidence in a specific practice.
Frequently Asked Questions
Is our traceability problem that we do not log enough?
What is the single most valuable thing to implement?
Does the EU AI Act apply to us?
Then why does this matter for a Canadian firm?
Should we be tracking training data lineage?
Will a data catalogue solve this?
References
- Snowflake. AI Traceability: Lineage, Logs and Audit Readiness, on a production AI system constantly creating a record of itself and evidence fragmenting without traceability, the definition of traceability as connecting data, model versions, prompts, outputs, access events, approvals and incident records, the list of record types, and the credit-risk feature tracing example. Note: published by a cloud data platform vendor. snowflake.com/en/artificial-intelligence/ai-governance/ai-traceability
- Atlan. (2026, March 15). LLM Training Data Lineage: Provenance, Tracking and Compliance, on lineage capturing provenance, transformations and ownership, the training-data pipeline framing, content hashing and model registry connection, governance policies defining completeness and retention, automated lineage extraction, and the statement that the EU AI Act requires documented provenance with enforcement beginning August 2026. Note: published by a data catalogue vendor. atlan.com/know/training-data-lineage-for-llms
- EWSolutions. (2026, June 26). Data Lineage Requirements for AI Systems, on the NIST AI RMF Playbook calling for documented provenance including sources, origins, transformations, dependencies, constraints and metadata, the NIST Generative AI Profile, NIST as the de facto baseline for boards and auditors, the EU AI Act Article 10 data-governance requirements, and the explicit caution that official EU timing sources differ between an August 2026 listing and a May 2026 political agreement. ewsolutions.com/data-lineage-requirements-for-ai-systems
- Decube. (2026, June 2). Data Lineage: Types, Components, and Why It's the Foundation of AI-Ready Data, on the compliance landscape including the EU AI Act described as effective August 2024 with fines reaching a stated maximum or percentage of turnover, DORA covering approximately 22,000 EU financial entities, GDPR, PDPA, SOX and Basel, Asia-Pacific regulators requiring provenance documentation, column-level lineage across a unified canvas, and the proposition that financial reporting accuracy depends on tracing reported figures to source with an auditable chain. Note: published by a data observability vendor. decube.io/post/data-lineage-concepts
- Xenoss. (2026, May 12). Data Lineage: From Compliance to AI Governance, on the reported 2026 Gartner Magic Quadrant requirement to trace lineage across structured data, unstructured data, models and AI-generated outputs, the reported projection of 492 million dollars of AI governance platform spending in 2026, and the observation that off-the-shelf tools cover standard connectors while custom engineering is needed for proprietary pipelines. Note: published by a data engineering consultancy; the analyst material was not accessed directly. xenoss.io/blog/data-lineage
- Atlan. (2025, May 3). Regulatory Data Lineage Tracking for Audit Success, on regulatory lineage mapping the complete journey from sourcing through transformation to consumption, point-in-time audit trails, the cited penalty range under the EU AI Act, the emphasis the Act places on data governance, logging and traceability, and the recommendation of minimal traceable human intervention in managing lineage with regular architecture assessment. Note: published by a data catalogue vendor. atlan.com/regulatory-data-lineage-tracking
- AI Governance Desk. (2026, June 19). EU AI Act Articles 12 and 13 Explained: Decision Traceability and Audit Compliance, on the expectation that AI-assisted decisions be traceable, interpretable and governed through structured processes, the shift from output-focused to evidence-driven operations, and organisations building dedicated decision-record layers as an evidence layer. Note: the source names a vendor as an illustrative example, discloses that platforms mentioned are illustrative, and discloses that the piece incorporates practitioner-informed insights. aigovernancedesk.com/eu-ai-act-articles-12-13-decision-traceability
This article discusses data lineage and traceability practice and is provided for general informational purposes. Its sources are commercial publications by vendors of related products. Regulatory characterisations are reported at second hand, sources disagree about the commencement and penalty levels of the most-cited regime, and none of the regimes discussed is Canadian. Nothing here is legal advice or a substitute for professional guidance on records and evidence.