Timeline extraction
Before IncidentScribe drafts a word of prose, it builds a structured timeline of what actually happened — a chronological list of events, each with a typed actor, a typed timestamp, and a one-line summary, each traceable to the exact source slice it came from. The timeline is the ground truth the rest of the pipeline writes against.
Drop in anything
Paste a Slack channel export, a PagerDuty incident dump, a raw log file, or freeform notes. Multi-thousand-line inputs are fine. IncidentScribe slices the input on natural boundaries first, so a long, messy incident channel becomes a set of manageable chunks the on-device model can reason over without losing the thread.
Schema-constrained, not free-form
Extraction is constrained to a typed schema: the model can only emit timeline-event records with the fields the schema defines. It can’t return an essay, can’t editorialise, and can’t invent a field. That constraint is what makes the output mergeable and verifiable rather than another wall of generated text.
Fabrications dropped before you see them
Every extracted event is validated back against its source slice. If an event names an actor or a timestamp that can’t be located in the original text, it’s dropped — not shown with a warning, dropped. On-device models, like all language models, occasionally hallucinate a plausible participant. The validation pass is deterministic Swift code, not a second model, so those fabrications never reach your timeline.
Reconciled into one master timeline
Per-slice timelines are merged into a single deduplicated, chronologically ordered master. The same event mentioned in three places collapses to one entry; out-of-order log lines sort into sequence. What you review is one clean timeline, with every entry still carrying its citation back to the source.
From there the drafter takes over — working only from this validated timeline, never the raw text. See the full walkthrough on a real memory-leak incident.