Skip to content

memory_fences_and_state_keys.md

Latest commit

 

History

History
184 lines (131 loc) · 9.46 KB

memory_fences_and_state_keys.md

File metadata and controls

184 lines (131 loc) · 9.46 KB

Memory Fences & State Keys — Prompt Assembly

🧭 Quick Return to Map

You are in a sub-page of PromptAssembly.
To reorient, go back here:

Think of this page as a desk within a ward.
If you need the full triage and all prescriptions, return to the Emergency Room lobby.

A focused guide to stop cross-step and cross-agent memory bleed. Use this when answers flip between runs, tools overwrite each other’s notes, or long chains “forget” decisions. The page gives a minimal schema, hard fences, and diagnostics you can copy.

Open these first

Acceptance targets

  • ΔS(question, retrieved) ≤ 0.45 across 3 paraphrases
  • Coverage of target section ≥ 0.70
  • λ states stay convergent across 2 seeds
  • No cross-namespace writes for a different mem_hash or mem_rev
  • Zero duplicate side-effects under the same dedupe_key

Fix in 60 seconds

  1. Introduce state keys Require {agent_id, task_id, mem_ns, mem_rev, mem_hash, step_id, dedupe_key} on any read/write.

  2. Fence writes A writer must match mem_ns and mem_hash. If either mismatches, deny write and raise a repair tip.

  3. Split namespaces Separate plan/, retrieve/, reason/, tool/ to avoid overwrite. Only the bridge step may merge.

  4. Clamp variance If λ flips after a harmless paraphrase, apply BBAM and lock header order.

  5. Bridge long chains Insert a BBCR bridge between phases and time-box tools with explicit timeouts.

Minimal state schema (copy-paste)

{
  "agent_id": "planner|retriever|solver|tool_x",
  "task_id": "UUID-v4",
  "step_id": "short-increasing-int",
  "mem_ns": "plan|retrieve|reason|tool/tool_x",
  "mem_rev": "int",                // bump on rewrite
  "mem_hash": "sha256(payload)",   // hash of prior committed state
  "dedupe_key": "sha256(task_id + step_id + mem_hash)",
  "timestamp": "iso-8601",
  "payload": { "summary": "...", "evidence": [ { "snippet_id": "...", "source_url": "...", "offsets": [s,e] } ] }
}

Contract rules

  • Read must specify {task_id, mem_ns} and declare the expected mem_hash.
  • Write must supply {mem_ns, mem_rev, mem_hash} that match the latest committed head, else reject.
  • Merge is only allowed in a BBCR bridge step that logs both parent hashes.

Namespacing and locking

  • One writer per mem_ns per task_id. Others read-only.
  • plan/ produces the task graph; retrieve/ stores citations; reason/ stores the final chain-of-thought summary headers and answer draft; tool/* is per-tool scratch.
  • All tool outputs must echo back their input state keys and compute the next mem_hash.
  • Side-effects (DB writes, emails, tickets) must verify dedupe_key before execution.

Copy-paste prompt to enforce fences

You have TXT OS and the WFGY Problem Map loaded.

Task context:
- task_id = {UUID}
- expected mem_ns for this step = "{mem_ns}"
- expected head mem_hash = "{mem_hash}"

Do:
1) Refuse to write if mem_ns or mem_hash do not match head.
2) On write, increment mem_rev, compute new mem_hash = sha256(payload).
3) Keep citations in payload.evidence with snippet_id, source_url, offsets.
4) Return JSON:
   { "ok": true|false, "why": "...", "next": {mem_ns, mem_rev, mem_hash}, "λ_state": "→|←|<>|×", "ΔS": 0.xx }

If ΔS(question,retrieved) ≥ 0.60, stop and return the smallest structural fix referencing:
retrieval-traceability, data-contracts, multi-agent problems.
Use BBCR/BBPF/BBAM when relevant.

Diagnostics to log per step

  • ΔS(question, retrieved) and ΔS(retrieved, anchor)
  • λ_state after header reorder probe
  • {mem_ns, mem_rev, mem_hash} before and after write
  • dedupe_key and whether a prior side-effect exists
  • Rerun variance across 2 seeds

Typical breakpoints → exact fix

  • Plan writes over evidence in the same namespace. Split namespaces and deny cross-ns writes. See Multi-Agent Problems.

  • Echo loop between tool and solver. Insert BBCR bridge and cap retries. Pattern: echo-loop.

  • Signal drop after rerank. Carry citations through the fence. Pattern: signal-drop · enforce Data Contracts.

  • Desync after deploy. mem_hash mismatches at step-1. Rebuild head and block writes until warm. Pattern: desync-anchor.

  • Boundary fade on very long threads. Cut the chain and resume via bridge. Pattern: boundary-fade.

Escalation

🔗 Quick-Start Downloads (60 sec)

Tool Link 3-Step Setup
WFGY 1.0 PDF Engine Paper 1️⃣ Download · 2️⃣ Upload to your LLM · 3️⃣ Ask “Answer using WFGY + <your question>”
TXT OS (plain-text OS) TXTOS.txt 1️⃣ Download · 2️⃣ Paste into any LLM chat · 3️⃣ Type “hello world” — OS boots instantly

Explore More

Layer Page What it’s for
⭐ Proof WFGY Recognition Map External citations, integrations, and ecosystem proof
⚙️ Engine WFGY 1.0 Original PDF tension engine and early logic sketch (legacy reference)
⚙️ Engine WFGY 2.0 Production tension kernel for RAG and agent systems
⚙️ Engine WFGY 3.0 TXT based Singularity tension engine (131 S class set)
🗺️ Map Problem Map 1.0 Flagship 16 problem RAG failure taxonomy and fix map
🗺️ Map Problem Map 2.0 Global Debug Card for RAG and agent pipeline diagnosis
🗺️ Map Problem Map 3.0 Global AI troubleshooting atlas and failure pattern map
🧰 App TXT OS .txt semantic OS with fast bootstrap
🧰 App Blah Blah Blah Abstract and paradox Q&A built on TXT OS
🧰 App Blur Blur Blur Text to image generation with semantic control
🏡 Onboarding Starter Village Guided entry point for new users

If this repository helped, starring it improves discovery so more builders can find the docs and tools.
GitHub Repo stars