# 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

```mermaid
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.