diff --git a/knowledge/hermes-triage-diagram-corrections.md b/knowledge/hermes-triage-diagram-corrections.md
index a3528c664..a677b2b1d 100644
--- a/knowledge/hermes-triage-diagram-corrections.md
+++ b/knowledge/hermes-triage-diagram-corrections.md
@@ -132,3 +132,35 @@ Smaller corrections to the same nodes:
 once the `junit` plugin is live. Note the plugin was never blocked on a core
 upgrade as previously recorded: `junit 1369.v15da_00283f06` runs on core
 2.528.3, only the latest release requires 2.533.
+
+## Third pass: the escalation branch now has an output
+
+The chart shows the human path as a dead end for the automation: no action
+fits, an issue is filed, and Ariadne learns nothing. That is no longer the
+whole story.
+
+**A diagnosis may now propose a remediation Ariadne cannot perform.** When no
+allowlisted action fits, Hermes may return `suggested_remediation` naming the
+action it believes would work and the evidence that should be required before
+running it. So the human path forks: an escalation always files an issue, and
+some escalations also carry a proposal. The chart should show that second
+output leaving the escalation node, labelled as a proposal for a maintainer
+rather than as anything executable.
+
+**The proposal must be drawn outside the trust boundary.** It is prose in an
+issue and a field in an audit event. No gate reads it; an id that is not
+already in the allowlist still fails `action_not_allowlisted`. If the boundary
+is drawn as "Hermes advises, Ariadne acts", the proposal sits firmly on the
+advisory side, and the arrow from it should terminate at a person, not at the
+Action registry. The registry only grows when a human deploys a new action.
+
+**The three allowlisted actions are now four.** `action_registry` should list
+`repair_demo_fixture`, `retry_transient_infra`, `reclaim_workspace_storage`
+and `clear_stuck_agent_pods`, each reachable only from its own classification.
+
+Two of those are worth calling out on the chart as separate paths rather than
+folding them into a generic retry, because the distinction is the point:
+`workspace_storage_exhausted` reclaims stale workspace storage *before*
+rebuilding, since a plain rebuild lands on the same full volume; and
+`jenkins_agent_provisioning_failure` clears finished agent pods first, since a
+retry otherwise queues behind the same stuck pool.