Same core, additional interface: a bounded synthetic comparison
Under these conditions, the interface preserved output and rejection behavior while adding 4.157104 ms to the median process time. This historical experiment does not establish a speed, algorithm, human-effort or business advantage, and does not benchmark the current Action Contract implementation.
Scope and method
Completed on 2026-10-13. A separate reviewer reproduced a frozen comparison of an existing full-validation comparison/export command against a structured-request interface calling that same core. Inputs were caller-declared results; neither side executed external systems or graded business truth. The reference retained full validation, matching rules, result semantics and no-overwrite behavior.
Environment: macOS 27.2 on arm64, Python 3.14.8. Both sides ran as local subprocesses with the same fixed locale, time zone and hash seed. There was one warm-up pair, followed by ten measured pairs, plus six paired rejection controls: 34 invocations. Each nominal export contained 20 synthetic cases: 12 normal, four failure and four exception cases. Process wall time includes interpreter startup; it is not full adoption effort.
Criteria frozen before execution
The fixture, golden output, specification, core and interface were fixed before the reproduction and checked unchanged afterward. Nominal output had to match the frozen golden bytes exactly. Each rejection had to exit with an error without creating a new output; existing output bytes had to remain unchanged. The interface receipt had to match supplied input, request and output bytes and their digests. These are contract checks, not scoring of real-world outcomes.
Observed results
| Measure | Existing command | Structured interface |
|---|---|---|
| Measured process samples | 10 | 10 |
| Median process time | 43.217688 ms | 47.374792 ms |
| Reported p95 process time | 46.359291 ms | 52.705375 ms |
| Nominal output, including warm-up | 11/11 exact golden | 11/11 exact golden |
| Rejection controls | 6/6 rejected | 6/6 rejected |
| Existing-output preservation control | Preserved | Preserved |
Combined frozen run: 34/34 invocations satisfied their checks; all 22 nominal outputs matched the golden bytes. All 11 interface receipts matched the checked byte counts and digests. No timeout was observed.
Held-out controls and an oracle correction
A further six invocations used a separate three-case nominal fixture and two paired rejection controls. The held-out plan was recorded before execution. It covered reversed system order, version-label changes, Unicode and multiline inert text, an extra result ID and whitespace-only evidence. The initial oracle accepted 4/6 invocations. After execution, the reviewer corrected its mistaken label for an Unknown-to-Ready caller-declared transition to match the documented contract; the same saved outputs then satisfied 6/6 checks. No additional invocation was run for this correction. This is a post-execution oracle correction, not six newly preregistered successes. Total product invocations were 40.
Limitations
The implementation on both sides shared the same comparison core, so parity provides no independent evidence of grading accuracy or algorithmic novelty. Ten local timing samples do not support general performance claims. Human preparation, expert configuration, review, rework, adoption effort and full cost were unknown. No actual participant or external system was tested. Public discovery and real workflow acceptance were not measured.
Only this completed, reproduced historical round is summarized here. No comparative result for the current Action Contract or external evaluation platforms is asserted. The publicly distributed package does not include the historical benchmark implementation, fixture or harness; the method and numbers here are a bounded summary, not a standalone reproduction kit.