A copyable evidence format for infrastructure-style technical work — operator, debugging, deployment, systems. Use it when a submission needs to prove what happened in production with enough detail that a reviewer can verify the claim without trusting the contributor.
Intended Use
Producing a single, compact block of technical evidence for one infrastructure event — one symptom, one diagnosis, one fix — that a reviewer can read in under two minutes and verify without asking follow-up questions.
Template (copy from here)
Copyable block for one infra event.
## Runtime Excerpt
[paste the smallest contiguous block of log output, command output, or runtime
state that contains the actual evidence. Trim surrounding noise. Keep
timestamps and identifying fields that prove the event was real. Redact
sensitive fields per the rules below.]
## Observed Symptom
[one sentence describing what the operator noticed first, in the language they
saw it — error message, broken behavior, missing data. No interpretation yet.]
## Validation Check
[one or two sentences describing the specific test or query that confirmed the
symptom was the actual issue and not a different problem with similar
appearance. Name the command, endpoint, or signal used.]
## Redaction Note
[one sentence stating what was removed from the runtime excerpt and the
category it belonged to — e.g. IPs, hostnames, private paths, account
identifiers, internal network topology. State the category, not the value.]
## Causal Explanation
[one or two sentences naming the actual cause and how it produced the symptom.
Distinguish the cause from the diagnosis path that led to it.]
Evidence Rules
- One event per artifact. Multiple events get multiple artifacts. Compound evidence reads as ambiguous evidence.
- Smallest excerpt that proves it. A 6-line log block is stronger than 40 lines of context. If the proof needs context, name the context in prose, don't paste it.
- Real timestamps and identifying fields stay in. A redacted log with no anchoring detail can't be verified by anyone.
- Symptom and cause are different sentences. If they collapse into one, the validation check is missing.
- The validation check names a thing. Not "I confirmed it." A specific endpoint, command, query, or signal that another operator could re-run.
Redaction Rules
- State the category, not the value. "IPs redacted" and "internal hostnames redacted" are usable signals; the values themselves are attack surface.
- Keep enough to anchor reality. Public IPs, public domains, public on-chain identifiers stay. Private network topology, internal paths, account IDs, and authentication material go.
- Redact at field level, not section level. Removing an entire log line because one token in it was sensitive removes the evidence. Replace the sensitive token with
[REDACTED-{category}]and keep the rest. - Privacy threshold is operator-specific. Decide where the cut is before publishing. If a reviewer can't tell what category was removed, the redaction is too aggressive.
Example 1 — Docker container exposes port despite host firewall
## Runtime Excerpt
$ ufw status verbose
Status: active
Default: deny (incoming), allow (outgoing)
[port 5005 not present in allow rules]
$ nmap -p 5005 [REDACTED-host]
PORT STATE SERVICE
5005/tcp open rfe
$ iptables -L DOCKER-USER -n
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
## Observed Symptom
A container's published port was reachable from the public internet despite
ufw being active and the port not appearing in the allow list.
## Validation Check
Ran nmap against the public host from an external network and confirmed the
port was open. Inspected the DOCKER-USER iptables chain and confirmed it had
no rules restricting traffic to published ports.
## Redaction Note
Public hostname and container service identity redacted; port number,
DOCKER-USER chain state, and ufw default policy retained as the anchoring
evidence.
## Causal Explanation
Docker writes its own iptables rules at a layer below ufw, so ufw's
deny-by-default posture does not apply to ports published by Docker. The fix
required explicit drop rules in the DOCKER-USER chain plus a systemd unit to
reapply them on reboot, since iptables rules do not survive a restart.
Example 2 — Domain verifier fails on apparent CORS error
## Runtime Excerpt
[verifier-tool] GET https://[redacted-domain]/.well-known/pft-ledger.toml
[verifier-tool] ERROR: Failed to fetch (CORS or network error)
$ curl -v https://[redacted-domain]/.well-known/pft-ledger.toml
* Could not resolve host: [redacted-domain]
* Closing connection
## Observed Symptom
Public manifest verifier reported "Failed to fetch" on the deployed TOML.
Error message implied CORS misconfiguration on the domain.
## Validation Check
Ran curl against the same URL from the local browser environment. Resolution
failed at DNS, not at HTTP. Repeated the curl from a second network path
(mobile hotspot); resolution and fetch succeeded.
## Redaction Note
Domain name redacted; resolution failure and successful second-path fetch
retained as the evidence that the deployed artifact was correct.
## Causal Explanation
Local VPN tunnel blocked DNS resolution to the deployed domain. The CORS
error string was misleading — the actual failure was at the network layer,
upstream of any browser security policy. The deployment was never wrong.
Minimum Completeness Check
An artifact in this format is verifiable when all five fields are present, the runtime excerpt is real, the validation check is reproducible, and the redaction note's stated categories match what was actually removed. Missing any of the five reduces the artifact to a claim.
