Being data-driven grows out of everyday work: people can question the evidence, data fits the decision, and the surrounding technology and responsibilities make action possible. The framework helps you build those conditions together, one useful change at a time.
Connected dimensionsWhat must work together?
Supported reachesHow far can a capability be relied on?
Separate renewal questionDoes it still fit after change?
Clear ownership can settle a definition. Better definitions make quality checks useful. Reliable data makes stable work easier to automate. The resulting time and evidence can support the next change.
One weekly planning decision depends on private knowledge, uneven data, and workarounds. Start with the capabilities the work already has.
Select a dimension to follow its five connections. Each relationship is a question to test in real work: what does this change need, enable, or make harder elsewhere?
Read the relationships. Follow a hypothetical planning decision through the animation. Select a dimension to see what it needs from the others and what it makes possible. You can pause or choose any moment.
Return with what you learn. An AI trial may reveal missing data; automated checks may create more exceptions than people can handle. Progress means returning to these dependencies. The shape is illustrative; its rings and moments do not represent the four reaches below.
A capability is something the work can rely on: a role practice, a quality rule, a data path, a decision right, an automated task, or an AI use. The same four reach questions apply to each.
Name one decision, the capability it needs, the people involved, and its limits. Make the owner, evidence, fallback, and stop conditions clear enough to examine a contained proposition.
Understanding the contribution is the starting point. Permission for consequential use still has to be established.
Demonstrate the same contribution through normal work, exceptions, absence, degraded inputs, and recovery. Give its operation, correction, and support to people with time and authority.
One successful demonstration becomes an operating capability only when its everyday support works too.
Find a materially different consumer and test what can travel. Reconsider meaning, purpose, evidence, local variation, support, and exit for that new use.
A copied dashboard or published component is a candidate for reuse. The second context supplies the fit evidence.
Support a named set of contexts with funded capacity, shared and local responsibilities, change management, conflict resolution, recovery, and a usable way to leave.
A shared service earns its reach through support that works. A platform or organization chart alone cannot establish it.
Keep the claim specific: this capability, for this decision, for these people and conditions, until this review. A dependable local practice can remain local. Different capabilities may support different reaches; they do not combine into a company maturity score.
Explore what each dimension contributes, what to work on, and what the four reaches and renewal mean in practice. Each guide includes a visual explanation of its central mechanism.
People need to frame questions, interpret evidence, challenge weak conclusions, and act. Whether they can do that depends on the conditions around their work: skills, usable information, time, authority, safety, incentives, and feedback.
Capability, opportunity, authority and safety, motivation, and feedback have to work together. A break can make silence or a workaround the sensible response.
People check, question, correct, and act with a clear view of uncertainty.
Observe what changed, who benefited, and what still needs correction.
Look at the work environment that makes that response reasonable.
Return outcomes and corrections to the people, incentives, and routines around the next decision.
Authors’ synthesis, based on chapter 5 of the forthcoming book.
People supply business meaning to Data Quality and judgment to AI. Governance must support their authority; Architecture must make the evidence usable. Automation helps only if the time it releases is available for better work.
Read each claim for a named capability and context. The examples describe what to establish and what evidence to look for.
Describe the behavior and conditions needed by a named role group. Establish who can respond when someone questions the data, including a safe route to pause or escalate.
Observe one decision and an exception. Can the person explain the issue and reach someone who can act?
Build practice, handover, deputies, feedback, and recurring capacity into ordinary work. Responsible behavior should be possible without the original expert or unpaid extra effort.
Observe normal and difficult cases, including an absent expert. Does challenge lead to a reasoned response and correction?
Test framing, tracing, judging, acting, challenging, and learning with a materially different role. Translate these abilities into its decisions, authority, onboarding, and development.
Watch the second role perform its actual task. Course attendance and identical job descriptions do not show role fit.
Fund coaching, practice, accessibility, support, and role development across named teams. Keep shared expectations and legitimate local differences explicit.
Can the admitted roles obtain support without hidden favors? Check provider capacity, local workload, opportunity, and exit.
Quality connects data to the action someone needs to take. A passing check, fitness for use, a valid measure, and adequate representation answer different questions. A complete field can still describe the wrong event or exclude the people who matter.
Passing a rule does not establish fitness, measurement validity, or representation. Each question can require a different response.
Conformance to this rule, on this data and version.
Question the rule, bound affected records, and correct only what the evidence supports.
This purpose, consumer, population, and consequence.
Limit, delay, or stop the affected use. Keep a usable fallback while fitness is reviewed.
The concept, proxy, denominator, method, and uncertainty.
Revisit the measure and method. Narrow a claim that the evidence cannot support.
The people, situations, and period where the result will be used.
Improve coverage where possible, or narrow, delay, or stop the use. Filling gaps cannot create unobserved cases.
A pass in one question does not answer the other three. Keep the evidence and response for each visible.
Authors’ synthesis, based on chapter 6 of the forthcoming book.
People and Governance establish what the data means and what use is acceptable. Architecture carries checks, status, and corrections to consumers. Automation can repeat a settled check; AI still needs its own fitness evaluation.
Read each claim for a named capability and context. The examples describe what to establish and what evidence to look for.
Agree a decision-quality contract: the population, meaning, rules, limitations, permitted use, owner, and fallback. Keep conformance, fitness, validity, and representation separate.
Can a consumer explain what a normal or degraded result allows them to do? Can a realistic exception change the decision?
Run checks, warnings, correction, reconciliation, and recovery repeatedly. Name deputies and notify affected consumers when an earlier result changes.
Test missing inputs, a change, and recovery. A green rerun is insufficient if earlier decisions still rely on the wrong result.
Reuse a small core of identifiers, definitions, checks, or correction patterns with a different consumer. That consumer establishes its own population, consequence, and fitness requirements.
Demonstrate the second consumer’s task and operate the support relationship. The provider’s quality status cannot grant permission.
Coordinate shared definitions, quality checks, incident support, and correction across named consumers. Fund the service while keeping use-specific fitness with the business owner.
Check local and provider effort, queues, correction notices, change, recovery, and exit across the supported contexts.
Architecture makes a decision’s data path understandable and operable, from producer through transformations to use and recovery. The useful starting point is the consumer’s job and service promise. A local file, batch, API, or platform can each fit a different need.
A usable service allocates meaning, delivery, change, recovery, and consumer feedback. Business and independent decision authority remain with their owners.
Work left for the consumer to discover
Meaning, definitions, and change obligations.
Versioned delivery, support, and recovery.
A named job, acceptable limits, fallback, and feedback.
Use, failures, and corrections return to the people who can change the service.
A service or platform does not inherit the business decision or independent specialist authority. A local or manual path can work well when responsibilities and support are explicit.
Authors’ synthesis, based on chapter 7 of the forthcoming book.
Architecture implements paths and controls agreed with Quality and Governance. People must be able to discover, understand, and operate them. Automation and AI depend on these paths without inheriting business authority from the platform.
Read each claim for a named capability and context. The examples describe what to establish and what evidence to look for.
Name a consumer, job, required timing, source, transformation, output, and service owner. Choose the simplest adequate pattern and make limits and fallback explicit.
Trace one result back to its sources. Show how a missing or stale input becomes visible before the decision.
Establish support, monitoring, change, replay, restoration, and reconciliation for the bounded path. Recovery must restore a usable business state as well as technical processing.
Rehearse late data, an interrupted run, and recovery. Can the consumer still meet its decision window or use the fallback?
Test a stable interface or service with a materially different consumer. Compare meaning, timing, history, consequence, authority, support, and exit before sharing it.
Observe the second workflow through normal and failure conditions. Record what can be shared and what must stay local.
Coordinate services for named workloads and consumers with funded provider capacity, local responsibilities, change notices, recovery, and portability.
Can consumers complete their lifecycle without hidden bespoke rescue? Check queues, unsupported versions, costs, and a representative exit.
Governance gives decisions about meaning, quality, purpose, access, change, and exceptions an accountable home. It works when a person can find the right decision holder, obtain an answer, implement the conditions, and challenge or correct the result.
Different decisions can belong in different places. Knowledge, cross-domain effects, consequence, frequency, and real authority guide that placement.
Decide each act separately. A single owner label can hide several different mandates.
Enterprise investment, policy, or exposure decisions remain separate from independent specialist authority.
Record the holder and mandate, required input, reasons, conditions, deadline, and a route to correction, appeal, or stop.
Affected people inform the decision. A reasoned response, correction, and recourse must reach them in return.
Authors’ synthesis, based on chapter 8 of the forthcoming book.
Governance enables People to act and defines the boundaries Architecture must implement. Data Quality supplies fitness evidence. Automation can enforce settled decisions; AI proposals still require accountable judgment and separate authorization.
Read each claim for a named capability and context. The examples describe what to establish and what evidence to look for.
Make one purpose or access decision explicit: its holder, mandate, required input, conditions, implementation, exception route, and recourse.
Can a requester reach the legitimate holder, an operator apply the conditions, and an affected person obtain a response?
Operate intake, evidence, decisions, implementation, monitoring, exceptions, and correction with funded primary and backup roles.
Test incomplete and urgent requests, absence, and withdrawal. Check whether the route works without personal favors or permanent exceptions.
Test a shared rule or decision pattern in a materially different context. Preserve local meaning and reserved specialist acts; trace the rule through controls, evidence, and revision.
The second context must be able to reject the proposed fit. Earlier approval supplies context, never inherited permission.
Agree what stays local, what needs shared decisions, and how disputes, services, funding, assurance, and exit operate across named contexts.
Observe actual decisions and handoffs. Check whether authority and capacity sit together and whether cross-context conflicts can be resolved.
Automation redistributes work between people and systems. It can repeat settled rules and reduce avoidable effort, while creating new review, exception, support, and recovery tasks. Its value depends on the complete workflow and what happens to the time released.
Released effort becomes useful capacity only if it forms usable blocks, has staffing and authority, and is protected from new queues. Observe the complete workload.
A missing or unknown condition leaves the capacity claim unproven.
An owner protects the released effort for quality, repair, and learning. Observe whether those activities improve.
More volume, exceptions, or on-call work consume the time. Observe workload and fatigue across roles.
Review total work, elapsed time, exceptions, recovery, and who carries the burden.
Authors’ synthesis, based on chapter 9 of the forthcoming book.
Automation needs definitions and quality controls, an operable architecture, clear authority, and people able to respond. A stable automated check can support quality work; it can also spread a bad rule faster. AI is a separate option for learned behavior.
Read each claim for a named capability and context. The examples describe what to establish and what evidence to look for.
Map the task, inputs, rules, judgment, authority, affected people, and current route. Decide what to remove, keep manual, observe, assist, or test.
Can the team explain the normal task and realistic exceptions? Observation alone does not authorize live automated action.
Operate an admitted task within its permission limits, with effective review, actionable stop controls, exception handling, fallback, and business recovery.
Test failure and recovery, reviewer workload, and duplicate effects. Demonstrate where released effort becomes usable capacity.
Share a stable preparation or evidence component with a different workflow. Reassess its local rules, meaning, permissions, support, and consequences.
Observe the new consumer’s result and recovery. Reusing a component does not transfer the first workflow’s autonomy or approval.
Support named consumers and versions through onboarding, operation, change, recovery, and exit. Fund provider and local review capacity.
Check capacity spikes, unsupported versions, outages, and consumer exit. Lower autonomy or a manual route can remain appropriate locally.
AI contributes a prediction, classification, retrieval result, or generated proposal to a defined task. Useful behavior depends on its data, context, configuration, and release. The organization still owns the purpose, judgment, authorized action, and consequences.
An AI signal reaches action only through effective control and authorized judgment. People can use, edit, reject, escalate, or stop it, and affected people need a response route.
Compare the complete outcome, total work, risk, and reversibility.
The contribution still needs accountable judgment.
Within the delegated authority and bounded task.
The relevant specialist or independent decision holder.
Stop AI-supported action; keep the current, manual, or simpler route usable.
Recourse can change the case and require repair of the wider system. It is a human and institutional response, not an automatic training feed.
Authors’ synthesis, based on chapter 10 of the forthcoming book.
AI relies on fit data, supported technical paths, clear authority, and people who can judge and intervene. It often exposes gaps in those conditions. Improving them may solve the original problem without introducing AI at all.
Read each claim for a named capability and context. The examples describe what to establish and what evidence to look for.
Define the decision, proposed AI contribution, baseline, affected people, evidence needs, and limits. Work here is observational, analytical, synthetic, or design-only.
Show a credible reason to test AI. This reach does not authorize a live pilot or output that shapes a real decision.
Evaluate and admit an exact purpose, workflow, and release. Operate it with effective human control, monitoring, correction, fallback, recovery, and exit.
Rehearsal and isolated shadow tests support admission. The reach claim requires evidence from the bounded, authorized operation.
Test a stable element, such as an evaluation or source-withdrawal pattern, with a different consumer. Reassess its task, data, release, evaluation, authority, and lifecycle.
Show consumer fit and provider support. A prompt library, model endpoint, or earlier model approval cannot establish either by itself.
Fund services for proven reusable elements across a named set of separately admitted consumers. Keep each use’s purpose, release decision, evaluation, and action limits explicit.
Can provider and consumers operate change, incidents, workload, and exit within the promised reach? Service access never authorizes a business use.
Start with the decision in front of you. Find the condition that limits the next useful outcome and the support it requires across the dimensions. The least developed-looking dimension is not automatically the priority.
Trace one real decision, its people, data, handoffs, delay, and workarounds. Name the current route and what must be protected.
First check hard conditions such as authority, fitness, and safe recovery. Then compare what each change would unlock, its evidence, total workload, risk, and reversibility.
Agree an immediate result and a lasting contribution. Include the necessary people, rules, technical path, support, fallback, and stop authority from the start.
Look at the decision, reliability, burden, and affected people. The evidence may support advancing, repairing, narrowing, holding, or retiring the capability.
A warehouse team reconciles two stock reports every week. One manager proposes faster data delivery; another wants an AI forecast. Observation shows that both reports arrive on time, but only one excludes reserved stock from “available.” Nobody has authority to settle which meaning this decision needs.
The next change connects People, Governance, and Quality: agree the definition, give an owner authority and time to resolve exceptions, and make the rule visible in the existing report. Architecture supports traceability; stable checks may later be automated. A forecast becomes a separate question when a credible baseline and the required support exist.
Observe reconciliation time, decisions, excluded cases, and support work under comparable demand. A quieter week could otherwise look like improvement. Keep the current review route available. The immediate promise is a usable stock view; the lasting contribution is an owned definition and a working exception route.
Stabilize · Repeat · Reuse · Scale with feedback
These are recurring work moves inside a change. They can appear at any reach. Completing a move does not establish a reach or demonstrate renewal; the observed capability and its evidence do.
The framework is the authors’ synthesis, developed in the forthcoming book. Its relationships are propositions to examine in your organization. The illustrations and examples explain the method; they are not company assessments.
Explore the bookBring the framework into a leadership conversation, a workshop, or your next event.