Repository Docs & Knowledge Base

Consolidated Spensara documentation repository (722 Markdown & architecture documents in ../repository)

Built Word Documents (.docx): Spensara Overview (.docx) Capability Assessment (.docx) Brink POS Ingestion Analysis (.docx) The Borg Ingestion Architecture (.docx)

Implementation Specs (157)

Detailed engineering and feature implementation specifications.

implementation-specs/specs/KdsMonitorServingContractMigration/TASK3.2.md 2,348 bytes · Updated Oct 23, 2026 10:44 AM EDT

Raw File

TASK 3.2: Run Redshift-Backed Dry-Run Validation

Summary

Validate the migrated KDS monitor specs through Redshift-backed dry runs.

This task confirms prompt compatibility with the runtime path from slice 03 and synthetic data from slice 02.

It is not the full monitor evaluation framework.

Dependencies

TASK 3.1 (static blocked-term validation)
Single-Store Redshift Runtime Read Path complete
Redshift Synthetic Data Feed complete

Files to Create or Modify

1. Validation notes if needed

If any dry run cannot be completed because of insufficient synthetic data or environment availability, document the reason clearly in an appropriate notes file or task output.

Do not change monitor thresholds to force validation success.

Required Behavior

Run dry-run execution for:

prep-time
order-surge
large-order-wave
priority-flood
slow-kitchen
station-bottleneck
forgotten-items
item-recall-storm

For each dry run, confirm:

generated SQL references only curated.orders and/or curated.order_items,
generated SQL does not reference kdsdev,
generated SQL does not reference store_guid or is_deleted,
generated SQL uses timestamp fields such as created_at, updated_at, prepared_at, done_at, or recall_at,
result is structured,
failures are data availability or environment issues, not prompt/schema mismatch.

Acceptance Criteria

[ ] Dry-run validation is attempted for all eight migrated monitors
[ ] Dry-run SQL uses only curated.orders and/or curated.order_items
[ ] Dry-run SQL does not reference kdsdev
[ ] Dry-run SQL does not reference store_guid
[ ] Dry-run SQL does not reference is_deleted
[ ] Dry-run SQL uses curated timestamp fields
[ ] Each monitor returns a structured result or clear no-data/no-anomaly outcome
[ ] Any environment or data-availability blocker is documented
[ ] No thresholds are changed merely to pass validation
[ ] No runtime code is changed in this task unless a small compatibility bug is explicitly identified and documented

Notes

Use existing dry-run monitor execution commands from the CLI/runtime.
A dry run after synthetic anomaly injection is useful when practical, but not required for this slice.
Full regression scoring belongs to the future evaluation framework.