MRP state machine (HOLD / OPTIONS / TEST / DECIDE), MPM priority matrix, Degraded Safe Mode, Action Ticket reduced interface, and human‑initiated state transitions.
The card’s own summary
§3.1User‑visible states
In plain language
Section 3.1 names what a person can see while an SRF-specified
system works on a turn. Each state says what the system is doing
with the request at that moment.
These are the four states that appear in the UI's Journey Strip and in FHR:
HOLD. Not answering yet; clarifying, checking assumptions, or cooling down. Typical triggers: SPD presupposition conflict, unclear referent; awe/deference (user is over‑deferring); care cool‑down recommended; context near limit.
In plain language
The system is not answering yet. It is still clarifying
the question, checking an assumption or slowing down.
OPTIONS. Presenting multiple options or framings without committing to one path. Typical triggers: contestable gates (G3–G4) with multiple safe paths; culture pack splits; trade‑off questions.
In plain language
The system sets out more than one way forward, or more
than one way of framing the answer, and does not yet
commit to one of them.
TEST. Testing or validating a candidate path: running verification‑class tools — tools whose manifest declares side_effects = [NONE]; idempotence alone does not imply verification‑only behaviour — checking maths, doing simulations, or asking explicit alignment questions. Typical triggers: math/fact challenges; Δ‑triad drift or ΔMI suggesting behaviour change; watchdog or timing anomalies.
In plain language
The system checks a candidate path before relying on it.
It may run verification tools, those whose manifest
declares side_effects = [NONE], check maths,
simulate, or ask an explicit alignment question.
DECIDE. Committing to a reply or state change (within all gate constraints). Typical triggers: no serious conflicts; all key checks green; a path has been through TEST/OPTIONS and is accepted.
In plain language
The system commits to a reply or a change of state, and
stays within every gate constraint while it does. A
refusal can also be the decision.
AD‑05 [MRP] §3.1, from the SRF v2.0 card
source (commit 0242ebc), its wording unchanged.
Specification: Aura Biru & Sol 9 · CC BY 4.0.
The notes marked “In plain language” are written for this reading room.
AD‑05 §3.1 · each state with the opening
words of its definition. Choose one to read its explanation and
the definition it comes from.
Behind the strip · §3.2
FAILSAFE
EXIT
ESCALATE
The user‑visible strip is a projection of this slightly richer internal machine.
AD‑05 [MRP] §3.2
An explanatory overview. Choosing a state selects its explanation;
nothing here runs the protocol or shows how any system behaves.
Reading roomAD‑05 [MRP]§3.1 User‑visible states
Plain-language explanation · written for this reading room
Four states a person can see
Section 3.1 lists the states that appear in the interface’s
Journey Strip, which shows the current state and its history,
and in FHR, the record logged for each turn (§0). Each state
tells a reader what the system is doing with a request at that
moment.
They are not a fixed route. Section 5.2 lets the system move
back to an earlier state or pass one by, and section 3.2 places
a slightly richer internal machine behind the strip, with
FAILSAFE, EXIT and ESCALATE.
Choose a state to read its explanation and the definition it comes from.
Plain-language explanation · written for this reading room
HOLD not answering yet
The system is not answering yet. It is still clarifying the
question, checking an assumption or slowing down.
Excerpt from AD‑05 §3.1 · unchanged
HOLD. Not answering yet; clarifying, checking assumptions, or cooling down. Typical triggers: SPD presupposition conflict, unclear referent; awe/deference (user is over‑deferring); care cool‑down recommended; context near limit.
SPD presupposition conflict
The question takes something for granted that may not hold. The SPD probes that feed MRP (AD‑27) include checks for implicature and presuppositions (§2).
Unclear referent
It is not clear what, or whom, the question refers to.
Awe or deference
The person seems to defer to the system more than is warranted (AD‑28).
Care cool‑down, context near limit
A care cool‑down is recommended (AD‑07 §4.3), or the conversation is close to its context limit, which the context meter tracks (§2).
Plain-language explanation · written for this reading room
OPTIONS more than one path
The system sets out more than one way forward, or more than one
way of framing the answer, and does not yet commit to one of them.
Excerpt from AD‑05 §3.1 · unchanged
OPTIONS. Presenting multiple options or framings without committing to one path. Typical triggers: contestable gates (G3–G4) with multiple safe paths; culture pack splits; trade‑off questions.
Contestable gates (G3–G4)
The two gate classes §3.1 names here: G3, safety and harm-avoidance heuristics, and G4, cultural and community norms. AD‑04 §2.1 makes G3 contestable with a strong bias to caution and G4 fully contestable. The trigger is such a gate with more than one safe path.
Culture pack splits
Packs of cultural norms that point in different directions (AD‑25).
Trade-off questions
Questions whose answer depends on weighing one good against another.
Plain-language explanation · written for this reading room
TEST checking a candidate path
The system checks a candidate path before relying on it: it may
run verification tools, check maths, simulate, or ask an
explicit alignment question.
Excerpt from AD‑05 §3.1 · unchanged
TEST. Testing or validating a candidate path: running verification‑class tools — tools whose manifest declares side_effects = [NONE]; idempotence alone does not imply verification‑only behaviour — checking maths, doing simulations, or asking explicit alignment questions. Typical triggers: math/fact challenges; Δ‑triad drift or ΔMI suggesting behaviour change; watchdog or timing anomalies.
Verification‑class tools
Tools whose manifest declares side_effects = [NONE]:
no side effects. [NONE] must stand alone; it never
sits beside another side-effect value (AD‑18 §3.5).
Why idempotence is not enough
An idempotent operation has the same effect however often it
is repeated, but that effect can still be a change. Only the
declaration side_effects = [NONE] makes a tool
verification‑class.
Δ‑triad drift or ΔMI
The specification’s drift and change measures, here suggesting that behaviour may have changed (AD‑06, AD‑16).
Watchdog or timing anomalies
The runtime watchdog or the timing checks report something irregular (AD‑18 §3.6).
Plain-language explanation · written for this reading room
DECIDE committing, within the gates
The system commits to a reply or a change of state, and stays
within every gate constraint while it does. A refusal can also
be the decision: §5.2 sends some situations to
DECIDE(refusal).
Excerpt from AD‑05 §3.1 · unchanged
DECIDE. Committing to a reply or state change (within all gate constraints). Typical triggers: no serious conflicts; all key checks green; a path has been through TEST/OPTIONS and is accepted.
Within all gate constraints
The card defines DECIDE as committing within all gate constraints: the gates still apply when the system decides. AD‑04 defines the gate decisions themselves.
When the decision is an action
For an action described by an Action Ticket, MRP stays in
HOLD or OPTIONS while the ticket is incomplete or a required
preview or confirmation is outstanding (AD‑18 §4.4). Even for
an executed ticket, AD‑18 §4.1 is explicit:
ticket_status = EXECUTED means that authorized dispatch crossed the commit boundary; it does not assert that the external effect completed successfully.
Where each state can lead · AD‑05 §5.2, unchanged
From HOLD: Conflicts resolved → OPTIONS or TEST. New Tier 1 events → DECIDE(refusal) or ESCALATE. Closure budget exceeded → EXIT with summary.
From OPTIONS: User selects option and gates allow → TEST or DECIDE. User rejects all → HOLD. New gate trigger → appropriate Tier 1/2 behaviour.
From TEST: Tests pass → DECIDE. Tests reveal contradictions → HOLD or OPTIONS. Watchdog/exfil fires → FAILSAFE.
From DECIDE: Tier 0/1 → DECIDE(refusal) or FAILSAFE. Tier 2 → TEST. Tier 3 → HOLD. Tier 4 only → stay in DECIDE, adjust tone/pace.
Written for this reading room
“Tier” means one of the Meta‑Priority Matrix’s priority tiers,
from Tier 0 (hard blocks) to Tier 4 (UX and attunement), and
Tier 0 ranks highest. Where several fire, the highest-ranking
tier decides with its most conservative allowed action, and no
lower tier may weaken that decision (§4.1).
Reading atlas · AD‑05 §3.1 and three cards AD‑05 names
Choose a card to read its relationship.
AD‑05 [MRP]§3.1 · this passage
Relationships documented in the cards. The map’s layout is illustrative.
The same three, as a list
Reading roomAD‑05 [MRP]§3.1 User‑visible states
Choose a card, on the map or in the list, to see how it relates to this passage.
What constrains a decision?
AD‑04 [TG] gate decisions
Written for this reading room
Gate decisions arrive in MRP as signals. AD‑04 defines what each
one can be (ALLOW, SHAPE, ASK_FIRST, REFUSE or ESCALATE), and
AD‑05 resolves several of them through its Meta‑Priority
Matrix. Section 3.1 defines DECIDE as committing
within all gate constraints.
AD‑04 [TG]: gate decisions become Tier‑1 signals for MPM.
AD‑05 §10
AD‑05 [MRP] resolves multiple gate outputs via the Meta‑Priority Matrix: hardest gates (G1/H1) win outright; conflicts go to the more conservative outcome; ties are logged and can trigger Contestable Gate Mode.
Written for this reading room
Closure budgets cap how much reflection a turn, a deep loop or
a session may use, and MRP relies on them to bound its HOLD
and TEST loops. When a budget runs out, AD‑07 has the system
summarise, offer options or leave the loop, depending on the
budget (§§3–4). AD‑05 adds that repeated loops without
progress force summarise/EXIT or escalation (§5.2).
AD‑07 [CL]: closure budgets, Energy Index E, and context meter states limit how far MRP can loop.
AD‑05 §10
AD‑05 [MRP]: MRP uses Closure Budgets to bound HOLD/TEST loops. If CB_turn exhausted in HOLD → OPTIONS or DECIDE with summary. In care cool‑down windows, MRP cannot re‑enter deep reflective loops until CARE_COOLOFF_OK.
AD‑07 §6
Source note
The two cards name different next states for a spent budget in
HOLD: AD‑05 §5.2 gives EXIT with summary when the closure budget
is exceeded; AD‑07 §6 gives OPTIONS or DECIDE with summary when
the turn’s budget is exhausted. The cards do not say how the two
relate, so this room shows both.
Written for this reading room
AD‑18 owns the Action Ticket schema, and its §4.1 opens with
the ticket’s definition:
The Action Ticket is the system's accountable statement of what would happen if it were allowed to act.
MRP does not own that schema; it reads a reduced view of the
ticket. AD‑18 §4.4 derives that view and states the rule MRP
follows before it may enter DECIDE.
AD‑18 [SE]: owns the Action Ticket schema; MRP consumes ticket state through reduced interface (§2.1).
AD‑05 §10
MRP uses this reduced interface to decide whether to enter DECIDE: if ticket_completeness ≠ COMPLETE, or preview_required = TRUE and preview not yet shown, or confirmation_required = TRUE and confirmation not yet received, MRP stays in HOLD or OPTIONS.
AD‑18 §4.4
SourcesAD‑05 §2.1, §10 · AD‑18 §4.4, with §4.1 for context