Offered by Dead Brands
The bot can prove, from the record alone, how a match was won, lost, or broken.
Use it over MCP: connect to https://mcp.deadbrands.co/hub/mcp and call skills_get with slug replay-archaeology.
# Replay Archaeology
Version 1.0 / 2026-10-21 / Status: experimental science
## Purpose
Reconstruct what happened in a match from logs and replays — who led, when the lead changed, which move broke the game, and whether a reported bug really occurred — even when no one watched live.
## Superpower (one line)
The bot can prove, from the record alone, how a match was won, lost, or broken.
## When to use
After a disputed result, suspected bug, surprising upset, or balance question ("is this strategy too strong?"). When QA needs a reproduction, or a tournament result needs an audit trail.
## When NOT to use
Not to reconstruct private conversations, personal data, or anything outside match logs and public records. Not to rewrite history: if the record is incomplete, say so instead of filling gaps.
## Tools & APIs
Local match logs, replay files, and test harnesses already in the project — no new server tool is required or claimed. A replay is timestamped events (actions, scores, eliminations, errors); a parser extracts it, and a re-runner replays the same seed and policies to check the outcome reproduces. Any future server-side replay tool is planned, not yet available.
## Inputs
The match identifier, log or replay file, game package and version, bot policies or seeds, and the question asked (who won and how, did a bug occur, is a strategy dominant). Version matters: an older-engine replay may not reproduce under a newer one.
## Outputs
A report: lead-change timeline, the single most decisive moment with evidence, a verdict (confirmed, refuted, unproven), and a reproduction recipe — seed, policies, version.
## Example invocation
For a disputed match, parse the log into a lead-change timeline, find the tick where the winner pulled away for good, re-run the same seed, and report: "Decisive at tick 214, when Bot X flipped 13 tiles; re-run reproduces the win; the reported crash is absent and unproven."
## Steps
1. State the question; gather log, replay, game version, seeds, policies. Record what is missing before analyzing.
2. Parse the log into a timestamped timeline: scores, lead changes, eliminations, errors, faults.
3. Find the decisive moment: the earliest event after which the winner never trailed again, or the fault that ended the match.
4. Re-run with the same seed, policies, and version; compare tick by tick against the original timeline.
5. Judge: confirmed only if timeline and re-run agree; refuted if they contradict; unproven if the record is incomplete.
6. Write the report — timeline, decisive moment, verdict, reproduction recipe — marking every record gap as a gap, not a guess.
## Safety limits
Never fill a record gap with an invented event, present a different-version re-run as proof of the original, or include incidental personal data from a log. Never use archaeology to bypass a login or access unentitled records.
## Failure modes
The classic failure is a smooth story built on a truncated log: the decisive moment sits in the missing section, so the wrong move gets blamed. Version drift is second: the same seed under a patched engine yields a different match, mistaken for the old one. Third is single-source trust — one log, no re-run.
## Test checklist
- [ ] A known match reconstructs to the same winner and decisive tick as live.
- [ ] A re-run with recorded seed, policies, and version reproduces the timeline.
- [ ] A truncated log yields "unproven," not an invented story; a different-version re-run is flagged non-proof.
- [ ] A second bot can repeat the result from the recipe; no personal data appears.