38°F, 103°F, 253°F: reconstructing the East Palestine bearing failure from the NTSB report
This article walks through maintenance-triage-agent, a workable example from the open-source SIE repo on GitHub: a document pipeline that reconstructs an equipment failure sequence from the published pages 4-5 spread of the NTSB SPC-24-06 East Palestine digest, with every value cited to its source span. SIE is Superlinked’s self-hosted inference engine, one cluster that serves embedding, reranking, OCR, vision, entity-extraction, and generation models behind three primitives (extract, encode, score). The example is a complete project with that spread bundled. Built by Superlinked.
Three wayside detectors recorded the same railcar bearing in the hours before the East Palestine derailment. The readings, in order: 38°F above ambient, then 103°F, then 253°F. Alerts escalated along the way. The NTSB documented all of it on the illustrated pages 4-5 spread of its public SPC-24-06 digest.
The maintenance-triage-agent example in the SIE repo asks a disciplined question: can a document pipeline reconstruct that failure sequence (locations, times, temperatures, alerts, and recipients) as a cited timeline, drawing only on what the report says and adding no causal claim of its own?
The constraint in that last clause is the whole example. It’s easy to build a system that reads an accident report and produces a confident narrative. It’s much harder to build one where every element of the timeline traces to an exact span in the source, and where the system stops rather than filling gaps.
The pipeline
The NTSB report PDF moves through five stages, all served by one SIE deployment.
Docling extracts markdown from the PDF. BAAI/bge-m3 embeds and ranks the relevant passages. Qwen3-Reranker-4B reorders that evidence against each specific question the reconstruction needs answered. GLiNER models then extract exact spans: detector locations, event times, temperature readings, alert types, railcar counts. Finally, Python performs the transparent calculations and validates the critical fields.
The chaining is strict. Each stage consumes the previous stage’s output, and if any required field is missing (an event time, a reading, an alert recipient, a bearing detail), the workflow stops. No required field, no reconstruction. The output is the progressive temperature rise across three detection stations, correlated with the escalating alerts, every value carrying its citation back to the report.
The failed experiment they kept
Here’s the detail that makes this repo worth reading rather than just running. The developers tried asking models to return structured JSON directly, the approach most document-AI tutorials teach. The probe failed on this material, and instead of deleting the attempt, they committed it: request and response preserved as diagnostic evidence.
The architecture that shipped goes the other way. Extract exact text fragments from ranked paragraphs, then do the assembly and arithmetic deterministically in code. For evidence work, the span-extraction approach has a property schemas can’t offer: a span either exists in the source document or it doesn’t. There is no gray zone where the model returned well-formed JSON containing a number that appears nowhere in the report. Schema-constrained generation is convenient; verifiable grounding is a different requirement, and this example documents the difference with receipts.
”Without adding a new causal claim”
The reconstruction stops at what the detectors recorded and who was alerted. It does not say the bearing caused the derailment, even though every reader will draw that line themselves. That restraint is deliberate, and it’s the difference between evidence tooling and narrative tooling.
The NTSB spent months establishing causation with metallurgy, simulation, and interviews. A document pipeline that reads the final report and re-asserts the causal chain adds nothing; one that quietly extends it (a stronger verb here, an inferred link there) actively corrupts the record. Restricting output to cited observations keeps the pipeline on the right side of that line. The temperature went from 38°F to 103°F to 253°F above ambient across three stations, alerts escalated, specific crews were notified. Those are extractable facts with page numbers. Everything beyond them belongs to the investigators.
If you’re building tooling for incident review in any industry, this constraint is worth adopting before your first user asks you to defend an inference your system made up.
Running it
uv run triage-fault --run-id localSIE Cloud endpoints are configurable via environment variables if you’d rather not run the models locally. The run emits comprehensive artifacts: raw model responses, per-detector spans, and evaluation results, so the full path from PDF to timeline sits on disk for inspection.
From accident report to maintenance log
The NTSB report is the demo corpus because it’s public, precise, and consequential. The pattern is broader. Every industrial operator holds sensor readings, inspection records, and incident writeups that occasionally need to be reconstructed into a defensible sequence: what did the equipment show, when, and who was told. Warranty disputes, safety reviews, insurance claims, and regulatory responses all reduce to that shape.
A pipeline that produces cited timelines and halts on missing evidence fits those uses. One that produces fluent uncited narratives does not, however good the prose. The gap between the two is exactly what this example is built to demonstrate, one failed schema probe and one working reconstruction at a time.
The report is bundled. Run the triage, read the timeline, and check any temperature in it against the NTSB’s own pages.
Try it on GitHub: superlinked/sie/examples/maintenance-triage-agent