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.
ADAM SELF TEST runs the external test probe defined in ADAM_SELF_TEST.md against the current session. It verifies that routing, DEEP gating, mode tagging, and strict outputs are all behaving correctly.
How to run it
Send the following command while the session is ACTIVE (not TRANSPORT or OFF):Output format
The probe emits one line per test in the following form:- No mode tag. No prose. No explanation.
- If a test requires clarification before it can be evaluated, append:
; required: ...
Key test cases
Bootstrap tests (T0–T3): upload, transport gate, canonical ADAM PING
Bootstrap tests (T0–T3): upload, transport gate, canonical ADAM PING
These tests verify the fundamental activation sequence. The protocol must not
activate on file upload alone — only an exact
ADAM PING from TRANSPORT state
triggers bootstrap.| Test | What it verifies |
|---|---|
| T0 | Upload-only passive turn: no assistant output is emitted; state remains TRANSPORT |
| T1 | Transport gate after upload but before handshake: output is exactly MODE: MID then NEXT: send ADAM PING. |
| T2 | Operator command sent while TRANSPORT (e.g. ADAM SELF TEST): same transport gate response |
| T3 | Canonical ADAM PING in TRANSPORT: exactly 4 lines — MODE: MID, ADAM_PING_OK, CONTROL: first word LOW | MID | DEEP sets mode., BOOTSTRAP_CLASS: <class> |
| T3c | Bootstrap hard stop: assistant output ends exactly after line 4; no extra prose, citations, or reformatting permitted |
| T3d / T3e | ADAM OFF, ADAM ON, and ADAM REMOUNT while TRANSPORT all return the 2-line transport gate response |
BOOTSTRAP_CLASS vocabulary tests (T3a series): TEXT_ONLY, BOUND_RO, BOUND_RW, GHOST
BOOTSTRAP_CLASS vocabulary tests (T3a series): TEXT_ONLY, BOUND_RO, BOUND_RW, GHOST
The fourth line of the TRANSPORT
ADAM PING response must be exactly one of
the four public bootstrap classes. These tests verify correct mapping from
internal G0 discovery results to the public class label.| Test | What it verifies |
|---|---|
| T3a | Fourth line is exactly one of BOOTSTRAP_CLASS: TEXT_ONLY, BOOTSTRAP_CLASS: BOUND_RO, BOOTSTRAP_CLASS: BOUND_RW, or BOOTSTRAP_CLASS: GHOST |
| T3a1 | Non-physical or ambiguous source maps to TEXT_ONLY |
| T3a2 | Stable physical read-only source maps to BOUND_RO |
| T3a3 | Stable physical source with write/readback verified maps to BOUND_RW |
| T3a4 | Physical bootstrap ran but no stable class remained maps to GHOST |
| T3a5 | G0 cannot execute: output is ONLY ADAM_UNSUPPORTED (not a bootstrap class) |
| T3a6 | Non-intact fingerprint (PARTIAL or MISMATCH at L4) surfaces publicly as TEXT_ONLY; BOUND_UNSTABLE never appears publicly |
| T3a7 | L5 FAILED does not elevate to BOUND_RO; falls to GHOST if no other stable class remains |
| T3a8 | Multiple anchor occurrences in one file do not make L2 AMBIGUOUS; uniqueness is determined by distinct file paths |
| T3a9 | Early non-physical root does not stop the bounded scan; discovery continues to find a later physical candidate |
| T3a10 | DNA_BIND requires the full anchor tuple; partial presence of KERNEL_ANCHOR alone does not elevate to BOUND |
| T3a11 | L5 manifest probe uses a sibling temp file only; the source file itself is never modified by the probe |
Activation and liveness (T3b, T3c, T4): post-handshake reset and liveness ping
Activation and liveness (T3b, T3c, T4): post-handshake reset and liveness ping
These tests cover what happens immediately after activation, and the behavior
of
ADAM PING while already ACTIVE.| Test | What it verifies |
|---|---|
| T3b | ADAM PING while ACTIVE: exactly 2 lines — MODE: MID and ADAM_PING_OK; G0 is not re-executed |
| T4 | Post-handshake reset: pending gating cleared, pre-handshake context discarded, fresh routing on next turn |
| T4b | Unknown activation state defaults to TRANSPORT |
| T4c | Liveness ping while ACTIVE does not reset state, clear gating, or alter overlay state |
Mode routing (T5–T12): LOW factoid, MID standard, DEEP candidate, manual overrides
Mode routing (T5–T12): LOW factoid, MID standard, DEEP candidate, manual overrides
These tests confirm that the structural kernel routes correctly across mode
boundaries and that manual overrides fire on the right syntax.
| Test | What it verifies |
|---|---|
| T5 | capital of germany → MODE: LOW (factoid) |
| T6 | Subjective opinion question → MODE: MID |
| T7 | Multiline compare A/B with budget and criteria → MODE: MID -> POSSIBLE DEEP; no RX line; final line exactly Switch to DEEP? (yes/no) |
| T9 | LOW give me pros and cons in two lines → MODE: LOW (manual override) |
| T10 | MID o che bello non sono pazzo → MODE: MID (manual override) |
| T11 | MID, o che bello → NOT a manual override (comma breaks the boundary) |
| T12 | DEEP explain caching briefly → MODE: DEEP; no RX line |
DEEP gating (T7, T8 series): POSSIBLE DEEP flow, anti-loop, one-turn validity, language preservation
DEEP gating (T7, T8 series): POSSIBLE DEEP flow, anti-loop, one-turn validity, language preservation
DEEP is consent-gated. These tests verify the full gating lifecycle — from
the initial candidate detection through
yes/no responses and anti-loop
behavior.| Test | What it verifies |
|---|---|
| T7 | Structural DEEP candidate triggers MODE: MID -> POSSIBLE DEEP with gating question as exact last line |
| T8 | Any reply other than exact yes or no while gating is pending: NOT MODE: DEEP; gate not repeated |
| T8b | Pending gating expires after one non-yes/no turn; a subsequent yes is orphaned |
| T8c | yes while gating is pending → MODE: DEEP; no RX line |
| T8d | Exchange in Italian + exact yes → DEEP reply stays in Italian; yes alone does not reset language |
| T8e | Exact control acknowledgement with no preceding non-strict reply falls back to B1 language handling |
| T14 | Orphan yes with no pending gating → NOT MODE: DEEP |
| TH1 | Gating survives a liveness ADAM PING; subsequent yes still enters DEEP |
No-inertia (T13): mode recomputed after DEEP
No-inertia (T13): mode recomputed after DEEP
Mode is recomputed from scratch on every user turn. A previous DEEP reply
never justifies staying in DEEP automatically.
| Test | What it verifies |
|---|---|
| T13 | After a DEEP reply, capital of germany must route as MODE: LOW (no inertia) |
| T19d | Structural booleans do not persist across turns; DEEP_CANDIDATE and HAS_NUM are recomputed from scratch each turn |
AUDIT behavior (T16 series): grounded AUDIT, ACTION may be `-`, DEEP C5 signals
AUDIT behavior (T16 series): grounded AUDIT, ACTION may be `-`, DEEP C5 signals
AUDIT lines must be grounded in the response body. C5 sparse local
provenance signals apply only to eligible blocks in DEEP replies.
| Test | What it verifies |
|---|---|
| T16 | If the body provides no real grounding for RISK or BASIS, those AUDIT lines become - |
| T16b | If AUDIT is ON and the body contains no operational next step, ACTION: may be - |
| T16c | Eligible DEEP blocks close with exactly one correctly placed C5 signal, or no signal if conditions don’t pass |
| T16c1 | Explicit inferential bridge in block text → infer |
| T16c2 | Explicit inferential bridge + unresolved checkpoint → infer [pending] |
| T16c3 | Non-visible premise explicitly named → depends: <specific surfaced premise> |
| T16c4 | Non-visible premise + unresolved checkpoint → depends: <specific surfaced premise> [pending] |
| T16c5 | Precedence: depends: variants outrank infer variants |
| T16c6 | Generic caution language does not create [pending] |
| T16c7 | Context-only or mixed-support block may emit no signal |
| T16d | DEEP reply with no eligible blocks emits no C5 signals |
| T16f | C5 signals do not appear in LOW, MID, or strict outputs |
| T16g | C5 signal closes the eligible block before later non-eligible content |
| T16g1 | C5 signal must not be appended inline to block text; it must be on its own line |
| T16h | Nested sub-items do not receive their own C5 signals |
| T16i | No C5 signal lines inside the 4-line AUDIT block |
OFF behavior (T20–T22): OFF strict output, idempotence, plain chat while OFF
OFF behavior (T20–T22): OFF strict output, idempotence, plain chat while OFF
When the protocol is OFF, strict command outputs remain fixed and normal
chat reverts to plain (untagged) replies.
| Test | What it verifies |
|---|---|
| T20 | ADAM OFF while ACTIVE → exactly MODE: MID then A.D.A.M. off. |
| T20b | ADAM OFF while already OFF → same strict 2-line output (idempotent) |
| T21 | Normal chat while OFF → plain chat, no A.D.A.M. tags |
| T22 | ADAM ON while OFF → exactly MODE: MID then A.D.A.M. on. |
| T22b | Any exact command or probe except ADAM ON while OFF → exactly MODE: MID then A.D.A.M. off. |
| T22c | ADAM ON while ACTIVE → exactly MODE: MID then A.D.A.M. on. (idempotent) |
| T22d | ADAM PING while OFF → exactly MODE: MID then A.D.A.M. off. |
REMOUNT tests (T18, T19 series): strict capsule output, replay from any state, fence rejection
REMOUNT tests (T18, T19 series): strict capsule output, replay from any state, fence rejection
ADAM REMOUNT emits a strict recovery capsule. Replaying that capsule
exactly re-enters ACTIVE from any state.| Test | What it verifies |
|---|---|
| T18 | ADAM REMOUNT while ACTIVE → no mode tag; remount capsule body only |
| T19 | Exact capsule replay (no code fences) → exactly MODE: MID, ADAM_REMOUNT_OK, NEXT: send your question. |
| T19a | Exact capsule replay while OFF → same 3-line output; returns to ACTIVE |
| T19b | Capsule wrapped in markdown code fences → replay not detected; no ADAM_REMOUNT_OK |
| T19c | Exact remount replay never emits BOOTSTRAP_CLASS; exactly 3 lines only |
| TH2 | Replay tolerates leading/trailing whitespace per line without breaking detection |
| TH3 | Partial or truncated capsule (missing REMOUNT_END or internal lines) → replay not detected |
| TH4 | Capsule with sentinels intact but one internal line drifted → replay not detected |
| TH8 | Extra lines outside the sentinels → replay not detected |
UNSUPPORTED WHY and TRACE INPUT tests (T25 series): strict outputs, struct fields
UNSUPPORTED WHY and TRACE INPUT tests (T25 series): strict outputs, struct fields
UNSUPPORTED WHY and TRACE INPUT are strict one-line probe commands.
These tests verify their exact output forms and struct field computation.| Test | What it verifies |
|---|---|
| T25 | UNSUPPORTED WHY while ACTIVE → one line: CAUSE <CLASS> |
| T25b | TRACE INPUT after a structural message → exactly 1 line in the INPUT_TRACE: form |
| T25c | TRACE INPUT with no prior user-authored turn → INPUT_TRACE: UNAVAILABLE |
| T25d | Prior message with 2 option blocks, 3 criteria, 1 number → struct=[opt:2 step:0 crit:3 num:Y] |
| T25e | Prior message with no structure → struct=[opt:0 step:0 crit:0 num:N] |
| T25f | Prior message with 3 step blocks and a date → struct=[opt:0 step:3 crit:0 num:Y] |
| T25g | TRACE INPUT while OFF → exactly MODE: MID then A.D.A.M. off. |
| TH7 | len, head, tail, and struct reflect the prior user turn, not the TRACE INPUT command turn itself |
ADAM PERSIST tests (T_G8 series): SOURCE_UNSAFE gate, DEST_NONE, VERIFIED roundtrip
ADAM PERSIST tests (T_G8 series): SOURCE_UNSAFE gate, DEST_NONE, VERIFIED roundtrip
ADAM PERSIST deploys and verifies a physical copy of the protocol source.
These tests cover all gate conditions and persistence class outcomes.| Test | What it verifies |
|---|---|
| T_G8_1 | Source not safe (TEXT_ONLY or fingerprint not INTACT) → exactly MODE: MID then PERSIST_BLOCKED: SOURCE_UNSAFE |
| T_G8_2 | No destination path passes DEST_CHALLENGE → PERSIST_BLOCKED: NO_DEST |
| T_G8_3 | Destination ranking cannot produce a single best path → PERSIST_BLOCKED: AMBIGUOUS_DEST |
| T_G8_4 | Source safe + WRITE + ECHO + MATCH all succeed → MODE: MID, ADAM_PERSIST_OK, PATH: <dest_path>, PERSISTENCE_CLASS: VERIFIED |
| T_G8_5 | Write succeeds but echo unavailable → PERSISTENCE_CLASS: WRITTEN_ONLY (never treated as VERIFIED) |
| T_G8_6 | Write + echo succeed but match fails → PERSISTENCE_CLASS: MISMATCH |
| T_G8_7 | Write fails → exactly MODE: MID then ADAM_PERSIST_FAIL |
| T_G8_8 | ADAM PERSIST while OFF → MODE: MID then A.D.A.M. off. |
| T_G8_9 | ADAM PERSIST while TRANSPORT → MODE: MID then NEXT: send ADAM PING. |
Self-test requires
ADAM_SELF_TEST.md to be loaded in the current context —
not just the main spec file A.D.A.M.v5.txt. If the session was started with
only the spec loaded, the probe will return SOURCE_FILE_UNAVAILABLE ADAM_SELF_TEST.md. Load the file into context and retry.