A goal-loop that studies our own purchase history and proposes supplier lead times and reorder points, 50 items at a time, as evidence-backed spreadsheets for Lerris to approve — the homework the Odoo migration needs done anyway.
Each batch lands as a review spreadsheet — proposal + evidence per item, with approve/reject columns. Approved values go into Odoo during migration data-prep, not into the dying ERP.
Only 9% of items had a supplier lead time on record and 0% had reorder points — so the ERP cannot warn anyone before we run out. A key design ruling is encoded: demand counts outflow only (sales + work orders); incoming purchases don't inflate it.
“All 50 items have a proposal + evidence”
PO intervals, vendors, demand variability
Lead time, reorder point, safety stock per item
Proposal + evidence + approve column
Approved values go to Odoo via the migration team
For implementers and the technically curious. The full build sheet — verified queries, thresholds, and build notes — lives on the specs page.
| System | Role in this loop |
|---|---|
| NetSuite warehousePostgres on our server | Our nightly read-only copy of NetSuite (ERP) data — items, stock, transactions — refreshed by the ETL sync every morning. The loop queries this copy, never NetSuite itself. |
| ETL extensionraw planning fields | The data connection built for this loop: item planning fields and preferred vendors now sync nightly into the warehouse — the same extension that unlocked the receivables watchdog. |
| Metabasebi.huxapps.com | The BI layer over the warehouse. The loop runs its SQL through Metabase's API, and every number in the digest links to a live, clickable Metabase list so you can drill into the exact records. |
| Email renderer + gwsrender_email.py | All digests pass through one shared renderer: Huxberry-branded HTML, tables for repeated rows, a coral 'needs your response' box when the loop has questions, and an arrow link on every record. Sent from the loops mailbox via the Google Workspace CLI. |
| Loop chassisloop_common.py | Shared plumbing every loop reuses instead of reinventing: state files, run-over-run diffing, Metabase drill-down link building, quiet-on-green notify logic. |
| Model / brain | What it does here |
|---|---|
| GPT-5.5 via Codexthe bulk-work model | Wrote and maintains the mechanical parts — SQL, diffing, digest assembly. Effectively free on our existing subscription, so routine cycles cost almost nothing. |
| Claude Opusthe judgment model | Reviews alert wording, thresholds, and anything a human will read and act on. Post-Fable, Opus owns everything that ships. |
| Claude Fablethe designer (retired) | Designed this loop's spec and encoded the judgment as thresholds and checklists before its retirement on 8 July 2026 — so cheaper models can run it without Fable-level reasoning. |
A cumulative burn-down ledger: proposed and approved items are excluded from future batches. Note for operators: even a dry-run reads this state — use a scratch copy to reproduce batch 1.
A spreadsheet per batch (emailed, attached), plus a coverage line: % of active items with proposed + approved values.
Proposals only — a wrong reorder point costs real money, so Opus sanity-judges every batch before it's sent, and a human approves every value.