Re: Your note on intent distribution across memories
Russ, your instinct here is solid — there's a real problem to solve at the intersection of memory retrieval and decision-making. I want to walk you through where I landed after thinking this through, because the conclusion isn't quite what either of us initially expected.
You said something important: when memories are retrieved, we need to know whether they're aligned with the system's current "intent," and that intent might shift due to circumstances even when the goal stays the same. That's a real gap. If Cogniscient retrieves memories based purely on semantic relevance to a topic, it can surface memories that are relevant to a goal but counterproductive to what the system is actually trying to do right now, given everything it's juggling.
That's a legitimate architectural problem. Where things get interesting is in how we solve it.
My first reaction was the same as yours — maybe ODIE needs a first-class "Intent" object that sits between Outcomes and Action Hypotheses, something that captures the system's current operational posture and filters memory retrieval.
But here's the issue: when you examine what "intent" actually is, it breaks down into things ODIE already has.
Let me explain with an example. Say you have an NPC shopkeeper with these desired outcomes:
And a constraint:
A player walks in with stolen goods to sell. The memory system retrieves a past experience of successfully haggling with a trader — that memory is relevant to the "acquire gold" outcome.
Now, you might say the shopkeeper's current "intent" is to "avoid drawing attention." But that's not actually a different kind of thing from an outcome — it's just another desired outcome: minimize the risk of drawing unwanted attention. And it connects to a higher-order outcome: minimize the risk of death, harm, or inconvenience.
The reason the haggling memory is problematic isn't that it conflicts with some separate "intent" — it's that the system is evaluating the memory against only one desired outcome (acquire gold) instead of against all relevant desired outcomes simultaneously. When you evaluate the "haggle for stolen goods" action against the full set — acquire gold (yes), maintain reputation (no), minimize risk of attention (no), avoid thieves' guild conflict (constraint violation) — the action scores poorly and the memory becomes deprioritized.
Intent, in this framing, is the emergent result of evaluating a potential action against the full, weighted collection of desired outcomes — not a separate object.
This connects to the foundational methodology ODIE is built on. Let me give you the quick version, because it matters for what comes next.
A Desired Outcome is a measurable statement of what someone is trying to achieve, written in a specific format: Direction + Measure + Object + Context. For example: "Minimize the time it takes to understand claim status when checking online."
Outcomes are not KPIs or metrics. They're stable, human-centered statements of what success looks like. They don't change often, even when strategies and actions change constantly.
Every desired outcome carries two weights:
The gap between importance and satisfaction is the opportunity score. High importance + low satisfaction = high opportunity = this is where attention should go.
CD-MAP is the model that defines the mission — what success looks like holistically — and maps out the phases, constraints, and signals involved. Think of it as the terrain map. ODIE is the navigator that operates on that map.
In CD-MAP, intent is not a separate construct. Intent is defined as a collection of desired outcomes, weighted by satisfaction and importance. When you look at the full weighted collection and evaluate an action against it, the composite result is the system's intent. You don't need to model intent separately — you need to model outcomes well and evaluate them collectively.
So if intent isn't a new object, what's the actual engineering challenge? It's exactly what you were circling: how do you efficiently determine which outcomes are relevant to a given decision, so the system evaluates actions against the right collection without having to score every action against every outcome in the entire system?
This is the combinatorial problem. An NPC might have a dozen outcomes. An enterprise agent might have hundreds. You can't evaluate every action hypothesis against every outcome for every decision cycle. That doesn't scale.
Several approaches could work, potentially in combination:
Outcomes already have parent/child relationships in the ODIE spec. When evaluating an action, pull in the directly-served outcome plus its parent and siblings — not the entire tree. The shopkeeper evaluates "acquire gold" plus its sibling outcomes under "maintain livelihood" without pulling in "pursue romantic relationship."
Signals are already linked to specific outcomes. When a cluster of signals fires (say, thieves' guild activity detected), the outcomes those signals are linked to get activated and pulled into the evaluation pool alongside the directly-served outcome. This is dynamic and context-responsive.
Before you even run opportunity scoring, check active constraints. If an action hypothesis violates a hard constraint, it's eliminated immediately — no need to evaluate it against every outcome.
If outcomes are stored in a graph (which the spec already recommends for beliefs), you can use graph distance to scope relevance. Outcomes within N hops of the directly-served outcome participate; distant ones don't.
Here's where this connects back to what you're building with Cogniscient. The memory retrieval problem you identified is real — but the solution isn't an "intent filter" that sits on top of memories. It's an outcome pooling mechanism within ODIE that determines which outcomes are contextually active for a given decision cycle. That active outcome pool then informs memory retrieval: Cogniscient doesn't just retrieve memories relevant to a single outcome, it retrieves memories relevant to the active pool of outcomes, weighted by their current opportunity scores.
This is the mechanism that makes memories "intent-aligned" without requiring a separate intent object. ODIE tells Cogniscient: "Here are the outcomes that matter right now, and here's how much each one matters." Cogniscient uses that to weight its retrieval. The result is memory retrieval that's effectively filtered by "intent" — because intent is just the composite of those weighted outcomes.
You're absolutely right that there's a bifurcation between computational and cognitive science communities here. The computational side models intent as probability distributions and reward functions. The cognitive side talks about motivational salience, goal shielding, and implementation intentions. Nobody has unified them.
I think the reason is that most researchers treat intent as a thing you can point at — a discrete state or object in the system. What CD-MAP and JTBD suggest is that intent is emergent — it's what you get when you evaluate the full weighted collection of desired outcomes against a decision context. That reframing might be part of what bridges the two communities, because it's compatible with both probabilistic (computational) and motivational (cognitive) frameworks.
But that's a longer conversation. For now, the practical implication is: we don't need to solve the unified theory to build the mechanism. Outcome pooling with weighted evaluation gets us the behavior we need.
You're not off-base — you identified a real gap. The gap just lives in a different place than where we first looked. It's not a missing data object (Intent). It's a missing process (Outcome Pooling) that determines which of ODIE's existing objects participate in a given decision cycle, and how that scoped context flows into memory retrieval.
I want to flesh this out into a proper architectural component. Let's discuss.