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.

BOOTSTRAP_CLASS is the fourth line of the ADAM PING bootstrap output. It records the source-side activation state established by the bootstrap boundary check (G0) — not the destination, not cross-turn persistence, not host reliability. It tells you how the protocol source was classified during this activation. 
MODE: MID
ADAM_PING_OK
CONTROL: first word LOW | MID | DEEP sets mode.
BOOTSTRAP_CLASS: TEXT_ONLY | BOUND_RO | BOUND_RW | GHOST

​
The four classes

​
TEXT_ONLY

Protocol operability passed but execution was not tentable, or no stable physical bind was established. This is the most common class on consumer AI chat hosts that do not expose a code execution surface. In TEXT_ONLY, the KERNEL HEADER is the structural hold — the protocol operates fully from the visible instruction text. REMOUNT is the recovery path if the session needs to be re-entered. All routing, gating, modes, and strict commands are fully available; only the source-side physical bind is absent. TEXT_ONLY is a valid operating condition, not a failure.

​
BOUND_RO

Source-side physical bind established. The source file was found and matched via the anchor tuple (KERNEL_ANCHOR, SPEC_SIGNATURE, KERNEL_END_ANCHOR) within the bounded discovery pass. Read-only at source side — no write/readback was confirmed. In BOUND_RO, the protocol has a stable physical identity for the source file. ADAM PERSIST is available and can attempt a destination copy. ADAM REMOUNT remains the universal recovery path.

​
BOUND_RW

Source-side physical bind established with verified 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 on the source-side path. In BOUND_RW, ADAM PERSIST is available. Internal opportunistic deploy (L6) may also have run automatically, though its result is internal-only and does not alter BOOTSTRAP_CLASS.

​
GHOST

Physical bootstrap ran (execution was tentable) but no sufficient classification basis remained — no usable candidate was found within the bounded discovery pass, or later internal outputs were inconsistent without yielding a stable non-physical class. Examples: ambient discovery found no local roots, or L0 returned NO. GHOST is a valid operating condition. ADAM REMOUNT is the recovery path.

​
Class comparison

ClassExecution tentable?Physical bind?Write/readback?Recovery path
TEXT_ONLYNot tentable, or bind not stableNoNoADAM REMOUNT
BOUND_ROYesYes (anchor tuple matched)NoADAM REMOUNT / ADAM PERSIST
BOUND_RWYesYes (anchor tuple matched)Yes (sibling probe verified)ADAM REMOUNT / ADAM PERSIST
GHOSTYes (ran but failed)NoNoADAM REMOUNT

​
What BOOTSTRAP_CLASS does NOT mean

BOOTSTRAP_CLASS is source-side only. Misreading it as a host reliability score or persistence guarantee is a common source of confusion.
  • It does not imply destination selection — that is PERSISTENCE_CLASS, set by ADAM PERSIST.
  • It does not guarantee cross-turn persistence. The class reflects what G0 could prove in a single bounded pass during the current activation.
  • It does not mean the host itself is reliable forever. Host truncation, context loss, or session boundaries are outside protocol scope.
  • Lower classes (TEXT_ONLY, GHOST) are valid operating conditions, not failures. The protocol operates fully in all four classes; only the source-side physical evidence differs.

​
ADAM_UNSUPPORTED vs. bootstrap classes

ADAM_UNSUPPORTED during ADAM PING in TRANSPORT means the protocol operability check (level 1) failed — required literal packets were missing from visible context. This is a different outcome from any bootstrap class:
  • Bootstrap classes (TEXT_ONLY, BOUND_RO, BOUND_RW, GHOST) are set when level 1 passes.
  • ADAM_UNSUPPORTED is set when level 1 fails — before physical classification (G0) can even proceed.
If you receive ADAM_UNSUPPORTED during activation, the protocol cannot determine a BOOTSTRAP_CLASS at all. See the compatibility guide for next steps.

​
Bootstrap discovery process

The bootstrap boundary (G0) runs in two levels when exact ADAM PING is sent in TRANSPORT: Level 1 — protocol operability check Required literal packets must be present as exact visible matches in the current visible context before any physical classification proceeds. Required packets include the identity packet (KERNEL_ANCHOR, SPEC_SIGNATURE, KERNEL_END_ANCHOR), the transport/activation packet, the strict bootstrap output packet, the fail-closed packet, and the state/routing packet. Any missing or partial packet fails level 1 and outputs only ADAM_UNSUPPORTED. Level 2 — physical classification If level 1 passes, G0 attempts an execution check. If execution is not tentable, the class lands immediately in TEXT_ONLY. If execution is tentable, bounded discovery proceeds:
  • Root candidate list: cwd, home, /mnt, /tmp (in that fixed order)
  • Maximum discovery depth: 1 for cwd, home, tmp; 2 for /mnt
  • Discovery is content-based via KERNEL_ANCHOR — not filename-based
  • Discovery stops immediately after the first unique sufficient physical candidate is found
  • No whole-filesystem scanning; no static host maps; no provider-name routing
The anchor tuple (KERNEL_ANCHOR, SPEC_SIGNATURE, KERNEL_END_ANCHOR) must all be present in the same candidate file for a bind to be established. If no usable candidate is found within the bounded pass, the class is GHOST. G0 must not simulate, infer, or approximate discovery results. If direct host evidence is insufficient, the output is ADAM_UNSUPPORTED.

​
PERSIST and bootstrap

ADAM PERSIST is a manually triggered deploy-and-verify command. It is available only when BOOTSTRAP_CLASS is BOUND_RO or BOUND_RW — states where a stable source-side physical identity was established during G0. For TEXT_ONLY or GHOST, ADAM PERSIST is blocked (PERSIST_BLOCKED: SOURCE_UNSAFE). Use ADAM REMOUNT for session recovery in those states. ADAM PERSIST sets PERSISTENCE_CLASS (destination-side), which is entirely separate from BOOTSTRAP_CLASS (source-side). Persisting a copy does not upgrade or change BOOTSTRAP_CLASS.
If you get TEXT_ONLY on a host you expected to support physical binding, verify that the full protocol file is loaded as active instructions (not just uploaded as a file attachment) and that code execution is not disabled on that platform. Upload alone is transport only — ADAM PING is always required for activation.

Build docs developers (and LLMs) love

Get started for freeTalk to us