Investigations

LifecycleCopy Anchor Link

Every investigation has one of these persisted statuses:

• pending — created and waiting for background work.
• running — the background worker is executing the investigation.
• completed — results were stored successfully.
• failed — a failure occurred before a result could be produced, or the investigation timed out.

March starts an investigation asynchronously. The UI can show a pending result before the background work is finished and refreshes to show the final result. Pending and running rows whose last update (updatedAt) is older than 20 minutes are treated as failed with Investigation timed out.

Failures inside the investigation run are stored as a completed escalate result: unreachable model providers after retries use model_unavailable; other run failures, incomplete conclusions, and step-budget exhaustion use insufficient_evidence. failed is reserved for failures outside the run that prevent a result, such as missing stored input, source/context-loading failures that escape before a result, storage failures, or a trigger path that calls store.fail.

The investigation traceCopy Anchor Link

For completed investigations, the detail page shows a structured trace called How March investigated this:

• Understood — what March believes changed and why it may matter.
• Checked — the searches and resources March examined, including links and relevant-result counts when available.
• Found — the evidence March considered relevant, with its provenance.
• Concluded — the final interpretation tied to the decision.

This is a concise, structured record. It is not a transcript of hidden model reasoning or chain-of-thought.

Outcomes and recommendationsCopy Anchor Link

The implementation uses these exact investigation decisions:

• propose_action — March found one or more consequences. The UI presents those as recommendations/required updates: the affected surface, current state, recommended state, why it matters, and evidence. A proposed action describes how a consequence might be carried out; it is distinct from the recommendation itself.
• no_action — March found no downstream update required. The UI can show the surfaces it checked and confirmed as already current.
• escalate — evidence or scope is insufficient for a safe decision. The result includes an escalation type, a question, and a reason. Types include needs_human_judgment, insufficient_evidence, conflicting_evidence, out_of_scope, and the system type model_unavailable.

Each evidence item has a finding and provenance: a label plus a URL or locator. The detail view uses that provenance to make the result inspectable. March does not force a normalized change when the event is purely internal or too ambiguous; a result can contain zero normalized changes.

Required updates have their own later work states (open, in_progress, resolved, and needs_review) and verification states such as verified or verification_failed. These are separate from the investigation's final status and decision.