Knowledge is endorsed, not retrieved

Support tells a user: "The system knows you're allergic to cashews." Engineering checks the logs. Cashew appeared once in a chat six months ago, never approved, never enforced in code. The user experience said knows. The architecture had retrieval.

That gap is how trust breaks quietly. Knowledge in Thoughtware is durable fact approved for use, with provenance, scope, and falsifiability. It is not everything the model retrieved, not everything the user once typed, and not everything that sounded plausible in context.

This page is the canonical home for endorsed knowledge versus context and chat. Memory as architecture covers storage forms. Endorsement logic lives here.

Helpful context: Meaning, knowledge, and authority introduces knowledge in the triad. Grounded verbs maps "knows" to this page. Authority is granted covers permission to treat facts as durable.

Three materials people collapse

Teams often treat context, endorsed knowledge, and chat retrieval as one blob labeled "memory." Architecture keeps them separate because each material has different lifetime, governance, and failure modes.

Material	Example	Lifetime	How it enters
Context	Tuesday is busy this week	This run	User request, calendar
Endorsed knowledge	Leena has confirmed cashew allergy	Durable until revoked	Approval path plus enforcement
Chat or retrieval	Cashew mentioned in old thread	Uncertain	Not knowledge until endorsed

"Avoid pasta because we had it recently" is context for this run. It must not silently become durable dislike without household approval. "Busy evenings stay under twenty-five minutes" started as preference, stabilized through use, was endorsed, and now enforces as knowledge in planning checks.

Retrieval alone does not create knowledge.

Introduction to Thoughtware · Ch. 23

Without endorsement, allergies live in prompts where fluency can override them. Temporary instructions harden into policy overnight. Users cannot contest what the system knows because nothing inspectable records belief. Least trustworthy input wins when retrieval mixes with endorsed facts in one undifferentiated stream. With endorsement, hard rules move to deterministic code after approval. Knowledge changes become visible events, not drift. Product copy using "knows" matches inspectable stores. Support can answer the cashew question by pointing to approver, date, and scope rather than by searching chat logs.

Endorsement feels slow compared to retrieval. Product pressure says ship now, govern later. The Meal Companion pattern shows the cost: allergies in prompts, temporary pasta avoidance becoming policy, users unable to say what the system actually believes. Endorsement is the mechanism that makes "knows" a truthful verb and hard rules enforceable in code.

Endorsement is authority

Endorsing knowledge is granting authority to treat a fact as durable and actionable. It connects directly to authority is granted. Proposal queues, approval UI, and audit on merge are not bureaucracy ornaments. They are how organisations bear responsibility for beliefs the system will enforce. A clinician endorsement differs from a household checkbox differs from an admin policy upload. Each path is explicit.

When the Meal Companion proposes that a first mention of cashew allergy become endorsed knowledge, the household confirms scope: which member, which severity, which enforcement level. Only then does deterministic allergy checking activate against that record. That confirmation step is what separates governed knowledge from accumulated chat.

Retrieval is faster to demo, and long context windows invite teams to treat chat as a database. RAG pipelines invite teams to present hits as facts without provenance. Each shortcut trades short-term velocity for long-term trust debt. The debt shows up when fluency performs knowing without enforcement, when users discover silent promotion, when auditors ask for evidence and receive prompt descriptions. Architecture makes endorsement the default path for safety-critical and policy-critical facts while keeping context lightweight for this-run interpretation.

What this looks like in the Meal Companion

The endorsed path works as follows: the household confirms cashew allergy through structured intake. The record enters the knowledge store with approver, date, and scope for household member Leena. Allergy check runs in the deterministic shell before plan display. Support's answer matches architecture.

The retrieval failure path is different: the model reads old chat, mentions cashew avoidance in narrative, skips code enforcement. Plan includes cashew garnish. Fluency performed knowing without knowledge. The promotion failure is subtler: three weeks of "avoid pasta" chat entries silently bias generation. No approval event. The user never agreed to a permanent rule. Memory discipline in conduct blocks promotion and offers propose-and-approve instead.

Correct contextual use shows the distinction clearly. "Tuesday is busy this week" lives in working state for the run, shapes AssessMealPracticality, expires when the week ends, and never writes durable policy without grant.

The most frequent mistakes follow predictable patterns. Chat as database turns "Tuesday busy this week" into "every Tuesday forever" in model bias. Single-click "remember this" without scope leaves users unable to tell what was endorsed, for whom, or until when. Retrieval augmentation without provenance presents RAG hits as facts with no link to source or approval state. Silent merge on confidence lets the model decide two statements refer to the same preference and promotes without event. Product copy ahead of stores says "the system knows your team" while engineering knows retrieval happened once.

Provenance and the memory boundary

Endorsement without provenance still breaks contestability. Users see source, approver, and date for durable facts that drive enforcement. Support staff answer "knows" questions by opening the same view. Provenance also protects engineers during incidents: when a plan violates a cashew constraint, the postmortem asks whether allergy knowledge was endorsed or retrieved. Without provenance fields, the team debates prompts instead of stores.

RAG pipelines attach retrieval hits as candidates, never as enforced rows. Candidate review is a human or workflow step with audit, not an embedding similarity threshold alone. When two departments share one assistant, scope rows by role and data domain. Shared capability without scoped grants produces cross-tenant trust failures that fluency hides until audit.

Memory as architecture defines stores and six forms. This page owns the endorsement boundary between context and durable belief. Preference store versus chat memory covers UX placement, because users see what is endorsed versus what is conversational residue, and conduct never treats the two identically even when the UI sits in one panel.

Endorsement is slower than chat accumulation and that slowness is intentional. Households see pending knowledge as proposals with scope, not as silent writes from transcript mining. Operations teams measure time-to-endorsement for critical facts, where long queues signal missing UX or unclear ownership, not patient governance. Revocation paths matter as much as promotion: endorsed allergy lists need edit and remove surfaces households can find without support tickets. Treating endorsement events as product analytics signals, such as promotion and revocation counts, reveals whether households feel in control of durable belief.

What to do next

The first step is identifying one safety-critical fact in the domain and tracing how it enters the system today. If the path is retrieval or prompt, endorsement plus enforcement is the design change needed before the next feature ships on top of it. Inventorying facts the product treats as true, labeling each as endorsed with approver and scope or as retrieved with risk label, makes the trust debt visible.

See grounded verbs, memory discipline in conduct, and memory as architecture.

Read next: Refuse and defer.