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.

When A.D.A.M. outputs ADAM_UNSUPPORTED, it means a strict invariant could not be satisfied. UNSUPPORTED WHY is an operator diagnostic that identifies the cause class so you can understand and address the failure.

How to use it

Send the exact command immediately after receiving ADAM_UNSUPPORTED:
UNSUPPORTED WHY
The output is exactly one line:
CAUSE <CLASS>

CAUSE classes

ClassWhen it applies
HARD_STOPA hard safety or policy limit imposed by the host was triggered. The underlying model’s built-in safety constraints prevented the output.
AUDIT_FORMATThe strict AUDIT block could not be produced correctly — for example, a required AUDIT field could not be grounded and the protocol could not safely use -.
HOST_FORMATA host-side issue: truncated protocol context, incomplete spec visibility, platform wrapper interference, or forced formatting that broke a strict invariant.
CONTROL_STRICTA strict command output contract could not be satisfied exactly — for example, the host added extra formatting or extra lines around a fixed-literal output.
CONFLICTConflicting invariants could not be resolved — two or more active protocol rules required mutually incompatible outputs.
UNKNOWNThe cause cannot be determined from visible context. Best-effort only.

Precedence

When multiple causes might apply simultaneously, the following precedence order determines which CAUSE class is reported:
HARD_STOP > AUDIT_FORMAT > HOST_FORMAT > CONTROL_STRICT > CONFLICT > UNKNOWN
Only the highest-ranking applicable class is reported. A single CAUSE line is always emitted.

Behavior in TRANSPORT and OFF

UNSUPPORTED WHY is only meaningful while ACTIVE. In other states it follows the standard gate responses — not the CAUSE <CLASS> output:
StateBehavior
TRANSPORTReturns the standard 2-line transport gate response: MODE: MID / NEXT: send ADAM PING.
OFFReturns the standard 2-line OFF response: MODE: MID / A.D.A.M. off.

Common scenarios

HOST_FORMAT

The most common cause. Typically triggered by a truncated protocol file that is missing required sections, or a platform that rewrites or reformats the assistant’s output — breaking a strict line-count contract. Check that the full A.D.A.M.v5.txt file is loaded and visible in context, not just partially mounted.

CONTROL_STRICT

Occurs when a strict command output was required (e.g. the exact 4-line bootstrap response) but the host appended banners, citations, or extra formatting around the fixed literals, making the output contract impossible to satisfy exactly.

HARD_STOP

The built-in safety or policy limits of the underlying model were triggered. This is outside the protocol’s scope — A.D.A.M. cannot override host-level safety limits. Rephrase the request or switch to a different host.

UNKNOWN

The cause is genuinely unclear from visible context. The protocol cannot determine which invariant failed. Try running SYS STATUS to get a health snapshot, or use ADAM REMOUNT to restore the session and retry.

Next steps after diagnosis

1

Check the CAUSE class

Read the single CAUSE <CLASS> line returned by UNSUPPORTED WHY to identify which category of failure occurred.
2

For HOST_FORMAT: verify context and host

Confirm the full A.D.A.M.v5.txt file is loaded in context and is not truncated. Check whether the host platform applies automatic formatting or wrappers to assistant output. If so, try a different host or load method that preserves strict line output.
3

For HARD_STOP: rephrase or change host

The request crossed a platform safety boundary. Rephrase the request to stay within the host’s policy limits, or switch to a host with different safety thresholds. A.D.A.M. cannot override host-level hard stops.
4

If ADAM_UNSUPPORTED persists: remount the session

Run ADAM REMOUNT to emit the recovery capsule, then re-paste the capsule body to restore the session to ACTIVE state and retry from a clean protocol state.
ADAM_UNSUPPORTED is intentional fail-closed behavior. A.D.A.M. prefers outputting this over silently degrading or pretending to follow the protocol incorrectly. If you see it, something in the current environment prevented a strict invariant from being satisfied — it is not a generic error message.
UNSUPPORTED WHY uses best-effort inference from visible context only. If the cause is genuinely unclear from what is visible in the session, it returns CAUSE UNKNOWN. This does not mean the failure was unimportant — it means the diagnostic cannot determine the specific class from available information.

Build docs developers (and LLMs) love