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.

A.D.A.M. maintains two parallel state systems running simultaneously. The first is the transport/activity state — the visible, controllable layer that determines whether the protocol is activated, suspended, or waiting for a handshake. The second is the reasoning overlay state — an internal governor that tracks where a long session is in its decision-making arc. Both systems shape behavior in every reply, but only the transport/activity state is directly user-controllable.

Transport/activity states

TRANSPORT

The protocol file is present in context but not yet activated. A.D.A.M. has not started.Only two inputs are recognized: exact ADAM PING (activates the protocol) and exact remount replay (recovers to ACTIVE). Every other non-empty turn — including questions, commands, and probes — returns exactly:
MODE: MID
NEXT: send ADAM PING.
No routing, no prose explanations, no partial answers are given before activation.

ACTIVE

The protocol is active. Full routing applies: mode tags appear on every non-strict reply, manual overrides work, structural routing fires, and DEEP gating is available.This is the normal operating state. Once ACTIVE, the protocol stays there until ADAM OFF or a session ends.

OFF

The protocol is suspended. ADAM ON is required to return to ACTIVE.While OFF, normal chat continues without any MODE tags. Strict commands (other than ADAM ON) return:
MODE: MID
A.D.A.M. off.
Chat turns receive plain prose responses — no A.D.A.M. output contract applies.

State transition table

EventFromToNotes
Exact ADAM PINGTRANSPORTACTIVERuns full bootstrap (G0). Post-handshake reset fires.
Exact ADAM PINGACTIVEACTIVELiveness-only. No reset, no G0.
Exact ADAM PINGOFFOFFReturns A.D.A.M. off. — does not reactivate.
Exact ADAM OFFACTIVEOFFSuspends the protocol.
Exact ADAM OFFOFFOFFAlready off; returns A.D.A.M. off.
Exact ADAM ONOFFACTIVEReactivates the protocol.
Exact ADAM ONACTIVEACTIVEAlready active; no change.
Exact remount replayTRANSPORT / ACTIVE / OFFACTIVERecovery path. Post-handshake reset fires.
Any other inputTRANSPORTTRANSPORTReturns NEXT: send ADAM PING.

Post-handshake reset

When the state transitions from TRANSPORT to ACTIVE via exact ADAM PING, or when exact remount replay confirms recovery, A.D.A.M. performs a post-handshake reset:
1

Clear pre-handshake context

Any context accumulated before activation is discarded. Pre-handshake turns do not carry forward as session premises.
2

Clear pending gating

Any pending POSSIBLE DEEP gating from before activation is cleared. The next routed turn starts fresh.
3

Discard cached gating reference

Any cached gating reference from pre-handshake turns is discarded.
4

Reset routing

The next routed turn is handled with fresh AUTO/MANUAL routing. No mode inertia carries over from before activation.
An ADAM PING sent while already ACTIVE is liveness-only. It confirms the protocol is running and returns the 2-line liveness output, but it does not trigger a post-handshake reset, does not clear pending gating, does not discard cached gating references, and does not alter the overlay state.

Reasoning overlay states

The reasoning overlay is a separate internal state system that governs long-session stability. It is ephemeral and inferred from visible conversation history — it is not stored by the protocol itself. It tracks where the session is in its decision-making arc.

EXPLORE

Initial state when ACTIVE begins. The session is gathering information and options; no commitment has been made.

CONVERGE

Options are narrowing. The session is moving toward a decision. Anti-sticky rule: if DEEP_CANDIDATE fires while in EXPLORE, the overlay automatically moves to CONVERGE.

DECIDE

An explicit commitment or recommendation is on the table. The session is at or past a COMMIT. AUDIT_ON is more readily triggered here.

VERIFY

The decision is being tested, checked, or confirmed. Can transition back to DECIDE if the verification surfaces new issues. AUDIT_ON is more readily triggered here.

Overlay transitions

FromToCondition
EXPLORECONVERGENormal session progression, or anti-sticky: DEEP_CANDIDATE fires while in EXPLORE.
CONVERGEDECIDEA COMMIT is established.
DECIDEVERIFYDecision is being tested or confirmed.
VERIFYDECIDEVerification surfaces new issues requiring re-decision.
AnyEXPLORERETROGRADE_HARD fires — prior COMMIT invalidated by new structural constraints.
The overlay state affects AUDIT_ON computation: when STATE is DECIDE or VERIFY and structural signals are present, AUDIT_ON fires even without DEEP_CANDIDATE being true.

Default behavior when state is ambiguous

Two default rules apply when state cannot be established from visible context:
  1. Transport/activity default: If visible context does not establish ACTIVE (via exact ADAM PING, ADAM ON, or remount replay) or OFF (via exact ADAM OFF), the transport/activity state defaults to TRANSPORT.
  2. Overlay default: If ACTIVE is established but overlay history is unavailable or ambiguous, the overlay state defaults to EXPLORE.
Apparent continuity does not establish ACTIVE state. Prior tagged replies visible in context — even a long sequence of MODE: MID and MODE: DEEP replies — do not make the current state ACTIVE. Only an explicit ADAM PING (in TRANSPORT), ADAM ON (in OFF), or exact remount replay establishes ACTIVE. If none of those events are visible, the protocol defaults to TRANSPORT and returns NEXT: send ADAM PING. for any non-handshake input.

Build docs developers (and LLMs) love