Twelve connected ideas. One practical operating model. Use the illustrations and examples to explain the work, ask a better question and choose a sensible starting scope.
The engraved illustrations are visual metaphors. The written examples explain the actual work. They do not depict a client system, live control status, measured maturity or verified compliance. Each real connection requires evidence.
Assign authority to a business role for a defined decision. A named owner without a mandate still leaves the decision unresolved.
Ask who approves a disputed reporting definition and who can accept an exception.
A steward keeps definitions, metadata and issue records useful. Coordination is a different responsibility from approving a business decision.
Rehearse how a steward escalates an issue they cannot resolve.
A critical-data register identifies selected assets, their purpose, owners, sources and known destinations. Start with the information behind a real decision.
Can a colleague find the source and owner of an important report?
Record the path from source through transformations to use. Keep filters, time windows, manual work and unverified links visible.
Trace one output, then name the uses affected by a changed input.
Keep the origin, version, dates and evidence behind an observation. A recent review does not turn an old source fact into a new event.
Separate the date something happened from the date someone checked it.
A glossary connects a business term to its definition, owner, scope and effective version. A field name is not a complete business definition.
Compare “active” in two reports before comparing their totals.
Define a rule against a scoped population. Record the denominator, exclusions, method and business owner before interpreting a percentage.
Say what the rule can prove and what still needs another check.
Treat the users, purpose and intended action as explicit boundaries. Viewing, exporting, publishing and training an AI system are different uses to review.
Test an unauthorised-user scenario as well as a permitted one.
Map refresh, correction, access changes, retention and authorised disposal. Keep obligations and exceptions tied to reviewed decisions.
Follow one approved action across every in-scope copy.
Describe the actual use and information flow. Separate a supplier statement from supporting evidence, open questions and client approval.
Explain how data is returned and access removed at exit.
Define approved sources, users, versions and update or removal responsibilities. Data readiness feeds into—not replaces—AI system governance.
Withdraw a test source and check the agreed downstream paths.
Bring changes, exceptions and decisions due into a repeatable review. An internally owned next cycle is a more useful handoff than a static presentation.
Have an internal owner run the review from the records.
Explore a fictional reporting workflow. Change the scenario to see which decisions and evidence need attention. This is an explanatory model, not connected monitoring.
The source owner explains the change. The custodian checks the transformation and downstream report. The business owner decides whether the meaning is unchanged before the next use.
Use this as a scoping conversation—not a legal allocation of responsibility.
Decision rights, policy, owners and review.
Who decides what good looks like?The operational and technical work of handling information.
How is the agreed process carried out?The workflows that implement approved privacy requirements.
How are approved obligations translated into action?The wider review of an AI system and its intended use.
What remains beyond the source-data boundary?