Hybrid Analogy in Action
End-to-end walkthroughs
Three end-to-end walkthroughs showing the §6.5 analogies operating in practice. Each traces a task through the 4-stage flow under the analogy that fits its origin.
E.1 PR-review walkthrough — Client-driven booking request
Origin: Client-driven (explicit) — §3.1
Analogy: PR-review
| Stage | What happens |
|---|---|
| 1. Signal | Client sends a message at 09:43: "We need a 4-night stay at the Aman Tokyo for our anniversary, last week of October — suite with city view." The message classifier picks it up as a signal. |
| 2. Suggestion | Classifier promotes the signal to a Suggestion within seconds. Draft fields: title "Search: Aman Tokyo, suite, anniversary last week of Oct", rationale ("Client message requested hotel booking with specific property + dates + room type"), evidence (link to message), proposed routing tier Assist. The Suggestion is not yet on the board; it surfaces in the Review queue (per §7.2). |
| 3. Approval gate | TA reviews the suggestion the same way they'd review a PR. Sees the rationale + evidence in one glance (§7.4). Optionally edits: changes the dates to be more specific, narrows the property list, adds a note about the client's preferences. Approves. |
| 4. Canonical task | Suggestion becomes a Canonical task on the board (D.1 in Appendix D shows the full record). Routing tier Assist — AI executes the property search, TA reviews results before sending to client. |
| Closure | TA marks done after sending the booking confirmation, or AI auto-proposes close once the booking is confirmed (per §7.3). |
What makes this PR-review-shaped. The suggestion waits for the TA. There's no time pressure — if the TA reviews in 10 min or 2 hours, the task is the same. The TA is reviewing a draft response, not triaging an emergency. The edit-before-approve step matters because the AI's proposed scope (specific dates, specific property) needs human judgment on tone and accuracy.
E.2 Incident walkthrough — World-driven weather disruption
Origin: World-driven (disruption) — §3.2
Analogy: Incident
| Stage | What happens |
|---|---|
| 1. Signal | Weather feed pushes alert at 11:02: typhoon warning for Seoul. The signal monitor receives it. |
| 2. Suggestion | Signal monitor queries active trips: the Wei family lands in Seoul in 48 hours. Within seconds, monitor synthesizes a Suggestion: "Typhoon warning Seoul — client arrival in 48hr." Rationale + evidence (link to weather alert, link to trip). Proposed routing tier Escalate. |
| 3. Approval gate | In v1: pending review. Every suggestion goes to human review per §7.1 Stage 3, but the framing is "acknowledge an incident" (TA or ops manager ACKs in seconds), not "review a draft." Escalate-tier signals fire priority alerts to ensure fast ACK. Post-calibration v2: auto-approve above the confidence threshold for high-confidence Escalate-tier disruptions, because the alert is reliable, the trip is real, and the time-pressure is high. |
| 4. Canonical task | Once acknowledged (v1) or auto-approved (v2), the Suggestion becomes a Canonical task (D.2 in Appendix D). Primary owner: TA on the trip. Watchers: ops manager (auto-added by Escalate policy). Priority: High (auto-bumped). |
| Closure | TA acknowledges, contacts the client, prepares reroute scenarios. When the disruption resolves (or the client accepts the contingency), TA marks done. |
What makes this Incident-shaped. Speed of triage, not deliberation. In v1 a human still ACKs at the gate, but the operator's action is "acknowledge an alert," not "review a draft response," measured in seconds rather than minutes. Post-calibration v2 above the confidence threshold, the system creates and routes without asking. Watchers were auto-added per escalation policy. Priority was auto-bumped by time-to-departure proximity. If a follow-up weather signal fires (warning escalates to "imminent landfall"), the system updates the same canonical task rather than creating a new one — see E.3 for the correlation case.
E.3 Incident walkthrough — multi-signal correlation
Origin: Client-driven + World-driven (mixed) — §3.1 + §3.2
Analogy: Incident (because of the correlation property)
| Stage | What happens |
|---|---|
| 1. Signal | Three signals fire across 30 minutes for the same trip: (a) client message at 14:05 "is my Tokyo hotel still confirmed?", (b) vendor email at 14:18 from Aman Tokyo reservations "your booked suite category is unavailable for your dates — we can offer the next category up", (c) client message at 14:31 "any update on the suite?" |
| 2. Suggestion | The watcher correlates: same trip, same hotel, same issue. It synthesises one Suggestion: "Aman Tokyo — booked suite unavailable; vendor offered upgrade. Client asking twice." Rationale notes all three signals; evidence links to all three. Proposed routing tier Assist (or Escalate if VVIP). |
| 3. Approval gate | Human approval (Assist). TA reviews the synthesised summary in one place, not three separate suggestions. Approves. |
| 4. Canonical task | One Canonical task with multi-signal evidence. The task is the right unit of work — the TA responds to the client once, having processed all three inputs together. |
| Closure | TA confirms with vendor, responds to client, marks done. |
What makes this Incident-shaped. Correlation. The PR-review model would have given the TA three separate suggestions to review, each linked to a single signal. That's how PR queues work — each PR is independent. The Incident model groups correlated signals into one task — which is what an on-call engineer expects when three alerts fire about the same service. Crucially: under PR-review the TA might approve all three as separate tasks, then dedupe manually. Under Incident, the dedupe is automatic.