One row per order (grain order_id), sourced from int_whse__order_enriched. Carries the SLA outcome trio (is_otif / is_on_time / is_in_full), cycle_time_hrs (order→ship), line_accuracy_pct, order_value, and the client_id / site_id / consignee_id FKs. De-identified — consignee_id is a surrogate, never the recipient's name/address/email. This is the per-order table the fulfillment metric aggregates over; read rows here (via query_records('fulfillment_order')) to name which orders breached SLA. Client-scoped: the client_account_manager row policy restricts rows to the caller's assigned client_id.
- highReading open orders as SLA failures
Open orders have NULL ship_date / is_otif / cycle_time_hrs. Filter ship_date IS NOT NULL (or is_otif IN (0,1)) before treating a row as a decided outcome.
- highAssuming a manager sees all orders
Row policy silently scopes to the caller's client_id — two client managers get disjoint, non-empty row sets; ops/compliance/AI personas see all. A "missing" order is usually a tenant-scope boundary, not absent data.
- mediumAggregating rates from rows instead of the metric
For OTIF/accuracy rollups use the fulfillment / pick_accuracy metrics; these rows are for naming individual orders, not window-correct rates.
- “Which orders for this client breached SLA in June, and what was the pick accuracy?”
- “List the slowest-cycle orders shipped last month.”
- “Show high-value late orders for chilled goods.”