Flow: Monitor Authoring (Manager Iteration)

This flow is interactive. A manager describes what they want to monitor in natural language and iterates with the system until a MonitorSpec is approved and enabled.

Primary objectives:

• Convert vague intent into an executable, versioned MonitorSpec.
• Use the KB to ensure the monitor is feasible for the restaurant’s available data.
• Support “simulate/backtest” against historical data during iteration.
• Explicitly surface missing data (and minimum requirements) when needed.

Sub-diagram

flowchart TD
  M["Manager"] <--> SB["Spec Builder (LLM)"]
  SB <--> ORCH["Orchestrator"]

  ORCH <--> SEM["KB/Semantic Agent"]
  SEM --> CM["Capabilities Manifest"]
  SEM --> KPI["KPI Catalog"]
  SEM --> DOC["Doc Index (RAG)"]

  ORCH <--> DA["Data Access Agent (MCP/tools)"]
  DA --> W["Warehouse DB(s)"]

  ORCH --> SPEC["MonitorSpec Store (versioned)"]
  SB <--> SPEC
  M -->|"Approve + enable"| SPEC

  classDef store fill:#f6f8fa,stroke:#9aa4b2,color:#111;
  class CM,KPI,DOC,SPEC,W store;

What “good authoring” produces

An approved MonitorSpec should be:

• Executable: contains enough structure for runtime to run broad scans and drilldowns.
• KB-aligned: references known entities/joins/units from the Capabilities Manifest.
• Evidence-oriented: includes minimum evidence requirements (e.g., baseline definition, sample size).
• Alert-ready: defines how to map findings to High/Medium/Low severity.

Typical iteration loop

1. Manager provides prompt (“Monitor prep times by hour; detect strange slowdowns; consider item-count correlation; refer to manual KPIs”).
2. Spec Builder drafts monitor intent + clarifying questions (only when necessary).
3. Orchestrator consults KB/Semantic agent to map intent → available data.
4. Backtest/simulate using Data Access agent (feature panels).
5. Spec is revised until manager approves and enables it.