record_case_timeline
Correlate previously submitted case evidence into a reproducible VMware incident timeline, revealing event spikes and ranked root-cause hypotheses for debug follow-up.
Instructions
[WRITE] Correlate everything this case has collected — steps 04/05.
WHEN: once evidence is in. Unlike build_incident_timeline, this takes no events: it reads the payloads already submitted, so the result is reproducible from the case folder alone months later, on a machine with access to nothing.
RETURNS: {event_count, window, binning, classification, spikes, spikes_total, hypotheses, evidence_without_events, evidence_without_events_detail, rejected, note} and writes timeline.md.
GOTCHAS: note distinguishes three states that all show zero events —
no evidence submitted at all, evidence that carried none, and a genuinely
quiet window — and names which items carried none, with what they held
instead. rejected names any row that could not be read, with the
evidence item it came from; dropping those silently would shrink the
picture the conclusion rests on. Submit a read tool's raw result as
payload for its events to reach here — a summary of the result carries
no rows, and submit_case_evidence says so at the time.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | How many ranked hypotheses come back (default 5). Spikes are capped separately at 20, true count in 'spikes_total'. | |
| case_id | Yes | The case whose submitted payloads are correlated (from open_case/list_cases). Unlike build_incident_timeline this takes no events — everything comes from the case folder. | |
| bin_seconds | No | Time-bin width in seconds. Omit and it is chosen from event density (ladder 1..86400, finest width still averaging 4 events per bin); `binning` reports which was used. | |
| z_threshold | No | Standard deviations above the mean bin count that mark a spike (default 2.0). Under 3 bins, or a flat series, yields none at any threshold. |