Meaning, knowledge, and authority

When the Meal Companion avoids cashews, it may have done three very different things: interpreted a request made for this week, consulted a household allergy record someone previously confirmed, or acted under an explicit permission. Because those routes are different, saying that the system “knows” about cashews hides the distinction that matters.

Meaning, knowledge, and authority must remain separate because each comes from a different source, lasts for a different period, and fails in a different way. If they collapse, a system can sound careful while treating a passing remark as a permanent belief or a useful recommendation as permission to spend money.

Helpful context: Where does a decision live? gives a judgment one accountable home. Knowledge is endorsed, not retrieved develops the durable-record boundary; authority is granted develops the action boundary.

They arrive by different routes

“Tuesday and Thursday are busy” is meaning. InterpretWeek should preserve it as part of this week's request, where the household can correct it before a plan is made. It should not silently become a claim about every future Tuesday.

“Leena has a confirmed cashew allergy” is knowledge only after an explicit endorsement. That provenance gives the system grounds to enforce the allergy deterministically and gives the household a way to inspect, change, or revoke the record. A sentence retrieved from a recipe website has no equivalent standing, even if it happens to be accurate.

Authority answers a third question. The Companion may assemble a grocery cart using the endorsed allergy rule, yet still be unable to submit an order. Permission comes from the people who bear the consequence of the purchase, not from the system's ability to calculate it correctly.

The mistakes always promote

The usual error is not losing information but giving it too much standing: a request not to eat pasta next week becomes a permanent preference, a retrieved note becomes a trusted household fact, and a trusted fact becomes a licence to act. Each promotion is convenient in the moment, which is why it escapes notice.

Every promotion makes the product appear more helpful in the moment, which is why it survives a demo. But each removes a necessary point of challenge: an endorsement, a confirmation, or an approval. The later failure looks like overconfident AI, although the real failure was that the architecture accepted a claim at the wrong level.

Capability does not override legitimate governance.

Introduction to Thoughtware · Ch. 14

Different failures need different repairs

If the Companion misreads the week, the repair is to expose the interpretation and ask the smallest useful question. If it holds an unendorsed belief, the repair is provenance and an endorsement path. If it takes an ungranted action, the repair is an authority check and an approval boundary.

Prompt edits cannot substitute for any of these. A polished explanation of a mistaken plan does not reveal whether the error was interpretation, belief, or permission. Separating the categories gives an incident somewhere precise to go.

One request can contain all three

“Plan dinners for four this week. Tuesday and Thursday are busy. Use the spinach before Wednesday and avoid meals we ate last week.” The request combines temporary meaning with facts the system may need to verify. Tuesday's busyness belongs to this run unless the household separately confirms it as a recurring schedule. The spinach deadline becomes a closed check once the date and ingredient are known. “Meals we ate last week” requires an endorsed record of the prior week and an open judgment about what counts as repetition.

The architecture should preserve those distinctions rather than flatten the sentence into generic context. InterpretWeek can make the provisional reading visible. A knowledge store can provide the endorsed history with provenance. AssessMealPracticality can weigh the candidate meal against the week. The purchase boundary can wait for approval. One natural-language request may therefore touch several components without making them interchangeable.

This is also why memory should not be described as a single feature. Current conversational context, working state, endorsed household knowledge, and accumulated experience have different write rules and different consequences when wrong. Knows, remembers, learns supplies the vocabulary for keeping those forms apart.

Design for revocation, not just recall

The useful question is not merely whether a system can remember a fact. It is how that fact can stop being used. A household may change its mind about a standing preference, correct an allergy record, or narrow its approval for purchases. Each event should reach the appropriate layer directly.

That is impossible when the system has mixed all information into a prompt or a similarity index. The team may be able to find a sentence, but it cannot show what decisions relied on it, whether it was endorsed, or whether an old copy still influences later answers. Provenance and revocation sound administrative until the first correction affects health, money, or trust.

Good boundaries make the product more candid as well. It can say, “I’m using the allergy record you confirmed on 12 June,” “I took busy Tuesday from this week’s request,” or “I can prepare the cart but need approval to place it.” Those are not disclaimers. They are evidence that the product knows the difference between interpreting, knowing, and acting.

A practical design test

For every fact or action in a flow, ask: Is this a reading of the current request, an endorsed durable record, or an authorised act? Give each answer its own store, lifecycle, and enforcement point. A single “context” box holding all three is a design warning, not simplification.

Read next: Where rules stop working shows when an endorsed rule is enough and when a decision must remain open.