The entire A.D.A.M. protocol is a single portable text file. There is nothing to install and no account to create. You copy the file, paste it into your host’s instruction field, and send one command. From that point forward, every response is depth-labeled and governed by the protocol contract.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.
Activate A.D.A.M.
Get A.D.A.M.v5.txt
Open
A.D.A.M.v5.txt from the repository and copy its entire contents. The protocol is a single, self-contained text file — everything A.D.A.M. needs to govern session behavior is inside it.Load it into your host's instruction field
Paste the full file text into your chat host’s persistent instruction field — this is the system prompt, custom instructions, or equivalent surface depending on your host. The complete file must be visible in context. Truncation causes fail-closed behavior, because the protocol checks for specific required literals before activating.
Send the activation ping
In your first message, send exactly:This is the canonical bootstrap trigger. Uploading the file alone does not activate the protocol — the exact The
ADAM PING command is required. The host will reply with exactly 4 lines:BOOTSTRAP_CLASS line reports the source-side bootstrap state the protocol established during activation. See What BOOTSTRAP_CLASS means below.Send a second ADAM PING (liveness check)
Send The first ping ran the full bootstrap sequence. The second is a liveness check — it confirms A.D.A.M. is still active on the next turn without rerunning the bootstrap. You should see exactly 2 lines:If you see the full 4-line response again instead of 2 lines, the host may have lost context between turns. Check that the instruction field is persistent across messages.
ADAM PING a second time:Ask a normal question
Send any simple question, for example:A.D.A.M. will route this automatically to LOW — a fast, minimal reply — because the input has no structural complexity. You should see:Every normal reply while A.D.A.M. is active begins with a
MODE tag. That tag is the visible depth contract on every response.Manual depth override
You can force any depth mode by starting your message withLOW, MID, or DEEP followed by a space, then your content. The first word is interpreted as the mode token and the rest is your request.
DEEP as the first word when you want full decision support without waiting for the protocol to detect a candidate and ask for consent.
Note that the boundary check is strict: DEEP, (with a comma) or DEEP: are not valid override tokens. The first word must be exactly LOW, MID, or DEEP followed by a space or end of message.
What BOOTSTRAP_CLASS means
TheBOOTSTRAP_CLASS line in the first ADAM PING response reports what the protocol was able to verify about its own source context during activation. It describes the source-side state at bootstrap time — it does not describe host reliability across all future turns.
| Class | Meaning |
|---|---|
TEXT_ONLY | Protocol operability passed, but execution was not tentable or no stable physical bind to the source file was established. The protocol is active and functional; recovery via ADAM REMOUNT is available. |
BOUND_RO | A physical source file was found and bound by content identity. The source is readable but source-side write/readback was not verified. |
BOUND_RW | A physical source file was found, bound, and source-side write/readback was verified. The strongest source-side class. |
GHOST | The bootstrap ran but no sufficient classification basis remained. No stable physical bind was established. |
TEXT_ONLY is a normal, valid operating condition — not a failure. Most hosted chat environments will report TEXT_ONLY because they do not expose a writable local file system to the model. The protocol governs responses correctly in all four classes.
Lifecycle commands
After activation you can control the protocol session with the following core commands. All commands are case-sensitive and must occupy the entire message (exact full-message match after trimming).| Command | What it does |
|---|---|
ADAM PING | Confirm liveness while already active. Returns the 2-line response. |
ADAM OFF | Suspend the protocol. Replies become plain chat with no MODE tags. |
ADAM ON | Resume the protocol after ADAM OFF. |
ADAM REMOUNT | Emit a recovery capsule. If session context is lost, paste the capsule back exactly to re-enter ACTIVE. |
ADAM PERSIST | Deploy and verify a physical copy of the protocol source to the best available local destination (requires BOUND_RO or BOUND_RW bootstrap class). |
Diagnostic commands
Operator commands are available while the protocol isACTIVE. They do not change protocol state.
| Command | What it does |
|---|---|
ADAM SELF TEST | Run the external self-test probe (ADAM_SELF_TEST.md). Returns SOURCE_FILE_UNAVAILABLE ADAM_SELF_TEST.md if the file is not in context. |
SYS STATUS | Run the external system status probe (SYS_STATUS.md). Returns SOURCE_FILE_UNAVAILABLE SYS_STATUS.md if the file is not in context. |
TRACE INPUT | Emit a strict forensic trace of the last visible user input: character count, head, tail, and structural classification. |
UNSUPPORTED WHY | After receiving ADAM_UNSUPPORTED, send this command to receive a single-line CAUSE <CLASS> diagnostic. |
How It Works
Understand the priority ladder, structural kernel, and output contract that govern every reply.
Modes
Deep-dive into LOW, MID, DEEP, and the POSSIBLE DEEP gating flow.
Core Commands
Full reference for ADAM PING, ADAM OFF, ADAM ON, ADAM REMOUNT, and ADAM PERSIST.
Recovery and Remount
How to use ADAM REMOUNT to recover a lost session context.