How it works · Signum Causa
How the record is made.
Five stages, each doing one thing, each leaving a trail. Nothing here depends on anybody remembering to write something down.
01 · Capture
Signum Causa joins the incident channel and buffers every message, edit, reaction and shared file as it arrives. Events are written to a durability log the moment they are received, so a process restart loses nothing beyond the write in flight. Channels bind to tickets by their name — no inbound webhook is required, because a missed webhook is silent and a deployment may have no inbound network path at all.
02 · Seal
Each revision of the transcript is canonicalised and hashed, and carries the hash of the revision before it. Change any earlier revision and every later one stops verifying. At rest the payload is sealed with authenticated encryption, bound to the ticket and document it belongs to, so a record moved elsewhere will not open.
03 · Extract
A language model reads the sealed transcript and returns structure: phase timeline, response delays, escalations, decisions taken, root-cause hypotheses, actions and their owners. The model is a configuration choice — Anthropic, OpenAI, Gemini, or any OpenAI-compatible endpoint you already run. A response that does not match the schema is rejected; a partial extraction is never stored.
04 · Verify
Every claim carries the identifiers of the messages it was drawn from. Claims that cannot be traced back to the transcript are shown as ungrounded rather than presented as fact, and an extraction whose grounding falls below the configured threshold is refused outright.
05 · Return
The transcript and the structured signals are written back to the ITSM ticket. Your service-management platform remains the system of record. Signum holds derived state only, and says so.