MEMORY_INTAKE_AND_AT_USE_DISCIPLINES_PROPOSAL_V1.md
Current Specs/Miscellaneous Specs/MEMORY_INTAKE_AND_AT_USE_DISCIPLINES_PROPOSAL_V1.md
ELNOR REPO READER TEXT MIRROR
Original path: Current Specs/Miscellaneous Specs/MEMORY_INTAKE_AND_AT_USE_DISCIPLINES_PROPOSAL_V1.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z
---
# Memory Intake and At-Use Disciplines — Cross-Doc Proposal V1
**Type:** Cross-cutting addendum proposal (adds new specs to multiple owner docs; does not integrate existing specs into each other)
**Date:** 2026-04-26
**Status:** Proposal — not yet integrated into any spec
**Affects (target docs requiring amendment):** DOC72 R5.72+, DOC24 R2.5+, DOC1, DOC73 V1.4+
**Author:** Claude Opus 4.7 (proposal); Will (architect, reviewer)
**Folder:** Main `Addenda Proposals & In Progress/` (not Cross-Doc — this proposal *adds* spec to multiple owner docs rather than integrating existing specs together)
---
## 0. Reading guide
This proposal addresses two structurally distinct failure modes in ELNOR's memory system that the 75/25 incident surfaced:
- **Intake-side:** the extraction pipeline strips epistemic register (speech-act type, original verbatim, utterance context) from user utterances, collapsing diverse speech acts into flat declarative propositions. Once collapsed, the information cannot be recovered.
- **At-use-side:** when a stored memory is retrieved into a reasoning chain, the system has no structured discipline for distinguishing "the user mentioned this once casually" from "the user has a load-bearing standing position." Both surface as premises with comparable weight.
The proposal also formalizes a third, related discipline: **cross-context retrieval as a labeled feature**. Cross-context relevance is one of ELNOR's highest-value behaviors — applying a reasoning pattern from one domain or matter to another is exactly what a personal AI agent should do well. The failure mode is not cross-context retrieval; it is *unlabeled* cross-context retrieval, where a memory acquires premise-grade weight in a chain it was never anchored to. The fix is to label, not gate.
The proposal is domain-agnostic by construction (per DOC73 P7 and the carryover §0 architecture-vs-domain separation). All schemas use abstract primitives with per-domain instantiation flowing through DomainSignalProfile. Examples are cross-domain illustration sets where used.
---
## 1. Origin and motivating evidence
The proposal originates in a conversation about whether to run a DOC24↔DOC73 seam audit. During that conversation, the reviewing system (Claude Opus 4.7, working from a memory summary generated by an upstream pipeline) cited a "75% hobby / 25% practical utility" framing as a load-bearing premise in arguments about audit timing and review investment. The user's response: "That memory was old, I don't remember it. It's not relevant really. It was a casual statement by me, not meant to be binding or inflexible or acted upon."
The failure decomposed into three layers:
1. **At intake:** the user's offhand framing (a casual characterization in a particular moment) was compressed by an upstream summarization pipeline into a declarative proposition ("Will describes the project as 75% hobby and 25% practical utility"). Speech-act type was lost.
2. **At storage:** the proposition was stored without an `original_utterance_verbatim` anchor, without an `utterance_context` (what was being discussed when the user said it), and without speech-act-type-appropriate temporal half-life.
3. **At use:** the proposition was retrieved into a reasoning chain (audit timing) different from its origin context, treated as a premise rather than as past-mention recall, and elevated to comparable weight with live signal from the active conversation.
Although this proposal originated in a Claude/upstream-summarization failure, the same architecture serves ELNOR's local memory system. The failure modes are general; the fixes apply to ELNOR's intake pipelines (DOC72 §20A, conversation mining; surface intake contracts) and at-use disciplines (DOC24 packet assembly, DOC73 CU input retrieval) regardless of whether the upstream LLM is Anthropic-managed or ELNOR-local.
---
## 2. Principle
Memory has two distinct lifecycle stages where epistemic information can be lost: **at intake** (when an utterance becomes a stored proposition) and **at use** (when a stored memory becomes a reasoning premise). Both require structured discipline.
The defense pattern mirrors DOC73 V1.4's existing `reasoning_authored_text` vs `reasoning_generated_text` split (§3.2): preserve the immutable original alongside the derived/regenerable artifact. DOC73 applies this at the CU level. The same pattern applies at the per-memory level (intake-side) and at the retrieval-labeling level (at-use side).
**Cross-context retrieval is a first-class feature.** A memory captured while discussing one topic is *intentionally* available when reasoning about another. The architectural job is not to gate the retrieval but to **label** it, so consumers (the LLM, the BDSM Matrix, the ranker, the user inspector) can weight the cross-context applicability appropriately.
**Live signal beats cached signal.** When the active conversation contradicts a memory being retrieved, the contradiction is evidence of staleness, not an inconsistency to paper over. The system should prefer live, flag the cached for re-validation, and surface the conflict to the user when load-bearing.
---
## 3. Three failure modes (and the corresponding amendments)
### FM-1: Epistemic register loss at intake
The user's utterance has a speech-act type — assertion, observation, aspiration, hypothetical, casual characterization, preference, directive, question, humor, etc. The extraction pipeline collapses all these into flat declarative propositions. Once collapsed, downstream consumers cannot recover the original register.
Existing DOC72 primitives partially cover this: `AuthorialVoice` captures who is speaking; `AssertionType` captures the epistemic shape of the claim (`direct_quote | synthesized_rule | applied_argument | procedural_rule | factual_claim`). Neither captures the **speech-act type of the originating utterance**, which is orthogonal to both.
### FM-2: Temporal and contextual provenance loss at intake
The original utterance had a moment of utterance and a context of utterance (what was being discussed; what mood; where in the conversational arc; which channel). Extraction strips all of this. Memories about self-descriptions of personal projects are particularly time-variant and need short half-lives; without timestamp, context, and speech-act-aware half-life, they don't get one.
### FM-3: At-use precedence error
When a memory is retrieved into reasoning, the system has no structured check for:
- (a) is this memory the kind that warrants premise-grade weight in this reasoning chain, or is it past-mention recall?
- (b) does the live signal in the current conversation contradict the cached memory?
- (c) is this retrieval cross-context (origin context ≠ current context), and is the applicability label surfaced to consumers?
Per the user's correction during proposal scoping: (c) does **not** gate retrieval. Cross-context retrieval is a feature; the architectural job is to label.
---
## 4. Existing primitives this proposal builds on
This proposal is largely additive — it formalizes disciplines that map onto existing architectural patterns:
| Existing primitive | Owner doc | Used here for |
|---|---|---|
| `AuthorialVoice` enum | DOC72 R5.72 | Existing; this proposal does not modify it |
| `AssertionType` enum | DOC72 R5.72 | Existing; this proposal does not modify it |
| `provenance` chain (Three-tier per node sparsity) | DOC72 R5.72 §33 | Extended with `original_utterance_verbatim`, `utterance_context`, `speech_act_type` |
| Half-life policy by node_kind | DOC72 R5.72 §5 confidence model | Extended with speech-act-type modifier |
| `reasoning_authored_text` vs `reasoning_generated_text` split | DOC73 V1.4 §3.2 | Pattern applied at per-memory and at-use level |
| Maturity bypass for user-stated durable facts | DOC1 §6 | Restricted: speech-act-type gates the bypass |
| Confidence-floor tagging algorithm | DOC24 §26.5.2 | Extended with a new tag `[recall]` and speech-act-aware tag mapping |
| `CompactEntityCard` injection schema | DOC24 §19.2 | Extended with applicability labels |
| Six-dimension knowledge framework | DOC72 §2.2 | Existing; cross-context applicability becomes a Connections-dimension signal |
| CU input edges with `input_essentiality` | DOC73 V1.4 §3.2 | Extended with optional `cross_context_applicability` decay |
No new ontology slots, no new node kinds, no new services. All amendments fit within existing schemas as field additions or algorithm extensions.
---
## 5. Amendment to DOC72 R5.72+ (intake schema)
### 5.1 Add `SpeechActType` enum to extraction output
```ts
// DOC72 — new enum, captured at extraction time (Stage 3 EXTRACT)
// Stored as part of provenance chain on every extracted node
export type SpeechActType =
| "direct_assertion" // "X is Y"
| "observation" // "I noticed X" / "It seems Y"
| "aspiration" // "I want X to be Y" / "Hopefully Z"
| "hypothetical" // "If X then Y" / "What if Z"
| "casual_characterization" // Offhand framing — "X is roughly Y"
// "kind of like Z" / "mostly P"
// Not meant as load-bearing claim.
| "preference_statement" // "I prefer X" / "Use Y"
| "directive" // "Always X" / "Never Y" / standing orders
| "question" // "Is X Y?" — captures user's open question
// for the curiosity engine (DOC73 R5.3 B8)
| "negation" // "X is NOT Y" / "Don't do Z"
| "uncertain_assertion" // "I think X is Y" / "Maybe Z"
| "humor_or_irony" // Not literal; for inspectability
| "correction"; // "Actually X is Y, not Z"
```
**Why this enum and not just expanding `AssertionType`.** AssertionType captures the *epistemic shape* of a claim (is this a quote? is this a rule? is this an argument?). SpeechActType captures the *form of the originating utterance*. They are orthogonal. A `direct_quote` (AssertionType) can come from a `direct_assertion` or from a `humor_or_irony` utterance — both are "quotes" but only one is a load-bearing assertion. Keeping the dimensions separate preserves the existing AssertionType→tag mapping (DOC24 §29) without overloading.
**Where extracted.** Speech-act type is determined at the extraction stage by the extraction LLM (or by deterministic heuristics for high-confidence cases — sentence shape, hedging cues, register markers). Default when uncertain: `direct_assertion` (the most common case; fail-open for backward compatibility).
**Storage.** As a field on the provenance chain entry that gave rise to the node (Three-tier provenance per DOC72 §33). Tier A nodes carry the full speech-act-type history (one entry per provenance source); Tier C nodes carry it on the latest source only.
### 5.2 Add `original_utterance_verbatim` field to provenance entry
```ts
// DOC72 — extends ProvenanceEntry
type ProvenanceEntry = {
// ... existing fields (source_kind, source_ref, captured_at, etc.)
// NEW
original_utterance_verbatim?: string; // Raw user text up to ~500 chars
// Preserved exactly; never auto-rewritten
// Mirrors DOC73 §3.2 reasoning_authored pattern
utterance_context?: {
conversation_topic: string; // Brief topic descriptor
turn_index?: number; // Position in conversation
channel_kind: ChannelKind; // Q chat / Discord / WhatsApp / etc
surrounding_entities?: EntityRef[]; // Entities active in conversation
// when utterance occurred
captured_at: string; // ISO datetime
};
speech_act_type: SpeechActType; // From §5.1
schema_version: 2; // bump from 1
};
```
**Rationale.** Mirrors DOC73 §3.2 `reasoning_authored_text` (preserved verbatim, never auto-overwritten) at the per-memory layer. Inspectors and re-validation prompts can recover exactly what the user said. The proposition extracted from the utterance is *derived*; the verbatim is *authored*.
**Size cost.** ~500 chars per provenance entry × Tier A nodes (high-value professional). Tier B carries verbatim only on the most recent provenance entry. Tier C carries it only when explicitly user-locked. The compact provenance variant in DOC72 §33 (Tier B Compact, Tier C Minimal) governs whether verbatim is preserved per node.
### 5.3 Speech-act-type-aware half-life policy
Extend DOC72 §5 confidence model's half-life table:
```
Half-life by node_kind × speech_act_type:
For memory_directive nodes:
speech_act_type: direct_assertion → use existing memory_type half-life
speech_act_type: directive → 365 days (standing order)
speech_act_type: preference_statement → 180 days
speech_act_type: observation → 90 days
speech_act_type: casual_characterization → 30 days ← short
speech_act_type: aspiration → 60 days
speech_act_type: hypothetical → 14 days ← shortest
speech_act_type: humor_or_irony → 7 days ← effectively non-durable
speech_act_type: correction → use target node's half-life
For domain_concept, goal, work_product, etc.:
speech_act_type does not modify half-life (these are not utterance-derived
in the typical case; their provenance is documents/sources, not utterances).
```
The policy table is configurable per DomainSignalProfile (some domains may want different half-lives for `casual_characterization` — research domains may want longer; conversational domains shorter). Default values ship in the generic profile.
**Effect on the 75/25 case:** with `speech_act_type: casual_characterization`, half-life would be 30 days. After 30+ days without reaffirmation, the proposition would be in the "stale" tier (per DOC72 §16.7) and surface in inspectors as such. Beyond 60 days without reaffirmation it would be "expired" and not auto-injected.
### 5.4 Maturity bypass restricted by speech-act type
Currently DOC72 §6 / DOC1 §10.4 allows maturity bypass for user-stated durable facts (`assertion_class: "durable_fact"` AND `confidence >= 0.85` → enter at `active` maturity).
Add restriction:
```
Maturity bypass eligibility:
- Permitted: speech_act_type ∈ {direct_assertion, directive, preference_statement, correction}
- Permitted with confirmation: speech_act_type ∈ {observation, uncertain_assertion}
(system MAY ask "should I remember this?")
- NOT permitted: speech_act_type ∈ {casual_characterization, aspiration,
hypothetical, humor_or_irony}
These enter at `candidate` maturity with TTL-bound promotion.
- Question: not stored as memory; routed to curiosity engine (DOC73 §3.3 B8).
```
This prevents the failure mode where an offhand framing acquires durable status via the bypass.
### 5.5 Cross-doc obligations from §5
| Target | Section | Change |
|---|---|---|
| DOC72 R5.72 | §20A intake pipeline | Stage 3 EXTRACT must capture `speech_act_type`, `original_utterance_verbatim` (Tier A/B nodes), `utterance_context` |
| DOC72 R5.72 | §33 Provenance Chain — Three-tier | Tier A: full verbatim + context + speech-act per entry; Tier B: latest entry only; Tier C: speech_act only |
| DOC72 R5.72 | §5 confidence model | Half-life table extended with speech-act-type modifier |
| DOC72 R5.72 | §6 promotion thresholds | Maturity bypass eligibility restricted by speech-act type |
| DOC1 | maturity bypass section | Mirror restriction |
| DOC1 | governance audit surface | Surface speech-act type in memory inspector |
---
## 6. Amendment to DOC24 R2.5+ (at-use discipline)
### 6.1 Add `[recall]` tag to canonical tag vocabulary (§26.5.1)
```
Primary tag (mutually exclusive — one per card):
recall | Surface as past-mentioned, not as load-bearing premise.
| The user mentioned this once; check if still applicable.
| LLM behavior: "You mentioned X — is that still right?" or
| weave it in lightly without treating as fixed fact.
```
This sits between `reference` (available for reference, low force) and `apply` (use silently as premise). It is the appropriate default tag for memories whose `speech_act_type` does not warrant premise-grade weight.
### 6.2 Speech-act-aware tag mapping (extends §29)
Add a new dimension to the tag computation. The §29 AuthorialVoice × AssertionType table runs first (existing), then the speech-act-type modifier applies:
```
Speech-act-type modifier (runs after §29 step 0):
If speech_act_type ∈ {casual_characterization, humor_or_irony, hypothetical}:
PROMOTE to [recall] regardless of step-0 tag, UNLESS the §26.5.2
AUTHORITY_PROTECTED_TAGS floor (from ISS-01 fix) applies.
Cannot collapse below [recall] either (i.e., cannot become low_confidence).
If speech_act_type == aspiration:
If step-0 tag is in {apply, follow, enforce, cite_as_rule}:
DOWNGRADE to [consider] — aspirations inform strategy but do not
execute or enforce.
Otherwise: keep step-0 tag.
If speech_act_type == observation:
If step-0 tag is [apply]:
DOWNGRADE to [reference].
Otherwise: keep step-0 tag.
If speech_act_type == question:
Should not appear in packet (questions are not memory; they're routed
to the curiosity engine per DOC73 §3.3 B8). If it does appear (extraction
error), surface as [recall] with diagnostic flag.
If speech_act_type ∈ {direct_assertion, directive, preference_statement,
correction, uncertain_assertion, negation}:
Keep step-0 tag.
```
**Effect on the 75/25 case:** with `speech_act_type: casual_characterization` and (let's say) `[apply]` from a misfired step-0 mapping, the modifier promotes to `[recall]`. The LLM sees "user mentioned X — is that still right?" rather than "the user prefers X — apply silently." The premise-grade weight is denied at the structural level.
### 6.3 Add `applicability_label` to `CompactEntityCard` (§19.2)
```ts
// DOC24 — extends CompactEntityCard
type CompactEntityCard = {
// ... existing fields (entity_ref, node_kind, why_relevant, tag, etc.)
// NEW
applicability: {
origin_context?: string; // From provenance.utterance_context.conversation_topic
current_context: string; // What's being reasoned about now
applicability_label: "same_context" | "adjacent_context" | "cross_context";
applicability_confidence: number; // 0.0-1.0; semantic similarity origin↔current
cross_context_decay?: number; // 0.0-1.0; multiplier on force_level when cross
schema_version: 1;
};
speech_act_type?: SpeechActType; // Surfaced for LLM behavioral cue
// ... existing fields
};
```
**Computation.** `applicability_label` is derived from semantic similarity between origin context and current context (when both are available; embedding cosine, threshold-bucketed):
```
similarity ≥ 0.75 → same_context (no decay)
similarity 0.55-0.75 → adjacent_context (mild decay, 0.85x force_level)
similarity < 0.55 → cross_context (visible decay, 0.7x force_level by default)
```
**Surfacing to the LLM.** The XML rendering includes the applicability label as an attribute on the card:
```xml
<card type="memory_directive" tag="recall" applicability="cross_context"
origin="discussing project scope decisions"
current="reasoning about audit timing">
User has previously characterized this as "roughly 75% hobby, 25% utility"
(offhand framing, ~3 weeks ago).
</card>
```
The LLM gets the cue and can weight appropriately. Per Will's correction: the cross-context retrieval **happens** — the memory is delivered. The labeling is what allows the consumer to apply correct weight. This is the architectural realization of "cross-relevance is valuable; gating it would be too limiting."
### 6.4 Live-vs-cached precedence rule (new §26.5.3)
```
§26.5.3 Live-vs-cached signal precedence
When a memory is retrieved into the packet AND the active conversation
contains a signal that contradicts it, the packet assembler MUST:
1. Inject BOTH the cached memory AND a `[contradicts_live]` modifier card
that summarizes the live signal contradicting it.
2. Demote the cached memory's tag to `[recall]` regardless of speech-act
type (the live contradiction overrides the speech-act-type baseline).
3. Set the card's `requires_revalidation: true` flag.
4. Emit `memory.live_contradiction_detected` event for the inspector.
Detection: the routing function (§13) computes a contradiction signal
when the current user message contains a proposition that semantically
contradicts a candidate memory (cosine similarity > 0.6 to the negation
of the memory's content). Bounded ≤10ms per turn.
The user-facing behavior: the LLM should naturally re-validate ("Earlier
you said X; just now you said Y — should I update my understanding?").
The system never silently doubles down on the cached signal.
```
**Effect on the 75/25 case:** had the user said in the same conversation "actually it's more 50/50," the retrieval of the cached "75/25" memory would carry the `[contradicts_live]` modifier, demoted to `[recall]`, prompting re-validation. The system explicitly defers to the live signal.
### 6.5 Cross-doc obligations from §6
| Target | Section | Change |
|---|---|---|
| DOC24 R2.5 | §26.5.1 canonical tag vocabulary | Add `[recall]` tag |
| DOC24 R2.5 | §26.5.2 / §29 tag mapping | Add speech-act-type modifier step |
| DOC24 R2.5 | §19.2 CompactEntityCard schema | Add `applicability` and `speech_act_type` fields |
| DOC24 R2.5 | new §26.5.3 | Live-vs-cached precedence rule |
| DOC24 R2.5 | §13 routing | Add contradiction-detection step (≤10ms) |
| DOC24 R2.5 | §21 minimum event catalog | Add `memory.live_contradiction_detected` event |
| DOC24 R2.5 | §22 cross-doc amendment matrix | Add row for this proposal as source |
---
## 7. Amendment to DOC1 (governance)
### 7.1 Maturity bypass restriction
Mirror DOC72 §5.4 restriction: maturity bypass is gated by `speech_act_type`. `casual_characterization`, `aspiration`, `hypothetical`, and `humor_or_irony` enter at `candidate` maturity regardless of stated confidence. Promotion requires either explicit user confirmation, repeated re-occurrence (3+ across sessions per existing §12.4C transient-vs-durable rule), or surfacing through the suggestions inbox.
### 7.2 Re-validation prompt policy
When a memory whose original utterance is older than its speech-act-type half-life is being retrieved into a load-bearing reasoning chain (any tag stronger than `[recall]` or `[reference]`), DOC1 governance MUST:
1. Allow the retrieval to proceed with current tag.
2. Emit `memory.requires_revalidation_prompt` to DOC24 packet assembler.
3. DOC24 attaches a re-validation prompt to the response: "I have X recorded from {utterance_context.conversation_topic} on {captured_at} — is this still right?"
4. User confirmation refreshes the memory's `last_affirmed_at` and resets staleness.
This is distinct from the live-vs-cached precedence rule (§6.4). That rule fires when active conversation contradicts cached. This rule fires when cached is stale and being used load-bearing without contradiction signal — proactive re-validation.
### 7.3 Audit surface
The Knowledge Manager memory inspector MUST surface:
- `original_utterance_verbatim` (when present)
- `utterance_context.conversation_topic` and `captured_at`
- `speech_act_type`
- Half-life remaining
- Last `applicability_label` value when retrieved (most recent retrieval)
User can edit (with audit trail), promote/demote, or delete. Audit trail includes who/when for each modification.
### 7.4 Cross-doc obligations from §7
| Target | Section | Change |
|---|---|---|
| DOC1 | maturity bypass | Restrict by speech_act_type |
| DOC1 | governance lifecycle | Add re-validation prompt policy |
| DOC1 | audit surface | Surface verbatim, context, speech-act-type, applicability history |
---
## 8. Amendment to DOC73 V1.4+ (CU input applicability)
### 8.1 CU input edges carry cross-context applicability
Add an optional field to CU input edges (§3.2):
```ts
// DOC73 — extends CU input edge schema
type CUInputEdge = {
// ... existing fields (input_role, input_essentiality, target_node_ref, weight)
// NEW
cross_context_applicability?: {
origin_context: string;
cu_context: string; // The CU's reasoning context
applicability_label: "same_context" | "adjacent_context" | "cross_context";
applicability_confidence: number;
schema_version: 1;
};
};
```
### 8.2 Authority computation respects applicability decay
§3.2A.1 `authority_of()` for VersionedClaim-trait inputs receives a multiplicative decay when the input is cross-context:
```
function authority_of_input(input_edge, retraction_states, active_profile) → float {
// ... existing branches (CU, AuthorityAnchor, VersionedClaim, static_fact)
base_authority = ... (existing logic)
// NEW: cross-context decay applies to supporting inputs only
// Essential inputs are essential by user/system declaration —
// the user marked them load-bearing for this conclusion, so
// cross-context labeling does NOT decay essential authority.
// Supporting inputs may have decay applied:
if input_edge.input_essentiality == "supporting"
AND input_edge.cross_context_applicability exists:
decay = match input_edge.cross_context_applicability.applicability_label:
"same_context" → 1.0
"adjacent_context" → 0.92
"cross_context" → 0.85
return base_authority * decay
return base_authority
}
```
**Why essential inputs are exempt from decay:** the user declared them essential to this CU's conclusion. The cross-context relationship is intentional. Applying decay there would penalize exactly the kind of cross-domain reasoning ELNOR is supposed to make valuable. Decay only applies to supporting inputs because supporting inputs are confidence boosters — and a cross-context booster is genuinely less confidence-anchored than a same-context booster.
### 8.3 Cross-doc obligations from §8
| Target | Section | Change |
|---|---|---|
| DOC73 V1.4+ | §3.2 CU input edge schema | Add `cross_context_applicability` field |
| DOC73 V1.4+ | §3.2A.1 authority_of() | Apply decay to cross-context supporting inputs only |
| DOC73 V1.4+ | §3.3 VersionedClaim eligibility carve-outs | Reference speech-act-type half-life as additional governance signal |
---
## 9. Acceptance tests
The following five tests collectively validate the proposal. Each is acceptance-grade for the cross-doc integration.
### Test 1 — Casual characterization is captured correctly
User says: "I'd describe ELNOR as roughly 50% hobby and 50% professional aspiration."
Expected:
- Extraction produces a `memory_directive` candidate with `speech_act_type: "casual_characterization"`.
- `original_utterance_verbatim` preserved.
- `utterance_context.conversation_topic` captured (e.g., "discussing project scope").
- Maturity = `candidate` (not active; bypass ineligible).
- 30-day half-life applied.
- After 30 days without reaffirmation, transitions to stale.
- After 60 days, expired (not auto-injected).
### Test 2 — Cross-context retrieval surfaces with label
The captured memory from Test 1 is later retrieved during a conversation about audit timing.
Expected:
- Memory is retrieved (cross-context relevance is preserved).
- `applicability_label: "cross_context"` (semantic similarity origin↔current < 0.55).
- Tag is `[recall]` (speech-act-type modifier dominates).
- Cross-context decay 0.7x applied to force_level.
- LLM receives the card with explicit cross-context label and origin description.
- LLM does not treat as load-bearing premise; either weaves lightly or asks for re-validation.
### Test 3 — Live signal contradicts cached memory
Same user makes Test 1 utterance, then later in same or subsequent conversation says "actually I think it's more 70% professional now."
Expected:
- Routing detects contradiction signal (≤10ms).
- Both cached and live signal injected; cached gets `[contradicts_live]` modifier.
- Cached memory tag demoted to `[recall]` regardless of original.
- `requires_revalidation: true`.
- `memory.live_contradiction_detected` event emitted.
- LLM naturally re-validates; user confirmation updates the cached memory or supersedes it.
### Test 4 — Standing directive retains premise weight
User says: "Always cite the primary source, never just secondary commentary."
Expected:
- Extraction produces `speech_act_type: "directive"`.
- 365-day half-life.
- Maturity bypass eligible (with `assertion_class: "durable_fact"` and confidence ≥0.85 from explicit framing).
- Enters at `active` maturity.
- AuthorialVoice = `self`, AssertionType = `procedural_rule` → step-0 tag = `[cite_as_reference]`.
- Speech-act-type modifier: `directive` keeps step-0 tag.
- Retrieved at full force_level into any reasoning chain about citation behavior.
- Cross-context retrieval still applies decay if used in a context far from citation reasoning, but `directive` semantics keep the tag at premise-grade.
### Test 5 — CU with cross-context supporting input
A CU about strategy in matter A (or domain A — software architecture decision) has an `essential` input from matter A's domain concepts AND a `supporting` input (a lesson) extracted from matter B (or domain B — a different matter / different musical project / different research direction).
Expected:
- Essential input: no decay regardless of cross-context. Cross-domain essential reasoning is intentional.
- Supporting input from matter B: `applicability_label: "cross_context"`, decay 0.85x applied to its authority contribution.
- CU `authority_level` reflects the principled cross-context decay on supporting only.
- Inspector shows the cross-context relationship explicitly.
---
## 10. Open questions and deferred work
### 10.1 Speech-act-type extraction accuracy
The extraction LLM must classify utterances by speech-act type. Accuracy will be imperfect (e.g., distinguishing `casual_characterization` from `direct_assertion` is genuinely hard for some utterances; humor and irony are notoriously LLM-difficult).
Default policy: when extraction confidence on speech-act-type is below 0.6, default to `direct_assertion` (most common, most permissive). The user can correct via Knowledge Manager.
DOC8 self-learning consumes the user's corrections and improves the extraction prompt over time (existing DOC8 §36 feedback loop).
**Deferred to V2 of this proposal:** explicit calibration benchmarking for speech-act-type classification, with a held-out set of utterances and manual ground-truth labels. LoCoMo-style methodology adapted from F4 in the V2 review.
### 10.2 Origin context similarity computation
Computing semantic similarity between `origin_context.conversation_topic` and `current_context` requires both to be embedded. For older memories whose context wasn't captured (pre-amendment), backfill is impossible. For new memories, both contexts are captured but embedding cost adds to the intake pipeline.
**Default for missing origin_context:** `applicability_label: "unknown"` (treated like `cross_context` for safety — visible decay).
**Deferred:** background backfill of origin contexts from conversation history for nodes captured before the amendment lands. Bounded best-effort.
### 10.3 Multi-utterance memories
Some memories are derived from multiple utterances (e.g., conversation mining synthesizes a preference from three separate mentions). Which speech-act-type applies?
**Proposed default:** the most-conservative speech-act-type wins (e.g., one `casual_characterization` and two `direct_assertion` → casual_characterization governs). Rationale: the system is being conservative about premise-grade weight when any utterance suggested informal framing.
**Alternative:** weighted vote by recency or by user-confirmation. Open question for V1.5+ revision after implementation experience.
### 10.4 Speech-act-type vs `assertion_class`
DOC72/DOC1 already has `assertion_class: "durable_fact" | "transient_observation" | ...`. There's potential overlap between `assertion_class` and `speech_act_type`.
**Resolution proposed:** they remain distinct because they answer different questions. `assertion_class` answers "should this be stored durably?" (governance question). `speech_act_type` answers "what kind of utterance produced this?" (provenance question). They co-determine: a `speech_act_type: casual_characterization` typically implies `assertion_class: transient_observation`, but the latter remains the storage-decision field.
A coherence rule MAY be added in V1.5+: warn when `speech_act_type: casual_characterization` AND `assertion_class: durable_fact` co-occur (probable extraction error or user override needed).
### 10.5 The cross-doc tracking question
This proposal's existence highlights a real meta-architecture question: how does the cross-doc obligation system itself stay navigable as the spec suite grows? V1 of this proposal does not address that. It is the user's call whether and when to consolidate the cross-doc tracking infrastructure (Master Integration Index R1, CD-A staging docs, embedded amendment matrices, etc.) into a simpler structure. Out of scope here; flagged as a related concern.
---
## 11. Summary of cross-doc obligations
For registration in CD Master Integration Index R1, this proposal generates the following obligation rows. Each obligation can be tracked as an `ObligationRegistryEntry` per DOC24 §23.3 schema.
| OBL ID | Target Doc | Target Section | Change | Priority | Depends On |
|---|---|---|---|---|---|
| OBL-MID-01 | DOC72 R5.72+ | §20A intake / §33 provenance / §5 confidence | Add SpeechActType, original_utterance_verbatim, utterance_context, half-life modifiers | required_now | — |
| OBL-MID-02 | DOC72 R5.72+ | §6 promotion thresholds | Maturity bypass eligibility by speech_act_type | required_now | OBL-MID-01 |
| OBL-MID-03 | DOC1 | maturity, governance, audit | Mirror restrictions; add re-validation prompt policy; expose verbatim/context in inspector | required_now | OBL-MID-01 |
| OBL-MID-04 | DOC24 R2.5+ | §26.5.1 / §26.5.2 / §29 / §19.2 | Add [recall] tag, speech-act modifier, applicability fields on CompactEntityCard | required_now | OBL-MID-01 |
| OBL-MID-05 | DOC24 R2.5+ | new §26.5.3 / §13 routing / §21 events | Live-vs-cached precedence rule | required_now | OBL-MID-04 |
| OBL-MID-06 | DOC73 V1.4+ | §3.2 CU input edges / §3.2A.1 authority_of() | Cross-context applicability on supporting inputs only | required_now | OBL-MID-01 |
| OBL-MID-07 | DOC8 | §36 feedback loop | Consume user corrections to speech_act_type extraction; tune prompt | required_later | OBL-MID-01 |
Acceptance test: §9 Tests 1-5 collectively validate. Each test maps to one or more OBL-MID rows.
---
## 12. End of proposal
This proposal is a **single consolidated document** per the architect's preference. Its scope spans four owner docs (DOC72, DOC24, DOC1, DOC73) plus a downstream feedback consumer (DOC8). Integration into target docs is the work of subsequent revision cycles; this document provides paste-ready schemas and algorithm specifications to make that integration mechanical rather than design-from-scratch.
**Reading sequence for reviewers:**
1. §1 Origin (the 75/25 case) — concrete failure mode evidence
2. §2 Principle and §3 Failure modes — architectural framing
3. §4 Existing primitives — what this builds on
4. §5-§8 Per-doc amendments — paste-ready code
5. §9 Acceptance tests — what "done" looks like
6. §10 Open questions — what's deferred
7. §11 Cross-doc obligations — for tracking integration
Sized for routing to multi-model reviewers in fresh windows. Self-contained.