Evidence
The part of the incident that survives the conversation.
An evidence record is a compiled artifact for one incident: what was measured, over what window, from where, what the detector concluded, and the hashes that let a stranger check none of it was altered.
The artifact
Independently measured · signed record
payments-api
Major dependency event on payments-api - resolved: 83.33% measured availability over 35 min 25 s
Incident window
35 min 25 s
14 Nov 2025, 09:12 → 09:48 UTC
Measured availability
83.33%
30 of 36 measured checks reached the target
Measured downtime
5 min 54 s
inside a 35 min 25 s window, 6 failed check(s)
Attribution
Vendor failure
91.25% confidence · v1.0
What the record shows
- 6 of 36 checks issued to https://api.payments.example/v1/charges failed inside a 35 min 25 s window beginning 14 Nov 2025, 09:12:41 UTC. Measured availability for the window is 83.3333%, computed from these checks only.
- The longest unbroken run of failed checks was 6, at 1 observation point. The detection rule that opened this incident was recorded as “Consecutive failed checks (single observation point)”.
- The attribution engine classified this as “Vendor failure” at 91.25% confidence under methodology v1.0. That classification describes what the timelines support, not fault or liability.
- Every observation here was issued from a single RELIASTRA observation point. Confirmation is by persistence of failure over 35 min 25 s, not by agreement between independent points, and no cross-verification is claimed.
1. Incident RecordFinal · incident resolved
3. Incident Window Measurements
4. SLA Impact Calculation
8. Deterministic Attribution
https://reliastra.com/reports/rsl_ver_7Q4M2X8A3RK9TZ0B
Retained for 365 days, then deleted: only the hashes recorded at the verification address remain checkable. Sections 1, 3, 4 and 8 are shown; the full document carries eleven, including the observation appendix and this block in full. Headings, labels and formatting are the ones the generated report uses; the values are an example, not a recorded incident.
Illustrative structure. The field labels and section order are the ones the renderer emits; the values shown are an example, not a real incident.
01The finding
Four figures before the sections that substantiate them.
A reader opens a document of record with one question. Answer it on the first page, then show the working - a report that makes somebody hunt for the number is a report that gets skimmed.
- 01Incident window
- 02Measured availability
- 03Measured downtime
- 04Attribution
02Contents
Ten sections, and the fields in each.
Incident Record
- Report Reference
- Incident ID
- Organization
- Monitored Dependency
- Severity / Status
- Started At (UTC)
- Resolved At (UTC)
- Measurement Window (UTC)
- Observation Topology
Detection Record
- Detection Rule
- Rule Identifier
- Detector Confirmation
- Basis
Incident Window Measurements
- Checks In Window
- Successful Checks
- Failed Checks
- Blocked Checks (Excluded)
- Measured Availability
- Longest Failure Run
- Latency (ms)
- First / Last Observation
SLA Impact Calculation
- Planned Target Uptime
- Measured Availability In Window
- SLA Degradation Impact
- Measured Downtime
- Allowance Exceeded
- Calculation Basis
Observed Latency And Failures
The chart, drawn from the observations in the appendix rather than from a separate aggregate.
Rolling 24-Hour Health (Context)
- Rolling 24h Availability
- Rolling 24h Average Latency
- Rolling 24h Checks
Correlated Dependency Events
- Correlated Dependency
- Correlation Method
- Time Window
- Confidence
Deterministic Attribution
- Classification
- Confidence Score
- Methodology
Documented Observations
- Executed At (UTC)
- Observation Point
- Result
- Latency
- Status
- Detail
Authenticity, Retention and Verification
- Verify this record
- Signature
- Retention
- Rendered By
03Integrity
Three separate things are being proved.
A checksum over the payload, a checksum over the rendered bytes, and a signature over the payload. They answer different questions, so the artifact reports them separately instead of collapsing them into one reassuring word.
- Evidence data hash
- SHA-256 over the canonical 2.0 payload - the incident's facts as data.
- Document checksum
- SHA-256 over the rendered file. A PDF cannot contain the hash of itself, so this lives on the record.
- Signature
- Ed25519 over the payload bytes, when the deployment has a signing key. Public key at /v1/verify/keys.
{
"found": true,
"incident_id": "9f1c8b0e-…",
"time_window": {
"start": "2026-09-18T09:53:00+00:00",
"end": "2026-09-18T10:07:00+00:00"
},
"data_hash": "3f9a…c41e",
"report_checksum": "0c72…a1b9",
"methodology_version": "v1.0",
"authenticity": {
"signed": true,
"algorithm": "Ed25519",
"signature_covers": "canonical payload bytes",
"public_keys": "/v1/verify/keys"
}
}Footer fields
- Evidence Data Hash (SHA-256)
- Document Checksum
- Public Verification ID
- Evidence Schema Version
Probes are issued from 1 observation point today, on a 300-second interval by default. Every page that reports a measurement says which window it covers and how many observations stand behind it.
04What it establishes
- Show what this dependency did during a window, from outside your network and the vendor’s.
- Show the observations the conclusion rests on, individually, with timestamps.
- Show that the document has not been altered since it was issued.
05What it does not
- Establish what happened inside the vendor’s infrastructure. The probe records the path it took, not the vendor’s internals.
- Establish that every one of the vendor’s customers was affected. One observation point measures one path.
- Prove a contract was breached. It reports measurements; your agreement with the vendor decides what they mean.
The only way to judge a record is to see one.
Start observing a dependency you already run, and the first confirmed incident produces a real one - with your endpoint on it and nobody else’s.