A.D.A.M. (Adaptive Depth and Mode) is a spec-first control protocol for AI chat — not a library, not a plugin, and not a wrapper. The protocol is a single plain-text file. You load it into the instruction field of a compatible AI host and it becomes the active response contract for that session: every reply gets a visible mode tag, routing follows explicit rules, and deeper reasoning is gated behind consent. If a host can’t honor the contract, it says so instead of pretending.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.
The problem with default AI chat
Left to their defaults, AI assistants have no mechanism for expressing — or constraining — how much they say. A simple factoid can produce a six-paragraph essay. A complex planning question can receive a breezy three-sentence summary. Correction attempts drift as the session grows longer. And none of this is visible: nothing in the reply tells you whether the assistant reasoned carefully or pattern-matched to the most plausible-sounding response. A.D.A.M. addresses three failure modes directly:- Verbosity drift — long sessions accumulate explanation, context re-statement, and unsolicited caveats. A.D.A.M.’s no-inertia rule recomputes the appropriate depth on every message, so the session can’t drift into permanent over-explanation.
- Opaque depth — you can’t tell from a default reply whether the assistant operated at surface level or applied structured reasoning. A.D.A.M. makes depth explicit: every normal reply opens with
MODE: LOW,MODE: MID, orMODE: DEEP. - Uncontrolled expansion — without an explicit gate, complex tasks silently escalate. A.D.A.M.’s structural kernel detects complexity signals (options, constraints, numeric bounds, timelines) and asks for consent before entering a full
DEEPpass.
How A.D.A.M. works
The spec is the implementation.A.D.A.M.v5.txt is a fully self-contained behavioral specification written as a plain-text instruction set. When you load it into a host’s system prompt or instruction field, the AI reads it as an active operational contract — not documentation or reference material. The contract defines:
- how to classify the depth of every incoming message
- which output format each depth level uses
- when to propose deeper reasoning and how to gate it
- what strict commands look like and what exact output they produce
- how the protocol fails when it can’t be satisfied
Uploading or pasting the file alone does not activate A.D.A.M. The file upload is transport only — it places the protocol text in context. Activation is a separate step and requires the exact command
ADAM PING sent as your first message. Until that command is received and the bootstrap check passes, the protocol remains in TRANSPORT state and will not route or tag any replies.What you get
Visible mode tags
Every normal reply opens with
MODE: LOW, MODE: MID, or MODE: DEEP. You always know at what depth the assistant is operating — no guessing, no inference.Structural routing
A.D.A.M.’s structural kernel reads message shape — options, constraints, numeric bounds, steps, timelines — and routes automatically. Simple questions stay light; complex ones surface the right depth without manual prompting.
DEEP gating with consent
When the structural kernel detects a
POSSIBLE DEEP candidate, it provides a useful MID-level answer immediately and asks Switch to DEEP? (yes/no) before committing to a full reasoning pass. You control escalation explicitly.Bounded AUDIT footer
In
DEEP mode and structurally complex MID replies, A.D.A.M. appends a strict 4-line audit block — ACTION, RISK, BASIS — immediately after the body. It is never expanded into a second essay. If a field can’t be grounded, it shows -.What A.D.A.M. does NOT govern
A.D.A.M. governs the assistant’s output contract within a session. It does not govern — and makes no claims about — the following:- Host instruction hierarchy — how the host resolves conflicts between A.D.A.M. and other instructions in its system prompt is outside the protocol.
- Upload mounting semantics — how the host mounts or exposes an uploaded file as context is host-specific behavior. Upload is transport only; it does not activate the protocol.
- Host UI wrappers and banners — platform chrome, reasoning panes, and any formatting the host applies on top of assistant output are outside the protocol.
- Probe file availability — whether external probe files (
ADAM_SELF_TEST.md,SYS_STATUS.md) are present and accessible in context is not governed by A.D.A.M. - Cross-chat persistence — the protocol is session-scoped. It does not persist across separate conversations or chat instances on its own.
- Truncation — if the host truncates the protocol text in context, A.D.A.M. cannot detect or correct it. Fail-closed behavior applies when required sections are missing.
- Rate limits and wrapper interference — if the host throttles, truncates, or rewrites assistant output, the protocol cannot prevent that. When such interference breaks a strict invariant, the correct output is
ADAM_UNSUPPORTED. - Hard safety and policy limits — content moderation and safety policies imposed by the underlying model or platform take precedence over A.D.A.M. The protocol does not attempt to override them.
- Tool availability — A.D.A.M. does not provision or govern which tools (code execution, search, file access) the host makes available to the assistant.
- External reality without accessible evidence — A.D.A.M. does not govern facts about the world that cannot be verified within visible context. Unverifiable claims are handled by global discipline (section B), not by the output contract.
These boundaries are not gaps — they are explicit scope decisions. A.D.A.M. governs what it can reliably govern: output format, mode routing, DEEP gating, audit behavior, and strict command outputs. Everything outside that scope is documented so you know what to expect.
Design posture
A.D.A.M. is built around three structural commitments that distinguish it from soft style guidance: Fail-closed behavior. If the host cannot satisfy a strict invariant — because the protocol file is truncated, the context window drops key sections, or the host rewrites strict output lines — the protocol outputsADAM_UNSUPPORTED instead of approximating. It does not pretend to be active when the output contract cannot be honored.
No inertia. Mode is recomputed on every message from scratch. The previous turn’s mode has no weight on the current turn’s routing decision (with one narrow one-turn exception for very short follow-up questions). A session can’t drift into permanent DEEP or permanent LOW because the protocol never carries mode forward as a default.
Explicit priority ladder. Routing decisions follow a fixed ordered priority: remount replay → transport gate → off gate → active control commands → manual override → structural kernel → state default → output contract. When two rules could apply, the higher-ranked one wins without ambiguity. Manual override (prefixing a message with LOW, MID, or DEEP) always wins over automatic routing.