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.

This page walks you through loading and activating A.D.A.M. v5 on any compatible AI chat host. The entire process takes under a minute and requires no installation, no API keys, and no code. By the end you’ll have a live session with visible mode tags, structural routing, and DEEP gating enabled.
Prerequisites: You need an AI chat host with a persistent system prompt or instruction field that can hold the full protocol text without truncation. Common options include:
  • ChatGPT — Custom Instructions (Settings → Personalization → Custom Instructions)
  • Claude — Projects (create a project and set a project instruction)
  • Any LLM interface with a configurable system prompt field
The host must be able to hold several thousand tokens of instruction text and apply them as an active behavioral contract — not just display them as context. If the host silently truncates or ignores the instruction field, A.D.A.M. will fail closed with ADAM_UNSUPPORTED.
1

Get the protocol file

Open the canonical protocol file in the A.D.A.M. GitHub repository:A.D.A.M.v5.txt on GitHub →Select all of the file’s contents and copy them to your clipboard. The file is plain text — no formatting, no special encoding.
Always copy from the canonical file in the repository. Do not paraphrase, summarize, or trim any section. The protocol includes a level-1 operability check during bootstrap that verifies the presence of specific anchor literals. If any required packet is missing, the bootstrap will fail closed.
2

Load into your host

Paste the full file contents into your host’s instruction or system prompt field. Save or apply the setting according to your host’s interface.
The entire file must be loaded. Truncation breaks activation. A.D.A.M. verifies that all required protocol packets are present in visible context during ADAM PING. If your host’s instruction field has a character limit that cuts off part of the file, the bootstrap will output ADAM_UNSUPPORTED rather than partially activating. Check that your host’s instruction field accommodates the full file length before proceeding.
After pasting, do not send any message yet. The protocol is now in TRANSPORT state — present in context but not yet active. Any message other than ADAM PING at this stage will return a two-line transport prompt asking you to activate first.
3

Send the first ADAM PING

Start a new conversation (or use the chat window if you’re already in one) and send exactly:
ADAM PING
The command is case-sensitive and must be the entire message — no leading or trailing text. If activation succeeds, the assistant will reply with exactly 4 lines:
MODE: MID
ADAM_PING_OK
CONTROL: first word LOW | MID | DEEP sets mode.
BOOTSTRAP_CLASS: TEXT_ONLY | BOUND_RO | BOUND_RW | GHOST
The BOOTSTRAP_CLASS line will show one of the four values depending on what the host can verify about the protocol source at activation time. See Understanding the bootstrap output below for what each value means.
The 4-line bootstrap output is a strict contract. The exact lines, in exact order, with exact wording are required. If your host reformats, paraphrases, or merges these lines, the activation did not complete cleanly — that is a host compatibility issue, not a protocol variant.
4

Send the second ADAM PING (liveness check)

Send ADAM PING a second time:
ADAM PING
Because A.D.A.M. is already in ACTIVE state, this is a liveness-only check. You’ll see exactly 2 lines — no bootstrap output:
MODE: MID
ADAM_PING_OK
This confirms the protocol is still active on the next turn. The second ping deliberately does not re-run the bootstrap sequence or reset the session state. It is a lightweight confirmation that the contract is holding.
5

Ask a normal question

Send any simple factual question to see automatic LOW routing in action:
capital of germany
Expected output:
MODE: LOW
Berlin.
A.D.A.M.’s structural kernel classified this as a simple factoid (AUTO_LIGHT) and routed it to MODE: LOW — fast, minimal, no structure overhead. The mode tag on the first line confirms the routing decision. From here, the protocol will recompute the appropriate depth on every subsequent message.

​
Understanding the bootstrap output

The 4-line bootstrap reply from the first ADAM PING carries information about the state of the protocol source as the host observed it during activation. Here is what each line means:
LineWhat it tells you
MODE: MIDThe bootstrap reply itself is routed at MID depth. This is fixed — it does not reflect the depth of your next question.
ADAM_PING_OKLevel-1 protocol operability check passed and the bootstrap sequence completed successfully. A.D.A.M. is now ACTIVE.
CONTROL: first word LOW | MID | DEEP sets mode.Reminder that manual override is available. Prefix any message with LOW, MID, or DEEP (followed by a space) to force that depth for one reply.
BOOTSTRAP_CLASS: <value>Records what the protocol could verify about its source file during activation. See the table below for the four possible values.
BOOTSTRAP_CLASS values:
ValueMeaning
TEXT_ONLYThe protocol text is visible in context, but no physical source file could be established. The protocol is fully operational — TEXT_ONLY is a valid operating condition, not a failure. Recovery via ADAM REMOUNT is available.
BOUND_ROA physical source file was found and verified via content anchor. Read access confirmed; write/readback was not available on the source side. Fully operational.
BOUND_RWA physical source file was found, verified, and source-side write/readback was confirmed. Strongest source-side binding.
GHOSTThe physical bootstrap ran but no sufficient classification basis was established. The protocol is operational, but source-side identity is unverified. Recovery via ADAM REMOUNT is available.
BOOTSTRAP_CLASS is a source-side classification only. It tells you what the host could verify about the protocol file at activation time — it does not predict how reliable the host will be across turns, nor does it guarantee cross-session persistence. Regardless of bootstrap class, ADAM REMOUNT is always available as a recovery path.

​
What if activation fails?

If the host cannot satisfy the protocol’s strict invariants — missing required packets in the protocol text, truncated context, output reformatting that breaks the strict contract — the reply will be: 
ADAM_UNSUPPORTED
This is intentional. A.D.A.M. prefers failing closed over pretending to be active with a degraded or approximate contract. ADAM_UNSUPPORTED is not an error message to work around — it is the protocol correctly reporting that the host cannot honor the full output contract. Common causes:
  • The instruction field was truncated and one or more required protocol packets are missing from visible context.
  • The host rewrites or reformats assistant output in a way that prevents exact strict command lines from being emitted.
  • The host does not mount the instruction field as an active behavioral contract (some hosts treat it as passive context only).
For host-specific compatibility notes and known limitations, see the Compatibility Reference.
If you receive ADAM_UNSUPPORTED and want to diagnose why, send the exact command UNSUPPORTED WHY in the same session. The protocol will return a single-line cause classification (e.g., CAUSE HOST_FORMAT or CAUSE UNKNOWN) based on what it can infer from visible context.

​
Next steps

Depth modes

Learn the exact behavior of LOW, MID, and DEEP — when each is chosen automatically, how manual override works, and what structural signals trigger POSSIBLE DEEP.

Command reference

Full reference for all A.D.A.M. commands: ADAM PING, ADAM OFF/ON, ADAM REMOUNT, TRACE INPUT, SYS STATUS, and more — with exact input and output contracts.

DEEP gating

Understand how the structural kernel detects DEEP candidates, how the consent flow works, and when to use manual DEEP override instead of waiting for automatic detection.

Self-test & diagnostics

Run ADAM SELF TEST to verify expected protocol behavior against the external probe, and use SYS STATUS to check session health during long or complex workflows.

Build docs developers (and LLMs) love

Get started for freeTalk to us