ITHZ MCP

Project memory that agents can inspect

ITHZ MCP separates what happened from what the system inferred. It gives agents bounded, source-aware project context and adds a guarded opt-in canary that can challenge stored memory without silently gaining authority over the project.

What it brings

  • The project owns the memory: agents receive deterministic, task-specific context packs instead of depending on one chat or scanning the whole archive.
  • Events remain immutable while decisions, risks, gates and claims are typed records with provenance, validity and explicit supersession.
  • Source-bound records can be checked against exact evidence; unverified or detached memory can be blocked or quarantined instead of being trusted automatically.
  • Implementers, reviewers and independent opponents can receive different evidence views, including a raw-first path that reduces shared-summary bias.
  • Checkpoint hashes, command receipts and final-review manifests make the reviewed project state reproducible, while Git remains the source-code history and ITHZ MCP remains review evidence rather than deployment authority.
Memory architecture

Claims no longer masquerade as facts

Classic project notes are useful until old and new decisions conflict or a summary loses its source. ITHZ MCP keeps an immutable episode trail and builds typed abstractions above it: a decision, risk, gate or claim can point to evidence, declare its scope and be superseded without erasing history.

The practical result is smaller, role-specific context. An implementer can receive the decisions and constraints needed for a task, while a reviewer or cross-lab opponent can inspect a more independent evidence path. The model is not made magically smarter; it becomes more consistent and easier to audit.

Guarded opposition

A canary with brakes, not a second authority

A long-lived memory can preserve a mistake as efficiently as a correct decision. The canary therefore tests suspicious or conflicting memory in a deliberately constrained lane: it starts disabled, reads evidence only, has time and case limits, and can be stopped with a kill switch.

Its verdict cannot execute a change or write itself into the archive as truth. Promotion still depends on traceable receipts, independent review and the human or workflow authority that already governs the project.

Upgrade path

Existing project memory does not need to be rewritten

Existing project.ithz archives remain readable. The safe upgrade is to back up the archive, install the current package in a fresh Python 3.10+ environment, run the memory-integrity and canary checks, and keep the canary disabled until the project explicitly opts in.

Older records can remain as legacy evidence while new work starts producing stronger provenance and v2 review receipts. Very old or customized installations still need a project-specific trial and a tested rollback; compatibility is not a reason to skip verification.