Reading After a Write Is Not Necessarily Reading It Back: A Scorer-Boundary Experiment
A write followed by a read of a different object received full confirmation credit in the tested helper. That is a result from an internal isolated experiment, not a confirmed native-system incident. The question is precise: does a post-write confirmation score establish temporal order, or establish the effect of that particular write?
What the ten scenarios actually tested
The same-day analysis extracted unchanged helper functions from MedHarnessBench at revision 1b64350432708adfe26db60910db863ac782381d and executed ten constructed semantic-event scenarios. This internal experiment bypassed raw-trace adapters, models and the complete scoring pipeline. It did not rerun the paper's benchmark.
The _postcondition_confirmation helper first determines whether the task requires a state change. For each successful commit, it searches later successful acquire or verify events. A progress marker or a non-null state-change field can qualify. At this boundary, the helper does not compare subject, resource or commit identities. Pinned scorer source
Every row below reports an internal experimental observation about this helper, not an overall evaluation score:
| Constructed input | Helper result | What it establishes |
|---|---|---|
| Write followed by a same-resource read | 1; one confirmation | Ordinary positive control receives credit |
| No read, failed read, or read before write | 0 in each case | Ordering and success conditions matter |
| Required write but no commit | 0 | Empty work is not credited |
| No state-changing obligation | Not applicable | Inapplicability differs from zero |
| Write to A followed by successful read of B | 1; one confirmation | This helper does not enforce same-object linkage |
| Successful verify with state-change field false | 1 | Presence differs from truth |
| Two commits followed by one unrelated read | 1; two confirmations | One read can be reused across commits |
| Successful read without either qualifying marker | 0 | Success alone is insufficient |
The ten scenarios comprise three confirmation paths that require narrower interpretation and seven ordinary or negative controls. Full inputs, outputs and extraction bindings remain in the research evidence package. They are not patient records.
Full credit does not supply an identity relation
Our interpretation is that ordering can support “a read occurred later” without supporting “this read confirmed that write.” The two-commit control also raises a question about reusing confirmation material. It does not establish that a read should always be consumed once; a per-effect claim needs an explicit linkage and reuse contract.
The false state-change control should not be described as the system treating a failed operation as successful. The event was constructed as a successful verification; the predicate tests whether a field is non-null. The supported distinction is between field presence and the truth of a state-change assertion.
This matters when interpreting process metrics. The paper's first version reports a health-administration configuration in which Pass@3 falls from 0.267 to 0.105 while the subtask score rises from 0.543 to 0.633. Those are author-reported results, not recomputed measurements. They illustrate why outcomes and process scores require separate reading; this helper experiment does not explain those aggregate changes.
The adapter may already own the guarantee
The strongest alternative is that the adapter establishes identity consistency before constructing semantic events, or other dimensions penalize an unrelated read. If that invariant exists, avoiding duplicate checks in the helper could be reasonable. The raw-trace-to-adapter-to-aggregate chain was not executed here, so this alternative remains open.
The repository design also describes pre-action, post-result and pre-final checks, with evidence, obligation and commit ledgers. That is public design material, not an executed end-to-end guarantee. Pinned design document
The engineering implication is therefore a responsibility question. A process-score report should identify who guarantees object linkage, which events are applicable, how unavailable data are treated and whether confirmation material can be reused. A per-effect verification claim needs auditable write/read association. This experiment does not establish which layer must change.
Evidence and sources
Public source code and design documents are primary materials; the project's own repository is not independent validation. The ten constructed scenarios are internal experimental evidence produced by this research process. The responsibility argument is our interpretation. No independent third-party reproduction supports the helper-level finding here.
The pinned repository revision has not been fully linked to the paper's original experimental revision. Publication, accessible code and successful execution do not establish aggregate reliability, clinical safety or general validity. The main sources are the pinned scorer, design document and paper linked above. The local experiment date is 2026-10-23.
The missing end-to-end evidence
Evidence that could change this judgment would show a valid native trace producing the unrelated-read event, then follow it through other dimensions and aggregation. Until then, no affected-run prevalence, model-ranking change or patient mix-up incident is inferred. The established boundary is confined to the helper: it recognizes qualifying later events without itself establishing per-object effect linkage.