Turn 3 integration: recover the check's limits, not just the correction
Outcome
The provenance case supplies concrete information a later worker needs to apply, revise or decline a method. It does not show that an ordinary concise correction fails to provide that information. Keep current procedures and ordinary evidence pointers as the baseline. Extra explanation remains an investment to justify, not a necessary stage between experience and reusable methodology.
Explorer B provides the main case: a review can finish successfully while preserving a false claim about which model executed it. Explorer A provides a distinct qualification: creation-time reuse does not imply continuing authority. The critic correctly prevents their agreement from becoming a performance claim. Neither report observes a later worker recovering and using the proposed correction.
This answers turn 2's next question at the level of case-specific requirements, not demonstrated reuse. The purpose remains useful knowledge work and learning to automate methodologies. The operator removed pauses between the five turns, not the unresolved priority choices retained in turn 1. No purpose change, doctrine deviation or new recording system is adopted.
The inspected surprise: successful completion can preserve false provenance
The local incident account reports 41 review jobs containing 268 pairs whose child traces recorded Sol while their finalized results claimed Luna. Those are attributed historical counts, not a recount here. The original traces were not recovered. This integration does not adopt the account's external API claims.
The important mechanism is directly inspectable in the current finalization code (src/commonplace/review/finalization.py). It derives a partition from supplied execution metadata and rejects a disagreement with the job's partition when that metadata yields a partition. The function receives those values from its caller; it does not independently establish which model executed. Thus an internally consistent supplied identity can pass that check without authenticating execution. This is a property of the inspected code, not a newly run experiment.
The current batch procedure supplies the operational distinction. The partition must be legitimately known before selection. Concrete provenance is separate and optional; exact values may come from harness launch configuration or execution telemetry, while worker self-report remains separately labelled. Known mismatch is not permission to force finalization. Missing concrete metadata is not automatically a reason to reject an otherwise permitted review.
The surprise is therefore more precise than “dispatch can fail”: the completion check can certify the consistency of the representation that contains the error. Completing the transaction and advancing freshness do not establish the historical truth of dispatch. The incident report supplies the claimed occurrence; the code inspection supplies the present check boundary. They do not independently authenticate each other.
What the later worker must recover
The consumer here is a review coordinator deciding what it may select, finalize or claim. The following is a case analysis, not a new schema or replacement procedure.
| Later decision | Required distinction | Consequence in this case |
|---|---|---|
| Apply | The commission requires ordinary partition-scoped review, or stronger proof of a realized concrete model | Do not silently exchange one acceptance condition for the other |
| Apply | Requested identity, harness-supplied values, worker self-report and unknown values have different evidential roles | Do not turn intent or reviewer prose into concrete provenance |
| Apply | The partition was legitimately known at selection; concrete metadata may still be absent | Permitted uncertainty can allow completion without a concrete-model claim |
| Decline or return partial | Known metadata contradicts the job, or required assurance cannot be obtained | Do not force a mismatch; report the unsupported claim when stronger assurance is required |
| Revise | Available dispatch, inheritance behavior, mappings or required assurance changed | Reacquire those facts rather than repeat the old dispatch recipe |
| Repair | Historical results may remain misattributed after future dispatch is fixed | Repair needs affected evidence and authority; future prevention is not retrospective correction |
A later worker need not load every historical job to apply these branches. It does need access to the current procedure and the actual harness information. Auditing the old results is a different task and cannot be completed from the incident summary alone.
The policy tension remains explicit
The incident account warns that an intended model string is not execution evidence. Current policy permits exact harness-supplied launch configuration as provenance; it does not universally require an independent execution trace. These statements must not be compressed into either “launch configuration proves execution” or “all reviews require authenticated traces.”
For ordinary review, follow the current authorized policy and preserve the source and uncertainty of metadata. For a commission requiring independently established realized identity, permitted provenance recording alone may be insufficient. If the required evidence is absent, more explanatory text cannot supply it. Return partial on that claim rather than strengthening ordinary policy or weakening the special commission.
What does concision fail to provide?
A strong concise correction could say:
Establish the available partition before selecting jobs. Keep intended identity, exact harness-supplied metadata and worker self-report distinct. Finalization checks supplied consistency, not actual dispatch. Do not force a known mismatch or invent missing provenance. Ordinary policy permits some unknown concrete metadata; a task requiring stronger execution assurance must return that limit if evidence is unavailable. Consult the current batch procedure rather than treating this reminder as its replacement.
This candidate contains the operative distinctions. Its effectiveness has not been tested. With the procedure and incident pointer available, it is a competent rival to additional case packaging, not a deliberately forgetful baseline.
“Use the right model” omits the evidence source, check boundary and uncertainty branches. Showing that those words are inadequate would establish an omission, not a general defect of concise corrections. A longer explanation might help a worker recognize a changed condition or challenge a mistaken inference. That remains a conjecture about behavior.
The critic adds an essential limit: this baseline already contains methodological investment in procedures and ordinary records. Failure to demonstrate value from extra packaging does not show that developing those existing materials was wasteful. Likewise, correct later behavior would not alone identify the correction as its cause: changed harness support, existing competence or coordinator repair could account for it.
A's separate finding: preserve the actual consumer and supersession boundary
A follows the retirement of a closed category scheme through its later correction. The original worked-case success remains an attributed ADR report; the integration has not inspected its sibling-repository notes. The critic's rival interpretation—specialized descriptive work rather than a fundamentally different category—remains unresolved here. The taxonomy was not empirically disproved by this turn.
The inspected ADR 069 supports a narrower, useful distinction. Shared profiles implied an ongoing relationship, while the retained operation was optional copying at collection creation. The resulting local COLLECTION.md supplies authority after copying. Its historical rationale can be useful when revising the design, but an ordinary writer primarily needs the current local obligations.
This is not a replication of the provenance mechanism. It identifies a different mistake: retaining the original lesson without its supersession can preserve an authority relationship that the later decision removed. An optional starting template can be declined by a collection designer; a binding local rule cannot simply be declined by a writer. The reported weak discovery path to the experimental template is a plausible retrieval concern, not an observed retrieval failure.
Together the cases distinguish availability of relevant text, finding it and applying it correctly. Neither availability nor detailed explanation demonstrates the other two.
Decisions changed, proposals and purpose boundaries
The actual changes are dispositions of this investigation, not implemented policy:
- Use B's case to make the executable-methodology question concrete: identify the claim a check supports and the branches under uncertainty, rather than equate execution with workflow completion.
- Keep unknown and contradictory metadata distinct. Reject universal trace authentication as an inference from this case.
- Retain A's supersession boundary: creation-time reuse and continuing authority are different consumers, not two names for one success.
- Evaluate extra explanatory packaging against current instructions, a competent concise correction and ordinary records. Do not compare it only against an empty memory or a deficient slogan.
Unadopted proposals include a behavioral comparison, additional evidence packaging and provenance tooling. No general store, adapter, extraction pipeline or change to review acceptance is authorized. Restricting all research to immediate service returns, abandoning methodology automation, or making authenticated execution the universal product standard would change the purpose; none is adopted. Improving local refusal and revision decisions remains within purpose without resolving the allocation priority between service and exploratory learning.
Proposed next question: choose the marginal investment
For the provenance case, what is the smallest informative comparison of extra case explanation against current procedure, a concise correction and ordinary records—and what outcome would justify further investment rather than simply correcting the baseline?
This moves toward turn 4's investment question without building a controller. The first useful observation could be whether a fresh worker already handles missing versus contradictory metadata correctly under the baseline. A comparison must preserve ordinary-record access in both conditions and avoid rewarding blanket refusal. If the target is actual execution truth rather than decision behavior, independent execution evidence is needed.
The competing returns are useful work and information about whether explanation changes behavior. Producing, finding, reading and reviewing the extra material all belong in its cost, not just worker execution. If no authorized probe or adequate evidence is available, retain a bounded comparison proposal rather than call textual inspection an experiment. This is a question for coordinator scheduling, not a launched turn, response gate or requirement that all exploratory research first demonstrate a baseline failure.
Limits, costs and completion
No later-worker reuse trial, review execution or comparative experiment occurred. This turn did not demonstrate improved methodology application, better retrieval, lower operator burden, broad transfer, profitable retention or superiority of the four-role procedure to simpler conversation. It did not establish an incremental benefit of economic guidance beyond naming the marginal investment. Original-case reassessment remains blocked by uninspected worked material and execution traces; comparative efficacy remains unknown. Those limits block stronger claims, not completion of this bounded integration.
Parked: historical repair status; whether explanations prevent stale-rule reuse; creation-only reuse tests; distinguishing missing material from failed retrieval or misapplication; and separating coordinator rescue from worker benefit. These are questions, not an implementation queue.
Navigation included scoped title/description searches across theory, reference, instructions, sources, historical and current system reviews, analyses and workshops. Full reads followed the selected local case and procedure links. Existing notes remain arguments or attributed records, not independent confirmations. No external empirical claim or analogy is needed for the conclusion; proposed behavioral benefits remain conjectures.
Coordination retains the investment rationale, isolation and operator intervention. The three returned result files contain completion statements and session/audit paths, but no measured token, monetary, model-duration or operator-review costs. These costs remain unknown; timestamped filenames are not elapsed-time measurements. Activity counts are two explorer outputs, one critic output and this integration. Preceding workers report no nested jobs, ingests or experiments; this integrator likewise used none. Counts are not cost estimates.
Only this assigned file was written. No delegation, external source mutations, code/library edits, commits, extraction or deletion occurred. Scheduling, aggregate accounting and recovery remain with the coordinator. Optional broader graph discovery could use cp-skill-connect under separate authorization; it is not needed for this integration.
Verification: commonplace-validate passed for this artifact: one text file, zero failures and zero warnings. A manual reread checked claim status, policy tensions and authority boundaries. Mechanical validation cannot authenticate the incident or establish comparative benefit.