The difference between knowledge and operational context

Knowing a rule does not determine its application

A general rule describes what should happen under certain conditions. Applying it requires establishing whether those conditions hold. Interpretation and verification remain necessary even when the rule's text is available.

A policy may permit an action when prior approval exists. The system needs that policy, but it must also establish whether the approval applies to this case, what it covers, and whether it has been withdrawn. None of those facts follows from the document's general wording.

Knowledge can help formulate the right questions. It should not fill in facts that have not been observed. If a necessary condition is missing, a plausible answer about what usually happens does not establish it.

This changes the expectations placed on an application. An explanatory use may require only a description of the procedure and its limits. An operational use must connect that same explanation with information about the particular situation. Moving from informing to acting changes what context must provide.

It also makes insufficiency a valid result. A system that identifies the missing fact may be more useful than one that completes its answer without exposing the gap. Consulting, waiting, or handing the work to someone else can be part of the task even when they do not immediately produce a final solution.

Operational context begins when the application stops treating every question as a request for general knowledge and distinguishes the facts needed to support a specific decision.

Time is part of meaning

A fact can be correct yet no longer describe the current situation. Currency is not merely an additional attribute. In many processes it determines whether information can support a decision.

When an event occurred, when it was recorded, and when the system retrieved it are different times. A recent read does not guarantee an up-to-date source. Equally, an older document can remain the applicable rule if nothing has superseded it.

Temporal requirements depend on the work. A historical description may remain useful for years. Resource availability can change while an operation is being prepared. No single update frequency satisfies both needs equally well.

Requesting “real-time data” is therefore often incomplete. The useful questions concern which decisions require recent information, how much age is tolerable, and how the system recognizes that a source no longer meets that condition.

Concurrency adds another difficulty. Several people or systems can act on the same work. An observation valid at the start may be stale before execution. Context must account for that possibility and establish when another check is necessary.

This does not imply a perfectly simultaneous view of the entire organization. It requires understanding the limitations of available information and adjusting behavior accordingly. When a necessary condition cannot be confirmed, the system may need to narrow its response or request another verification instead of proceeding on an assumption.

Sources have different responsibilities

Two sources can describe the same subject without having the same authority. An approved policy, a working note, and an informal conversation contribute different kinds of information. Treating them as equivalent fragments can erase the distinction between a rule, a proposal, and an observation.

Provenance helps interpret that difference. Who maintains the source? What kind of information does it represent? For which decisions is it considered valid? A link to the original document is useful, but it does not replace those definitions.

Contradictions require resolution criteria. The answer should not depend solely on which passage is retrieved first or written more clearly. Resolving it may require a hierarchy of sources, a check in a system of record, or a decision from the responsible person.

That hierarchy should not become a universal ranking of documents. A policy may govern the conditions for an action while an application records whether the action has occurred. Each is authoritative about something different. Declaring one more important for every purpose would lose that distinction.

The system must also distinguish the information it processes from instructions governing its behavior. An incoming text may contain a request or an apparent instruction without having authority to change the application's mandate.

These distinctions need to exist before the model encounters a conflict. Asking it to “use the right source” does not specify how to recognize that source. Context engineering must reflect organizational decisions that can subsequently be represented and checked within the system.

Retrieval is one part of the work

Document retrieval introduces external information into the context of a query. It can supply relevant material absent from the initial interaction. Finding a pertinent passage, however, does not establish that it is sufficient to resolve the case.

Relevance concerns the relationship to the question. Operational validity adds authority, currency, permitted access, and the relationship to work state. Retrieval must be assessed in light of what the application will do with the information it finds.

Anthropic describes context engineering as selecting and maintaining the information supplied to the model, including instructions, tools, external data, and history. This places document search within a wider design rather than equating the two.

More material does not guarantee better use. Lost in the Middle found that the position of relevant information could affect performance in the models and tasks studied. That is a situated finding, not a measurement of every current model. Its relevance here is that having information and using it effectively need to be checked separately.

Testing retrieval should go beyond locating a similar sentence. It should examine whether relevant exceptions appear, whether provenance is retained, and whether the application recognizes when the retrieved material does not justify a conclusion.

This defines the scope of retrieval augmentation rather than objecting to it. It may be sufficient for certain informational uses. Once the application participates in an operation, it needs connections to the other sources and conditions that make the next step valid. A relevant passage can inform that step without establishing every fact on which it depends.

Memory needs retention criteria

Longer work accumulates messages, results, and decisions. Continuity requires retaining some of that information, but saving everything without distinguishing status can make an earlier decision appear to remain in force.

Memory should separate observed facts, hypotheses, proposals, and accepted decisions. If a summary mixes these categories, a possibility discussed at the start can return later as a firm instruction. Increasing storage capacity alone does not solve that problem.

Supersession must also be represented. A later correction should invalidate an earlier fact without removing the ability to understand what changed. Work continuity needs both a current view and a proportionate way to reconstruct relevant decisions.

Summarization can reduce the amount of information, but it introduces a transformation that deserves review. A summary may retain the broad idea while losing a decisive exception. Details that constrain an action should not depend exclusively on an abbreviated narrative when they can be maintained as explicit state.

Negative facts matter too. An authorization that does not exist, unfinished work, or an unavailable source may determine the next step. Memory concerned only with successful results would omit some of the conditions needed to proceed safely.

Retaining context does not mean retaining all information indefinitely. What is stored should be limited to its purpose and the applicable access and retention rules. Memory is a product and operational decision as well as a technical capability. Its usefulness depends on how accurately it represents the status of what it retains.

Context quality needs an owner

When a source becomes stale or a rule supports incompatible interpretations, the problem does not belong exclusively to the model. Someone must be able to determine which information prevails, correct it, and ensure the change reaches those who use it.

Responsibility can be distributed. One team maintains policy, another manages records, and another operates integrations. What matters is that the application does not inherit those boundaries as areas with no owner.

A source definition should establish what it represents, how it changes, and what happens when it becomes unavailable. That supports decisions about continuing with reduced scope, performing another check, or stopping. The response depends on the consequences of using incomplete information.

Context failures also need to be observed as a category in their own right. An incorrect answer may mean the model misused information. It may also mean the necessary fact was never supplied, or that the authoritative source contained an error. Each cause calls for a different correction.

Grouping all these situations under “the model was wrong” can lead a team to adjust instructions without addressing the cause. Attributing everything to data can conceal a real interpretation problem. Review needs to reconstruct what information was available and what it meant at the time.

Ownership includes communicating changes. Updating a policy in its source document does not establish that every copy, index, or summary contains the new version. The system needs a way to recognize when a derived representation requires updating.

Context should also be assessed from the recipient's perspective. A person may need to consult the source, check a date, or understand why the work stopped. Providing those signals supports review without turning every interaction into an investigation of the application's internals.

Operational context is a maintained representation of a situation. It need not be exhaustive to be useful. It must contain what the decision requires, express what cannot be guaranteed, and preserve a verifiable relationship with the sources supporting it.

That relationship must remain understandable when sources change, not only when the application is first assembled.