Self-hosted validators on Post Fiat-style networks experience operational incidents — process crashes, sync stalls, version drift, manifest desyncs, peer isolation. Most operators either publish nothing, publish prose that is hard to parse, or publish details that expose private infrastructure. This is a copyable template that defines what a validator incident disclosure should contain, how its severity and status should be labeled, and what to omit for operator privacy. It is link four in a chain that began with the Validator Failure Response Manifest, continued with the Validator Failure Classification Matrix, and added the Validator Operator Profile Template. Manifest defines what to do when a node breaks. Matrix defines how to identify what broke. Profile defines who runs the validator. This template defines how the operator tells anyone else.

Why This Exists

Operators publish incident notes inconsistently or not at all. There is no shared convention for what fields belong in a disclosure, what severity labels mean, what should be revealed, or what should be omitted. The result is that delegators reading two different operator pages cannot meaningfully compare incident posture, and automated evaluators parsing those pages cannot extract structured signal.

The fix is one template with a fixed field set, embedded label definitions, and explicit include/omit guidance per field. Operators copy it, fill it, publish it. Humans and machines parse the same shape every time.

Severity Labels

Three levels. Severity describes operational impact, not subjective stress.

• warning — Node is operational but degraded; may have self-recovered or is recovering without operator action.
• degraded — Node is partially functional; consensus participation or rewards impaired. Operator action required or in progress.
• critical — Node is non-functional or actively damaging itself; immediate operator intervention required.

These match the Validator Failure Classification Matrix so an incident's severity in a disclosure aligns with its severity in the operator's classification table.

Status Labels

Four values. Status describes where the operator is in the incident timeline.

• active — Incident is ongoing. Node is currently affected.
• investigating — Operator has acknowledged the incident and is working on root cause; node may still be impacted.
• resolved — Node has returned to baseline; incident is closed.
• monitoring — Node has returned to baseline but the operator is observing for recurrence before fully closing the incident.

A disclosure can be updated as status progresses. The publication path defined in the operator's profile (per the Operator Profile spec) should support edits or appended notes.

The Template

## Incident: [SHORT_TITLE]

**Class ID:** [F-XXX-NN — refer to the Validator Failure Classification Matrix]
**Severity:** [warning | degraded | critical]
**Status:** [active | investigating | resolved | monitoring]
**Start time (UTC):** [ISO 8601 timestamp]
**End time (UTC):** [ISO 8601 timestamp, or "ongoing" if active]
**Duration:** [HH:MM, or "ongoing"]

**Affected service area:**
[What part of the validator's operation was impaired. Examples: consensus participation, peer connectivity, agreement score, sync progression, manifest validity. State the user-visible or network-visible effect, not the internal subsystem name.]

**Impact:**
[What this meant in network terms. Examples: "Agreement score dropped to 0% during the affected window," "Validator excluded from consensus for the duration," "No proposals attributed to this node ID for ~3 hours." Describe outward effect on network participation. Do not describe internal node specifics, peer IDs of others, or routing details.]

**Resolution path:**
[The action sequence that returned the node to baseline. Examples: "Generated a new manifest token, swapped into validator config, restarted node, manual rejoin." Describe what was done at the operator level. Do not include specific commands with credentials, file paths under home directories, or any path that maps to internal infrastructure.]

**Evidence signal:**
[The observable fact that proves the incident occurred and proves it has resolved. Examples: "Agreement 1H reading from the public dashboard at [link]; Domain Verified status returned to green at [time]." Reference public observables only.]

**Current status:**
[One sentence summarizing where the node stands at the time of publication. Update this field on each disclosure revision.]

**Operator note (optional):**
[Any context the operator wants delegators to know — preventive measures taken, expected risk of recurrence, related upstream issues. Keep brief.]

Field-By-Field Guidance

Class ID. Use the existing Failure Classification Matrix taxonomy when the incident matches a defined class. If the incident does not match any defined class, use F-UNKNOWN. Do not invent ad-hoc class IDs in a disclosure — the taxonomy is shared infrastructure.

Severity. Pick the highest severity level the incident reached during its window. An incident that was briefly critical and quickly recovered to warning still discloses as critical, with status reflecting current state. Severity is a high-water mark, not a current reading.

Status. Update on every revision. A disclosure published while the incident is active starts at active or investigating; the same page is edited to resolved or monitoring once the situation stabilizes. Operators should not delete the original disclosure when status changes — append updates and revise the status field.

Start time / End time / Duration. Use UTC. ISO 8601 format. Duration is calculated from start to end and rounded to the nearest minute. For ongoing incidents, set end time to "ongoing" and duration to "ongoing." Do not omit the start time even for incidents recovered before disclosure — the timestamp is what makes the disclosure verifiable against public dashboard history.

Affected service area. Describe the failure in terms a delegator can understand. "Consensus participation," "peer connectivity," "agreement score," "sync progression," and "manifest validity" are user-facing concepts. Avoid internal subsystem names that would only mean something to someone with access to the node's source tree.

Impact. Describe the outward effect. The reader should be able to answer: did this validator earn rewards during the window, was it counted in consensus, was it visible to its peers. Public dashboards already expose these answers; the disclosure names them. Omit peer IDs other than the operator's own, IP addresses, and internal session or token identifiers.

Resolution path. Describe the operator-level action sequence in enough detail that another operator could follow the same general pattern if they hit the same class of failure. Reference the Manifest by class ID for procedures rather than repeating them inline. Omit shell commands with credentials, paths under operator home directories, config file contents, and deployment automation specifics.

Evidence signal. Point to public observables — dashboards, explorer transactions, signed on-chain manifests, the operator's own profile page. The evidence must be independently verifiable without operator cooperation. Omit private logs, screenshots of internal admin panels, or anything not reachable from the public network.

Current status. One sentence. Updated on every revision. The reader should be able to skim only this field and know whether the validator is currently safe to delegate to.

Operator note. Optional context. Useful for explaining preventive measures, related upstream conditions, or risk of recurrence. Keep brief — anything longer than three sentences belongs in a separate writeup linked from the disclosure, not in the disclosure itself.

Privacy Boundary, Restated

Every field in this template has explicit omit guidance because a disclosure that exposes private infrastructure is worse than no disclosure. The general rule across all fields: an attacker reading a complete disclosure should learn nothing they could not have learned from the public network. Validator public keys, agreement scores, domain status, and proposal attribution are all already public. Internal IPs, port numbers, file paths, peer IDs of other operators, credentials, command-line flags with secrets, and screenshots of admin dashboards are not. Filling every field correctly never crosses that line.

Closing

This template makes validator incident disclosure legible. An operator using it produces a note that another operator can read in seconds, that a delegator can compare against any other operator's notes, and that an automated evaluator can parse for severity, status, duration, and class. Combined with the Operator Profile Template (which commits the operator to publishing disclosures) and the Classification Matrix (which supplies the class IDs), it closes a gap that has been open since self-hosted validators became common: operators have a shared format. They no longer have to invent one each time something goes wrong.