Kendall Framework AI Guide - A System of Work for AI Adoption

© 2026 NKD Agility. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License . You are free to share and adapt this material for any purpose, even commercially, provided that attribution is given and adaptations are shared under the same license.

Kendall Framework, Context Block, Context Warehouse, Context Operations, AI Bill of Materials (AI BoM), and Context 360 Sprints are marks of The Kendall Project. NKD Agility is an official Kendall Partner, and this guide is published on the basis of that partner relationship. This guide describes the Kendall Framework in NKD Agility’s own words and extends it with the NKD Agility operating layer; extensions are explicitly labelled as such throughout. The guide stands alone - you do not need to have read The Kendall Project’s materials to use it - and where it restates the canon it uses Kendall’s terms with this attribution. Adaptations under the licence may reuse this guide’s text; the marks remain The Kendall Project’s, and using them beyond naming the framework requires their permission.

Kendall Framework Purpose & Definition

Most of the organisations we see do not have an AI capability problem. They have a starting problem. The tools are bought, the pilots are running, the board is asking - and nobody can say with evidence which problem the AI is actually for. The Kendall Framework exists to close exactly that gap. Its single purpose is to answer: “Where do we start with AI?”

It is a structured, data-driven framework for identifying and prioritising AI opportunities. It does not prescribe tools or architectures. It directs the organisation to start from validated problems rather than technology trends, to make its own operating knowledge explicit, and to decide with evidence rather than enthusiasm. It emphasises flow - of information, decisions, and value - guided by empirical inspection and adaptation (the empiricism framing is this guide’s operating layer).

The Context Gap and the Accuracy Ceiling

Across the AI programmes we see, a pattern repeats: capable tools, serious budget, and results nobody can point to. Sometimes the model is the problem. Far more often, in our experience, the organisation is asking AI to work somewhere it has never been told how the work works. How decisions get made, which exceptions matter, who owns what, which words mean which things - that knowledge lives in experienced heads, buried spreadsheets, sign-off rituals, and shorthand that only makes sense on the inside. None of it is anywhere a machine can reach. Kendall calls that distance the Context Gap: the space between what AI could do for you and what you have made explicit enough for it to use.

Left unclosed, the gap produces the Accuracy Ceiling: the point where AI performance stops improving no matter how much you spend on it, because the model has run out of organisational knowledge to work with - not intelligence. That makes it a limit of the operating model, not of the model - and it is why, when AI disappoints, the answer is rarely another pilot or a newer model. Inspect the context you gave the last one instead.

That diagnosis is testable, and you should test it before believing it (NKD Agility operating layer). Take one underperforming use case and run the cheapest context intervention available - a Role Context Block and a certified glossary for its top terms - alongside the alternative you were considering, such as a newer model. If the context work moves the outcome and the swap does not, context is your constraint and this framework will help. If model changes keep outperforming context work, your constraint lives elsewhere - capability, task fit, or economics - and you should not adopt this framework to fix it. One caution in reading the result: the cheap probe can fail where richer context would succeed - a negative on one Role Block and a glossary is a lead, not a verdict. Re-run it with the context the use case’s AI BoM would actually declare before concluding context is not your constraint.

The framework itself carries the same obligation (NKD Agility operating layer). If frontier models working from raw, unprepared estates start matching what curated context achieves - if the exit test’s model arm starts winning routinely across portfolios, not just use cases - then the constraint this guide exists to close has moved, and the guide should be revised or retired rather than defended. We will say so when we see it.

This is why we say AI is a mirror - it is our operating thesis, and the claim that follows is where it earns its keep. AI amplifies whatever system of work it lands in - chaos just as easily as excellence. AI outcomes are a system property, produced by the same operating-model design decisions that produce every other delivery outcome. Organisations with an adaptive operating model - one that can sense reality, separate signal from noise, and revise its own assumptions - are far better placed to convert AI capability into value. Organisations without one risk automating their existing dysfunction at machine speed. The Kendall Framework is the disciplined entry point for the first path.

The framework is deliberately incomplete. It defines boundaries and focus, and it expects to be complemented by practices that provide delivery discipline, modern engineering, effective team collaboration, and observability.

Kendall Application

The Kendall Framework can be applied by organisations, teams, entrepreneurs, and governments that need clarity on how to approach AI adoption. It suits any domain where complex challenges require principled prioritisation, flow-based thinking, and structured learning.

Scope, Claims, and Non-Claims

Who this is for. Leaders accountable for an AI decision they cannot yet scope, the people they name into the accountabilities below, and practitioners expected to use AI in real work. It is an operating-model guide first; “Choosing Tasks for AI” below is the practitioner’s entry point.

What must be true to start. An executive sponsor with budget authority; at least one candidate problem someone is willing to own; and permission to observe the work as it is actually done, not as the process manual describes it.

What this guide does not claim. It does not claim AI will work for you - it claims you will find out cheaply, and on evidence. It does not claim context fixes every AI failure; the diagnostic test below tells you whether context is your constraint before you commit. And it does not replace delivery discipline, modern engineering practice, security, or your regulatory obligations - it expects to operate alongside them. The Kendall Project also defines a phased capability-building path (leadership alignment, workforce literacy, context operations, curator development) delivered through its training line; this guide describes the system of work those phases build towards, not the training itself.

Seven Principles (and One Habit) of AI Leadership

The Seven Principles are Kendall’s diagnostic core. Each names a way AI programmes fail, and the discipline that prevents it. The headings below are this guide’s own restatement; Kendall’s canonical name for each principle is noted beneath it. Read them as a checklist against your own programme: the principle you cannot evidence is the one costing you money.

1. Context is the Operating Asset

(Kendall’s canonical name for this principle is “Context is king.”)

If your AI’s output could have been written for any company in your industry, it is because you have told it nothing that makes you your company. A model without context can only generalise - and generalised answers are what stall enterprise AI programmes.

Context is not volume. It is the specific knowledge that makes an answer correct here: the facts, policies, process detail, terminology, role expectations, decision criteria, and constraints that surround a request. When a piece of context is used often, or is too important to stay in someone’s head, capture it as a Context Block: knowledge written down once, given a named owner, and shaped so a machine can pick it up cold. Every other artifact in this framework is assembled from these.

Application: Define purpose, scope, and constraints so solutions align with organisational goals. Capture high-value knowledge as Context Blocks with a named owner, a known location, and a stated risk if the block goes missing or stale. Pull context into AI systems at the rate of actual demand - accumulating context speculatively is waste.

First move: Take one high-stakes AI use case and write down what a capable new hire would have to be told before you would trust them with the task, where each of those things is written down today (if anywhere), who owns each one, and whether an AI system could actually retrieve it. Every “nowhere” and “nobody” on that list is your Context Gap, itemised.

2. Language Sets the Error Rate

(Kendall’s canonical name for this principle is “Language is the raw material.”)

Every naming inconsistency your organisation tolerates, your AI inherits as a defect. Three names for the same product, two definitions of “active customer”, shorthand that only one department understands - humans route around this in meetings; a model cannot. It will pick one meaning, silently, and be wrong with confidence.

The discipline is not to make language rigid. It is to make the language that matters stable enough to reuse: canonical definitions, certified terminology with named owners and review dates. A glossary stops being reference material and becomes operating infrastructure.

Application: Use precise, unambiguous language when defining problems, context, and requirements. Invest in articulating constraints, boundaries, and success criteria. Certify the terms that matter: approved word, single-sentence definition, examples, non-examples, owner, review date.

First move: Pick the one term your organisation argues about most and certify it as a glossary Context Block. The argument you have while writing it is the defect you were shipping to your AI.

3. Who Comes Before What

(Kendall’s canonical name for this principle is ““Who” anchors AI.”)

An answer that is not anchored to a person is an answer for nobody. Before AI can respond usefully it needs to know who is asking - not the name, but the role in that moment: the responsibility on their shoulders, the decision on their desk, the audience who will judge the answer, and the limits they cannot move. The same question from a junior analyst and a board director has two different correct answers.

“Who” also draws the deeper boundary - between what AI does and what only humans can do. AI optimises inside a system. Humans adapt and redefine the system. Purpose, adaptation, sense-making, and accountability stay with humans; pattern detection, tactical optimisation, and consistent execution are where AI excels. AI cannot perceive new purpose, it cannot lead, and it cannot be held accountable. Humans govern; AI serves. Anchoring every AI use case to a named human role is how that division of labour becomes real rather than aspirational.

Application: Identify stakeholders explicitly. Define their needs, perspectives, and success measures. Capture critical roles as Role Context Blocks - what the role owns, decides, answers to, and works within, and how it prefers its answers - so the work carries its owner’s truth and limits wherever it goes. Ensure AI systems are accountable to those they serve.

First move: Write a Role Context Block for the one stakeholder whose rejection can kill an AI output. If you cannot state what that role is accountable for and what it will not accept, neither can your AI - and it is guessing on your behalf.

4. Problems Pull; Tools Follow

(Kendall’s canonical name for this principle is “Problems fuel AI.”)

“We should be using AI for proposals” is not a problem statement - it is a purchase looking for a justification. A problem worth AI investment is an operating gap you can evidence: a named owner, a reproduced failure, a measurable cost - stated in the language of operations (throughput, cycle time, error rate, cost, customer outcome), not the language of tool capability.

Kendall calls this a validated problem, and the discipline is to build a backlog of them before selecting any technology. Demand pulls the tool; the tool never goes hunting for demand. This is the cheapest place to stop wasting AI budget, because every pound spent downstream inherits the quality of the problem it was aimed at. One caution before the lifecycle: problems come in kinds - decide early whether a problem is complicated or complex, because the distinction (drawn under the Opportunity Backlog below) changes whether your next step is analysis or a probe.

The sharpest operating term is the one that lives outside the building (NKD Agility operating layer): what changes for the customer. Internal measures - throughput, cycle time, error rate - justify effort; a changed customer outcome justifies existence. A problem statement that cannot be traced to someone the organisation serves is a cost-reduction exercise, and should be ranked as one.

Application: Start with the problem, not the solution. Name three things before naming any technology: who is affected, what specifically goes wrong for them, and what it costs the operation in numbers someone owns. A statement that survives all three earns the next question - what would AI need to know to help? Let the resulting demand signal decide where AI investment goes.

First move: Write one problem statement that names all three for the AI initiative you are currently most excited about. If you cannot, you have found out something important before it got expensive.

5. Rules Live Outside the Model

(Kendall’s canonical name for this principle is “AI needs your rules to play your game.”)

Your organisation runs on rules - formal ones written into policy and compliance manuals, and informal ones that live in judgment: the feel, learned the hard way, for what review will reject. AI knows none of them until they are made explicit. A rule the model has never seen is a rule it will eventually break.

Be clear-eyed about what a written rule is to an AI system: an ask, not a constraint. A model cannot reliably distinguish an instruction from the rest of its context - it is all one stream, and in the systems we work with, when the stated goal and the stated rule conflict, the goal wins often enough that you must plan for it. Rules stated in a prompt give teams a false sense of control unless they are backed by structure. Verification must therefore be structural, not conversational: validate outputs in independent contexts that had no part in producing them, gate consequential actions behind deterministic checks, and place a human at the decision boundary. An answer that reads well has passed no test except reading well.

Application: Make policies, values, and constraints explicit as Rule Context Blocks: the rule in approved language, its owner, where it applies and where it does not, what it allows, what it prohibits, the evidence behind it, and when it must be reviewed. Then enforce the rules that matter outside the model - through independent validation contexts, deterministic gates, and human review - rather than trusting the prompt.

First move: Write one Rule Context Block for a rule your AI could plausibly break tomorrow, and name the structural check - not the prompt wording - that would catch the violation. If no such check exists, the rule is currently a hope.

6. Context is Assembled, Not Accumulated

(Kendall’s canonical name for this principle is “Assemble AI like a truck.”)

The instinct is to give the AI everything and let it sort things out. Resist it. Irrelevant context is not neutral - it confuses retrieval, introduces contradictions, and makes governance harder with every document added.

The discipline is composition: reusable Context Blocks, assembled per use case. For each significant AI application, the organisation should be able to say exactly which context is in play - Kendall calls this the AI Bill of Materials (AI BoM): for one use case, the declared set of blocks, data sources, documents, owners, access boundaries, and review cadence - a parts list with ownership attached. The payoff is control. When output quality drops you do not interrogate the model; you open the assembly and ask which block has drifted, which rule never made it in, and whose certification is overdue. If you cannot list what your AI knows, you cannot fix what it gets wrong.

Application: Collect, structure, and version context systematically as Context Blocks in the Context Warehouse. Assemble per use case into an AI BoM rather than uploading everything and hoping. Limit work in progress to maintain focus and relevance.

First move: Draft the AI BoM for one live use case: every Context Block, data source, and document it depends on, with an owner, an access boundary, and a review cadence for each. The parts you cannot name are the parts you cannot govern.

7. Context is Shared Work with Named Owners

(Kendall’s canonical name for this principle is “AI is a team sport.”)

Enterprise AI sits at a junction no single function can see across: engineering knows the systems but not the work; the domain knows the work but not the boundaries; compliance knows the boundaries but not the priorities; leadership knows the priorities but not where the process gives way on a wet Tuesday afternoon - the frontline knows that. Park AI in IT alone and you get solutions that are technically sound and operationally disconnected; park it in the business alone and governance, integration, and risk get underestimated. And when everyone contributes but no one owns, the context rots quietly until the answers built on it fail loudly.

Be honest about what you are asking for (NKD Agility operating layer). The people whose knowledge you want are being asked to write down the judgment that makes them valuable, and to disclose the errors AI makes on their watch. They will do neither in an organisation that punishes either. Two commitments make the framework viable: disclosed errors and failed probes are treated as the system inspecting itself, never as individual performance data; and contributors get the first benefit of their own blocks - the AI that serves them improves first, visibly. An organisation unwilling to make both commitments should not expect its warehouse to contain anything true.

There is a deeper disincentive than embarrassment (NKD Agility operating layer): the fear that codifying your judgment is codifying yourself out of a job. Meet it honestly, because pretending it is irrational makes concealment rational. Codified knowledge does change roles - some work genuinely moves to the machine - and the person who wrote the block is the person best placed for the higher-leverage work that replaces it: certifying, judging at the decision boundary, catching the confident error. An organisation that harvests judgment and then discards the judges will get exactly one harvest. Say out loud, before the first Sprint, what happens to the roles whose knowledge is being captured; the answer will reach every contributor either way, and the version they invent is worse than any truth you can tell.

Application: Foster collaboration across disciplines. Build shared understanding and collective ownership. Name the accountabilities (see below) for every significant use case - if an accountability is unfilled, the use case is not ready to scale.

First move: For one AI use case, put a name against every accountability in the list below. Each blank is a prediction of where that use case will fail.

The One Habit: Continuous Improvement is Non-Negotiable

(NKD Agility operating layer - this habit extends the Seven Principles with the empirical discipline the framework runs on.)

Context decays, organisations change, and every AI answer is a bet against a moving target. The only durable response is a habit: inspect outcomes against intent, treat surprises as signals, and adapt on a rhythm rather than in a crisis.

Application: Establish regular discovery cadences. Hold Opportunity & Context Sourcing Events quarterly or half-yearly. Inspect outcomes against intent. Treat surprises as signals for adaptation. Maintain rhythm around review cycles to ensure continuous learning and adaptive alignment.

The cadence is the backstop, not the mechanism. Feedback should be event-driven first: a missed expectation, a drifted Context Block, a surprised stakeholder, a use case whose quality has visibly dropped - each of these triggers inspection now, not at the next quarterly event. An organisation that waits for the calendar to tell it something is wrong has built a batch process around its learning.

How It Works

The Kendall Framework adapts the best of Lean manufacturing, Design Thinking, and Agile philosophy for today’s AI challenges. It applies a problem-first approach through a team-based framework that integrates management clarity, systems thinking, and iterative improvement to ensure adoption creates measurable value.

Together, the principles establish Context Operations: knowledge run like an engineering discipline - authored by the people who hold it, reviewed and certified by named owners, versioned in one governed place, and shipped deliberately to the AI systems that depend on it. What the model knows stops being an accident. The flow behind that discipline is the Context Supply Chain: the journey a piece of knowledge makes from a human head to a model input - out of people and systems, into an owned block, through certification, into the Warehouse, into the AI BoM a use case declares, and finally into the model when demand pulls it there.

Team-Based Approach

The framework thrives on collaboration and shared intelligence:

• Problem-First Focus: Workshops concentrate on defining and prioritising validated problems, ensuring that AI investments align with real needs, reducing waste, and maximising returns.
• AI Roles and Problem Identification: Participants define their roles and articulate problems from their unique perspectives. This data-driven approach ensures all voices are heard and key issues are accurately captured.
• Team Collaborative Scoring: Participants vote on which problems should be solved first, resulting in clear, shared understanding of priorities.
• Human-in-the-Loop by Design: Humans sit at the decision boundary - wherever a wrong output would cascade, where domain expertise is required to evaluate correctness, or where the cost of a silent failure is high. The expert between the segments is not a legacy cost; it is the quality control AI cannot yet replace, retired node by node only when a validated replacement exists.

Core Mechanisms

• Context as Foundation: Define purpose, scope, and constraints so solutions align with organisational goals.
• Pull-Based Context Flow (NKD Agility operating layer): Context is pulled into AI systems at the rate of actual demand, avoiding waste from excessive accumulation and ensuring relevance.
• Structured Collaboration: Build shared understanding and collective ownership across disciplines.
• Empirical Governance: Guide adoption through inspection and adaptation, not prediction.
• Discovery Cadence (NKD Agility operating layer): Hold regular Opportunity & Context Sourcing Events (quarterly or half-yearly) to surface problems, adapt, and rebalance flow of priorities.

Governing AI Decisions

An agent’s goal is to satisfy the objective function it was given, not to honour your intent - and when the stated goal and the unstated constraint are in tension, the goal wins. The failure point is rarely the model; it is the orchestration around it. Govern accordingly:

• Draw the deterministic/probabilistic boundary deliberately. Decide which outputs may vary (drafts, suggestions, exploration) and which must not (approvals, denials, compliance-relevant decisions), and enforce the deterministic side outside the model.
• Validate completion claims against observable outcomes, in a context independent of the one that did the work - never take “done” at face value.
• Log every non-human decision. Delegation within declared boundaries is how AI acts at all; the log is how that delegation stays accountable. Each decision must be attributed, explained by recorded criteria, and retrievable. “Ask again in a couple of days” is not an audit trail, and in regulated environments an unexplainable automated decision is not an operational system - it is a liability.
• Keep a named human accountable at the decision boundary. Accountability cannot be delegated to a system that cannot carry it.
• Pair every stop with a recovery path. A halted use case needs more than a pause: quarantine the suspect block (it stays visible but leaves every AI BoM that consumes it), freeze the BoM at its last known-good assembly, and fall back to the pre-change behaviour while the named human investigates. Stop authority without a rollback path is half a safety mechanism - the half that creates pressure never to use it.
• Assign stop authority ahead of need. Anyone operating at the decision boundary can halt a use case’s output pending inspection; the named accountable human decides on resumption. A stop is a quality act, not an escalation failure.
• Govern outward as well as inward. For each use case that touches customers, employees, or the public: name who identifies and reports harms, how an affected person contests an AI-assisted decision and gets it corrected, and who investigates incidents. Validate supplier and model-vendor claims the way you validate any other input - against your own evidence, not their benchmark.
• Set the data boundary at Selection. What data a use case may touch, under whose authority, and with what privacy, security, bias, and accessibility obligations is part of its AI BoM - not a discovery made in production.

What outward governance looks like in one concrete case (a marked hypothetical): a lender deploys AI-drafted first responses to complaint letters. Selection names the data boundary (complaint text and account metadata, nothing else), the harm reporter (the complaints team lead), the appeal path (any recipient can demand a human re-draft, and the demand itself is logged as a harm signal), the investigator (the named human at the decision boundary), and the stop (the team lead halts drafting pending inspection, resumption owned by the accountable human). None of this required sophistication - it required the questions to be asked before deployment instead of after the first regulator letter.

Choosing Tasks for AI

(NKD Agility operating layer.)

The principles govern the programme; this is the daily filter for the work itself:

• Fit the task to what AI is good at. Drafting, summarising, transforming, pattern-finding, and first-pass analysis suit it well; tasks where a plausible-but-wrong answer is expensive and hard to detect suit it least. Capability is uneven and task-dependent - test on your task, not on reputation.
• Scale checking to stakes. A brainstorm needs a skim; anything that leaves the team, touches a customer, or feeds a decision needs verification by someone with the expertise to catch a confident error. If reviewing the output costs more than doing the work, the task was a poor fit - stop. Classify stakes with three questions: who is affected if the answer is wrong (blast radius), how easily the action can be undone (reversibility), and how quickly a wrong answer would be noticed (detectability). Anything touching customers, money, safety, or legal standing starts high and argues its way down - and a wrong answer that is hard to detect is high-stakes regardless of how small it looks.
• Know your mode. Augmentation (AI drafts, a human owns), delegation (AI executes inside declared boundaries with checks), and automation (no human in the loop) are different risk classes; the decision-boundary work above decides which is permitted where.
• Expect the ground to move. Models change under you. Re-run your use-case checks when the model version changes, and treat a capability gain or regression as a demand signal for the AI BoM, not a surprise.
• Keep the checker qualified. Verification by someone with the expertise to catch a confident error assumes that expertise persists - and it decays when people stop doing the work they now review. Retained skill is context too: keep humans doing enough of the real work, deliberately, to stay qualified to check it.

Starting Small

(NKD Agility operating layer.)

The smallest viable configuration is one validated problem, one Context 360 Sprint, and the accountabilities merged into the people already nearest the work - a Problem Owner who also owns their blocks, a facilitator borrowed for the Sprint. No new hires, no platform. Expand on the evidence of the first settled bet, not before.

We publish no effort estimates for this configuration, deliberately: effort scales with the organisation and the use case, and a number from someone else’s context would anchor yours falsely. There is a second, plainer reason: our own first client Sprints are ahead of us, not behind us, and we would rather publish nothing than a number we cannot stand behind. When our engagements produce honest ranges, this section will carry them. Until then, the honest number is the one your own first Sprint produces - which is fitting, since producing evidence about your own operation is the entire point of the framework.

The borrowed facilitator needs a floor of competence, not a certification: run the Sprint sequence, draw out exceptions and unwritten norms without leading the witness, and write a candidate block an owner can certify. The fastest route we know is apprenticeship on the artifacts - write the Role, Rule, and glossary blocks for your own role first (the First moves above), then facilitate for a domain you do not know, where your ignorance is an asset because it forces the experts to make things explicit. The Kendall Project’s training line builds this capability formally; this guide’s exhibits are the minimum viable substitute.

You can size the standing burden before you start, without our numbers: count the blocks your first use case’s AI BoM declares, multiply by their review cadence, and put a named owner’s real minutes against each verification. That product is the operating cost the framework adds. It is what the owner-load indicator watches - and if it does not fit inside genuine capacity, the use case is not ready.

Treat the first cycle as a probe of the framework itself: the smallest viable configuration is its safe-to-fail boundary, the first settled bet is its signal, and walking away is an allowed verdict.

Scale on signals, not ambition. Split a merged accountability the first time it queues - an owner who cannot re-certify within the cadence is a bottleneck, not a hero. Stand up a dedicated Context Controller when conflicts between domains, not volume alone, start consuming owner time. Add a second domain only after the first has a settled bet and a stable staleness-found rate. Each expansion is itself a bet with a settlement date.

Expect the framework’s real enemies to be mundane: the budget cycle that funds the Sprint but not the curation, the owner who changes roles and leaves orphan blocks, the day job that quietly eats certification time. Orphaned blocks and rising owner load are the leading indicators of quiet death - watch them.

The sceptic’s fair challenge: enterprises have spent thirty years filling knowledge repositories that decayed into expensively maintained graveyards, and the Context Warehouse looks like the next one. The structural difference is the consumer. Those repositories had none - capture was the product, and nothing depended on freshness. Here the AI consumes the knowledge relentlessly, which changes two things: nothing is captured that no use case demands (pull keeps the store small enough to govern), and every block sits in a named assembly, so when quality drops there is a specific block to suspect rather than a wiki to despair of. What consumption does not do is guarantee that a stale block announces itself - this guide argues everywhere else that a wrong answer can read beautifully. Detection is therefore built, not assumed: structural verification at the decision boundary catches what plausibility hides, and re-certification against the work as done catches what verification misses. The loop knowledge management never had is closed by consumption plus inspection - not by consumption alone.

Is Adoption Working?

(NKD Agility operating layer.)

Bets and verdicts govern use cases; these indicators govern the programme. Every one is derived from artifacts the framework already produces - no new instrumentation - and every one carries its gaming path named, because an indicator whose gaming path is secret becomes a target. Do not set targets against them; inspect them.

• Settled-bet ratio. Of the use cases past Selection, how many have reached a Review with a verdict? This measures whether the empirical loop actually closes. Gaming path: settling bets fast by making them trivial - inspect bet quality alongside the ratio.
• Abandon rate above zero. Some verdicts should be abandon. Once a portfolio is old enough to have settled several bets, zero abandonments does not mean everything worked; it means the verdict mechanism is not being used honestly. A young portfolio with two bets can honestly have none - the flag applies when failure has had a fair chance to occur.
• Staleness found at review. How often does re-certification catch a drifted block? A steady non-zero rate means verification is real. Once the estate has age, a perfect record means owners are signing, not checking. This indicator doubles as a safety gauge (see Principle 7): when disclosure is safe, owners keep finding drift; a rate collapsing toward perfect is more often fear than excellence.
• Problem-to-evidence lead time. Days from a problem passing Validation to its first settled evidence - a probe result or a first review. This measures flow, not activity. Gaming path: compressing it by skipping Validation, which just moves the cost downstream.
• Pull ratio. Of the Context Blocks created recently, how many were demanded by a use case and how many were supplied speculatively? This is the early-warning light for the knowledge-graveyard failure: when supply outruns demand, the Warehouse has stopped being pulled and started being filled.
• Expected-result hit rate. Of the settled bets, how many met the result recorded at Selection? This is the outcome roll-up the others cannot supply - the machine can turn perfectly while moving nothing. Gaming path: sandbagged expectations - inspect bet ambition alongside the rate.
• Owner load. Blocks × review cadence per Context Owner - the supply chain’s most likely constraint. Gaming path: quietly lengthening cadences; watch staleness-found for the consequence.

When the indicators say context has stopped being a use case’s constraint - the exit test run in steady state confirms it - the constraint has moved, usually to review capacity, integration, or governance throughput. Follow it. This framework manages context; it does not claim context stays the bottleneck forever, and pretending otherwise is how frameworks outlive their usefulness.

A leader reading these indicators can answer “is this working?” without asking a vendor - and a bad number points at the specific mechanism to inspect rather than at morale. The worked example below already exhibits two of them in production: staleness found at review (vague definitions caught by scoring and re-certified) and the pull ratio (a taxonomy that grew from 140 tags to 156 on demand while shedding two categories nobody needed).

The System on One Page

Kendall Accountabilities

The Kendall Framework defines accountabilities. Each may be fulfilled by one person or many, provided leadership and responsibility are clear. These are accountabilities, not job titles. (NKD Agility operating layer:) they exist because agency is the precondition for all of them: without agency, accountability is a lie - you cannot be accountable for what you have no authority to influence. Every accountability below must carry the authority to act on what it owns.

Kendall Framework Accountabilities

• Problem Owner - Owns the problem statement and the definition of “solved”. Keeps stakeholder needs and outcome measures clear, coordinates the context work inside their problem domain, and orders that work by problem urgency rather than technical interest. At Review, they judge the result (NKD Agility operating layer - see the bet-and-verdict discipline below): whether the operating number moved as the bet at Selection said it would.
• Context Owner - Puts their name against a specific Context Block. Every block an AI use case depends on needs one; they keep it accurate, current, and honest about where it applies and where it does not.
• Context Curator - Facilitates Context 360 Sprints. The Curator’s craft is drawing out what experts know but have never written down - the variation, the exceptions, the unwritten norms - and shaping it into candidate Context Blocks for owners to certify.
• Context Controller - Runs the Context Warehouse day to day: versioning, publishing, and conflict resolution, with traceability of where each block came from, what changed, and what depends on it.
• Context Leader - Sets context standards and strategy across the programme, keeps problem domains coherent with each other, spots cross-domain patterns worth reusing, and escalates systemic context problems to leadership.
• SPOC - The single point of contact for a given AI use case, where one is needed.

If any of these accountabilities is unfilled for a use case, that use case is not ready to scale.

A note on how these accountabilities operate (NKD Agility operating layer): they name who answers for an outcome, not who must be asked before acting. Standards set by the Context Leader exist to enable local decisions, not to route them through a central queue - the moment certifying a block or updating an AI BoM waits on a committee, the framework has recreated the bottleneck it was built to remove. Leadership here is exercised at the point of need by whoever holds the accountability, and escalation is for systemic conflicts, not routine work.

NKD Agility Extensions

(These accountabilities extend the Kendall canon with the stewardship and strategic-flow disciplines NKD Agility applies when running the framework. They are labelled as extensions and are not part of The Kendall Project’s core definition.)

• Kendall Coach - Accountable for helping the organisation understand and apply the framework. They mentor the other accountabilities, ensure consistency, promote discipline in defining and refining opportunities and context, challenge rigid patterns that inhibit learning, surface systemic constraints and impediments to flow, and cultivate feedback loops for organisational learning. They do not manage day-to-day AI work; they steward coherence and learning across teams.
• Opportunity Owner - Drives disciplined use of the Opportunity Backlog as a tool for strategic clarity and adaptive alignment. A single Opportunity Owner is accountable for each Opportunity Backlog, ensuring clear ownership and ordering of priorities. They maintain rhythm around review cycles, help interpret learning, connect strategic direction to measurable initiatives, and own the Roadmap. On the Problem Owner’s evidence they issue the Review verdict - continue, adapt, or abandon - as the investment decision it is.

Events

Opportunity & Context Sourcing Event

(NKD Agility operating layer. The name follows Kendall’s Phase 3, “AI Opportunity & Context Sourcing”; the event design here is ours.)

This event aligns leaders and teams on the most effective problems to solve with AI. It functions as a feedback loop in the framework, closing the gap between strategy, evidence, and adaptation. It emphasises clarity, discovery, and evidence-informed prioritisation. By surfacing demand signals, this event enables pull-based context flow and ensures context development remains aligned with actual needs.

Outcomes include:

• Alignment with objectives and context
• A prioritised set of validated problems
• Clear direction for an AI roadmap
• Evidence review of outcomes against intent
• Learning orientation, treating surprises as signals for adaptation
• Identification of demand signals that trigger context creation or refinement
• Feedback loops into the Opportunity Backlog, Context Warehouse, and Roadmap

The Kendall Coach and Opportunity Owner co-facilitate to ensure balance and discipline. Held on a regular cadence (quarterly or half-yearly), it inspects and adapts objectives based on evidence and rebalances flow of priorities.

Context 360 Sprint

The Context 360 Sprint is Kendall’s structured discovery method - the mechanism that turns the principles above into captured, certified context. Facilitated by a Context Curator, it puts the people who actually run the work in one room and takes them through a fast, disciplined sequence: name the problems worth solving, map the roles involved, and surface the rules, policies, workflows, exceptions, and constraints that govern daily operations - including the ones nobody has ever written down, which are often the ones that matter most.

What comes out is not a workshop report. It is working inventory: a shared picture of how the work actually runs, and a structured AI Bill of Materials for each candidate use case, its Context Blocks certified by named owners and stored in the Context Warehouse. That inventory is the foundation Context Operations builds on. A use case that has been through a Context 360 Sprint carries its evidence with it - the problems, roles, rules, and exceptions it depends on are written down, owned, and inspectable. Discovery done another way can produce the same asset; discovery skipped produces deployment on assumptions.

Outcomes include:

• A prioritised list of validated problems worth addressing with AI
• A shared operational picture across roles and functions
• Policies, rules, boundaries, and exceptions articulated as certified Context Blocks
• An AI Bill of Materials per candidate use case, ready for Context Operations
• Confidence that any AI solution will be embedded in real organisational reality

The Sprint is also the framework’s brake on premature agent-building: it forces the organisation to understand the environment an AI must operate in before anything is built to operate in it.

Artifacts

Opportunity Backlog

(NKD Agility operating layer, incorporating the Kendall validated-problem lifecycle.)

The Opportunity Backlog is an ordered list of validated problems - each owned, reproduced, and costed before it earned its place. Kendall’s canon calls the underlying artifact the problem backlog; the Opportunity Backlog is this guide’s extension of it, maintained by the Opportunity Owner to ensure relevance and clarity. It provides visibility, supports prioritisation, and informs where to apply AI. Entries move through five stages:

1. Intake - no owner, no entry: the problem arrives with a name against it, a description in the numbers the operation runs on, and the evidence that it is real
2. Validation - the problem has to happen more than once and cost something measurable before it counts
3. Ranking - the queue is ordered by what the gap costs the operation, never by how interesting the solution would be to build
4. Selection - only now does technology enter: a tool is chosen to fit the problem, and the rules it must obey are named in the same breath
5. Review - the steering rhythm inspects the backlog and its verdicts; nobody demos tools

Two disciplines sharpen the lifecycle (NKD Agility operating layer):

• Sense-making before analysis. At Validation, decide what kind of problem this is. A complicated problem yields to analysis - experts can specify the solution before building it. A complex one does not: cause and effect only become visible in hindsight, so it must be probed with small, safe-to-fail experiments before the organisation commits real budget to it. Running a complex problem through a complicated-problem process produces confident plans and surprised executives, in that order. A probe is not a small pilot: it states the signal it expects to see (a hypothesis), the boundary that makes failure safe (limited users, reversible outputs, capped spend), and the date or condition at which it stops. Each outcome has a next step - a confirmed signal is amplified into Selection; a failed one is dampened: recorded, stopped, and kept from quiet resurrection. Two registers run through this framework - control (owned, certified, audited) and complexity (probe, sense, adapt) - and under pressure they pull opposite ways: control hardens, probing softens. The sense-making step above is the mediator: match the register to the domain, and when in doubt, probe before you govern.

• Every selection is a bet with a settlement date. At Selection, record the result you expect and the date you will check. The bet is only as honest as its measure: record the baseline, the outcome measure and the system boundary it is measured at (end-to-end flow, not local task speed), and one counter-measure that would reveal the improvement being paid for elsewhere - review effort, rework, queue growth downstream. An expected result that cannot fail is not a bet, and Review should say so. At Review, one of three verdicts is returned: continue, adapt, or abandon. Abandonment is a result, not a failure - a portfolio that can only add use cases decays into one nobody can afford to inspect. If the organisation would not start this use case today knowing what it now knows, stopping it is the evidence-based decision.

The verdict has two owners. The Problem Owner judges the result - did the operating number move as the bet said it would? That is a question of evidence, and it belongs to the person who owns what “solved” looks like. The Opportunity Owner issues the verdict - continue, adapt, or abandon is an investment decision about where the next unit of budget and attention goes, and it belongs to the accountability that owns the backlog and the Roadmap. The steering cadence inspects verdicts; it does not make them.

Context Warehouse

The Context Warehouse is where certified Context Blocks live: stored, versioned, and governed in one place so they can be trusted and reused. The Context Controller maintains it - preventing duplication, resolving conflicts, and preserving the traceability that makes context auditable across its lifecycle. Following lean principles (NKD Agility operating layer), the Warehouse grows in response to demand rather than speculation: context is pulled in as use cases need it, keeping the flow efficient and the content current. A governed central store inside a pull-based system is a deliberate trade-off, not an oversight: consistency, deduplication, and traceability need one place; pull is what keeps that place from becoming inventory.

One caution belongs here (NKD Agility operating layer): a Context Block describes the work as it was understood on the day it was written, and the work keeps moving. Certification is therefore a verification act, not a signature - at each review the owner checks the block against the work as it is actually done, where it is done, not against memory or the process manual. A warehouse of confidently stale blocks is more dangerous than an empty one, because everything built on it inherits the drift silently.

AI Bill of Materials

The AI Bill of Materials (AI BoM) is the declared inventory of everything one AI use case depends on: its Context Blocks, data sources, documents, owners, access boundaries, and review cadence - a parts list that also records who owns each part and where it came from. Its value is control: when output quality drops, the team opens the assembly instead of interrogating the model.

Roadmap

The Roadmap is a high-level view of prioritised AI initiatives derived from the Opportunity Backlog. It communicates intent, sequence, and focus areas without prescribing detailed implementation. The Opportunity Owner owns the Roadmap, ensuring it reflects priorities and remains evidence-based and adaptive.

A Worked Example: Tagging the Estate

(NKD Agility operating layer. This example is our own - the NKD Agility content estate run through the framework described above - and the evidence trail is public: the engineering notes “How I Used Generative AI to Transform Site Tagging and Categories” and “Leveraging AI Embeddings for Related Content Classification” (both 2025, nkdagility.com) document the work as it happened, and the estate itself carries the current numbers. One honesty note before the mapping: this work was done in 2025, before this guide’s articulation of the framework, and is presented as a retrospective mapping - evidence that the framework names a shape that already worked, not a log of the framework operating in real time. Where the mapping adds structure the notes do not show, such as a stated hypothesis or a settlement date, that structure is reconstruction, and we say so. A second honesty note: on this estate every accountability is held by the same person, so the example evidences the mechanisms - blocks, bets, enforcement, verdicts - not the multi-party coordination the framework exists to govern; that evidence arrives with the first delivered engagements. We use ourselves because the evidence is verifiable - the notes are public and the estate is live. It is also the shape we take into client engagements: the Context 360 Sprint is, at this writing, a new line for us, and as delivered engagements produce real facilitator-days and owner-hours we will publish the ranges here.)

The problem, as first stated: “We should use AI to tag our content.” A purchase in search of a justification, not a problem - it would have failed Intake.

Restated as a validated problem: Readers experience inconsistent discovery - related content missing, categories contradicting tags - because a corpus begun in 2006 and grown past 800 posts carried over 1,000 tags and 200 categories accumulated across 19 years of shifting focus, which made discoverability a nightmare and buried the content a reader needed next. Owner: named. Evidence: the same topic tagged several different ways across the corpus. The customer outcome: the next article a reader needs actually surfaces.

Sense-making: mostly complicated - taxonomy design yields to expert analysis, and it came first: a human certification pass took 1,000+ tags down to about 140 and 200 categories down to 12, each survivor earning a definition and an intent. One corner was complex: could AI assignment against that taxonomy be trusted on published content? That corner got probes.

The probes: the first stated its hypothesis - give the model the full list of certified tags and categories in one prompt and it will choose correctly - inside a safe boundary: a JSON cache layer, no content touched, every result inspectable. It failed; the output was junk. The probe was dampened: recorded, stopped, and not quietly retried at larger scale. The second embedded the certification itself - each tag and category carrying its own instructions - and scored every proposed assignment. The signal confirmed, and the approach was amplified into Selection.

The context, assembled. What the AI needed was not more content but rules and language:

• Glossary Context Blocks - the certified taxonomy: each tag and category with its definition, intent, and instructions for when it applies. The pruning argument was the defect we had been shipping for years.
• Rule Context Block - what an assignment must never do: leave the certified list, or pass unscored. Every proposed classification is scored 0-100 across six dimensions (mentions, alignment, depth, intent, audience, signal) with penalties, and low scores are rejected by the pipeline - the rule lives outside the model.
• Role Context Block - who the classification serves: the reader mid-journey, not the archivist.

Here are three of those artifacts as they exist in production, abridged:

Exhibit - a Glossary Context Block (one of the 156 certified tags, abridged and re-tabulated from the estate’s tag page):

Exhibit - the Role Context Block the classification acts for:

Exhibit - the Rule Context Block, enforced by the pipeline:

Exhibit - the assembled prompt (abridged), which is where the AI BoM stops being a diagram and becomes an input:

You classify content for the NKD Agility estate on behalf of a reader mid-way through their journey. Use only the certified taxonomy provided. For each candidate classification, score Mentions, Alignment, Depth, Intent, Audience, and Signal from 0-10, apply the stated penalties, and return a structured record with your reasoning.

Certified tag - Adaptive Operating Model: an operating model designed for environments of uncertainty, complexity, and continuous change… (and so on, one entry per certified term in scope)

Do not assign any term not listed. Assignments below the threshold will be rejected by the pipeline regardless of your confidence.

Notice what the prompt is and is not: it is the assembly - role, rules, and glossary composed for one use case - but it is not the enforcement. The certified list, the scores, and the rejection threshold are checked again by the pipeline after the model responds. Rules live outside the model, exactly as Principle 5 requires.

The AI BoM for the use case:

The bet, partly settled: baseline - 1,000+ uncertified tags, 200 categories, discovery failing. What the evidence settles: certified-taxonomy coverage across the corpus, scored and enforced by the pipeline - an output, in this guide’s own terms. What remains open: the reader outcome the problem statement named - does the next article a reader needs actually surface? The engineering notes are honest that this “remains to be seen”, and no pre-change reader baseline was captured, so the outcome half of the bet cannot yet be settled at the estate boundary. Counter-measure - human review effort per batch, watched so consistency was not being bought with unsustainable checking.

The verdict: adapt, then continue - issued, we should be clear, on the settled coverage evidence and the operating experience of the pipeline, with the reader-outcome measure still open. A Review that can name which half of its bet is settled and which is not is the discipline working; a Review that silently swaps an output for an outcome is the failure this guide exists to prevent. The junked first probe forced the instruction-embedded design; early scoring exposed definitions that were still vague, so blocks were re-certified and re-run. That is the system working - each failure was inspectable because the assembly said exactly which block to fix. The pipeline now runs as standing Context Operations: as of mid-2026 the estate holds over 1,800 content items - more than 1,700 of them published resources - governed by 156 certified tags and 10 categories, and classifications regenerate whenever content or taxonomy changes. The taxonomy’s own drift since certification (roughly 140 tags to 156, 12 categories to 10) is pull-based flow doing its job: tags earned their place as demand appeared, and categories that carried no weight were retired. Note the order honestly, though: the original pruning was a seeding batch, not pull - a thousand tags were certified down before any use case demanded them. Some domains need that initial pass before pull can operate; the discipline is that the batch happens once, and demand governs everything after it. Nothing in it was done once.

A Counterexample: A Bet That Should Die

(NKD Agility operating layer. This one is a marked hypothetical - no such use case has run. We publish it anyway, because a framework that only exhibits its successes is exhibiting survivorship, and because the verdict system’s credibility rests on abandon actually being usable.)

Picture the estate’s next candidate: “use AI to recommend a personalised course to every reader.” It passes Intake - a named owner, an operating-terms cost (readers leave resource pages without ever seeing the course that would help them). At Validation it is judged complex: nobody can specify in advance why a reader converts, so it earns a probe, not a project. The probe states its terms: hypothesis - recommendations assembled from the certified classifications will lift click-through on one bounded section; boundary - one section, reversible, capped spend; stop - four weeks.

The probe returns noise. No lift the counter-measure can’t explain away, and review effort higher than expected - editors quietly re-checking every recommendation, which is the “more work than it removes” signal from Choosing Tasks for AI. The verdict is abandon: recorded with its evidence, its blocks returned to the Warehouse for the use cases that do demand them, and the idea kept from quiet resurrection until something material changes.

Nothing was wasted except the probe’s cap - compare that with making the same discovery six months after a platform purchase. The abandon rate just went above zero, honestly. That is not the framework failing; that is the framework doing the exact job it was bought for.

Terminology

Kendall Framework, Context Block, Context Warehouse, Context Operations, AI Bill of Materials, and Context 360 Sprints are marks of The Kendall Project; the definitions below are this guide’s own restatement.

Summary

The Kendall Framework is a structured, data-driven framework for AI adoption. It is principled, concise, and evidence-based. By applying it, organisations:

• Align on purpose, context, and objectives
• Break through the Accuracy Ceiling by closing the Context Gap deliberately
• Establish clear accountability - with real agency - through the Kendall accountabilities
• Prioritise validated problems through the Opportunity Backlog
• Capture knowledge as certified Context Blocks, governed in the Context Warehouse, and assembled per use case into AI Bills of Materials
• Pull context at the rate of demand, ensuring lean flow and preventing waste
• Govern AI decisions structurally: independent validation, deterministic gates, audit logs, and a human at the decision boundary
• Close the loop on every deployed use case: the Problem Owner judges the observed result against the expected one, and the Opportunity Owner decides continue, adapt, or abandon as the investment verdict it is
• Create and adapt a Roadmap led by the Opportunity Owner
• Inspect and adapt through Opportunity & Context Sourcing Events
• Rely on the Kendall Coach to uphold principles, expose constraints, and enable organisational learning

Combined with the delivery, engineering, and governance disciplines it expects alongside it, the result is AI adoption that is purposeful, trustworthy, adaptive, flow-oriented, and aligned with mission and value creation - a system of work in which humans govern, AI serves, and context is the operational asset that connects them.