Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/a.d.a.m.-adaptive-depth-and-mode/llms.txt

Use this file to discover all available pages before exploring further.

AI chat sessions can lose context — truncation, host restarts, or long sessions where the protocol context drifts out of the visible window. A.D.A.M. provides two recovery mechanisms: ADAM REMOUNT, which is always available regardless of bootstrap state, and ADAM PERSIST, which deploys a verified physical copy of the protocol source when a physical bind is confirmed.

​
ADAM REMOUNT

ADAM REMOUNT is the universal recovery entry point. It emits a compact recovery capsule that re-establishes the full protocol contract when pasted back into the chat — no files, no uploads, no re-activation required.

​
How to use it

1

Send ADAM REMOUNT

While ACTIVE, send exactly:
ADAM REMOUNT
The protocol emits the recovery capsule — a fixed text block starting with REMOUNT_BEGIN and ending with REMOUNT_END.
2

Copy the entire capsule body

Copy the complete capsule output, from REMOUNT_BEGIN through REMOUNT_END, inclusive. Every line. Do not wrap it in markdown code fences (```) — those are display-only and must not be included in the replay.
3

Paste the capsule back into the chat

In a new session (or the same session after context loss), paste the entire capsule body as your message. The message must contain the exact line sequence from REMOUNT_BEGIN through REMOUNT_END — nothing added, nothing removed.
4

Confirm ADAM_REMOUNT_OK

If the replay is recognized, the protocol replies with exactly 3 lines:
MODE: MID
ADAM_REMOUNT_OK
NEXT: send your question.
The protocol is now ACTIVE. Session context is restored.
5

Resume normally

Send your question. The protocol runs normally from ACTIVE state with fresh routing.

​
What the capsule contains

The remount capsule carries the key structural anchors and the essential protocol contract: 
REMOUNT_BEGIN
SYSTEM: A.D.A.M. - Adaptive Depth & Mode (REMOUNT CORE)
SPEC_SIGNATURE: ADAM_V5_SPEC_SIG
KERNEL_ANCHOR: ADAM_V5_SSOT_KERNEL
KERNEL_END_ANCHOR: ADAM_V5_SSOT_KERNEL_END

PRIORITY: REMOUNT_REPLAY > TRANSPORT_GATE > OFF_GATE > ACTIVE_CONTROL_COMMANDS > MANUAL_OVERRIDE > STRUCTURAL_KERNEL > STATE_DEFAULT > OUTPUT_CONTRACT
TAGS: MODE: LOW | MODE: MID | MODE: DEEP | MODE: MID -> POSSIBLE DEEP
BOOTSTRAP: upload is transport only; exact ADAM PING from TRANSPORT -> ADAM_PING_OK
REPLAY_EFFECT: exact replay of this capsule body -> ADAM_REMOUNT_OK and ACTIVE
REPLAY_MATCH: exact full line sequence from REMOUNT_BEGIN through REMOUNT_END, inclusive, after trimming leading and trailing whitespace on each line
COMMAND_MATCH: case-sensitive; exact full trimmed message for commands/probes; no aliases; manual overrides are prefix-only
DEEP: only after explicit yes to gating or manual override DEEP
GATING: if POSSIBLE DEEP -> last line exactly: Switch to DEEP? (yes/no)
AUDIT: if AUDIT_ON -> exact 4-line AUDIT with grounded ACTION:/RISK:/BASIS: or `-`; immediately before the final gating line if present, otherwise as the final block of the reply.
FAIL_CLOSED: if strict invariants cannot be satisfied reliably -> ADAM_UNSUPPORTED
REMOUNT_END

​
Why the capsule works

The capsule contains the three structural identity anchors (KERNEL_ANCHOR, SPEC_SIGNATURE, KERNEL_END_ANCHOR), the full priority ladder, and the core behavioral rules for routing, gating, audit, and fail-closed behavior. Pasting it back re-establishes the protocol contract in the visible context without needing the full spec file — making recovery available even when the original file is no longer mounted. Remount replay is detected at the top of the priority ladder (REMOUNT_REPLAY_DETECTED), before transport gate, off gate, and all other routing. It restores ACTIVE state from TRANSPORT, ACTIVE, or OFF.

​
Common Pitfalls

These mistakes will cause the replay to be rejected:
  • Do NOT wrap the capsule in markdown code fences. Pasting the capsule inside ```text ``` prevents detection. The replay requires the raw line sequence, not a code block.
  • Do NOT omit any lines. The match requires the exact full line sequence from REMOUNT_BEGIN through REMOUNT_END, inclusive.
  • Do NOT modify any internal line. Even one changed word, character, or label breaks the match. Leading and trailing whitespace per line is tolerated, but line content must be exact.
  • Do NOT use capsules from older versions. Capsules using pre-v5 identity literals are no longer valid. Always regenerate via ADAM REMOUNT from a live v5 session.

​
ADAM PERSIST

ADAM PERSIST deploys a verified physical copy of the current protocol source to the best available local destination. It provides a stronger recovery substrate than capsule replay when conditions allow it.

​
When it is available

ADAM PERSIST requires both of:
  1. BOOTSTRAP_CLASS is BOUND_RO or BOUND_RW
  2. Internal source fingerprint is INTACT
If either condition is not met: 
MODE: MID
PERSIST_BLOCKED: SOURCE_UNSAFE

​
How it works

The protocol selects a destination using a fixed cascade: mounted output → cwd → home → /tmp. The first destination that passes a write/readback canary check is selected. The source file (as physically identified during G0) is then copied to that destination, re-opened from disk, and compared against the source fingerprint. Success output — exactly 4 lines: 
MODE: MID
ADAM_PERSIST_OK
PATH: /home/user/A.D.A.M.v5.txt
PERSISTENCE_CLASS: VERIFIED

​
PERSISTENCE_CLASS values

ValueMeaning
VERIFIEDCopy written, re-opened from disk, and matched to source fingerprint. Physical copy confirmed.
WRITTEN_ONLYWrite completed, but readback confirmation is unavailable or incomplete. File may exist — confirmation is not guaranteed.
MISMATCHCopy was written and re-opened, but does not match the source fingerprint.
FAILEDWrite itself failed (L5 = COPY_FAIL). Public output is ADAM_PERSIST_FAIL — no PERSISTENCE_CLASS line is emitted.
PERSISTENCE_CLASS: VERIFIED means a verified physical copy exists at PATH as of this turn. It does not imply cross-turn durability or that the file will persist across session restarts. BOOTSTRAP_CLASS is unchanged — it is source-side only. PERSISTENCE_CLASS is destination-side only.

​
Other blocked and failure outputs

OutputMeaning
PERSIST_BLOCKED: SOURCE_UNSAFESource conditions not met (BOOTSTRAP_CLASS is not BOUND_RO/BOUND_RW, or fingerprint is not INTACT)
PERSIST_BLOCKED: NO_DESTNo destination passed the canary write/readback check
PERSIST_BLOCKED: AMBIGUOUS_DESTDestination selection was ambiguous
ADAM_PERSIST_FAILDestination was bound but the write itself failed

​
REMOUNT vs PERSIST

FeatureADAM REMOUNTADAM PERSIST
Always available✅ Yes — regardless of BOOTSTRAP_CLASS❌ No — requires BOUND_RO or BOUND_RW + INTACT fingerprint
What it doesEmits a recovery capsule for manual replayDeploys a verified physical copy of the protocol source to a local path
Recovery mechanismPaste the capsule body back into chat; works from TRANSPORT, ACTIVE, or OFFPhysical file at destination provides a stable source for future sessions
When to useFirst-line recovery: context drift, session loss, protocol state unclearEnhancement: when you want a physical copy on disk as a stronger recovery substrate
State afterACTIVE (after successful replay: ADAM_REMOUNT_OK)Unchanged — BOOTSTRAP_CLASS is not modified; PERSISTENCE_CLASS describes only the destination-side result
Requires physical bindNoYes (BOUND_RO or BOUND_RW)
Copies from fileN/AYes — from the physically identified source file, never from visible context text
Start with ADAM REMOUNT. It is always available regardless of bootstrap class, and it works from any state — TRANSPORT, ACTIVE, or OFF. Use it as your first recovery step whenever you suspect context loss. ADAM PERSIST is an enhancement that gives you a physical copy on disk when conditions allow it, but it does not replace REMOUNT. Both mechanisms work together: REMOUNT gets you back into ACTIVE immediately; PERSIST gives you a durable source to bootstrap from in future sessions.

Build docs developers (and LLMs) love

Get started for freeTalk to us