How we handle verification of operational events
A prospect asked how we handle verification of operational events when humans and agents work together on risk assessments, risk registers, compliance, standard controls and vendor assessments, using email, Slack, voice notes and documents alongside each other. Verification is the part that bites, and it is the reason the architecture looks the way it does rather than being an ingest-and-query pipe. Nothing becomes history just because it arrived.
Every inbound item (email, Slack, voice note, document, ticketing webhook, scanner finding, agent output) is normalised into one canonical event shape with a “VerificationStatus” governed by a four-stage lifecycle:
- Unverified (initial ingestion state)
- Pending Review (queued for human or agent evaluation)
- Verified (confirmed and committed to history)
- Rejected (dismissed or failed validation)
Only verified events count as operational history. Agents read the verified layer; unverified material stays visible but explicitly marked as unconfirmed, and agents are not permitted to act on it. A bad Slack message lands as a claim, and stays a claim until someone verifies it.
Conflicts and supersession
New information that conflicts with a confirmed event doesn’t replace it. It raises a conflict that a human resolves, or it auto-supersedes once the replacement is itself confirmed. Superseded events stay in the record, so the timeline distinguishes “what is currently true” from “what used to be true”, with the full chain of why it changed and who changed it. Timestamps alone were never enough for us either.
Evidence strength
We score evidence strength rather than treating confirmation as binary. A geotagged, timestamped, hash-anchored document is not the same signal as someone typing “done”. That score gates what automation is allowed to do: weak proof can inform; only strong proof can sign off a control or clear a finding.
Governed execution
Agent decisions arrive as structured events routed through a controlled action router, with severity, confidence, rationale and a trace ID written to an append-only audit log before any state change. High-consequence actions require approval and are reversible where reversibility is meaningful. That makes us slower to adopt, and the trade is deliberate, because the actions in our domain end up in front of an auditor.
Multi-party access
An organisation, its external auditor and its managed service provider as separate organisations on one shared object is the case we built for. Anyone claiming the problem is solved should be treated with scepticism. Ours is a per-organisation identity with row-level access control at the database, scoped so each party sees only its permitted slice of the shared timeline, plus an allowlist governing which external tools may ever be connected to a workspace. Every cross-org read and write is logged. Airtight-by-construction rather than airtight-by-assertion, and the access model is the thing we keep pressure-testing.
In brief: the timeline is a verification pipeline with an audit trail attached, and the interesting engineering is entirely in what it refuses to accept.