Open Questions
For the alignment meeting
These are the calls only the PM + TA leads can make. The outline does not pre-decide them.
Bucket priority for MVP
Five buckets in §3. Which 1-2 do we build for first? Different stakeholders may rank the buckets differently — World-driven (weather, vendor changes) versus Client-driven (explicit requests) versus Trip lifecycle (pre-arrival prep). Rank order is the gate before any scoping.
Starting proposal from the Conductor PM (for the alignment meeting to react to; can be refined in the PRD):
Two lanes: (a) explicit client / ops tasks from messaging + core workflows (§3.1a + manual ops creation), and (b) high-confidence proactive tasks from Trip lifecycle (§3.3) + Internal ops (§3.5). Defer behavioural signals (§3.1b), relationship moments (§3.4), and broader ambient sensing to a later phase.
Listening cadence per event-driven stream and schedule-driven query
Per-stream, not blanket. Some need real-time push (flight delays); some hourly is plenty (vendor pricing); some daily (birthdays). Affects infra cost and operator perception of "liveness."
Default routing per bucket
Matrix in §6.4. The proposed defaults are a starting point. Worth a working session.
Tolerance for false positives, per bucket
Auto-tier tasks fire without human review. What's the failure budget — global, or per-bucket? A 1% false-positive rate on relationship-bucket tasks is unacceptable; on internal-ops it's fine.
Closure model and per-origin mapping
(a) Same auto/assist/escalate tier model as creation, or separate? E.g. an assist-tier task might still auto-close, or always require human ACK regardless of creation tier. (b) Per origin bucket, what's the default closure path (manual completion / AI auto-close / AI-proposed close / manual dismissal)? Trip-lifecycle templated comms could auto-close on confirmation; Relationship-bucket tasks should require human ACK on closure regardless of creation tier. Default mapping to confirm at alignment meeting.
Default filters and sort orders per role
Tasks live on the shared task board (§7.2), visible to owners and watchers, not separate per-role dashboards. The open call: what default filters or sort orders do TAs vs ops associates apply, and which presets should we ship out of the box? Drives onboarding and the feel of the shared view without spawning role-specific dashboard products.
Agent sub-tasks: same entity model as ops tasks, or separate?
When the agent splits into AI sub-tasks + human sub-tasks inside a single agent run, do those flow into the global Tasks dashboard, or live local to the agent run?
Scope boundary — Tasks vs Alerts/Monitoring
Several schedule-driven queries (deal thresholds, award-space scans, expiring documents) feel like alerts more than tasks. Where does Tasks stop and a separate Alerts surface start? Affects whether a task is created up front, or only created when the user acts on the alert.
VVIP policy and detection
(a) What counts as VVIP — client profile flag, account tier, trip value above threshold, or some combination? (b) Once defined, does VVIP status auto-escalate every task tied to that client (or trip above $X) regardless of bucket, or apply specific bypass rules per origin? Both parts affect whether the escalation policy is implementable.
Closure audit and recovery
(a) Beyond a Reopen button, do we need a "soft-closed" intermediate state for high-stakes tasks (VVIP, large bookings)? Trade-off: cleaner UI vs. recoverability. (b) When AI auto-closes a task and an operator reopens it, what does the system do next cycle? Learn (skip re-firing under similar conditions), re-propose closure (forcing operator review), or escalate (mark the task as suspect)?
Review queue placement and expiry policy
The Surface model is set (central task board + Review queue, see §7.2). Open: where does the Review queue live in Conductor (standalone surface, overview-tab section, notification stack)? What's the expiry policy for stale suggestions, and the batch operations needed to prevent dead-inbox accumulation? Both are design + product calls for the alignment meeting.
Behavioural-signal scope
Which app behaviours count as task-shaped intent vs background-only? The §3.1b examples (4 properties tapped in a planning window, 3 deals saved in a region, repeated dynamic-trip-card opens) are starter examples; the full set + threshold values are a product call. Needs mobile-product input.
Priority assignment rule
§7.2 lists priority as a filter and the canonical fields block includes priority, but the outline doesn't say how priority is assigned. Manual? Urgency-derived (T-2 vs T-10 days)? VVIP-weighted? Origin-default with overrides? Affects whether operators trust the priority column.
Workload-balancing enforcement
§3.5 detects imbalance (TA A has 12 active trips, TA B has 5). When the next incoming task arrives, does the system auto-route to the lighter TA, or just flag the imbalance to the ops manager? Affects whether routing in §6 is fully automated or has a human checkpoint at assignment.
Internal-surface signal sources
§4 enumerates client-facing channels (chat, WhatsApp, email, voice, in-app) and external feeds (weather, flight, vendor data, advisory). Operator-side internal surfaces (Slack threads, operator inboxes, internal tool actions) are not yet enumerated as Signal sources. Which of these should the system sense from, and what's the rollout priority? Scope decision for the alignment meeting; affects how broad the v1 Signal surface is.