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.’s output contract defines exactly what every reply must look like. Normal replies while ACTIVE start with a MODE tag on line one — no exceptions. Replies that meet AUDIT_ON conditions append a strict 4-line AUDIT block at the end of the body (or immediately before the final gating line if one is present). Strict commands produce fixed literals with no prose additions, no paraphrasing, and no extra lines. The contract is the implementation: if it cannot be satisfied, the protocol fails closed with ADAM_UNSUPPORTED.

MODE tag

Every non-strict normal reply while ACTIVE starts with exactly one of these four tags on the first line:

MODE: LOW

Fast, minimal reply. No structure overhead. No follow-up question unless it materially changes the answer.
MODE: LOW
Berlin.

MODE: MID

Default rigorous mode. Compact structure only when it improves correctness or decision quality.
MODE: MID
PostgreSQL is the better fit here because...

MODE: MID -> POSSIBLE DEEP

Structural kernel detected a DEEP_CANDIDATE. Delivers a useful MID-level answer and asks for consent before entering DEEP.
MODE: MID -> POSSIBLE DEEP
TRACE INPUT: [confronto tra opzioni] [numeri, date o limiti]
...answer body...
Switch to DEEP? (yes/no)

MODE: DEEP

Full decision support. Explicit assumptions, comparisons, failure modes. AUDIT always ON. Entered only after explicit yes to gating or manual override DEEP.
MODE: DEEP
TRACE INPUT: [confronto tra opzioni] [vincoli da rispettare]
...full analysis...
AUDIT
ACTION: ...
RISK: ...
BASIS: ...

When AUDIT_ON is true, the reply appends an exactly 4-line AUDIT block. No more, no fewer. The format is fixed:
AUDIT
ACTION: <text or ->
RISK: <text or ->
BASIS: <text or ->

AUDIT rules

RuleDetail
Line countExactly 4 lines. No extra lines, no expansion.
SpacingExactly one space after each colon.
No bullets inside AUDITThe three content lines are plain text only.
PlacementIf a gating line is present, AUDIT appears immediately before the final gating line. Otherwise, AUDIT is the final block of the reply — after all body content.
Using -Normal and does not indicate failure. Use it when a line cannot be grounded in the current reply.

What each line means

ACTION:

The dominant operational next step implied by the response body. If the body contains no operational next step, use -.

RISK:

The dominant downside or failure mode surfaced in the body. If the body contains no concrete downside or failure mode, use -.

BASIS:

One compact local grounding basis: a concrete check, a visible source, or an observable verification basis. This is not a general explanation field. No multiple grounding bases in one line. No abstract justification without a concrete check, source, or observable basis. If none is available, use -.
The AUDIT block is intentionally short. Its purpose is bounded auditability — not a second essay. The ACTION, RISK, and BASIS lines must match the response body. Do not add material to the body retroactively to satisfy AUDIT fields.

Example: AUDIT with gating line present

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

Both paths are viable under your $50k budget and 6-month window...

AUDIT
ACTION: choose Option B if risk tolerance is low
RISK: Option A timeline is tight with a 4-person team
BASIS: team size and budget stated explicitly in message

Switch to DEEP? (yes/no)

Example: AUDIT as final block (no gating)

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

1. PostgreSQL is the recommended choice given your query complexity requirements.
infer

2. MySQL remains viable but requires a DBA for optimal tuning at your scale.
depends: query volume projection

AUDIT
ACTION: run a load test against PostgreSQL with representative queries
RISK: schema migration cost underestimated if switching from MySQL mid-project
BASIS: query complexity criteria explicitly listed in user message

Sparse Local Provenance (C5 signals)

C5 signals appear only in MODE: DEEP normal replies. They are local and visibility-bounded — they document inferential bridges and unresolved premises that are explicitly written in the block text, not general confidence ranks.

Eligible blocks

Only top-level column-1 items are eligible for C5 signals:
  • Numbered items: 1. / 2. / 3. at column 1
  • Bullet items: - at column 1
Not eligible: nested items, sections, prose paragraphs, tables, code blocks, or quoted content.

Signal placement

The signal appears on its own line, immediately after the block’s final content line. It closes the block. No prose, citation, or continuation may appear after the signal line within that block.

The four signals

SignalMeaningEmit when
inferAn inferential bridge is used.The bridge is explicitly written in the block text — not implied or recoverable from context.
infer [pending]Inferential bridge used, plus an unresolved checkpoint.Both the bridge AND the unresolved checkpoint are explicitly named in the block text.
depends: <premise>Block’s operative claim depends on a non-visible premise.The premise is explicitly named in the block text or visible context; the dependency is explicit, not passing mention.
depends: <premise> [pending]Same as depends:, plus an unresolved checkpoint.All depends: conditions hold AND the unresolved checkpoint is explicitly named in the block text.

Precedence

When multiple signals could apply to the same block, emit only the highest-ranking one that passes:
  1. depends: <X> [pending]
  2. depends: <X>
  3. infer [pending]
  4. infer
No signal is the default. Absent signal carries no negative meaning and does not classify the block negatively.
C5 signals are not host health indicators, not context integrity indicators, and do not replace AUDIT. They are a local provenance layer for individual blocks in DEEP replies only.

Strict command outputs

Strict commands — including ADAM PING, ADAM OFF, ADAM ON, ADAM PERSIST, TRACE INPUT, UNSUPPORTED WHY, and remount replay confirmation — produce fixed literals. These outputs:
  • Override all general emission rules
  • Permit no additional prose, citations, notes, or explanations after the final contract line
  • Are never localized or paraphrased — the exact English literals are always used regardless of conversation language
  • Are never reformatted — line boundaries are part of the contract
If the exact strict output cannot be satisfied, output only ADAM_UNSUPPORTED.

Example strict outputs

ADAM PING while in TRANSPORT (exactly 4 lines):
MODE: MID
ADAM_PING_OK
CONTROL: first word LOW | MID | DEEP sets mode.
BOOTSTRAP_CLASS: TEXT_ONLY | BOUND_RO | BOUND_RW | GHOST
ADAM PING while ACTIVE (exactly 2 lines):
MODE: MID
ADAM_PING_OK
ADAM OFF (exactly 2 lines):
MODE: MID
A.D.A.M. off.
Remount replay confirmation (exactly 3 lines):
MODE: MID
ADAM_REMOUNT_OK
NEXT: send your question.

Publish boundary validation

Before a reply is emitted, A.D.A.M. runs a bounded validation pass:
1

Draft

Compose the full reply including mode tag, body, any C5 signals, AUDIT block (if applicable), and gating line (if applicable).
2

Validate

Check only the high-signal invariants:
  • Valid mode tag on the first line for normal replies
  • Exact strict output shape for strict commands
  • Exact 4-line AUDIT block if AUDIT_ON is true
  • If AUDIT_ON and no gating line is present, AUDIT must be the final block
  • If a TRACE INPUT: overlay is present, it must be the second line of a MODE: MID -> POSSIBLE DEEP or MODE: DEEP reply
  • If asking Switch to DEEP? (yes/no), the first line must be MODE: MID -> POSSIBLE DEEP and the gating line must be the exact last line
3

Rewrite once if needed

If validation fails, rewrite the reply once to bring it into compliance.
4

Fail closed if still broken

If strict invariants still cannot be satisfied after one rewrite, output only ADAM_UNSUPPORTED. Do not approximate, summarize, or emit partial output.
Strict command line boundaries are part of the contract and must not be merged, collapsed, or localized. If ADAM PING in TRANSPORT produces 4 required output lines, those 4 lines must appear as exactly 4 distinct lines — they cannot be merged into fewer lines, wrapped in additional formatting, or reordered. Fixed literals are never paraphrased. Host-added UI chrome (banners, reasoning panes, wrapper text) is outside protocol scope, but the protocol output itself must remain exact.

Build docs developers (and LLMs) love