From First Symptom to Post-Mortem, Without Losing the Thread

The gap between fixing it and understanding it

An incident gets resolved, everyone moves on, and three months later the same class of failure happens again — because the actual root cause never made it past the engineer's short-term memory into something the next on-call could find. TRCAA's core workflow exists to close that specific gap, not to replace the judgment of the person doing the triage.

Six steps, one continuous record

Every incident in TRCAA moves through the same structure: New Issue → Log Upload → Triage → Resolution → RCA → Post-Mortem. Each step writes to the same underlying record (IssueDetail: the issue itself, its log files, its resolution steps, and its full conversation history), so the reasoning from step two is still there and referenceable when you're writing the post-mortem in step six.

The 5-Whys, as a conversation

Triage happens as a chat, seeded with a domain-specific system prompt — TRCAA ships expert-level prompts for Linux, Windows, Networking, Kubernetes, Databases, Virtualization, Hardware, and Observability, so the AI's first response is already grounded in the right domain instead of asking generic clarifying questions. As the conversation progresses through why-levels 2 through 5, each answer is captured as a resolution step, building the causal chain instead of leaving it scattered across a chat transcript nobody will reread.

Generation, not transcription

Once the root cause is identified, RCA and post-mortem documents are generated from that structured history via markdown template builders (docs/rca.rs, docs/postmortem.rs) — not a raw dump of the chat log, but a document built from the actual resolution steps, timeline events, and root cause the triage session produced. The result opens in a doc editor for review and edits before export, because a generated first draft is a starting point, not a final answer.

Why this matters more than the AI model underneath

The specific AI provider — local Ollama, or a cloud provider once PII redaction has run — matters less than most vendors would like you to believe. What actually determines whether an incident produces a useful post-mortem is whether the reasoning survives the trip from "something's wrong" to "here's the document for next time." That's the problem TRCAA's workflow is built around.