The sentence that changes meaning

Imagine an AI assistant helping prepare a supplier-onboarding review. A specialist writes, “The documentation is complete for an initial assessment.” A summary reaches the next team as “Documentation complete.” A later workflow treats that status as permission to proceed.

This is an illustrative example, not an account of an employer’s process. The point is how easily the purpose of a statement can disappear. The words became shorter. The implied authority became broader.

For enterprise AI, I would treat context as maintained operating information. It needs an owner, a defined use, and an explicit path across handoffs. A collection of accessible documents is a starting point. Leaders also need to decide what those documents are allowed to mean in a particular decision.

Keep facts, rules, and judgments distinguishable

Different kinds of context deserve different treatment. A fact describes an observed state, such as a document being received. A rule establishes a requirement, such as which documents are needed for a particular assessment. A judgment interprets the situation, such as whether the submitted evidence is adequate.

All three may appear in the same conversation. Combining them into an undifferentiated summary makes it harder to see which statement needs updating and who can update it. A new document may change the facts without changing the rule. A different use case may require a new judgment even when the underlying facts remain the same.

For decision-critical information, preserve its type, source, applicable scope, and current status. That does not require displaying every field to every person. It requires keeping enough structure that the next decision can distinguish evidence from interpretation and interpretation from authorization.

Assign ownership where meaning can change

A technical owner can keep a source available. A business owner needs the authority to say whether its meaning and use remain appropriate. Sometimes one person can do both; often the responsibilities need to be connected explicitly.

Start with the sources that can change a consequential decision. For each, answer four questions.

  • Who can approve a correction, replacement, or retirement?
  • What decisions and circumstances is this source intended to support?
  • What event should trigger review of its validity?
  • How will people and systems using it learn that it changed?

Make the receiving side responsible, too

A good handoff describes both what the sender provides and what the receiver must verify. The sender should preserve the proposed next step, its evidence, unresolved questions, and the limits of any authorization. The receiver should confirm that those limits fit the action it is about to take.

In the onboarding example, the next team needs to know that “complete” applies to an initial assessment. It also needs a way to reject the handoff if its own stage requires different evidence. Otherwise, a reasonable upstream statement becomes a misleading downstream instruction.

I would make rejection a normal workflow state, with a reason and an owner, rather than an informal failure. A receiver might return the task because the scope is unclear, the source has changed, or a required judgment is missing. Each reason suggests a different correction. Routing everything back as “AI error” throws away that diagnostic value.

Let exceptions remain exceptions

Local knowledge can be valuable precisely because it describes unusual conditions. The challenge is preserving those conditions when the knowledge is reused.

An exception should carry its rationale, scope, decision owner, and review or expiry condition. If it applies only to one supplier, one assessment stage, or one temporary constraint, retain that boundary in the reusable record. Do not let repetition alone turn a workaround into a general rule.

This creates a real maintenance burden. Capturing every conversation in full can expose unnecessary information and make relevant distinctions harder to find. The design choice is to preserve the minimum context needed for the next decision, with appropriate access, rather than copying everything everywhere.

Close the correction loop

When someone corrects an AI-assisted interpretation, ask whether the correction belongs to this case or to the shared source. A case-specific judgment should not automatically rewrite general policy. A recurring source error should not require every future reviewer to rediscover it.

Create a route from the correction to the accountable owner. Make it possible to see whether the source was updated, whether dependent work needs review, and whether unresolved cases remain. Budget that work as part of operating the system.

A practical first exercise is to follow one important phrase, such as “approved” or “complete,” through three handoffs. At each transition, ask what the receiver believes it permits. Where the meaning expands, there is a design decision waiting to be made.

Preserve the meaning and limits of context, not just its words, when work moves to the next person or system.
Perspective and proposed operating practices. Scenarios are illustrative, not employer or client case studies. Views are my own.

Sources & intellectual foundations

  1. [1] Related reading: NIST AI Risk Management Framework NIST frames AI risk management as involving perspectives and actors across the AI lifecycle. The context-ownership and handoff practices here are proposed operating practices, not a validated framework or an account of a company implementation.