D3 — what the model was allowed to learn

The first impressive answer is often the dangerous one.

Not because it is wrong. Often it is good enough to move the room. A customer-policy assistant finds the clause no one else had found. A product agent reconciles five documents into a neat answer. A finance workflow explains a variance in language the business can actually use. The sponsor relaxes. The technologist smiles. Someone says the model is working.

Then the quieter question arrives.

What did it learn from?

I have watched that question change the temperature of a discussion faster than any benchmark score. The answer may be a SharePoint folder, a vendor dataset, a fine-tuning file, call transcripts, a synthetic dataset, or an index built six months ago by a team that has since moved on. Each answer sounds operational until someone asks whether the source was current, authoritative, lawful to use, resident where the organisation thought it was, and tied to a named owner.

That is D3 — Data & Knowledge Foundation in the framework. It sits in the Strategy pillar because data is no longer a back-office hygiene problem once AI starts consuming it as a decision ingredient. It is strategic because it determines what the organisation can safely scale, what it must constrain, and which attractive use cases should not proceed until the foundations catch up.

The differentiator is D3.4, training-data provenance, rights, contamination, and output attribution. Traditional data governance asked where data came from and whether it was good enough for reporting. AI asks a harder question: what was the model, agent, evaluator, or retrieval system allowed to learn from, and can the organisation prove that later when the answer is challenged?

D3.1, data lineage and quality, is the first layer of that proof. Lineage has to run to the AI consumption point, not stop politely at the data-warehouse boundary. A data product may be well described in a catalogue and still fail the moment an agent uses a stale extract, a transformed field, or a downstream cache whose quality has drifted away from the source. The maturity test is not whether a lineage diagram exists. It is whether the organisation can trace the data being consumed at the moment of inference, tie quality to the sensitivity of the use case, and trigger a response when quality regresses.

That last phrase matters: sensitivity of the use case. A content assistant drafting internal campaign copy can tolerate a different freshness profile from an AI workflow assisting hardship assessments, credit decisions, or safety-critical triage. The operating model should make that difference visible before one generic quality score blesses very different decisions.

D3.2 adds the knowledge layer. Most organisations already have more documents than they can govern. Policies, procedures, standards, playbooks, FAQs, product sheets, intranet pages, board-approved documents, local guidance, deprecated templates, and old PDFs with surprisingly durable search rankings. Humans cope badly with that mess. Retrieval systems cope worse, because they can make the wrong source sound beautifully settled.

Retrieval-readiness is not the same as having a document library. The useful signals are canonical-answer flagging, conflict-resolution rules, recency tagging, and authority signalling made available to the agent at retrieval time. If two policies contradict each other, which one wins? If a procedure has been superseded, how does the system know? If an internal FAQ conflicts with a board-approved policy, does the retrieval logic understand authority, or does it rank by semantic closeness and hope for the best?

This is why knowledge cataloguing is now part of the data foundation. RAG did not make enterprise knowledge reliable. It made unreliable knowledge easier to query. The operating model has to turn human-browsable metadata into agent-consumable retrieval signals, otherwise the organisation has built a more fluent way to surface contradictions it never resolved.

D3.3 is where Australian privacy and residency discipline enters the foundation. Personal information and sensitive information need field-level classification, not table-level folklore. AI workloads need residency evidence per workload: where data is processed, where the model is hosted, where inference occurs, and where logs persist. A cloud-region assumption is not the same as a verified residency posture.

The Privacy Act 1988 and the Australian Privacy Principles matter here, including APP 11’s reasonable-steps obligation to protect personal information held by an APP entity. APP 8 matters where personal information is disclosed to an overseas recipient. The Privacy and Other Legislation Amendment Act 2024 also puts substantially-automated-decision transparency into the forward work, with new APPs 1.7–1.9 commencing on 10 December 2026. Privacy counsel determines the specific pathway, disclosure content, and legal tests. The operating-model question is whether classification, residency evidence, workload inventory, and accountable handoff exist before the benefits case hardens.

Synthetic data does not make this problem disappear. I still hear synthetic used as if it were a magic solvent for rights, privacy, and residency concerns. It is not. Synthetic or augmented data can carry residual identifiability risk and inherit provenance questions from the data used to generate it. D3 asks whether the evidence exists in a form privacy counsel and IP counsel can actually use.

That brings the work back to D3.4. Training data is broader than many executive papers imply. It includes fine-tuning sets, retrieval corpora, evaluation sets, synthetic-data inputs, augmented datasets, and the messy internal examples used to teach a system how the organisation speaks. Each source needs a provenance chain: where it came from, what rights attach to it, whether personal information is involved, which version was used, and what happens when the legal or litigation landscape moves.

The Australian copyright landscape is not the US fair-use conversation with a different accent. Nor is it the EU text-and-data-mining regime. The Copyright Act 1968 and the surrounding reform debate need Australian IP counsel. The operating-model discipline is not to draft the rights view in a maturity framework. It is to make training-data provenance a standing watchpoint, with named cadence, named counsel handoff, and enough records that a contested model can be investigated rather than guessed about.

This is the difference between a one-time dataset check and a living rights posture. A procurement review can ask whether a vendor contract was signed. A mature data foundation asks whether the organisation still knows which sources trained or grounded the system, which rights assumptions were live at the time, whether the model artefact and data manifest are version-controlled together, and how a disputed output would be traced back to likely contributing sources.

Full causal attribution is not always feasible. That should not excuse having no investigative capability. For high-risk outputs, the organisation should know whether it can reconstruct enough of the answer path to support a serious review: retrieval sources, training-data versions, evaluation sets, model version, prompt context, and a disposition record reviewed by the right specialists. D5 owns evaluation design and agent architecture; D10 observes drift and incidents. D3 owns whether the underlying data and knowledge estate can be traced at all.

D3.5 makes the foundation operational rather than ornamental. Data-product accountability means every AI-consuming domain can name the owner for the data feeding its agents, the SLA for quality and freshness, the lineage maintenance obligation, and the change-management consequence when a schema change breaks downstream AI behaviour. “Central data team” is not an owner. A person with an accountable function, a live SLA, and a consequence for breach is closer.

Role design can vary. Some organisations will put this under a Chief Data Officer. Others will extend a CIO, CTO, or privacy function. The dependency map matters more than the title: D3 feeds platform choices in D4, agent design in D5, vendor governance in D8, security and identity in D9, and production monitoring in D10. If the foundation is weak, every later control becomes more theatrical.

The test I would put in front of an executive team is simple. Pick one production AI workload and produce the lineage, field-level personal-information classification, residency evidence, retrieval-source authority signals, and training-data rights register live from systems of record. Not a slide. Not a manually curated pack. Live artefacts, owned by named people, current enough to make a decision.

If the organisation can do that, D3 has substance. If it cannot, the model may still give useful answers. It may even give impressive ones.

But the operating model will not yet know what those answers are standing on.