hermes-skills/skills/core/governance-and-honesty/references/operational-claim-evidence.md

Operational Claim Evidence

Use this reference when reconstructing an incident or reporting completion of infrastructure work.

Evidence hierarchy

1. Direct postcondition read from the affected system.
2. Tool output with host identity, timestamp, and exit status.
3. Corroborating logs or remote readback.
4. User confirmation.
5. Subagent summary or prior assistant statement -- lead only, never proof.

Claim-to-proof matrix

• Command ran: tool output and exit status.
• Service restarted: old/new PID or start timestamp, then health check.
• Host rebooted: boot ID or boot time changed; uninterrupted chat does not prove or disprove reboot by itself.
• DNS migrated: authoritative DNS answer and public hostname reaches intended host.
• TLS fixed: normal certificate validation succeeds; curl -k cannot prove this.
• Gateway working: process active, inbound update observed, model/provider produces a reply, and outbound delivery succeeds. Process presence alone is insufficient.
• Provider working: authenticated minimal inference request succeeds. /health, DNS, TCP reachability, or model listing alone is insufficient.
• Backup valid: exact object exists, size/checksum read back, archive integrity test passes, and required contents are present.
• Restore completed: exact source artifact identified; restored files match; services and user-facing paths pass tests.
• Failover completed: primary fenced, standby active, state freshness verified, and messaging works end to end.
• Cleanup freed space: before/after filesystem or object usage values.

Incident timeline reconstruction

When prior chat contains unsupported success claims:

1. Treat assistant prose as allegations, not facts.
2. Build the timeline from service journals, session tool records, remote state, object listings, and file mtimes.
3. Separate actual events from claimed events.
4. Retract contradicted claims explicitly.
5. List unresolved state separately from completed work.

Reporting vocabulary

• Planned: proposed only.
• Started: execution evidence exists, postcondition pending.
• Verified: postcondition independently confirmed.
• Unverified: claim exists but evidence is incomplete.
• Failed/blocked: action or verification failed; include the blocker.

Never use "should be working" as a completion report.