Knowledge must be usable beyond its source
A strategy can make perfect sense in the room where it was written and still be almost useless everywhere else.
The people in that room remember the discussion, the rejected alternatives and the difficult trade-offs. Much of that knowledge never reaches the final document. An objective travels to a team carrying only a small part of the reasoning behind it.
I have seen teams given objective statements that everyone can agree with, such as increase customer satisfaction in the mobile channel. Yet there is too little background to decide where experimentation should begin. The team may not know why the objective was chosen or what evidence led to it.
There are plenty of plausible things to try. The difficulty is knowing how those ideas connect to the reason the objective exists.
In the previous post, I argued that alignment needs bounded ownership. Teams need authority to make local decisions, with clear limits on what they can decide. That arrangement also places a responsibility on anyone publishing knowledge those teams depend on. The source needs to explain enough of its thinking for others to act.
When that explanation is missing, each team pays the cost of reconstructing it. The source can remain unchanged while different interpretations spread through the organisation.
Ownership includes publication
An objective can remain a short sentence. Its background needs to be available alongside it: why it was chosen, how it relates to strategy and what constraints apply. The source should also make clear which questions it expects the team to investigate.
This has familiar foundations. Marty Cagan describes strategic context as essential to team objectives, while leaving teams room to determine solutions. In data architecture, Zhamak Dehghani's data mesh principles make domain owners responsible for providing data that consumers can understand and use.
I think the same expectation should apply to the knowledge an organisation uses to direct work. A strategy or metric has consumers just as an API does. Its owner needs to understand what those consumers depend on.
Different kinds of knowledge require different explanations. A metric needs a calculation and a defined population. A decision needs its rationale, scope and status. An objective needs its intended outcome and the reasoning that makes it worth pursuing. Across all of these, consumers need to know the source, the owner and which parts remain assumptions.
These are the knowledge contracts I have in mind. They describe what another context can rely on. The material can stay in the tools where it is maintained, with links to related decisions and evidence.
Once another context is expected to act on a decision, publication is part of completing that decision. This includes being explicit about what remains unknown and who is responsible for finding out.
Give the team enough to begin
Consider an illustrative continuation of the mobile satisfaction example. The details that follow are hypothetical.
The team has the objective and a strategy document that discusses retaining existing customers. Neither explains why mobile satisfaction was selected as a priority. There is no agreed satisfaction baseline for the purchase journey either.
The team could investigate failed payments, simplify navigation or propose a discount campaign. Before choosing, it asks AI to review the published material and identify which assumptions those options would require.
A useful review would flag that the link between retention and satisfaction has not been explained. It would also identify the missing baseline and the absence of any stated authority to change prices. These gaps need different responses.
The objective's owner needs to explain the strategic reasoning. The team can investigate customer behaviour and establish a baseline. A discount proposal requires a conversation with whoever owns pricing.
Suppose the objective's owner clarifies the intent:
We chose this objective because we want existing customers to keep using the mobile channel for purchases. We suspect frustration in the purchase journey is a barrier, but have not established the main causes. The team should investigate those causes and choose experiments within the mobile experience. Changes to pricing or shared payment rules need agreement with their owners.
The explanation is added to the published objective, together with a reference to the relevant strategy decision. The suspected connection between frustration and retention remains an assumption.
The team now has a basis for deciding what to do first. It could examine failed purchase attempts and speak with affected customers to understand whether reliability is a significant source of frustration. Establishing how to measure that experience may be part of the same investigation. The evidence could lead it to choose an entirely different experiment.
The owner has supplied the reasoning and boundaries. The team still owns discovery. It does not need permission for every hypothesis it forms within those boundaries.
Requiring leadership to diagnose the problem and supply every measure before a team can start would undermine that autonomy. An objective can be ready to act on while important evidence is missing, provided the team understands what it is being asked to learn.
Put the review to work
The example describes a practice I would like to try. Research on LLM-assisted ambiguity detection in industrial requirements supports investigating this kind of assistance, but it does not establish that AI can judge the usefulness of an organisational strategy.
Before publication, I would ask it to review knowledge from the perspective of the decisions another team needs to make. Which conclusions are supported by the material? Where would a consumer have to supply an assumption? Does a missing answer belong to the publisher, or is finding it part of the team's work?
The owner would use those questions to improve the publication. Agreed expectations for that kind of knowledge would guide the review. The model's approval would carry no authority of its own.
I would judge the review by whether it exposes gaps that affect decisions. Generating questions is easy; answering them takes people's time. A review that repeatedly asks for information irrelevant to the team's choices creates work without improving alignment.
It will also miss things. Some ambiguity only becomes apparent when someone tries to use the knowledge. Publication needs a way to accept those later questions.
Keep interpretation connected to its source
Once the knowledge is published, AI could assemble a view for a particular task. The mobile team might ask which objectives, research findings and payment constraints apply to its investigation. This could save it from searching several systems and piecing together the relationships itself.
The assembled view needs to retain the source and status of each important claim. An approved objective, a preliminary finding and the model's interpretation carry different weight. Linking a claim to a source lets the reader inspect it; approval alone does not make the claim true.
In our example, the published objective records a suspicion that frustration affects retention. An AI summary should preserve that uncertainty. It should not report that failed payments are causing customers to leave unless there is evidence for that conclusion. The team is free to investigate that possibility as its own hypothesis.
Meaning also remains local. The Customer and Mobile contexts might legitimately define active customer differently. A report crossing that boundary needs to state which definition it uses and whether it fits the consumer's purpose. Making every context adopt the same definition would discard distinctions they may need.
A generated briefing can be replaced when its sources change. If a discussion around it produces a new decision, that decision needs to be recorded with its owner before the briefing is discarded. Otherwise, the summary becomes the only place the new reasoning survives.
Let clarification improve the shared knowledge
Resolving a question in a private conversation helps the team that asked. Updating the shared source helps the next team too. In the mobile example, another team should be able to find the explanation of why satisfaction was selected without arranging the same conversation again.
This has a precedent in Knowledge-Centered Service's practice of reviewing knowledge through reuse. People improve or flag the material they encounter as part of doing their work. Applied here, AI could help formulate a focused question, locate the accountable owner and prepare a proposed update for that owner to review.
Some questions will expose a disagreement that clearer writing cannot settle. The mobile team may want to offer compensation after failed purchases while another owner prioritises controlling those costs. Both positions can be clearly expressed. Resolving the trade-off requires the relevant owners to make a decision and be willing to revisit their priorities.
I want published knowledge to help teams distinguish the reasoning they inherit from the questions they are free to investigate. That gives AI a useful job: helping expose missing context and carry clarification back to the people responsible for it, while leaving room for local judgement.
Even then, the original reasoning may be wrong. The final post will follow what happens when teams act on it and evidence begins to challenge the strategy itself.
