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.

The three depth modes — LOW, MID, and DEEP — are the core output contract of A.D.A.M. While the protocol is ACTIVE, every non-strict reply begins with a MODE tag on the very first line. That tag is not decorative: it is a binding declaration of exactly what kind of answer you are getting — how much structure to expect, whether assumptions will be stated, and whether an AUDIT footer will appear. You always know the depth before you read a single word of the response body.

​
Mode overview

Mode tagMeaningWhen used
MODE: LOWFast, minimal, direct. No structure overhead.Factoids, brief definitions, trivial calculations, banter.
MODE: MIDDefault rigorous mode. Compact structure only when it improves correctness.Explanations, evaluations, moderate comparisons.
MODE: MID -> POSSIBLE DEEPStructural kernel detected a DEEP_CANDIDATE. DEEP is offered but not yet entered.Messages with 2+ options + numeric/criteria signals, or steps/timelines.
MODE: DEEPFull decision support — explicit assumptions, comparisons, failure modes, stress tests. AUDIT always ON.Complex decisions, entered via explicit yes to gating or manual override DEEP.

​
MODE: LOW

LOW is fast, minimal, and direct. There is no needless structure. No follow-up question is appended unless it would materially change the answer. Use it — or let auto-routing select it — when the request is a factoid, a brief definition, a trivial calculation, a micro-procedure, or casual banter. Example exchange: 
User: capital of germany

MODE: LOW
Berlin.

User: what year was it founded as capital?

MODE: LOW
1871, when the German Empire was proclaimed.
No bullet points, no headers, no “Great question!” — just the answer.

​
MODE: MID

MID is the default rigorous mode. It adds compact structure — headers, bullets, short tables — only when doing so improves correctness or decision quality. If the message has no structural complexity, MID replies stay lean and prose-forward.

​
Comparison mini-table (MINI_TABLE_TRIGGER)

When the structural kernel fires MINI_TABLE_TRIGGER — that is, when a message contains 3+ option blocks, or 2+ option blocks combined with a numeric constraint or 3+ criteria bullets — a MID reply includes:
  1. A compact comparison mini-table covering the options.
  2. A short “when to use what” conclusion that maps each option to its best-fit scenario.
This keeps multi-option comparisons honest and scannable without escalating to a full DEEP pass. Example exchange: 
User: compare SQLite, PostgreSQL, and MySQL for a small side project

MODE: MID
All three are solid choices; the right pick depends on your deployment constraints.

| | SQLite | PostgreSQL | MySQL |
|---|---|---|---|
| Setup | Zero-config, file-based | Server required | Server required |
| Concurrency | Single-writer | High | High |
| Feature depth | Basic SQL | Full (JSON, window fns, extensions) | Good |
| Portability | Excellent (one file) | Moderate | Moderate |

When to use what:
- **SQLite** — solo dev, prototyping, or any app where the DB travels with the binary.
- **PostgreSQL** — you expect growth, need advanced queries, or want strong standards compliance.
- **MySQL** — existing team familiarity or a hosting stack that defaults to it.

​
MODE: MID -> POSSIBLE DEEP

When the structural kernel detects a DEEP_CANDIDATE — a message that combines structural breadth (2+ options, steps/timeline, or 3+ inline alternatives) with constraint depth (a number, 3+ criteria, or a retrograde condition after a prior COMMIT) — the reply enters MODE: MID -> POSSIBLE DEEP. This state means:
  • A useful MID-level answer is delivered right now — you never leave empty-handed.
  • The protocol has detected that a full DEEP pass would add meaningful value.
  • Consent is required before entering DEEP; the protocol does not assume you want the longer version.

​
Automatic structural classification overlay

Immediately after the MODE: MID -> POSSIBLE DEEP tag, an automatic structural classification overlay appears as a TRACE INPUT: line. This overlay shows which structural primitives triggered the routing decision as short chips — for example [confronto tra opzioni] (options), [vincoli da rispettare] (criteria), [numeri, date o limiti] (numbers). The chips are structural classifiers only; they describe input shape, not input content.

​
Gating line

The final line of a MODE: MID -> POSSIBLE DEEP reply is always exactly: 
Switch to DEEP? (yes/no)
Nothing follows it. Reply yes to enter DEEP, no (or anything else) to stay in MID. Example exchange: 
User:
A) Option 1: migrate to microservices
B) Option 2: refactor the monolith in place
- must complete within 6 months
- team of 4 engineers
- budget under $50k

MODE: MID -> POSSIBLE DEEP
TRACE INPUT: [confronto tra opzioni] [vincoli da rispettare] [numeri, date o limiti]

Both paths are feasible under your constraints, but they carry different risk profiles.

**Option A — Microservices migration** cuts coupling and scales individual services, but six months for a team of four is a tight runway. Scope risk is high without clear service boundaries defined upfront.

**Option B — In-place refactor** preserves deployment continuity and is more budget-predictable, though it can stall if the codebase has deep entanglement.

Given the $50k ceiling and 6-month window, Option B is lower-variance unless you already have a service decomposition plan ready.

Switch to DEEP? (yes/no)

​
MODE: DEEP

DEEP is full decision support. It is always entered deliberately — either by replying yes to a POSSIBLE DEEP gating question, or by starting a message with the manual override token DEEP. In DEEP mode:
  • Explicit assumptions are stated.
  • Comparisons, failure modes, and stress tests are included where relevant.
  • AUDIT is always ON — every DEEP reply ends with a strict 4-line AUDIT footer (see Output Contract).
  • Sparse Local Provenance (C5 signals) may appear on eligible top-level blocks: infer, infer [pending], depends: <premise>, depends: <premise> [pending]. These signals are local and visibility-bounded — they document inferential bridges and unresolved premises explicitly written in the block, not confidence ranks.
DEEP is recomputed per message like every other mode — prior DEEP mode does not carry forward automatically. If DEEP is needed again next turn, use the manual override DEEP or trigger a new POSSIBLE DEEP flow.

​
Mode selection priority

The following priority order governs which mode is active for any given reply:
1

Manual override wins

If the first token of your message is exactly LOW, MID, or DEEP followed by a space or end-of-message, that mode is forced for the reply. Manual override always beats structural routing.
2

Structural kernel routes

If no manual override is present, the structural kernel (section S of the spec) computes mode from message shape. DEEP_CANDIDATE → MID -> POSSIBLE DEEP. AUTO_LIGHT signals → LOW. Everything else → MID.
3

State default applies

If neither manual override nor a structural signal resolves mode, the state default applies.

​
No inertia

Mode is recomputed on every message. The previous mode never justifies staying in DEEP or LOW. There is no session-wide mode lock. One-turn exception: A message with no whitespace that ends in ? inherits the previous exact LOW, MID, or DEEP for one turn only. MODE: MID -> POSSIBLE DEEP is never inherited.
The MODE tag is not cosmetic — it is part of the strict output contract. Every non-strict normal reply while ACTIVE must begin with a valid mode tag. If the host prevents correct mode tagging, the protocol must output ADAM_UNSUPPORTED rather than approximate or omit the tag. A reply without a valid mode tag on line one is not a valid A.D.A.M. output.

Build docs developers (and LLMs) love

Get started for freeTalk to us