Decision-guided software synthesis

Decision-guided software synthesis is the bounded path behind bmo synthesize. You declare the candidate states, the checks, and the penalty for each observed check failure. The engine ranks those measurements and, when one state wins, retains an ordinary Patch Proposal. It does not search an open space of programs, and it does not treat its own ranking as proof that the parent task is done.

Maturity: Advanced. The ranking, proposal retention, apply fence, and pending parent obligation are implemented and covered by the bounded fixtures linked below. The homepage diagrams and the SIGNIN-204 recording are not this path. This page does not claim general software synthesis.

Command syntax, resource ceilings, and exit strings stay on Change synthesis. This page is the lifecycle: what each transition decides, who owns it, what is stored, and how it fails. Exact fixture names and commands are in the maintainer evidence mapping.

What the phrase means

The decision is a fixed comparison of observations, not a model choosing among ideas it invented.

Unrestricted generation	This path
The model may propose code that was not in the request.	programs and candidates are in the specification. The engine also measures an unchanged state. DecodeSpec rejects unknown fields.
A plausible diff can be applied because the model said it worked.	A selected state is stored as ready_for_human. Accept and apply are later transitions.
One passing test can close the task.	A required check can make a candidate eligible. Parent validation obligations stay pending until their own owner runs them.

The comparison unknowns named below stay on the report whether or not a proposal is kept. The figure is that boundary, not a trace of a run.

flowchart TD
  spec["Declared candidates, checks, penalties"] --> measure["Measure each, including unchanged"]
  measure --> rank["Rank by observed coordinates"]
  rank --> report["Unknowns stay on the report"]
  report --> win{"One changed state wins?"}
  win -->|yes| proposal["Retain ready_for_human"]
  win -->|no| none["No proposal"]

failure_loss is an integer you put on a check. qualifyCheck adds that integer to the scenario loss only when the check outcome is failed. A passed check adds nothing. Any other outcome, including timeout, start failure, cancellation, and a checker that mutates the captured inputs, marks the candidate ineligible and records unknown. Unknown evidence is not given a penalty and is not relabeled as an ordinary failure. A failed optional check adds failure_loss to that scenario and does not by itself make the candidate ineligible. A failed required check adds the penalty and does.

flowchart TD
  outcome["Observed check outcome"] --> passed["passed"]
  outcome --> failed["failed"]
  outcome --> other["Anything else"]
  passed --> nopenalty["Add no penalty"]
  failed --> req{"Check required?"}
  req -->|no| opt["Penalty only"]
  req -->|yes| hard["Penalty and ineligible"]
  other --> unk["Ineligible, unknown, no penalty"]

The only admitted policy is minimax_then_total_then_change. Select orders eligible candidates by four coordinates, lowest first:

1. Worst-case scenario loss.
2. Total loss across the declared scenarios.
3. Number of changed paths.
4. Sum of before-and-after bytes in those changed files.

The first coordinate that differs is the only one that decides. Later coordinates are not a tie-break unless every earlier coordinate matches.

candidateComparison records the first coordinate that differs as decisive_metric. The comparison object lists these unknowns on every report: behavior outside the declared checks, mutation authority, applied state, independent parent verification, and goal convergence. Select does not fill those in.

How a state enters consideration

Run captures source_paths from the workspace, then realizes each candidate, including unchanged, by applying that candidate’s programs to the captured image. Realization that returns an error marks that candidate ineligible and keeps going. A realized image is diffed against the capture. The retained candidate directory is a copy of the evaluated image. The live workspace is not written. Synthesize only reads. A later accept and apply is the write, not a return from this run.

flowchart TD
  live["Live workspace"] -->|read only| capture["Source-path capture"]
  capture --> scratch["Copies and checker scratch"]
  scratch --> report["Report and proposal"]
  report --> closed["No write back from synthesize"]

By default, every candidate is then measured against every scenario. The first scenario uses the captured files. A later scenario may replace declared non-mutation inputs. Each check runs in a fresh directory as the host user. The scratch directory is not an operating-system sandbox. The checker executable is fingerprinted before and after the run. If that fingerprint changes, the outcome becomes unknown. If the same check’s executable or environment digest changes across candidates, the run stops with checker support changed across candidate comparisons.

A specification is invalid without one hard condition: a required check, a versioned constraint source, or a blocking or required-coverage validator. A scenario with no applicable hard condition is ineligible (no_applicable_hard_condition).

There is a second entry, bmo protected-admission run-synthesis, for an already admitted signed root. That command is not bmo synthesize run. Repair evidence it retains still leaves parent completion to the obligation owner. Corridor qualification is another owner again. Its projection sets ParentCompletion to not_evaluated even when the verifier result passes. Returning verified_evidence from that projection hands the evidence back to the parent obligation owner. It does not accept the objective.

Equivalent candidates, empty sets, and unresolved decisions

Select walks eligible candidates in report order. Equal measurements stay unresolved only when the state digests differ. The figure is one decision. The exits are exclusive. The table stores the reasons.

flowchart TD
  select["Eligible candidates"] --> any{"Any eligible?"}
  any -->|no| empty["Residual, no proposal"]
  any -->|yes| best{"One strictly best?"}
  best -->|yes| kind{"Winner unchanged?"}
  best -->|no| digest{"Digests differ?"}
  digest -->|yes| tie["Distinct tie, no proposal"]
  digest -->|no| earlier["Keep the earlier candidate"]
  earlier --> kind
  kind -->|yes| nochange["no_change, no proposal"]
  kind -->|no| ready["candidate_ready, proposal"]

Situation	Disposition	Proposal
No eligible candidate	bounded_residual. Reason: no candidate has complete hard-condition and risk evidence.	None. run exits 0.
Two or more eligible candidates share all four coordinates and have different StateDigest values	bounded_residual. Reason: equal measured risk and cost for distinct resultant states. SelectedID is empty. The comparison marks those alternatives unresolved.	None.
Eligible candidates share coordinates and the same StateDigest	The first of them in report order stays selected. This is not the distinct-state tie above.	Follows that candidate.
unchanged wins	no_change.	None.
One other eligible state is strictly best	candidate_ready. Reason: hard conditions satisfied; minimum observed worst-case loss, total loss, paths, then changed content.	Created.

Select writes SelectedID, Disposition, Reason, DominatedBy, and Comparison. It does not rewrite a candidate’s files, diff, state digest, or check records. ValidateCandidateComparison replays Select and rejects a comparison that does not match the retained observations.

An ineligible candidate is observed_hard_condition_failure only when a retained failed check, failed blocking validator, or violated constraint matches that candidate’s residual. Otherwise the comparison reason is qualification_incomplete. A failed residual that is not backed by a failed observation stays incomplete.

From a chosen state to ready_for_human

App.SynthesizeChanges creates a proposal only when the disposition is candidate_ready and the selected candidate has at least one changed path. The proposal is inserted with:

Field	Value
Status	ready_for_human
Source	workflow_step
Validation status	candidate_ready
Summary	Parent verification remains required. Warning and advisory validator counts are included when validators ran.
Artifacts	The specification, the report, and the unified diff.
Event	change_synthesis_selected, with spec, source, and candidate digests.

ready_for_human means an operator can review the proposal. The legal next statuses from that state are accepted, send_back, rejected, superseded, and conflicted. applied is not one of them. The live workspace still has the pre-selection bytes. The bounded proposal-lifecycle fixture demonstrates refusal before acceptance followed by successful application after acceptance.

Accept records approval. It does not write files.

What apply is allowed to write

ApplyPatchProposal calls requireSynthesisQualification before and again immediately before the write. For a synthesis proposal that check requires:

• The path set is exactly the selected candidate’s changed paths. A subset returns synthesis partial-path application requires new joint qualification.
• Combining this proposal with another returns synthesis composition requires new joint qualification.
• Each prepared write’s path, content digest, and permission bits match StateFiles on the selected candidate. A mismatch returns prepared synthesis effect differs from evaluated state.

The qualification-fence fixture covers a changed source file, a changed retained candidate, a changed spec or diff artifact, a partial path set, a combined proposal, and altered prepared bytes. In each refusal the live strategy.go still contains return false, and a proposal that had been accepted stays accepted.

Apply reads the retained candidate directory. It does not re-run Select and it does not substitute a different candidate. After a successful write the proposal status is applied. Validation status stays candidate_ready.

What aftercare does

When the session’s change-contract owner is the durable mutation store, writeProposalWorkspaceFiles reserves the effect, writes the files, then commitProposalContractEffects ingests the observation. For each changed path it adds a pending review obligation whose explanation is: an accepted proposal changed this path; applying a proposal does not verify its effects. The obligation kind is a review flag and the source type is proposal_effects.

That ingest is the aftercare for this apply path. It records that the reserved observation was stored. It does not grade the diff, does not satisfy a parent validation, and does not accept a coordinator objective.

If aftercare returns an error after the workspace write, reconciliation keeps the proposal conflicted for an operator decision. It does not pretend the contract record matches the files.

Two neighboring records are different mechanisms:

• Auto-checkpoint, when enabled, is a git commit. It defaults to off. It does not retire the reservation and it does not verify the parent goal.
• An effect-observation ticket owner uses commitProposalEffectTickets instead of the review-flag ingest above. An owner that is neither the durable mutation store nor that protocol writes the files without this ingest. Mutation aftercare states that scope.

How independent verification accepts or refuses completion

Selection’s checks are candidate measurements. They are not the parent decision.

On an ordinary session, parent validation obligations that were already on the change contract stay pending through synthesis and apply. The parent-validation fixture separates a candidate readiness check from a parent budget check against source.go and source_test.go. The exact commands are retained in the maintainer evidence mapping. After accept and apply:

• The proposal is applied.
• Ready returns true in the live file.
• The parent obligation is still pending. Candidate qualification did not discharge it.
• RunValidations then runs that command. In the parent_failed case the obligation becomes failed, the completion summary stays unresolved, CompletionVerifiesSuccess is false, and RetireLiveContract refuses completion.
• A second RunValidations does not add another failure and does not change the stored contract. The failed obligation is not given a fresh attempt.
• The proposal row is unchanged. The applied bytes are unchanged. Reopening the contract store does not roll the file back.

In the parent_passed case the same parent command satisfies the obligation only because the candidate also changed UnitCost from 2 to 1, which is what the parent budget check measures. The proposal still stays applied with the same validation status. Satisfying one obligation does not by itself prove every other obligation on the contract.

Operators inspect open rows with /contract-obligations and run pending validation commands with /contract-rerun or contract_rerun. Until that run, verification is pending.

On a provisioned controller, the separate command is bmo protected-admission decide-coordinator-outcome. Any residual leaves accepted false and returns non-zero. That command is not called by bmo synthesize. The receipt rules are on Parent outcome.

A corridor verifier result that fails or is unknown leaves disposition bounded_residual and the next action “keep the applied repair actionable.” A passing projection returns verified_evidence and still reports ParentCompletion: not_evaluated.

What becomes stale

A qualification names one measured image. Bytes that differ from that image are a different question, not a reuse of the old answer. A match means the retained report is still about that image. It is not permission to apply. Each refusal is in the table, including a parent row that has already failed.

flowchart TD
  measured["Measured bytes and path set"] --> same{"Same bytes and path set?"}
  same -->|yes| hold["Report still names that image"]
  same -->|no| fresh["New run or compose"]

Change after measurement	Consequence
Live source bytes differ from the capture before Run finishes	source_changed: captured files differ from evaluated state. The run errors. Select is cleared to bounded_residual with an empty SelectedID.
Checker executable or environment digest differs across candidates for the same scenario and check	The run errors. No selection.
Retained candidate bytes, spec artifact, or diff artifact change before apply	Apply refuses. Live files stay as they were.
Prepared write path, digest, or mode differs from StateFiles	Apply refuses.
A later scenario replaces a non-mutation input	That replacement is a counterfactual for the check. The retained candidate directory keeps the captured input; the bounded fixture checks its input.json against the capture.
Further edits after apply	The proposal does not move back from applied, and its validation status stays candidate_ready. Parent evidence whose observed state digest does not match the expected digest marks the check outcome invalidated. A new joint question needs a new specification and a new run or compose.
A parent validation already failed	Another rerun does not invent a new attempt. Repair is a new candidate evaluation, not a silent retry of the failed row.

Worked example: observed penalty chooses the larger edit

This example uses a bounded joint-repair fixture and its App proposal fixture. Both demonstrate the outcomes below. Their exact source assertions are linked from the maintainer evidence mapping. This page does not embed a receipt file. Digests are computed at run time and are not copied here.

Initial task and failing condition

Captured files:

• state.json: {"a":false,"b":false,"c":true}
• input.json: {"edge":false}
• strategy.go: func Robust() bool { return false }

The joint constraint allows only the Boolean tuples (0,0,0), (0,1,1), (1,0,1), and (1,1,0), read from state.json. The initial tuple (0,0,1) is not allowed, so unchanged is ineligible. The optional check edge-behavior has failure_loss 10. On the edge scenario, where input.json is replaced with {"edge":true} for the check only, the command requires return true in strategy.go. The nominal scenario does not trip that command.

Candidates and observations

The fixture records six checker calls: three candidates times two scenarios.

Candidate	Eligible	Worst-case loss	Changed paths	Why
unchanged	false	—	none	Joint tuple is not allowed. The fixture records it as ineligible.
small	true	10	1 (state.json, a becomes true)	Tuple (1,0,1) is allowed. The edge check fails because Robust still returns false, so the declared penalty 10 is recorded.
robust	true	0	2 (state.json with b true, and strategy.go returning true)	Tuple (0,1,1) is allowed. The edge check passes, so the penalty is not added.

Selection

SelectedID is robust. Disposition is candidate_ready. robust wins because its worst-case loss is 0 and small’s is 10. decisiveMetric names that first difference observed_worst_case_loss. The extra changed path is not consulted. The report still lists mutation authority, applied state, and independent parent verification as unknown.

The live workspace still contains return false after selection.

Proposal and authorization

The App fixture records a non-empty proposal id, status ready_for_human, validation status candidate_ready, and a summary that says parent verification remains required. Apply before accept returns an error.

Apply

After accept, apply succeeds and the proposal status is applied. The qualification fence is the same one that refuses the altered-byte cases described above.

Aftercare and the independent result

The library fixture then compiles the selected candidate directory with go test strategy.go as an oracle outside the specification. That command passing is not a BMO parent outcome.

The App fixture writes a second strategy_test.go whose test fails, runs go test itself, and asserts the failure text. It then reloads the proposal and asserts validation status is still candidate_ready. That second go test is the test process, not /contract-rerun. It shows that an outside failure does not rewrite the proposal. It is not the parent-obligation owner.

The parent-validation fixture exercises the separate obligation owner. See the unsuccessful path.

Provenance

Retain, from the proposal event and artifacts: spec digest, source digest, candidate state digest, spec artifact, report artifact, and diff artifact. contract_ref on this fixture is operator:joint-repair/v1 in the App test and operator:test-contract/v1 in the library test. That string is a label. It is not an admission grant.

Unsuccessful path: the candidate check passes and the parent check does not

The parent-validation fixture in mode parent_failed demonstrates the unsuccessful path below.

Initial source.go has Ready() bool { return false } and UnitCost() int { return 2 }. The specification’s required check is a readiness check. The parent obligation, merged into the durable contract before synthesis, runs a separate budget check: if Ready() is true and UnitCost() is greater than 1, that check fails.

The only program sets Ready to return true. It does not change UnitCost. Synthesis reports candidate_ready, and the candidate check outcome is passed. The live file still says return false until apply.

Accept and apply land Ready returning true. The parent obligation is still pending. Running validations then fails validation:parent-budget. The completion summary is unresolved. A second validation run does not change the contract. The proposal stays applied. Cold reopen of the contract store preserves the failed obligation and does not restore the old file.

What this refuses: treating the candidate readiness check passing, or apply succeeding, as completion of the budget obligation.

What this does not show: a provisioned decide-coordinator-outcome receipt, or that every parent obligation in every session uses this budget rule.

A separate distinct-state tie fixture builds the report in memory and leaves no winner. It is a selector witness, not a workspace run. Two eligible states share one changed path and 10 changed bytes, with different state digests. Select leaves SelectedID empty and disposition bounded_residual.

The shared Go-repair fixture is a workspace run on testdata/shape_repair. Both repairs pass the declared checks. literal is selected because its changed-content byte count is lower. The fixture then runs go test ./generated against the selected candidate directory and asserts failure: generated classification is still "square" while runtime classification is "rectangle". That command is not in the specification. The comparison unknowns include independent_parent_verification. Declared success did not measure the generated file.

Who owns each state

Proposal status and parent completion are different records. Apply does not create the parent obligation. A refused apply leaves the proposal accepted.

stateDiagram-v2
  [*] --> Spec
  Spec --> Refused: invalid spec or ceiling
  Spec --> Measured: Run
  Measured --> Residual: no eligible or distinct tie
  Measured --> NoChange: unchanged wins
  Measured --> Ready: candidate_ready
  Ready --> Accepted: operator accept
  Accepted --> Accepted: apply refused
  Accepted --> Applying: qualification matches
  Applying --> Applied: write succeeds

A parent obligation that was already on the contract stays pending through selection, accept, and apply. One command satisfies that row. Other rows can remain. A failure is not a new attempt. Aftercare is in the table below. It is not the next proposal status.

stateDiagram-v2
  [*] --> Pending: already on the contract
  Pending --> Failed: its command fails
  Pending --> Satisfied: its command passes

State	Authoritative owner	Stored	Failure behavior
Admitted specification	changesynthesis.ValidateSpec, then synthesis resource preflight	spec.json under the run directory once preparation starts	Validation or ceiling error. No checkers when the spec itself is invalid. No proposal.
Candidate image and check outcomes	changesynthesis.Run	Candidate records in report.json, plus the retained candidate directory	Ineligible residual, or a run error that clears SelectedID.
Ranking	changesynthesis.Select	SelectedID, disposition, reason, dominance, comparison	bounded_residual or no_change. No proposal.
Reviewable proposal	App.SynthesizeChanges and the patch-proposal store	Status ready_for_human, three artifacts, change_synthesis_selected	Created only for candidate_ready with a non-empty change set.
Approval	Patch-proposal accept	Status accepted	Does not write the workspace.
Workspace write	ApplyPatchProposal and requireSynthesisQualification	Status applied, live bytes	Mismatch refuses the write. Accepted status remains.
Aftercare	commitProposalContractEffects when the durable mutation store owns the session	Pending proposal_effects review flags	Returned failure can leave the proposal conflicted after the bytes changed.
Parent validation	Change-contract validation runner, reached by /contract-rerun or contract_rerun	Obligation status on the session contract	failed stays failed across another rerun. Files and proposal status stay.
Coordinator objective	decide-coordinator-outcome	Parent-outcome receipt	Any residual: accepted false, non-zero status. Not invoked by bmo synthesize.

Demonstrated and only designed

Behavior	Status	Witness
Optional failure penalty selects the zero-loss repair over the one-path repair	Demonstrated	Joint-repair workspace fixture.
Distinct equal coordinates stay unresolved	Demonstrated on a constructed report	In-memory distinct-state tie fixture.
Unknown evidence is not labeled as an observed hard failure	Demonstrated	Incomplete-qualification comparison fixture.
ready_for_human, apply refused before accept, apply after accept	Demonstrated	App proposal-lifecycle fixture.
Changed bytes or a partial path set cannot reuse the qualification	Demonstrated	Altered-effect refusal fixture.
no_change retains a report and no proposal	Demonstrated	Unchanged-state App fixture.
Parent obligation stays pending through apply, then fails or is satisfied only by its own command	Demonstrated	Parent-validation fixture, passing and failing modes.
Declared Go checks can pass while an undeclared generated-package check fails	Demonstrated	Shared Go-repair workspace fixture.
Homepage storyboard, authority map, and SIGNIN-204	Designed illustration and a separate historical fixture	Proof gallery. Not a bmo synthesize receipt.
Corridor projection closes the parent objective	Not what the code does	ParentCompletion stays not_evaluated. finishCorridorRepair returns evidence to the obligation owner.
One scenario establishes general software synthesis	Not claimed	Each witness is the specification and checks it names.

Claims that do not follow

Each record below stops at its own owner. None of them is an input to parent completion. A process arrow would draw those records as steps toward that completion, which is the claim this section refuses.

A successful edit means the parent task is complete

Apply can set the proposal to applied while a parent validation obligation is still pending, and later failed, with completion unresolved in the parent-validation fixture. Limit: the obligation has to exist on the contract before apply. Synthesis does not invent that parent command from the candidate check.

An accepted proposal is already applied

ready_for_human can transition to accepted. applied is reached from applying, which is reached from accepted. The App test requires an error when apply is called on ready_for_human. Limit: other proposal producers use the same status machine. This is not specific to synthesis.

A verdict grade proves the requested outcome

A verdict grade is evidence strength for a judge declared on a run. The grade page states that a grade does not mean the task is right, and that a later edit resets the observation. Synthesis selection does not write a verdict grade. Limit: a run can carry both a grade and a synthesis proposal. Neither record satisfies the other.

Auto-checkpoint provides independent verification

Auto-checkpoint is an optional git commit after a mutation. It defaults to off. The aftercare explanation stored for a proposal effect says that applying the proposal does not verify its effects. Limit: enabling auto-checkpoint still does not run the parent budget check or decide-coordinator-outcome.

Selection silently rewrites the compared candidate

Select updates ranking fields on the report. Candidate file records stay as realized. Apply refuses when prepared bytes differ from those records. Limit: a later compose or a new run is allowed to evaluate a different specification. That is a new measurement, not an in-place rewrite.

A single scenario proves general software synthesis

The penalty example measures one joint constraint and one optional edge check. The shape example’s declared checks miss a generated-file disagreement that a separate command observes. SIGNIN-204 is a sign-in fixture archive, not this selector. Limit: adding scenarios changes the coordinates. Omitted cases can reverse the ranking. The report says so by keeping behavior outside the declared checks unknown.

Independent verification can reuse stale or self-asserted success

A candidate’s own passed check is not the parent obligation. Apply will not take bytes that differ from the measured StateFiles. A parent validation that already failed is not reattempted by another rerun. Corridor evidence marks checks invalidated when the state digest does not conform. The comparison lists independent parent verification as unknown at selection time. Limit: a parent command that really does pass will satisfy that obligation. That pass is a new observation of the post-apply tree, not a copy of the candidate check’s outcome.

Discrepancies recorded while checking the code

The maintainer topic docs/topics/quality/change-synthesis.md is a hypothesis, not the public contract. Where this page and that topic could be read differently, the code wins:

• The topic describes ordinary proposals, corridor verification, and signed native repair in one narrative. bmo synthesize run stops at the proposal. It does not dispatch the corridor verifier.
• The topic says independent verification of the live workspace remains a separate step. The implemented separate step for the ordinary session is the pre-existing parent validation obligation, run by the change-contract validation owner. The corridor projection’s ParentCompletion field stays not_evaluated.
• The topic says distinct states with equal coordinates remain unresolved. Select applies that rule when StateDigest differs. Equal coordinates with the same state digest keep the earlier candidate. This page did not find a separate integration test for the same-digest branch.
• The App proposal-lifecycle fixture runs go test in the test process after apply. That is not /contract-rerun. The separate parent-validation fixture exercises the obligation owner.

Source-to-claim trace

Claim	Source	Checked	Limit
Penalty is added only for outcome failed	qualifyCheck in internal/changesynthesis/qualification_result.go	Read	Required failures also clear eligibility.
Ranking coordinates and distinct-state tie	Select in internal/changesynthesis/run.go	Distinct-state tie fixture passed	Same-digest tie is the code branch, not its own integration test.
Zero worst-case loss beats a penalty of 10	Joint-repair workspace fixture	Passed	One fixture. Not a population result.
Proposal stays ready_for_human until accept	internal/app/change_synthesis.go, status transitions in internal/patchproposal/validation.go	App apply-before-accept test passed	—
Apply refuses altered bytes	requireSynthesisQualification	Altered-effect refusal fixture passed	—
Aftercare review flag says apply does not verify	commitProposalContractEffects	Read	Durable mutation store only.
Parent check can fail after a passing candidate check	Parent-validation fixture	Passed, both modes	The parent command was installed by the fixture before synthesis.
Declared checks can miss a generated disagreement	Shared Go-repair workspace fixture	Passed	The extra go test ./generated is outside the spec.
Corridor pass does not set parent completion	ProjectCorridorParentVerification, finishCorridorRepair	Read	Provisioned parent acceptance is decide-coordinator-outcome.
SIGNIN-204 is not this selector	Proof gallery archive links	Read	Historical fixture. Raw logs are absent from that archive.

Residual gaps

• There is no checked-in public receipt that freezes the SHA-256 values from a bmo synthesize run of the joint fixture. Reproduce the example with the fixtures linked in the maintainer evidence mapping.
• The same-state-digest branch of Select is not covered by its own integration test.
• Ordinary sessions do not gain a coordinator parent receipt. An unprovisioned checkout cannot record decide-coordinator-outcome acceptance.
• Checker execution is host-user execution in a scratch directory. It does not attest the whole machine.
• Publishing this page does not by itself update the deployed website. The deployed site changes when this source is what that site was built from.

Related

• Change synthesis — commands, ceilings, exit strings
• Mutation aftercare
• Independent verification
• Parent outcome
• Patch proposals
• Verdict grades
• Proof gallery