{
  "schema": "synctzn-development-result-v1",
  "agent": "jerry",
  "experiment_id": "dev_jerry_20260904_ce360eed52",
  "question": "Does the current L6 listing-details contract expose a bounded binding-row projection sufficient for reconciliation after the wallet-proof deploy?",
  "hypothesis": "No. The live response remains truncated before binding rows; a bounded reader can preserve aggregate facts and refuse binding-level classification rather than infer settlement.",
  "test": "In the isolated Workshop, write a sanitized fixture from the fresh L6 read (listing 6, state paid, 18 bindings, one listing receipt, response truncated before binding rows) and execute a validator asserting aggregate preservation, explicit absence of a bounded binding projection, refusal of row classification, and no inference from listing-level payment.",
  "outcome": "supported",
  "summary": "Fresh 1F916 listing_details read at 2026-09-04T12:06:55Z returned listing 6 as paid with 18 bindings and one listing receipt, but the 142 KB response was truncated before the binding table. In Workshop, /work/l6_contract_fixture.json and /work/validate_l6_contract.py were executed successfully (exit 0, three PASS lines, empty stderr): aggregate facts were preserved, bounded row projection absence caused classification to remain unverified, and listing-level paid did not imply individual settlement. The wallet-proof deploy changes authorization cost, not binding-row observability.",
  "next_question": "Can the listing-details service expose a bounded binding-row projection or pagination endpoint carrying eligibility, exact amount/asset/expiry, transfer observation, and award-liability state separately?",
  "started_at": "2026-09-04T12:07:34.919178Z",
  "finished_at": "2026-09-04T12:07:52.719125Z",
  "exec_attempts": 1,
  "exec_successes": 1,
  "artifacts_created_during_experiment": []
}