Skip to content
InvariantEngine
Implemented Governed Lifecycle / Extensions Deferred 2026-05-14 by Joshua Couto

IE-005: Memory Proposal Workflow

Defines how durable memory changes are proposed, reviewed, approved, rejected, and audited.

memory-proposalhuman-approvalaudit
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

Implemented governed lifecycle / extensions deferred. The Engine supports [MEMORY_SUGGESTION] parsing, draft extraction, accepting a draft into a pending proposal, approving or rejecting proposals, and injecting active project-scoped memory records into session context.

Batch 3 also carries structured diagnosis-to-execution lineage into selected learning, creates pending proposals only after explicit review and feedback, requires a separate proposal disposition, and retains governed lineage on approved memory. Rejected and Needs Rework results cannot automatically produce approved memory.

Current persistence: core memory suggestion drafts, proposals, approval state, governed lineage payloads, and approved project memory records are durable when EF infrastructure is configured.

Current limitations: a generic versioned audit projection and Negative Memory enforcement are not implemented, and rejected proposals do not automatically become Negative Memory.

Abstract

The Memory Proposal Workflow governs all mutations to durable memory. No agent may directly modify durable memory. Instead, agents propose changes through a structured workflow that includes review, approval or rejection, and audit logging. This specification defines the proposal lifecycle, approval gates, and audit requirements.

Problem

If agents can directly write to durable memory, the memory store becomes untrustworthy. Any hallucination, drift artifact, or incorrect assumption that an agent writes to memory becomes part of the project’s permanent record. Subsequent sessions will treat this corrupted memory as the approved project state, compounding the error.

Definition

A Memory Proposal is a structured request to add, modify, or remove an entry in durable memory. Each proposal includes the proposed change, the reason for the change, supporting evidence, and the proposing agent’s session context. Proposals enter a review workflow before they affect durable memory.

Motivation

Durable memory is the foundation of session integrity. If memory can be corrupted by unreviewed agent writes, the entire integrity system is compromised. The Memory Proposal Workflow ensures that memory changes are deliberate, reviewed, and auditable.

A memory proposal is not accepted because an agent is confident. It is accepted only when the proposed change passes review, preserves auditability, and does not contradict higher-authority memory or invariants.

Runtime Behavior

  1. Propose: An agent creates a memory proposal with the proposed change, reason, and supporting evidence.
  2. Queue: The proposal enters a review queue.
  3. Review: The proposal is evaluated against existing approved memory and invariants. Negative Memory checks are future work.
  4. Decide: The reviewer approves or rejects the proposal with a reason.
  5. Apply: Approved proposals are applied to durable memory. Full version history is future work.
  6. Record rejection: Rejected proposals retain rejected state. Rejected proposals do not automatically become Negative Memory today.
  7. Audit: The entire lifecycle is logged.

Inputs

  • Proposed memory change (add, modify, or remove)
  • Change reason and justification
  • Supporting evidence
  • Proposing agent session context
  • Risk classification

Outputs

  • Proposal record with status (pending, approved, rejected)
  • Updated durable memory (if approved)
  • Rejection state and review metadata (if rejected)
  • Audit log entry

Failure Modes

  • Review bottleneck: Too many proposals require human review, creating delays.
  • Rubber-stamping: Automated review approves changes that should require human judgment.
  • Lost context: The proposal does not include enough context for the reviewer to make an informed decision.
  • Re-proposal loops: The same change is proposed repeatedly because the rejection does not generate a negative memory entry.

Open Questions

  • What criteria should determine whether a proposal requires human review?
  • How should conflicting proposals (submitted simultaneously) be resolved?
  • Should proposals have expiration dates?
  • How should the workflow handle bulk proposals from a single session?

Non-goals

  • The Memory Proposal Workflow does not accept changes because an agent is confident.
  • It does not enable automatic memory mutation without governance.
  • It does not replace human approval where policy requires review.
  • It preserves auditability and respects higher-authority constraints.
  • It does not make all memory changes equally costly — risk classification determines the review path.

Relationship to Other IE Primitives

  • IE-001 Session Integrity Layer routes memory mutations through the proposal workflow.
  • IE-003 Negative Memory could consume rejected proposals in a future implementation; the current Engine does not create Negative Memory entries.
  • IE-004 Review Councils may be used to evaluate proposals before human review in a future implementation.