Skip to content
InvariantEngine
Proposed Specification / Not Implemented 2026-05-14 by Joshua Couto

IE-003: Negative Memory

Defines how rejected ideas, invalid assumptions, and blocked paths are preserved to prevent reintroduction.

negative-memorymemorygovernance
Specification context: Runtime sections describe the target contract unless the implementation-status section explicitly marks them as implemented. See What works today for the private-alpha implementation boundary.

Implementation Status

Proposed Specification / Not Implemented. Negative Memory is not implemented as a memory kind or runtime enforcement behavior today. Rejected memory proposals exist in the Engine workflow, but rejected proposals do not automatically become Negative Memory. RejectedApproach and UserCorrection memory kinds are not implemented in the current core memory model.

Abstract

Negative Memory is the subsystem responsible for recording and helping enforce rejected ideas, invalid assumptions, failed approaches, and blocked paths. It helps detect, challenge, and block attempts to reintroduce previously discarded work — a failure mode called rejected-idea resurrection. This specification defines how negative memory entries are created, stored, queried, and enforced at runtime.

Problem

Agents do not inherently remember what was rejected. When a context window resets or a session restarts, the agent loses awareness of prior rejections. It may then re-propose the same invalid approach, wasting time and introducing errors that were already identified and resolved.

Definition

Negative Memory is a governed collection of records, each representing something that was explicitly rejected, invalidated, or blocked. Each record includes the rejected item, the reason for rejection, the authority that rejected it, and a timestamp. Negative memory is queryable at runtime and is used by the Session Integrity Layer to detect potential rejected-idea resurrection.

Motivation

Durable memory records what is approved. Negative memory records what has been explicitly rejected, invalidated, or found unacceptable. Without negative memory, the agent has no mechanism to distinguish between an idea it has not yet considered and an idea that was already considered and rejected.

Negative memory is not a permanent blacklist. Entries can become stale as project context evolves. The system requires appeal, supersession, or expiration mechanisms so that old rejections do not block valid future decisions that differ in context from the original rejection.

Runtime Behavior

  1. Record: When an idea, approach, or assumption is rejected (by human review, invariant violation, or council verdict), a negative memory entry is created.
  2. Store: Entries are persisted in durable storage with full audit metadata.
  3. Query: Before an agent action is approved, the Session Integrity Layer queries negative memory for matches.
  4. Enforce: If the proposed action matches a negative memory entry, the match is flagged — resulting in a block, a warning, or escalation depending on policy. The agent receives the rejection reason and related context.

Inputs

  • Rejected item (idea, approach, assumption, or decision)
  • Rejection reason
  • Rejection authority (human, invariant, council)
  • Timestamp
  • Related context (session ID, related memory entries)

Outputs

  • Stored negative memory entry
  • Match results when queried
  • Audit trail of rejections and enforcement actions

Failure Modes

  • Missing entries: A rejection occurs but no negative memory entry is created.
  • Overly broad matching: Entries match legitimate new ideas that are superficially similar to rejected ones.
  • Stale entries: Entries that were valid at one point become invalid as project context changes, but are never updated.
  • Incomplete reasoning: The rejection reason is too vague to distinguish the rejected idea from valid alternatives.

Open Questions

  • Should negative memory entries expire or be versioned?
  • How should semantic similarity matching be tuned to avoid false positives?
  • Should agents be able to challenge negative memory entries through a formal appeal process?
  • How should negative memory interact with memory proposals?

Non-goals

  • Negative Memory is not a permanent blacklist of ideas. It does not mean a rejected idea can never be reconsidered.
  • It requires appeal, supersession, or expiration paths so that stale rejections do not block valid future decisions.
  • It helps prevent accidental reintroduction, not thoughtful reconsideration with new evidence.
  • It does not guarantee that rejected ideas will never resurface — only that matches are detected and flagged.

Relationship to Other IE Primitives

  • IE-001 Session Integrity Layer enforces negative memory at runtime.
  • IE-002 Hallucination Gauge uses negative memory matches as a drift signal.
  • IE-005 Memory Proposal Workflow may be used to formally challenge or retire negative memory entries.