Historical replay measured September 25, 2026

Measurements and replay notes

The detailed record behind the progress overview: calculations, saved versions, limits, and instructions for repeating the run.

Differences under the original scoring

• Eight more passing checks: 18 − 10 = 8, or 38.1 percentage points on this 21-case set. Failures fall from 11 to 3: (11 − 3) / 11 = 72.7% fewer failing cases. This is a description of these selected checks.
• The advantage remains without timeout allowances: excluding both unbounded-search cases gives 16/19 for the rewrite and 10/19 for the earlier engine. The difference is six passing checks, or 31.6 percentage points.
• The first rewrite already has most of that result: 17/21 overall and 16/19 without the two unbounded-search cases. Its only later pass gain in this corpus is an open generator changing from a RecursionError to an external query timeout. The case permits that timeout; this does not demonstrate that the engine reports an incomplete search itself.
• The sampled earlier engine improves too: 8/21 on May 8, 9/21 on June 14, and 10/21 on August 30. The two observed gains are left recursion and combining facts and rules. The sample endpoints are about 114 calendar days apart. These checks do not cover all the other work done during that period.

What the dates establish

The seed prompt commit (private) is dated September 13 at 19:51:55 −04:00. The first kernel commit is September 14 at 05:56:51: an interval of 10 hours, 4 minutes, 56 seconds. The September 15 commit, which retrospectively scores 18/21, is 34 hours, 37 minutes, 54 seconds after the seed. Those are calendar intervals between recorded commits, not a time sheet or a measurement from zero prior work.

The first source commit includes the kernel, tests, and documentation together. The comparison corpus was added on September 22. I cannot assume the work began at the seed commit, treat the later-selected checks as a prospective target, or divide these intervals into a fair rewrite-versus-refactoring productivity ratio.

All eleven snapshots

Every row uses the same 21 cases and the same frozen harness. Dates below are commit dates, not dates when these tests were originally run. Timeout passes are included in the pass total. “Unassessable” means the harness could not judge the result.

Why this is not a speed multiplier

• No comparable effort denominator. I found no project-wide record of active human hours, agent hours, or API cost for both approaches. Commit counts, lines changed, and calendar gaps do not supply one.
• The earlier repository begins with existing work. Its first source import (private) already includes an engine and a long test history. February 2026 is not its development start. The rewrite also benefits from the earlier requirements, models, tests, and mistakes.
• Scope and tests differ. The migration map (private) records omitted and deferred responsibilities. Raw unit-test growth also mixes new engine checks with harness tests. The three remaining comparison failures concern explanations, including one capability the earlier engine passes.
• The cases were selected with knowledge of both implementations. They are not an independent or random sample. Sparse snapshots of the earlier engine can miss intermediate gains or regressions. A flat count on this set does not mean no other progress was made.

To measure pace going forward, I would freeze an independent set of behavior targets before each work period, record active human and agent time and cost, and count targets met while retaining earlier passes. A fair strategy comparison would also need matched scope and comparable starting knowledge. This replay is a useful baseline for that work.

Tools and version records

The replay script uses the worker, oracle, and scoring functions unchanged from harness revision 9be7804c933cc8a3c51af3d8a5e4f54b012c8be6. It runs each engine snapshot in its own fresh local clone, each case in a separate process, with the original timeouts. SWI-Prolog expectations are obtained once and reused for all snapshots. Both published endpoints reproduce every verdict in the September 24 comparison, including reasons, answer rows, and completeness flags.

The revisions were selected before replaying: all five commits that changed the rewrite's src tree, plus its published endpoint; the earlier engine's first compatible import layout on May 8, then the last commit of each month through August. Earlier package layouts cannot be tested by this unchanged adapter and are outside this sample. Different sampling densities are explicit; this is not a search for the earliest passing old revision.

The run used Python 3.12.10 and SWI-Prolog 10.0.2 on Windows. The raw replay includes every worker result, pass/fail/unassessable decision, timeout marker, commit timestamp, source-tree identity, script hash, and expected answer. The case corpus and outcome definitions explain what a pass means.

The graph is generated from that replay with this Matplotlib script. Standalone versions: SVG and PNG.

python evidence\replay-development-progress.py --old-repo C:\path\BadScienceFiction-CyclopsStorm --new-repo C:\path\AkiyaBlocks-CyclopsStorm --work-dir C:\temp\cyclops-replay --output C:\temp\cyclops-replay.json --swipl "C:\Program Files\swipl\bin\swipl.exe"

python scripts\compare_implementations.py --output artifacts\comparison\reproduction