Tickets and routing assumptions
Channel, customer tier, region, symptom code, sentiment, reopens, tenure, prior CSAT, observed response/resolution minutes, and a free-text note.
6 Billing6–7 Technical5 Account & Access
Basel Jabour / Automation & Engineering
A routing decision is only useful if you can trace it.
A reproducible daily workflow that turns ticket batches into verified routing, visible exceptions, and a reviewable ops handoff.
Intake→Triage→Brief
Sep 03 / Recorded exception
96.3%Capacity coverage against a 100% requirement
8 material warningsCRITICAL
Input / config / codePINNED
Human approvalPENDING
Dates3
Daily tickets~17
Stages3
UnitMinutes
Source contract
Validate once. Preserve exactly what was filed.
Nine source files cover September 1–3, 2026. Each date contains three small ticket queues.
Bad inputs stop the workflow
Required fields, finite values, cross-file IDs, controlled vocabularies, submission timestamps, and the ten-ticket limit.
File and field diagnosticsFailure journalNo silent coercion
Expect exactly the configured inputs.
Reject malformed or inconsistent rows.
Copy inputs and pin configuration.
Bind data, config, code, and predecessor.
System design
A triage run can resume because its state is explicit.
Python orchestrates stages. Persistent checkpoints make prerequisites and evidence verifiable.
Daily ticket CSVs
+ versioned config
→+ versioned config
INTAKE
→Contract checks
Input + config snapshot
TRIAGE
→Verified input hashes
Deterministic routing + SLA
BRIEF
Verified result hashes
Handoff + what-if export
Run identityCheckpointsSQLite registryJSONL journalSHA-256 evidence
Same evidence, same run identity
Completed stages are reused. Changed input, configuration, code, or predecessor result produces a different identity.
Check first, then continue
Downstream stages verify their prerequisites. Altered snapshots are rejected before a result is consumed.
Decision signal
The final snapshot exposes a capacity shortfall.
The reporting sequence progresses from CLEAR to REVIEW to CRITICAL. The dashboard links warnings to evidence.
Bounded assistant
Explanations are anchored to recorded facts.
The briefing layer follows registered tools, verified facts, and explicit reporting rules.
Inspect → cite → explain
Read the verified summary, resolve warnings and source references, then produce an ops brief and successor questions.
Tool prerequisitesExact metric claimsVisible evidence paths
Review stays with the owner
The reporting layer cannot change routing, remove warnings, approve a run, or reassign staff.
Pending human reviewTicket text is data, not instructionsNo hidden provider
Example / from the verified September 03 snapshot
“Staffed capacity covers 96.3% of required handling time, below the configured 100% requirement.”
result.json → metrics.ccr_pct / metrics.ccr_requirement_pctVerification evidence
Test the failure paths, not just the happy path.
The exported checks exercise the implementation with controlled faults and compare outputs against the accepted baseline.
✓
All metrics and per-queue metrics match the archived baseline to six decimals.
✓
A capacity ratio below the configured requirement is flagged CRITICAL, not merely reported.
✓
A change to operational source changes the run identity and blocks an old prepared checkpoint.
✓
Live config drift blocks downstream reuse; preparing again preserves the old snapshot as a new run starts.
✓
IDs must be globally unique across all three files, not just unique within each file.
✓
Batch intake rejects missing predecessor checkpoints before creating any partial runs.
✓
Structured values, all warnings and pending approval must match; arbitrary prose stays unverified.
✓
Repeated all reuses exact run identities, artifact bytes and log events.
Eight selected checks. Full suite in the control tower.
Routing, priority and SLA outcomes reproduce the original scenario. Improvements are in controls, evidence, and interaction.
Checks cover routing regression, SLA-boundary accuracy, data integrity, version changes, recovery, reporting boundaries, and injection resistance.
Successor handoff
One project, two ways to inspect the work.
Explore the evidence in the browser or reproduce it locally from the included source.
Understand the operating decision
Compare dates, inspect tickets, explore a staffing shock, replay actual logs, and question the bounded assistant.
Reproduce the engineering
Run intake, triage, brief, or all. Inspect plan, status, and verify outputs. Execute the control suite.
Process the dated synthetic inputs.
Check identity and evidence.
Reconcile exceptions with an owner.
Replace proxies with governed models.
Extension points: approved ticketing-system adapters, governed classification and staffing models, authenticated review, monitoring, and model-service evaluation.