Decision ReceiptIncident ResponseDR-K7M9-2P4Q
Verified- Decision
- Approved by Risk Committee
- Policy
- Third-party risk — Tier 1, v7
- Evidence
- 3 attestations, 2 documents
- Integrity
sha256:0xdead…beef
Use casesIncident decisions
Incident decisions you cannot justify.
Calls are made in real time, under pressure. When asked to justify them afterwards, most organisations cannot produce a verifiable Decision Receipt.
MeshQu changes that.
Signals
System state
Alerts
Runbook clause
On-call actor
Comms log
Decision
Incident decision at execution
Contain · Override · Escalate
Proof
Decision Receipt
Verified
01The moment
An incident occurs.
A system fails. A transaction is disrupted. A service degrades. Teams respond in real time.
A decision is made: Contain, Override, Continue, or Escalate.
Severity declared
INC-2406-0144 · Payments degraded
- State
- partial outage · EU region
- Duration
- 00:09:42
- Posture
- Customer impact SEV-2
ContainOverrideEscalate
02The failure
You are asked to justify it later.
Why was the service kept live? Why wasn't it shut down? Who made the call? What information was available at the time?
You reconstruct from incident logs, chat threads, dashboards, timelines. It takes time. And under pressure — you don't have a clear answer.
Reconstructing the response…
- Pull incident timeline40 min
- Recover chat transcript60+ min
- Capture dashboard stateoften lost
- Match runbook revision30 min
- Build justification90+ min
Not justifiable.
03The reason
It was never captured at execution time.
Incident systems track events — they don't capture the decision itself as a verifiable, replayable record. No Decision Receipt is produced.
The response happens. The proof doesn't.
Signals received
Logs written
The gap
No verifiable record of the call
04The shift
Decisions made under pressure should still produce proof.
Not post-incident reports. Not reconstructed timelines. Not best-effort explanations.
A decision should leave behind a verifiable record at the moment it is made.
Signals received
Logs written
Decision + Proof
At execution
05At execution
Captured as it happens.
Most incident workflows record decisions after the event.
MeshQu captures them at execution time.
When the decision is made, it is recorded, sealed, and verifiable. After the fact is narrative. At execution is proof.
ALSTON
MeshQu Decision Layer
Decision Receipt
Verified
06The receipt
Every incident decision produces a receipt.
A Decision Receipt contains the context at the time, the inputs available to the team, the policy or thresholds applied, the decision taken, and the actor.
Signed. Verifiable. Replayable. No reconstruction required.
07A new layer
It works with what you already use.
Monitoring systems. Alerting tools. Incident management platforms. Runbooks. MeshQu doesn't replace them.
Your systems detect the incident. MeshQu proves the response.
Monitoring
Alerting
IM
Runbooks
MeshQu
— receipt
decisioncontain
runbookPAY-04.2
actorinc-lead
sealverified ◎
08Consistency
Pressure doesn't change the requirement.
Manual response. Automated failover. Runbook execution. Every decision produces the same receipt.
Subscriptions raise an alert the moment a receipt is missing — not at the post-mortem. Gaps surface live.
Manual response
On-call call
Automated failover
Runbook trigger
Runbook execution
Step-by-step
Pressure doesn't change the requirement.
09The result
You can answer with certainty.
The receipt resolves instantly — what happened, what was known at the time, what decision was taken, under which conditions. Verifiable.
Asked
Why was this decision made?
RCP-01H7M12B7G6IR9X VerifiedResolved in instantly
10Close
You made the call under pressure.
The question is — can you justify it afterwards?
Decision AssuranceCapture every decision. Prove every time.