Runtime Incident Reconstruction & Forensics

Understand what happened - and whether it was already unstable before it did.

Traditional AI forensics can show what a system did.
Runtime field forensics can show whether the system was already unstable when it did it.

This service reconstructs AI incidents at the inference-phase, where logs and metrics go blind.

What This Is

Runtime Incident Reconstruction & Forensics is a focused SubstrateX engagement that rebuilds a real AI incident as a runtime field event.

Using your governed telemetry - and, where available, FieldLock™ / ESL traces - we reconstruct:

  • when the system first left a Stable regime

  • how long it operated in Transitional or Phase-Locked states

  • which stability signals deviated before failure became visible

  • what changed between nominal behavior and the incident window

This is not generic debugging.
It is post-incident inference-phase analysis.

Why It’s Valuable

Most AI incidents are described in vague terms:

“The agent went off the rails.”
“The model suddenly became brittle.”
“We saw cascading hallucinations.”

Those descriptions don’t explain what actually changed.

Runtime Incident Reconstruction:

  • turns opaque failures into structured, explainable events

  • shows how far back instability began — not just where it surfaced

  • identifies precursor signals you can monitor next time

The output feeds directly into:

  • future FieldLock alert thresholds

  • ESL risk history and baselining

  • board, audit, and regulatory reporting

You leave with a defensible answer to:

What happened, when did it start, and could we have seen it coming?

Why Logs Aren’t Enough

Traditional tools can tell you: which endpoint failed or which step produced an error.
They cannot tell you how the system’s behavior was deforming over time.

SubstrateX reconstructs the runtime worldline of the incident - the invisible trajectory that led to failure -
using stability regimes, deviations, and temporal dynamics that conventional observability does not capture.

This is the only incident analysis built on inference-phase dynamics, not surface metrics.

Flowchart titled 'Deconstructing AI Failures: The SubstrateX Forensic Process' with two main steps. Step 1: 'Ingest & Reconstruct the Trajectory' shows a diagram of data flowing into a funnel labeled 'Replay the 'Flight Recorder'' which ingests logs to recreate an internal dynamic model, and 'Map the AI's 'Train of Thought'' illustrating traces in a workflow. Step 2: 'Analyze Signals & Generate Evidence' depicts analyzing signals like 'Curvature (Φ)' and 'Drift (Ψ)' to generate JSON reports, then determining if failure was forecastable, documenting the time gap between instability signals and failure.

What This Service Does Not Do

This service does not:

  • modify your models or prompts

  • tune agents or policies

  • replace SRE or postmortem processes

  • provide legal or compliance sign-off

It is a field-level analytical layer that integrates with existing incident management.

When to Use This Service

A Runtime Incident Reconstruction is appropriate when:

  • a visible failure occurred (hallucination, runaway loop, tool misuse, collapse)

  • logs and traces exist, but don’t explain why

  • internal reviews answered what, not how instability formed

It is especially effective when:

  • a FieldLock Validation Engagement has already run, or

  • telemetry can be mapped into the ESL schema

What You Receive

Each engagement produces a consistent, governance-ready artifact set:

  1. Incident Worldline Reconstruction

  2. Regime Timeline & Transitions

  3. Deviation & Precursor Signal Analysis

  4. Baseline vs Incident Comparison

  5. Incident ESL Summary

  6. Forward Recommendations (non-binding)

All outputs use the same invariant and regime canon as FieldLock, enabling comparison across incidents and future runs.

Engagement Structure

Typical: 2–4 Weeks

Phase 1 —
Scoping & Governance
Incident window, data envelope, access constraints, stakeholders

Phase 2 —
Data Mapping
Normalize telemetry and align to invariant / regime inputs

Phase 3 —
Reconstruction & Analysis
Rebuild the incident worldline and identify deviations

Phase 4 —
Report & Review
Deliver artifacts and review with engineering, SRE, and governance teams

Optional outcomes:

  • recommendation for Validation Engagement

  • guidance on permanent FieldLock deployment

Diagram showing a process for evaluating isolated outputs in AI, illustrating snapshots of outputs, resulting in failure due to lack of context. Includes sections on trajectory analysis, failure prediction, behavioral regime transitions, recovery, and redefining failure as a system problem.

How to Engage

Because incidents are sensitive, every engagement begins with a confidential call.


➡️ Request an Incident Reconstruction
➡️ Speak with the Founding Team

We will help you turn an opaque failure into a measurable, explainable runtime event — and use it to harden what you build next.