Loomworks — recordable facts and topic/category — investigation — v0.1

Document: loomworks-recordable-facts-and-topic-investigation-v0_1 Version: v0.1 Status: investigation — a design question surfaced in testing, not a defect and not scoped for build. Captured to inform the classifier and matcher direction. No CR implied. Date: 2026-06-28 Origin: Operator testing (E0007). Operator said "It is Sunday June 28. It is sunny." → the Companion treated it as conversation ("Good to know it's a nice day!"), recorded nothing. Later "What is the weather like today" → "You mentioned it's sunny — that's all I know." Then "remove weather information regarding today" → "I couldn't find a note matching that to remove." Operator: "I would have thought that 'sunny' would be identified as weather information."

The observation

The Companion knew "sunny" was weather — when asked "what's the weather," it answered "you mentioned it's sunny." So it connected sunny→weather in recall (the LLM reading the conversation). But "remove weather information" found nothing — because "it is sunny" was never recorded as a note, and even if it had been, the removal matcher (literal token/stem match) has no concept that sunny is weather. The Operator's expectation — that stating "it is sunny" registers as weather information that could then be recalled or removed by topic — is reasonable, and the gap it exposes is conceptual, not a single bug.

Two questions tangled together (pull them apart)

Question 1 — what counts as a recordable fact?

"It is sunny" is a stated fact about the world. The system's thesis is memory over a body that does not forget — so why wasn't it kept? Two readings:

It correctly wasn't recorded — "it is sunny" is ephemeral (true now, false tomorrow); not every stated fact is worth keeping, and transient ones (weather, "I'm tired right now") may rightly stay conversational. The system distinguishing durable from ephemeral would be a feature, not a miss.
It should have been recorded — the Operator stated a fact; the system's job is to capture facts; dropping it silently means it can't later be recalled or removed as a fact. The capture gap is the real gap, upstream of the removal.

The unsettled core: the system does not currently distinguish durable facts ("my car is on level 8", "the deadline is the 14th") from ephemeral facts ("it is sunny", "I'm in a hurry"). Should it? And if a fact is ephemeral, is the right behavior to (a) not record it, (b) record it with a freshness/expiry, or (c) record it like any other? "It is sunny" is the clean probe case for this.

Question 2 — should assertions carry a topic/category?

The recall-vs-removal asymmetry recurs here in a deeper form. Recall connected sunny↔weather semantically (LLM reads everything and focuses). Removal does literal token/stem matching — "weather" shares no word or stem with "sunny", so "remove weather" could never match a "sunny" note even if it existed. The matcher has no notion that sunny is an instance of weather.

A topic/category on assertions would let recall and removal work by subject, not just literal text: a note "it is sunny" tagged weather would be findable by "the weather", "remove weather", "what's the weather" — without the matcher needing to know the word "sunny" relates to "weather". This is the same recall/removal asymmetry seen with parking (last night's stem fix), but topic would address it at a higher level than stemming: stemming closes "parking"↔"parked"; topic would close "weather"↔"sunny" (no shared stem, only shared concept).

Open: does Loomworks want a topic/category dimension on assertions? If so — assigned by whom (the classifier at capture? the Operator?), drawn from a fixed taxonomy or free? And does it change Memory's structure, or sit as metadata?

Why this matters (it touches the thesis)

These aren't surface bugs — they're about what the system understands about what it holds. "What is a recordable fact" and "do facts have subjects" are close to the heart of an engagement-memory product. The current behavior (literal-text matching, no durable/ephemeral distinction, no topic) works for exact recall and exact removal but breaks the moment the Operator thinks in categories ("the weather", "my appointments", "where I parked") rather than exact words.

Relationship to other queued work

The matcher (removal): topic would be a higher-level answer to the recall/removal asymmetry that the stem fix addressed narrowly. Same family of problem.
Conversation search (queued): searching messages by topic vs. literal text is the same semantic-vs-literal question.
Command/settings discoverability (queued): all four (this, matcher, search, discoverability) circle "how does the system understand and surface what it holds."
The classifier: if facts get topics, the classifier (or a follow-on step) likely assigns them at capture — an extension of the Phase-1 work.

Not a fix — a direction

No CR implied. This is a design question for when the classifier/matcher/Memory-structure direction is taken up deliberately. The immediate testing behavior (sunny → conversation, "remove weather" → nothing found) is internally consistent; the question is whether that's the intended model or whether durable/ephemeral distinction + topic should change it. Settle the design before any build.

Three things to decide when this is taken up:

Does the system distinguish durable from ephemeral facts? If so, how does it treat ephemeral ones (drop / expire / record-anyway)?
Do assertions carry a topic/category? Assigned how, from what vocabulary?
If topic exists, do recall and removal both use it (closing the semantic asymmetry that stemming only narrows)?

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — recordable facts and topic/category — investigation — v0.1 — 2026-06-28 "It is sunny" exposed two unsettled questions: what counts as a recordable fact (durable vs. ephemeral), and should assertions carry a topic so recall/removal work by subject not literal word. Recall connects sunny→weather semantically; removal can't. A design direction for the classifier/matcher/Memory work, not a fix.