0xStrategies
· portfolio · dispatches · tracker architecture
deployed · spec v6.2← back
[ tracker · architecture specification · v6.2 ]

Tracker v6.2 — Subsystems, live ingestion, and the decision-first read.

A working specification of the live tracker as deployed at CHEMA Twilight: ~10,100 lines, 7 tabs, three export sources plus a live-CSV auto-pull, an engine-parity Outbounds view, and a three-layer Intel read built around what the coordinator does next.

Station
CHEMA TwilightPD-01 → PD-12
Scope
~10,100 lines · 7 tabsSOR/TMS · iGate · CURE · live CSV
Models
projection v0.5 · κ(DOW) · γM/M/c · LP-Lite · phase · Wilson
Author
Rafael Almeida2026-05-31 · spec v6.2
/ 01

Master architecture map

7 tabs · all online

The tracker is one HTML file holding the pipeline in conversation. Data flows left-to-right; corrections flow right-to-left. Sources arrive as drag-and-drop xlsx or as live CSV pulled from a watched folder; ingest reconciles them into one snapshot ledger; state derives a single truth keyed to the active sort snapshot; the seven tabs each read state and produce a report; the feedback path writes supervisor actions and constant changes back through metric_contract.json, the single source of truth the tools re-read.

function · pure computation
module · contains state
data store · persisted
source / input
Fig. 1.1 — tracker.architecture.svg 3 sources + live pull · left-to-right data flow · right-to-left corrections
SOR / TMSHeader + Operations iGateHub + Employee CUREdestination atlas live CSV pullFS-Access · 2 min ingest.reconcile()classify · 2-file SOR mergepull-bucket → 1 snapshot stateactive snapshot truthphase · zone · κ(DOW) · γscrubbed PPH ledger Hub · Timelinesnapshot arc Outbounds engineper belt+zone PPH Intel · 3 layersproject · live · post DOP plan · Historypre-sort wall sheet IDB v5 storetracker_ops_db · sort_snapshots metric_contractγ · κ · ρ · Π — single truth feedback / recalibraterebind constants → re-read data flow ─→ ←─ ─ correction loop · constants re-read from metric_contract.json ─ ─ one HTML file · ~10,100 lines · 7 tabs · IndexedDB v5
v6.0 → v6.2 · what changed The tracker moved from a single static import to a live, decision-first instrument. v6.0 added the signature theme and an engine-parity Outbounds view; v6.1 rebuilt Intel into three decision layers and turned DOP into a pre-sort plan generator; v6.2 (Codex) fixed live-pull snapshot grouping so the current view stops losing SOR hours. The constants are pinned in metric_contract.json — γ = 0.982, κ as a day-of-week vector, ρ = 0.509.
/ 02

Data ingestion — xlsx drops & live CSV

Three sources arrive in different shapes: SOR/TMS (a Header sheet + an Operations sheet), iGate (Hub Summary + Employee Summary), and CURE (the destination atlas). They can be dragged in as xlsx, or pulled automatically as the live-CSV exhaust of the export script from a watched folder via the File-System Access API (re-checked about every two minutes). Each file is classified by name, the two SOR sheets of a pull are merged, and the result is bucketed into a single operational snapshot.

functionresponsibilitybasis
_classifyTlFile()Routes each dropped/pulled file to hub · emp · sor by filename pattern.name-pattern match
_parseFilenameIdx()Derives the snapshot index from the (N) suffix (xlsx) or the YYYY-MM-DD_HHMMSS timestamp (live CSV).recency key
_livePullBucket()v6.2: rounds the timestamp to the nearest 30 s so all files of one pull share one snapshot index.30-second bucket
loadLatestFromFolder()Picks the highest-index file of each required type and runs the same pipeline as manual drop.FS-Access · ~2 min
reconcile / mergeMerges sources into the snapshot ledger; the 2-file SOR pull (Header + Operations) merges on the shared key.per-snapshot ledger
snapshot, not file One pull is one snapshot. A single live pull lands as separate files a few seconds apart — SOR at 23:10:59, Hub at 23:11:00, Employee at 23:11:03. The latest pull (highest index) becomes the live current view; see § 08 for the v6.2 fix that keeps those three files together.
/ 03

State & constants

The state module is the only place truth lives, and it is keyed to the active sort snapshot. Every tab reads from state rather than from the raw ledger, which is what lets a correction or a new pull re-flow the whole view without re-importing. Snapshots persist in IndexedDB (tracker_ops_db, schema version 5, sort_snapshots store keyed by [sort_date, source, snap_idx]) so a sort can be reopened and replayed.

State carries: phase (Φ1 → Φ4 by elapsed-volume fraction), the per-zone κ day-of-week vector, the current γ, the scrubbed per-loader PPH ledger, and the active borrow/loan map. The structural constants are not hard-coded in the tracker — they are read from metric_contract.json: γ = 0.982 (Friday ≈ 93% of Monday), κ_Z3 as the SEAS-basis DOW vector (Mon 0.413 → Fri 0.322), ρ_PD/Hub = 0.509 (a volume share), and Π_SOR ≈ 120.3 with cost c = 1/Π.

/ 04

Outbounds live engine

v6.0 · engine-parity

v6.0 replaced the old post-hoc "Area" view with _renderOutboundsLive(), which recomputes the loading picture from the same inputs the offline engine uses — iGate Hub + iGate Employee + live SOR — on every pull. For each belt and zone it reports Net, Loaders, Paid Hrs, Paid PPH, Scan Hrs, Scan PPH, and Util %, matching the engine rather than approximating it.

validated · 2026-05-28 Engine-parity confirmed on a full sort: 59,863 net · 77 loaders · paid-PPH 179 · scan-PPH 156. The outbound-only first cut breaks out the PD belts; pick-off and non-outbound areas roll into the building total rather than being shown separately.
/ 05

Intel — three decision layers

v6.1 · decision-first

v6.1 rebuilt the Intel tab around what the coordinator actually decides, in three layers. (01) Pre-Sort Projection — per-belt expectancy bands from the hierarchical projection (projection_per_belt_DOW_v05.json): the building-volume DOW band × the canonical belt share, turned into a paid-hour target at a plan PPH that steps 230 → 190, with a reliability bar showing how deep the allocation evidence goes. (02) Live · Now vs Projected — per-belt scanned-net against the band (BEHIND / ON-TRACK / AHEAD), with a building queue-state light and the sort phase. (03) Post-Sort — the Sort Quality Score, the γ trajectory, and zone performance.

The academic constructs (κ, ε, zone-entropy, Wilson intervals, M/M/c ρ) were moved into a collapsible Analyst-detail panel, each with a plain "what it means / what to do" line. The earlier Destination Load Intelligence and the CURE Cube scorecard were retired from the live view and archived.

/ 06

DOP — pre-sort plan generator

v6.1 · two decoupled PPHs

The DOP tab became a pre-sort plan generator built on two decoupled PPHs. A user-fixed Planned Adjusted Building PPH (the corporate, all-buckets number, ~118–124) drives the building manifold — total building volume ÷ adjusted PPH gives total paid hours and the cost-per-piece identity c = 1/Π. A separate per-belt outbound Load PPH (each belt's own ~170–270, with an optional override) drives outbound loader staffing — belt volume ÷ belt PPH ÷ target paid-day = the boss's Column M. The two are never conflated; the output matches the Friday-DOP.xlsx PresortDOP format and prints as a wall sheet.

/ 07

The feedback loop

Corrections flow right-to-left. Supervisor actions (borrow / loan, phase advance) rebind state rather than the data sources, so the next render reflects them without re-importing. Constant changes go one level deeper: when γ, κ, ρ, or Π are recalibrated, they are written to metric_contract.json, the single source of truth that both the tracker and the offline outbound engine re-read on boot. That is what stops net / window / exclusion definitions from drifting between the live tool and the engine.

/ 08

v6.0 → v6.2 changes

Codex fix merged

The lineage from the v2.11 spec ran v3 → v4.1 → v5 (live-CSV ingestion) → v6.0 → v6.1, with v6.2 the current head. The notable changes:

provenance The v6.2 fix was authored by Codex as an isolated fork of the v6.1 head; this spec documents the merged behavior. The deployed tracker bundle is tracker_v6.2.html at the CHEMA hub-operations suite.
document
Tracker Architecture · spec v6.2
CHEMA Twilight Hub · 2026-05-31
Rafael Almeida · Employee 6068314
related
Sort Intelligence v3.0
Unified Opus v6.0
all dispatches
source of truth
Constants from metric_contract.json
γ 0.982 · κ(DOW) · ρ 0.509 · Π 120.3