IE-001: Session Integrity Layer

Implementation Status

Architecture Draft / Implemented Governed Foundations. The current Engine contains a substantial human-governed improvement workflow, but the full Session Integrity Layer is not implemented as a universal end-to-end enforcement boundary.

Implemented foundations include bounded project onboarding, server-authoritative deterministic diagnosis, governed Brief → Outline → Plan artifacts, structured lineage through a paste-ready Codex packet, pasted-result analysis, explicit human review, execution feedback, separately dispositioned memory proposals, Context Packs, Trusted Restart Pack v1/v2 artifacts, a durable Contradiction Queue, Hallucination Gauge v0 deterministic risk scoring, and read-only Roslyn inventory.

Current boundary: the combined governed path has survived a real API/client restart against durable state. That proof does not establish universal runtime integrity or code correctness. Universal runtime gating, Negative Memory, Review Councils, Context Compression, semantic contradiction detection, and autonomous source or pull-request actions are not implemented. Human approval remains the truth gate.

Abstract

The Session Integrity Layer is the central runtime component of InvariantEngine. It provides continuous validation that an agent session remains aligned with durable memory, approved facts, rejected decisions, source-grounded evidence, explicit invariants, and human intent. This specification defines the layer’s responsibilities, inputs, outputs, runtime behavior, and failure modes.

Problem

Long-running agent sessions degrade over time. As context windows fill, as retrieval becomes approximate, as sessions restart and resume, the agent’s working state drifts from the project’s approved state. Without a runtime validation layer, this drift is invisible until it produces incorrect output, violates constraints, or reintroduces rejected ideas.

Current approaches rely on larger context windows, better retrieval, or post-hoc evaluation. These are necessary but insufficient. They do not provide continuous, runtime-level validation of session state against governed memory.

Definition

The Session Integrity Layer is a runtime component that routes selected agent actions through validation checks before allowing execution. The scope of validation is policy-defined — not every internal reasoning step is intercepted, but governed actions (outputs, memory writes, tool calls, architectural decisions) are validated against:

• Durable Project Memory: Approved facts, decisions, and historical context.
• Negative Memory: Rejected ideas, invalid assumptions, and blocked paths.
• Source Grounding: Evidence chains linking output to approved sources.
• Invariant Validator: Project-level constraints the runtime is designed to enforce.
• Hallucination Gauge: Drift-risk scoring for the current session.

Motivation

Agent reliability in long-running systems cannot be achieved through prompt engineering alone. A runtime layer is needed that can answer, at any point during execution: Does the current session still align with the project’s approved, governed state?

The Session Integrity Layer provides this answer as a runtime gate on governed agent actions, not as a post-hoc check.

Runtime Behavior

1. Intercept: Selected agent actions (outputs, memory writes, decisions) are routed through the layer according to policy.
2. Validate: The action is checked against durable memory, negative memory, invariants, and source grounding.
3. Score: The Hallucination Gauge evaluates the cumulative drift risk for the session.
4. Respond: Based on validation results and drift score, the layer takes one of the following actions:
   • Pass: The action is allowed to proceed.
   • Warn: The action proceeds but a warning is logged.
   • Repair: The action is modified to align with durable memory.
   • Re-ground: The session is reset against durable memory.
   • Escalate: The action is escalated to human review.
   • Abandon: The session is terminated.

Inputs

• Agent action (proposed output, memory write, or decision)
• Current durable memory state
• Current negative memory state
• Active invariants
• Source grounding evidence
• Current session drift score

Outputs

• Validation result (pass, warn, repair, re-ground, escalate, abandon)
• Updated drift score
• Validation evidence (reasons for the decision)
• Audit log entry

Failure Modes

• Stale memory: Durable memory has not been updated to reflect recent approved changes, causing false rejections.
• Missing negative memory: Rejected ideas are not recorded, allowing resurrection.
• Incomplete invariants: Constraints are not fully specified, allowing violations to pass validation.
• Gauge miscalibration: Drift scoring thresholds are too permissive or too aggressive.
• Validation latency: The layer introduces unacceptable latency into the agent loop.

Open Questions

• What is the optimal granularity for validation? Per-token, per-action, per-step?
• How should the layer handle conflicting signals from different validation sources?
• What is the right default behavior when the layer cannot determine validity?
• How should validation thresholds be tuned for different project types?

Non-goals

• The Session Integrity Layer does not guarantee correctness of agent output.
• It does not replace human judgment for high-stakes decisions.
• It does not validate every token or private reasoning step — only governed actions routed by policy.
• It does not prove that a session is aligned; it provides evidence-based validation signals.

Relationship to Other IE Primitives

The Session Integrity Layer is the orchestrator. It depends on all other primitives:

• IE-002 Hallucination Gauge provides drift scoring.
• IE-003 Negative Memory provides rejected-idea suppression.
• IE-004 Review Councils provide critic-based evaluation.
• IE-005 Memory Proposal Workflow governs memory mutations.