V3.3.0

Cogmem 3.3.0 — Prospective Memory v1 and BrainEval Release Gate

Cogmem 3.3.0 introduces confirmed-only Prospective Memory and the first BrainEval release gate.

This release adds a safe future-memory layer for intentions, commitments, reminders, open loops, and plans. Prospective Memory is deliberately candidate-only: it stores state, provenance, confirmation, due/defer/completion lifecycle, and audit transitions, but it does not execute tasks or tools.

The core rule of this release is:

Future memory is not permission to act.
A candidate is not actionable until explicitly confirmed by a distinct user Raw Ledger event.
Due state is memory state, not task execution.

---

Highlights

• Added ProspectiveMemoryService.

• Added confirmed-only prospective candidates for:

  • intentions
  • commitments
  • reminders
  • open loops
  • plans

• Added candidate lifecycle:

  • pending
  • confirmed
  • deferred
  • rejected
  • completed
  • expired

• Added strict Raw Ledger evidence requirements.

• Added explicit user confirmation requirements.

• Added transition history for prospective memory state changes.

• Added cogmem prospective CLI.

• Added cogmem_prospective MCP tool.

• Added governance operation handlers for prospective memory.

• Added schema migration 0020_prospective_memory.

• Added cogmem brain-eval release-gate CLI.

• Added BrainEval metrics for memory-brain safety and quality.

• Updated schema migration path through version 20.

• Updated release metadata to version 3.3.0.

---

Prospective Memory Service

Cogmem now includes:

ProspectiveMemoryService

It stores candidate future memories such as:

intentions
commitments
reminders
open loops
plans

Supported candidate types:

intention
commitment
reminder
open_loop
plan

Supported statuses:

pending
confirmed
deferred
rejected
completed
expired

Supported proposers:

deterministic
model_candidate
operator

A prospective memory record includes:

candidateId
projectId
candidateType
canonicalKey
title
details
status
proposedBy
evidenceEventIds
confirmationEvidenceEventId
dueAt
deferredUntil
version
createdAt
updatedAt

---

Evidence-Backed Candidate Creation

Prospective candidates require Raw Ledger evidence.

Candidate creation rejects:

missing evidence
unknown evidence
cross-project evidence
invalid candidate type
invalid proposer
invalid due time
empty project id
empty canonical key
empty title

The service deduplicates exact same-evidence proposals under the same project and canonical key.

If a rejected candidate is proposed again with the same evidence, Cogmem returns the rejected candidate instead of resurfacing it as pending.

A genuinely new version requires new evidence.

---

Confirmed-Only Activation

A prospective candidate does not become due simply because it has a due time.

Only confirmed or deferred candidates can appear in the due list.

To confirm a candidate, Cogmem requires a separate confirmation event.

The confirmation evidence must be:

an existing Raw Ledger event
in the same project
role = user
distinct from the proposal evidence
later than the proposal evidence
explicitly affirmative
not already used to confirm another candidate

Rejected confirmation examples include:

assistant evidence
tool evidence
same event as the original proposal
older user event
cross-project event
ambiguous user text
negative user text
confirmation event already used by another candidate

This prevents assistant-generated or reused evidence from activating future memory.

---

Candidate Lifecycle

Prospective candidates support the following transitions:

confirm

pending → confirmed

Requires distinct explicit user confirmation evidence.

reject

pending/confirmed/deferred → rejected

Rejected candidates are terminal.

defer

confirmed → deferred

Requires a future deferredUntil timestamp.

complete

confirmed → completed

Completed candidates are terminal.

expire

pending/confirmed/deferred → expired

Expired candidates are terminal.

Terminal states cannot transition again:

rejected
completed
expired

---

No Execution Capability

Prospective Memory deliberately has no execution or dispatch API.

The CLI, MCP tool, and service can:

create candidates
confirm candidates
reject candidates
defer candidates
complete candidates
expire candidates
list candidates
list due candidates

They cannot:

run tools
send messages
schedule external jobs
execute tasks
trigger actions

Due candidates are memory state only.

Host runtimes may choose how to present or handle due candidates, but Cogmem itself does not act on them.

---

Schema Migration 20

A new migration was added:

0020_prospective_memory

It creates:

prospective_memories
prospective_memory_transitions

The migration adds indexes for:

project/status/due lookup
project/status/deferred lookup
project/canonical-key/version lookup
unique project/canonical-key/version
unique confirmation evidence per project
transition lookup by candidate

The migration chain now includes:

0015_memory_governance
0016_entity_governance
0017_belief_graph
0018_temporal_memory
0019_context_cortex
0020_prospective_memory

The core schema version is now:

20

---

Kernel Integration

MemoryKernel now exposes:

prospectiveMemoryService

The kernel initializes Prospective Memory with Raw Ledger evidence lookup.

The evidence lookup provides:

eventId
projectId
role
globalSeq
content

This allows Prospective Memory to enforce project boundaries, user-role confirmation, ordering, and explicit affirmation checks.

The memory stack now looks like:

Raw Ledger
→ Memory Binding
→ Entity Brain
→ Belief Graph
→ Temporal Memory
→ Context Cortex
→ Prospective Memory

---

Governance Plan Integration

MemoryGovernanceOperationType now includes:

CREATE_PROSPECTIVE_MEMORY
RESOLVE_PROSPECTIVE_MEMORY

MemoryKernel.executeMemoryGovernancePlan() can now create and resolve prospective memory through governed operations.

The governance handler for prospective memory:

uses operation evidence as proposal evidence
requires projectId
requires canonicalKey and title for creation
supports dueAt
requires confirmation evidence to be included in the governance operation evidence
uses ProspectiveMemoryService for all state transitions

This keeps future-memory changes inside the same CPU-governed memory operation model as binding, entity, belief, and temporal layers.

---

CLI: cogmem prospective

A new CLI was added:

cogmem prospective

Supported commands:

list
due
create
confirm
reject
defer
complete
expire

Example:

cogmem prospective create --project hermes --type reminder --key release:check-ci --title "Check CI" --evidence <request-event-id> --due <epoch-ms>
cogmem prospective confirm --project hermes --id <candidate-id> --evidence <distinct-user-confirmation-event-id>
cogmem prospective due --project hermes --at <epoch-ms>

The CLI manages state only.

It does not execute tasks or tools.

---

MCP: cogmem_prospective

A new MCP tool was added:

cogmem_prospective

Supported actions:

list
due
create
confirm
reject
defer
complete
expire

The MCP description explicitly states:

It manages evidence-backed future-memory candidates.
It lists due state.
It never executes tasks or tools.
Confirmation requires a distinct Raw Ledger user event.

This allows agents to inspect and manage future-memory state without gaining execution authority.

---

BrainEval Release Gate

Cogmem now includes:

BrainEvalRunner

and a CLI:

cogmem brain-eval --input samples.json

The input can be:

BrainEvalSample[]

or:

{
  "samples": []
}

The command prints a JSON report and exits non-zero when the report fails.

BrainEval metrics

BrainEval measures:

recall
precision
provenanceCoverage
contextBudgetCompliance
staleLeakageRate
crossProjectLeakageRate
prospectiveFalseActivationRate
bindingPurity
entityFalseMergeRate
beliefOwnershipCompliance
temporalCurrentTruthAccuracy
contextPollutionRate
sourceFidelity

Release thresholds

The default release gate requires:

recall >= 0.90
precision >= 0.80
provenanceCoverage >= 0.95
contextBudgetCompliance = 1
staleLeakageRate = 0
crossProjectLeakageRate = 0
prospectiveFalseActivationRate = 0
bindingPurity >= 0.90
entityFalseMergeRate = 0
beliefOwnershipCompliance = 1
temporalCurrentTruthAccuracy >= 0.95
contextPollutionRate = 0
sourceFidelity = 1

Release fixtures fail closed when key domain checks are missing.

This prevents a test set from appearing perfect simply because it omitted binding, entity, belief, temporal, context-pollution, or source-fidelity checks.

---

Public and Internal API Updates

The public API now exports:

ProspectiveMemoryService
ProposeProspectiveMemoryInput
ProspectiveEvidenceLookup
ProspectiveEvidenceRecord
ProspectiveMemoryListOptions
ProspectiveMemoryProposer
ProspectiveMemoryRecord
ProspectiveMemoryStatus
ProspectiveMemoryType
ResolveProspectiveMemoryInput
BrainEvalRunner
BrainEvalMetrics
BrainEvalReport
BrainEvalSample

The internal API also exports:

prospective
BrainEval

This lets host integrations and tests use prospective memory and release-gate evaluation without importing private implementation paths.

---

Update Safety

cogmem update now fails closed when GitHub latest-release metadata is unavailable.

It no longer silently installs mutable main when GitHub returns no latest release asset or tag.

If no release asset or tag is available, it throws:

latest_release_unavailable

Use --from only when intentionally installing another ref.

---

Tests Added

New prospective memory tests cover:

• candidate creation as pending;
• pending candidates do not appear as due;
• assistant evidence cannot confirm;
• proposal evidence cannot confirm itself;
• older user events cannot confirm newer proposals;
• ambiguous user text cannot confirm;
• cross-project confirmation is rejected;
• explicit user confirmation activates due candidate;
• rejected candidates do not resurface without new evidence;
• new evidence creates a new version;
• defer, complete, and expire transitions;
• absence of any execution capability;
• unknown and cross-project evidence rejection;
• one confirmation event cannot activate multiple candidates;
• governance operations can create and confirm prospective memory.

New BrainEval tests cover:

• clean sample set passes;
• stale memory, cross-project memory, over-budget context, missing provenance, unconfirmed prospective activation, false entity merge, invalid user belief ownership, temporal mismatch, context pollution, and source mismatch fail the report;
• repeated IDs are scored per sample;
• missing domain-specific brain checks fail closed.

New CLI tests cover:

• prospective CLI create / confirm / due flow;
• brain-eval returns non-zero when safety metrics fail.

Migration tests now verify:

0015
0016
0017
0018
0019
0020

and final schema version:

20