Example Canonical Task Records
The schema in action
Three example tasks pulled from §3 / Appendix B, with their canonical fields populated. Shows the schema in §7.2 in action — and how much is inferred vs explicit at creation time.
D.1 Client booking request (assist tier)
A TA gets a message: "We need a 4-night stay at the Aman Tokyo for our anniversary, last week of October — suite with city view."
| Field | Value | How populated |
|---|---|---|
| id | tsk_01HXY... | System-generated |
| title | Search: Aman Tokyo, suite, anniversary last week of Oct | Auto-generated from message content |
| action | Search hotels matching property + dates + suite type; return options to TA for review | Inferred from message intent |
| actor | TA (with AI search assistance) | Captured at creation |
| when | immediately | Default for Client-driven Assist |
| primary_owner | TA on the trip | Routing-assigned from trip ownership |
| watchers | — | None |
| status | In progress | Lifecycle |
| primary_context | trip:<Anderson family Tokyo Oct 2026> | Inferred from conversation thread |
| origin | Client-driven (explicit) | From §3.1 |
| creator | AI message classifier | Captured at creation |
| creation_surface | Message bubble — inline suggestion | Captured at creation |
| routing_tier | Assist | Default for Client-driven from §6.4 |
| priority | Normal | Default; no urgency markers in message |
| due_at | — | None set |
| rationale | Client message requested hotel booking with specific property + dates + room type. | AI |
| evidence_refs | [link to message] | AI |
| approval_state | human-approved | TA accepted the AI-proposed task |
| confidence_score | 0.92 | High — message specific, no ambiguity |
| task_type | client_follow_up | Inferred |
| subtype | direct_booking_request | Inferred |
| created_at | 2026-05-12T09:43Z | System |
| updated_at | 2026-05-12T09:44Z | System |
| snooze_until | — | None set |
| dismissal_reason | — | None set |
| reopen_count | 0 | System default |
| last_reopened_at | — | None |
| parent_task_id | — | Top-level task (not a sub-task) |
| agent_run_id | — | Not from agent mode |
D.2 Weather-disruption alert (escalate tier)
Flight-tracking feed pushes an alert: typhoon warning for Seoul, client arriving in 48 hrs.
| Field | Value | How populated |
|---|---|---|
| id | tsk_01HXZ... | System |
| title | Typhoon warning Seoul — client arrival in 48hr | Auto-generated from signal |
| action | Alert client of typhoon warning + prepare reroute scenarios | Inferred from signal + active trip |
| actor | TA on the trip (with AI for reroute option generation) | Routing-assigned |
| when | immediately | Time-sensitive disruption |
| primary_owner | TA on the trip | Routing-assigned |
| watchers | Ops manager | Auto-added (escalate-tier policy) |
| status | In progress | Lifecycle |
| primary_context | trip:<Wei Seoul May 2026> | Inferred from active-trip query |
| origin | World-driven (disruption) | From §3.2 |
| creator | AI signal monitor | Captured at creation |
| creation_surface | Weather feed monitor | Captured at creation |
| routing_tier | Escalate | Default for World-driven (disruption) from §6.4 |
| priority | High | Auto-bumped by time-to-departure proximity |
| due_at | 2026-05-14T06:00Z (T-24hr from arrival) | Derived from trip arrival timestamp |
| rationale | Typhoon warning issued for Seoul; client arriving 2026-05-14. Operator should alert client and prepare reroute scenarios. | AI |
| evidence_refs | [weather feed alert], [trip itinerary] | AI |
| approval_state | v1: pending-review (every suggestion goes to human review). v2: auto-approved for high-confidence disruptions | See §7.1 Stage 3 |
| confidence_score | 0.97 | High — reliable weather feed, real active trip, clear time pressure |
| task_type | disruption_response | Inferred |
| subtype | weather_disruption | Inferred |
| created_at | 2026-05-12T11:02Z | System |
| updated_at | 2026-05-12T11:02Z | System |
| snooze_until | — | None set |
| dismissal_reason | — | None set |
| reopen_count | 0 | System default |
| last_reopened_at | — | None |
| parent_task_id | — | Top-level task (not a sub-task) |
| agent_run_id | — | Not from agent mode |
D.3 Pre-arrival checklist (auto tier)
Daily scheduled query finds a trip departing in 10 days.
| Field | Value | How populated |
|---|---|---|
| id | tsk_01HY0... | System |
| title | Pre-arrival prep: Anderson Tokyo trip T-10d | Templated from trip name |
| action | Re-confirm transfers; brief restaurants on dietary notes; send weather + packing notes to client | Templated from pre-arrival policy |
| actor | Ops associate (with AI for templated communications) | Routing-assigned |
| when | scheduled:T-10d-from-departure | Derived from trip-lifecycle rule |
| primary_owner | Ops associate on the trip | Routing-assigned |
| watchers | TA on the trip | Auto-added per pre-arrival policy |
| status | In progress | Lifecycle |
| primary_context | trip:<Anderson family Tokyo Oct 2026> | Inferred from scheduled query result |
| origin | Trip lifecycle (templated prep) | From §3.3 |
| creator | AI scheduled query | Captured |
| creation_surface | Scheduled query (daily, trips departing in N days) | Captured |
| routing_tier | Auto | Default for Trip lifecycle templated prep from §6.4 |
| priority | Normal | Default; will auto-bump as date approaches |
| due_at | 2026-10-15T00:00Z (T-3d from departure) | Derived from trip departure |
| rationale | Trip departing in 10 days — pre-arrival checklist auto-spawned. | AI (templated) |
| evidence_refs | [scheduled query run id], [trip record] | AI |
| approval_state | v1: pending-review (templated trip-prep tasks still go to human review at launch). v2: auto-approved for high-confidence templates | See §7.1 Stage 3 |
| confidence_score | 0.99 | High — pure templated query, clear active trip, well-known pattern |
| task_type | trip_lifecycle_prep | Inferred |
| subtype | pre_arrival_checklist_T-10 | Templated |
| created_at | 2026-10-05T00:01Z | System (when the daily query ran) |
| updated_at | 2026-10-05T00:01Z | System |
| snooze_until | — | None set |
| dismissal_reason | — | None set |
| reopen_count | 0 | System default |
| last_reopened_at | — | None |
| parent_task_id | — | Top-level task (not a sub-task) |
| agent_run_id | — | Not from agent mode |
Reading the examples
- D.1 (Client-driven, Assist) — AI proposes, human approves; routing into the TA's task list. Most fields auto-filled from the message.
- D.2 (World-driven disruption, Escalate) — AI auto-creates the suggestion; the routing tier bumps watchers and priority. Human gate behaviour is phased — v1 always routes to human review for fast triage; v2 auto-approves above the confidence threshold.
- D.3 (Trip lifecycle prep, Auto) — Pure templated. The scheduled query knows it's a pre-arrival task and fills almost everything.
In all three: the operator never types 23 fields. The system or upstream signal does almost all the work. Manual creation is the only case where humans see fields directly — and per the §7.2 constraint, even then it's just title + owner.