A.D.A.M. assumes the host provides a stable instruction surface that can hold the full protocol file without truncation. TheDocumentation 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.
BOOTSTRAP_CLASS at activation tells you how well the current host satisfies the protocol’s requirements — from a fully verified physical bind (BOUND_RW) down to plain visible-text operation (TEXT_ONLY). All four bootstrap states are valid; what varies is how much the protocol can verify about its own source.
Minimum host requirements
For A.D.A.M. to operate reliably, the host needs to satisfy all of the following:- A persistent instruction or system prompt field capable of holding the full
A.D.A.M.v5.txtcontent without truncation. Hosts with very short system prompt limits may not support the full protocol. - The ability to follow strict output formats — exact line counts, fixed literals, no extra prose after a strict command line.
- No forced reformatting of assistant output that breaks strict command lines. Some hosts add markdown formatting, inject banners, or restructure output in ways that invalidate strict contracts.
ADAM PINGmust be the activation trigger. Uploading or pasting the file does not activate the protocol — upload is transport only. ExactADAM PINGis always required.
What is outside protocol scope
A.D.A.M. governs assistant-authored output format, mode routing, DEEP gating, bounded audit behavior, and strict command outputs. It explicitly does not govern:- Host instruction hierarchy — how the host prioritizes the system prompt versus other inputs or injected context.
- Upload mounting semantics — whether an uploaded file becomes active context, or remains a passive attachment.
- Host UI wrappers, banners, or reasoning panes — UI chrome injected by the host is outside protocol control.
- Tool availability and cross-chat persistence — the protocol cannot guarantee which tools are available or that session state survives across conversations.
- Truncation and rate limits — if the host truncates context or applies wrapper interference, the protocol fails closed rather than inferring missing sections.
- Hard safety or policy limits imposed by the underlying model — these are outside-the-protocol material exceptions.
Known host limitations
| Limitation | Description |
|---|---|
| Upload is transport only | Pasting or uploading A.D.A.M.v5.txt does not activate the protocol. The file must be loaded as active instructions, and exact ADAM PING must be sent to trigger the bootstrap boundary check. |
| Truncated context | If the protocol file is too large for the host’s context window, sections may be cut silently. The level 1 protocol operability check will fail on missing required literal packets and output ADAM_UNSUPPORTED. |
| Host-forced formatting | Some hosts add markdown formatting, inject headings, or restructure assistant output. This can break strict command line counts or merge lines that must remain separate. |
| Reasoning pane / thinking mode | Some hosts display intermediate model reasoning in a separate pane. This reasoning is outside protocol control and is not part of strict output validation. |
| Short system prompt limits | Hosts with very short system prompt limits may not be able to hold the full A.D.A.M.v5.txt content. Partial protocol visibility causes the operability check to fail. |
| Probe file availability | External probes (ADAM SELF TEST, SYS STATUS) require their respective source files (ADAM_SELF_TEST.md, SYS_STATUS.md) to be available in visible context. If unavailable, the strict fallback SOURCE_FILE_UNAVAILABLE <FILENAME> is returned. |
Interpreting bootstrap states by host type
BOOTSTRAP_CLASS at activation is the clearest signal of what the current host supports:
BOUND_RW — The host supports code execution and source-side write/readback. This is the strongest bootstrap state. The anchor tuple matched a unique physical candidate and a sibling probe write/readback succeeded. ADAM PERSIST is available.
BOUND_RO — The host mounts the file as active context with a stable physical identity, but source-side write/readback is not available. Full protocol capability is present. ADAM PERSIST is available for destination-side copy. ADAM REMOUNT is the recovery path.
TEXT_ONLY — The most common state on consumer AI chat hosts. Protocol operability passed and the protocol operates fully from visible instruction text, but execution was not tentable or no stable physical bind was established. The KERNEL HEADER is the structural hold. ADAM REMOUNT is the recovery path.
GHOST — Execution ran but physical classification failed — no usable candidate was found within bounded discovery, or internal outputs were inconsistent. ADAM REMOUNT is the recovery path.
See Bootstrap Classes for a detailed breakdown of each state and the internal discovery process.
When ADAM_UNSUPPORTED appears
ADAM_UNSUPPORTED during ADAM PING means the level 1 protocol operability check failed — required literal packets were missing from visible context before physical classification could even proceed. This is distinct from a bootstrap class.
Not all ADAM_UNSUPPORTED outputs are permanent. Use UNSUPPORTED WHY to get the CAUSE class:
| CAUSE | Meaning | Next step |
|---|---|---|
HOST_FORMAT | Host-side truncation, incomplete visible protocol context, wrapper interference, or forced formatting broke a strict invariant. | Try a host with a larger context window, or load the protocol file in a fresh context. |
HARD_STOP | A hard invariant was violated at the protocol level. | Check that the full unmodified A.D.A.M.v5.txt is loaded. |
AUDIT_FORMAT | The audit block could not be satisfied reliably. | Try a different chat interface for the same model. |
CONTROL_STRICT | A strict command output could not be exactly satisfied. | Check whether the host reformats or merges output lines. |
CONFLICT | Internal conflict preventing strict output. | Check the full protocol file is loaded without modification. |
UNKNOWN | Best-effort inference could not determine the cause. | Reload the protocol in a fresh context and retry. |
ADAM PING.
If caused by forced formatting: Try a different chat interface for the same underlying model. Some UIs reformat output while the API does not.
If persistent across hosts: The underlying model may not follow strict output contracts reliably. ADAM_UNSUPPORTED is intentional — the protocol fails closed rather than pretending to be active when its output contract cannot be satisfied.