Twiddl - Query Interface

basel-QA ●

Sheet1~qa_release.xlsx +

inventory_basel.csv +

boston-logistics ●

orders.csv +

inventory_boston.csv +

shipment_batch_allocations.csv +

shipments.csv +

dublin-operations ●

production_batches.csv +

machine_events.log +

SQL Query

Press Ctrl+Space for suggestions • Ctrl+Enter to execute

Query Results

⚡

Execute a query to see results

Query Playbook

Northstar Biologics

Northstar is a regulated, multi-site company: manufacturing in Dublin, QA in Basel, and logistics in Boston/North Carolina.

This walkthrough is designed for users who are new to the story and need a clear step-by-step explanation of what happened.

Operational data is split across CSV, log, and XLSX files on different nodes.
We first observe a company-wide incident signal, then localize the source to a specific production machine.
The key detection window is the last 7 days, with strongest excursion behavior in the most recent days.
Goal: move from signal detection to root cause and business impact with clear, explainable steps.

Observed Issue

Temperature excursion rates rise above normal across shipments tied to output from one specific machine lineage.

This means the signal appears across multiple carriers and routes because they are all transporting product from the same affected source.

This walkthrough is designed for someone new to the story: every step explains what to look for and why it matters.

1. Weekly lane-level anomaly signal

Motivation: Find where temperature excursion behavior is most abnormal so we can focus investigation.

Expected output: A ranked list of lane-carrier pairs with high excursion rate and enough shipments to be statistically meaningful.

2. Last-2-day spike timing

Motivation: Confirm when the incident sharply worsened inside the 7-day observation window.

Expected output: Daily trend with a clear late-window jump in temperature excursion rate.

3. Affected deliveries, batches, orders

Motivation: Build an actionable handoff list of exactly which shipments are affected.

Expected output: Shipment IDs linked to batch lineage and order value, ready for cross-team action.

4. QA history on affected batches

Motivation: See whether impacted batches share recurring QA hold/failure patterns.

Expected output: Release-status and hold-reason distribution that highlights systemic QA risk.

5. Alternate warehouse coverage

Motivation: Check whether alternate sites can cover demand right now.

Expected output: Net available inventory by site, indicating practical reroute options.

6. Delayed revenue estimate

Motivation: Quantify immediate financial exposure from blocked shipments.

Expected output: Two clear KPIs: impacted shipment count and delayed revenue amount.

7. Root-cause machine and line

Motivation: Localize likely operational root cause at machine-line level.

Expected output: Downtime concentration by machine and reason code, pointing to the strongest root-cause candidate.

8. Same-machine impact list

Motivation: Build quarantine candidates with direct customer and order impact context.

Expected output: Batch lineage records with customer names and per-record impacted revenue.

9. Finance handoff

Motivation: Provide a simple executive number for escalation and mitigation decision.

Expected output: Total quarantined revenue under the machine-linked incident scope.

10. Shared incident summary

Motivation: Create one shared cross-functional view for standup and decision alignment.

Expected output: Site-line summary with affected batches, quality signal, and delayed revenue in one table.