The model changed the requirements. The work changed with them.

Why this is a research problem. Wedding seating is an academic optimization problem as well as an everyday one. Karie A. Nicholas and Vikram Khipple Mulligan published seating benchmarks for classical and quantum solvers in 2026. Their work maps placement constraints and preferences to cost-function networks, a formulation also used in protein design. Radiolaria’s independent 12-guest instance is not a reproduction of their benchmark.

Our reference examines the activity around the solver: changing requirements, actual computation, original-condition checks, consumption and separately approved saving. In its hardware episode, invalid Rigetti candidates were rejected rather than repaired into classical answers. The selected measured plans reached saved outputs with their identities intact. This is a traceable intent-to-result chain, not a claim of quantum advantage or physical quantum error correction.

An organizer wants twelve guests seated under explicit conditions, then asks to change the arrangement. In the semantic story, Gemini 2.5 Flash returns amendments that reach the actual computation: two guests move to the newly requested table. A later request to check the arrangement runs validation without solving again.

In the separate quantum story, two real Rigetti Cepheus-1-108Q tasks through Amazon Braket return 1,000 measurements each. Ordinary checking finds usable seating candidates, and later work consumes selected results. Saving those results still needs its own decision.

The useful connection is from a participant's contribution to work that actually uses it. The semantic and hardware episodes have separate identities; the hardware record establishes neither quantum advantage nor physical error correction.

Read with your assistant: focus XML · Plain text

Twelve guests, explicit conditions, several kinds of participant

The fixture has twelve guests, three tables of four and six pairs that must stay together. Guests 01 and 05 must sit apart; guest 11 belongs at table 3. Familiarity creates a softer choice: keep familiar circles together, or encourage mixing. These are synthetic inputs whose exact structure can be inspected.

The organizer supplies purpose and permitted changes. Gemini 2.5 Flash performs two semantic roles: WEDDING_INTENT_ORCHESTRATOR proposes the kind of task and its needs; WEDDING_REQUIREMENT_ARCHITECT returns an objective and typed amendments. Ordinary code validates those fields, materializes supported Work, compiles the problem and checks results. The local Organizer Root reviews its own acceptance and effects. In W4, the quantum processor supplies numerical candidates; it does not interpret the organizer's wishes or approve a save.

The publication records 19 serialized model calls. Fourteen original captures contribute to seven final semantic episodes. A and SR1 use CAPTURED_PROVIDER_RESPONSE_REEXECUTION; B, VERIFY, AMBIGUOUS, SR2 and SR3 retain LIVE_ROLE_ORIGIN. These historical classes explain why a native lane can have zero new model calls while consuming a genuine earlier model response. The initial failed receipt for call 15 remains part of the record; later consumption after a bounded consumer repair did not change its raw bytes.

Words changed the work that ran

Request A selects KEEP_FAMILIAR_V01; request B selects MIX_CIRCLES_V01. The selected field reaches the compiler, and the consumed seating changes. Their separate request identities matter: this is not one invented continuous Host session.

The SR sequence goes further. Before: SR1 places guests 07 and 08 at table 2 under problem revision 2. Change: the organizer requests table 1 instead, keeping the other restrictions and the mixing preference. After: SR2 supplies two REPLACE amendments, advances the accepted problem to revision 3, and executes review → compile → solve → validate → consume. The eight protected base conditions remain in force.

This exact selected amendment is from w3/story/SR2_captures.json, row 1, /raw_response decoded as JSON, then /amendments/0. The enclosing row identifies WEDDING_REQUIREMENT_ARCHITECT, gemini-2.5-flash, LIVE_ROLE_ORIGIN and request:w3:v02:sr2. All primary paths in this page resolve under the Wedding evidence at publication ref 800f38c3407b3f4ec93dc943c977ffeecb614881.

{
  "operation": "REPLACE",
  "predicate": "ALLOWED_TABLES",
  "subjects": ["guest_07"],
  "tables": ["table_1"],
  "source_ref": "request:w3:v02:sr2",
  "replaces": ["added:cefff2237df9864e94438b6db02b436e"]
}

The second amendment names guest 08 and its own prior condition. The model's returned text is only the beginning of the chain. In SR2.json, /results/1/invocation/inputs/0/value is a JSON string whose decoded /problem/hard_conditions actually includes these table-1 conditions. The compiler's /results/1/consumed_fields/0 records disposition: USED, output_field: /material and decision_effect: bind_input. Later solve, validation and consumption have their own producer and consumer references.

The arrangement changes from [0,0,1,1,2,2,1,1,0,0,2,2] to [0,0,1,1,2,2,0,0,1,1,2,2]; 0, 1 and 2 identify tables 1, 2 and 3. Guests 07/08 move to table 1 and 09/10 to table 2. The owner acknowledgement is explicitly SCRIPTED_CONTROLLED_OWNER_INPUT, with browser_click_claimed: false; the separate revision review records ACCEPT.

The old plan failed the new requirements

An attractive score cannot rescue a plan that violates current conditions. The supplementary old-under-new record preserves SR1 as valid under revision 2 and invalid under revision 3, while leaving the original result unchanged. Its two placement failures explain the difference. The field named current_root_refusal contains current_owner_context: this is a domain owner-context check, not evidence of a newly executed Root rejection. AMBIGUOUS provides another useful boundary: it asks for the missing objective instead of choosing one for the organizer.

Validate without solving again

SR3 asks only to check the current arrangement. The model returns VALIDATE_EXISTING, a null newly selected objective and VALIDATE_ORIGINAL. The accepted material inherits the objective from the actual prior result.

Selected exact fields from SR3.json, at the same publication ref:

/program/ordered_work_ids = ["validate", "consume"]
/output/assignment = [0,0,1,1,2,2,0,0,1,1,2,2]
/results/1/consumed_fields/0/disposition = "USED"
/results/1/consumed_fields/0/producer_actor_id = "validate"

There is no solve in that program. The narrower request produces narrower performed work and retains the SR2 arrangement. That is a concrete difference between interpreting “recalculate” and “check.”

Real quantum hardware: Rigetti Cepheus-1-108Q through Amazon Braket

W4 is a separate revision-1 problem, using captured A/B meaning and current W4 owner intake. Two hardware tasks ran on one Rigetti Cepheus-1-108Q through Amazon Braket, each requesting and returning 1,000 measurements. The encoding uses 10 logical qubits; the 108Q device name is not the number used by this task.

The provider integration, adapter and encoding were developer changes, as part of the engineering supplied for this finite profile. They do not demonstrate autonomous provider discovery. No D-Wave execution is part of this recorded demonstration. The published chapter separates that engineering role from the model's semantic contributions and the QPU's measurements.

The source files are w4/provider/KEEP_FAMILIAR_V01_results.json and MIX_CIRCLES_V01_results.json; /taskMetadata identifies the device, status and shots. /measuredQubits is [0,1,2,3,4,5,6,7,8,9]. Selected exact measurements are:

KEEP /measurements/63 = [1,0,1,0,0,0,0,0,0,1]
MIX  /measurements/31 = [0,0,1,0,0,1,0,0,1,0]

The corresponding *_sample_validation.json records apply ORIGINAL_12_GUEST_VALIDATOR_V01, rather than treating provider completion as a valid seating plan. KEEP has 967 invalid samples; MIX has 958. Both selected samples have local_repair: false and objective gap 0 against the finite reference. This is original-condition checking and postselection. It does not establish physical quantum error correction, noise suppression or quantum advantage.

A measured candidate became a saved result

The selected KEEP row decodes to [1,1,1,1,0,0,0,0,2,2,2,2]. Its native consume record orders qpu_validate → qpu_consume. At /results/1/consumed_fields/0, the latter consumes the former's /material with disposition USED. The output retains shot 63, basis 517 and origin LIVE_QPU_RAW_DECODED_POSTSELECTED, plus the raw-result SHA-256 746f6671f68dff12c31f9637c9ddefc4fa1f1692868d569316275abb144bad0e.

Saving then needs its own current review. In KEEP save_receipts.json, /0/root_result/decision is ACCEPT and /0/status is SAVED_READBACK_VERIFIED. The JSON claim is 520 bytes with SHA-256 3756378338308c7f97d438519fabb3a64ae98b3c861b96e10aa46976666689c5. The HTML save has a separate receipt. These are task-owned reports, not invitations or physical seating actions. Even an identical seating array in W3 and W4 would not make their problem, task or permission identities equal.

Inspect the selected evidence

Typed amendments reached actual Work

SR2 replaces the two guest placement conditions, compiles their reviewed material and consumes a changed arrangement.

Record: W3 SR2 request:w3:v02:sr2. Class: recorded execution. Scope: W3 SR2 request:w3:v02:sr2; historical published evidence read as data, no new core execution or authority.

View source — W3 SR2 request:w3:v02:sr2

Check the arrangement without another search

SR3 performs validate and consume, retaining the SR2 arrangement.

Record: W3 SR3 request:w3:v02:sr3. Class: recorded execution. Scope: W3 SR3 request:w3:v02:sr3; historical published evidence read as data, no new core execution or authority.

View source — W3 SR3 request:w3:v02:sr3

A historical plan can fail current conditions

The old SR1 arrangement stays valid historically but fails the current requirement revision; this is a domain check, not a newly executed Root refusal.

Record: W3 old_under_new. Class: recorded domain validation. Scope: W3 old_under_new; historical published evidence read as data, no new core execution or authority.

View source — W3 old_under_new

KEEP: a raw hardware sample was checked and used

The historical Rigetti task returned 1000 shots. Original-condition checking selected an unchanged raw sample for native consumption.

Record: W4 KEEP revision1. Class: recorded execution. Scope: W4 separate revision-1 hardware task; real provider measurement, historical record reading; no physical error-correction or quantum-advantage claim.

View source — W4 KEEP revision1

MIX: a raw hardware sample was checked and used

The historical Rigetti task returned 1000 shots. Original-condition checking selected an unchanged raw sample for native consumption.

Record: W4 MIX revision1. Class: recorded execution. Scope: W4 separate revision-1 hardware task; real provider measurement, historical record reading; no physical error-correction or quantum-advantage claim.

View source — W4 MIX revision1

Saving needed a separate current decision

KEEP consumption was followed by a distinct Root SAVE review and readback-verified JSON output.

Record: W4 KEEP SAVE. Class: recorded effect receipt. Scope: W4 KEEP SAVE; historical published evidence read as data, no new core execution or authority.

View source — W4 KEEP SAVE

The original Wedding Reader is an 8,732,562-byte publication containing architecture, full call records, code and hardware evidence; its size and identity are recorded in the release index. The site focus above is a new, smaller editorial selection. Presentation PDF · Technical appendix PDF · Full published chapter. Original links are pinned to the publication snapshot; this reading creates no new execution result.

This is the same kernel

The changed field actually reaches downstream Work, just as the permitted shift in Football changes a computed offer. A request to validate avoids unnecessary search, while Workspace preserves useful photograph work through a different kind of change. The model, classical solver and QPU have distinct roles within one task; the save decision remains local and current.

Follow those relationships through Growth, one kernel and seven views of the same activity. General provider discovery and universal workflow synthesis are beyond this finite evidence.

Case identity

W3 semantic episodes and W4 revision-1 hardware tasks are distinct historical executions.

Task: Seat twelve synthetic guests at three tables while preserving mandatory conditions, responding to revised wishes and saving only an approved result.

Roles: Organizer defining wishes and permitted changes; Gemini 2.5 Flash intent orchestrator and requirement architect; Organizer Root and native Host/Work; Ordinary compiler and exact solver; Rigetti Cepheus-1-108Q through Amazon Braket in W4; Original-condition checker and downstream consumer.

Observed result: W3 changed actual requirements and plans; SR3 validated without a new solve. W4 consumed original measured samples 63 and 31, with no local repair, before separate save reviews.

Limits:

• Synthetic twelve-guest problem
• Historical evidence reading with no new model or QPU call
• W3 scripted owner acknowledgement rather than personal browser clicks
• W4 hardware use does not establish quantum advantage or physical error correction
• Separate current save permission

Read with your assistant

The existing offline edition preserves the recorded episodes, selected fields, attributed excerpts and original source routes. This webpage’s updated introduction is also available in its Markdown version. Original publications are linked in the case.

Download XML · 31,597 bytes · SHA-256: ca6f629489d2e0b15c02c8e3f6b709e208699487995a57c4385ee25e9b047232

Download TXT · 29,646 bytes · SHA-256: fe044271565dbb7acbeb0f5610aa0d858018b246964a4367d40a040e1392b037

Sources and scope

This page is a website explanation, updated 2026-10-03. Its explanation does not create a new execution result or change the status of its sources.