evidence-verification

name	evidence-verification
description	Mandatory evidence rules for any report or briefing that makes factual claims. Prevents the known corruption modes: AGE-column misreads, stale Day-N counters, Flux-status-as-outage claims, dropped resolutions, and uncited numbers.

Evidence Verification — Report Integrity Rules

These rules are mandatory whenever you produce a report, briefing, or summary that makes factual claims. They exist because each one maps to a real corruption incident in a published briefing. Violating them produces a fabricated briefing.

Rule 1 — AGE is not a duration

The kubectl/flux AGE column is the resource's age — how long the object has existed — not how long a problem has existed. A 507-day-old kustomization that started failing yesterday has been broken for one day, not 507.

• NEVER report AGE as a stall, failure, or outage duration.
• Get problem durations from status.conditions[].lastTransitionTime, events, or your own prior reports' first-seen dates.

Rule 2 — Re-verify before you increment

Before carrying any tracked item forward ("⏳ Day N", "Still pending", "Day 139+"), re-run the check that originally found it, today.

• Still reproduces → carry it forward and increment.
• No longer reproduces → report it as RESOLVED: — do not silently drop it, and never increment a counter from memory or from yesterday's report alone.

Rule 3 — Control-plane status is not workload status

A Flux Kustomization/HelmRelease that is False/not-ready tells you GitOps reconciliation has a problem. It says nothing about whether the workload is up.

• Check the actual pods (kubectl get pods ...) before claiming a service is degraded, down, or "failing silently".
• If pods are Running and Ready, say so explicitly and scope the finding to reconciliation only.

Rule 4 — Resolutions are first-class signal

When something you previously reported is fixed, closed, or no longer present, that is one of the most valuable things you can report.

• Lead your summary with a RESOLVED: <item> bullet for each such item.
• RESOLVED: bullets never count against any bullet-count cap and must never be dropped for space — compression that loses a resolution creates a phantom issue that haunts every future report.

Rule 5 — No number without a source

Every number you print — day counts, durations, versions, counts of anything — must be traceable to a command you ran today, a file you read today, or an explicitly cited prior report.

• If you cannot point at the source, do not print the number.
• Estimates must be labeled as estimates.

Rule 6 — Chronic is still critical

"Focus on changes" never demotes an ongoing incident. A node that has been down for four days belongs in the headline every day until it is fixed, above new-but-cosmetic findings. If your report has a "stale items" section, an active outage never goes there.

Rule 7 — Your instructions can be stale

Task prompts and skills are written at a point in time. If evidence you gather today (vault files, cluster state, calendars) contradicts a fact stated in your instructions, trust the evidence, say you did, and flag the stale instruction in your report so it gets fixed.