@@ -4,7 +4,7 @@ Decisions made for Phase 1, newest last.
 Rows marked "orchestrator, owner to confirm" were made by the orchestrator; implementation proceeds on them, and the owner confirms or changes them at the check-in that lists them (design, "Owner check-ins"; decision H12); only tasks depending on a listed row wait, and defect fixes never wait.
 Rows marked "approved by owner 2026-10-08" record the owner's written answers to re-review rounds 1 and 2; no other row is owner-approved unless its status says so.
 Only these wait for the owner: the 1b go or no-go, any new refusal of an input Python accepts (P1B-1), relaxing a comparison rule, adding an exclusion, downgrading a field to unavailable or adding one as unavailable, a new acceptance capability, an addition to `emulation-allowlist.txt`, the Q2 narrowing fallback, and a stop-rule counter reaching 2.
-Rows marked "revised R1" or "revised R2" were changed after that review round; rows C1 to C9 come from round 1, D1 from round 2, E1 to E14 from implementation, H1 to H26 and F1 to F7 from re-review round 1, H27 from the batch 2 code review. Re-review round 2 and its closure checks added no row: their corrections revised rows in place ("re-review R2") and the design text, and superseded rows are marked, not deleted.
+Rows marked "revised R1" or "revised R2" were changed after that review round; rows C1 to C9 come from round 1, D1 from round 2, E1 to E15 from implementation, H1 to H26 and F1 to F7 from re-review round 1, H27 from the batch 2 code review. Re-review round 2 and its closure checks added no row: their corrections revised rows in place ("re-review R2") and the design text, and superseded rows are marked, not deleted.
 The design is updated in the same change as a row that changes it.
 Standing decisions are in [migration-plan.md](../migration-plan.md) section 2 and [phase-0/decisions.md](../phase-0/decisions.md).
 
@@ -52,6 +52,7 @@ Standing decisions are in [migration-plan.md](../migration-plan.md) section 2 an
 | E12 | The 417-query PQL corpus (`sdm-core/tests/pql/corpus.json`, the archive's `tests/parity/pql` with schemas shared by name) and the journey's queries recorded on the reference (`journey.json`, by `record_journey.py` beside it) live with `sdm-core`'s adapter tests, not in `sdm-pql-interim`, and run through the adapter; the archive's 29 quirks and custom-profile tests come with T1.6b, whose exit they are | The corpus outlives the interim crate: it holds the PQL team's crate behind the same adapter to the same answers, and the capability checks it covers are in `sdm-core` | orchestrator, owner to confirm |
 | E13 | `sdm-host`'s calls take and give control messages as bytes, with the attachments each message names (`HostRun::start`, `next`, `reply`, `cancel`, `take_attachment`, `take_warnings`); each call is contained (a panic poisons the run and gives `INTERNAL_ERROR` with `fields.panic = true`) and refused with `RUN_BUSY` while another call is in the run. A message from the host must attach exactly the ids it names, as the kind it names (Arrow data or bytes), or it is refused with `INVALID_MESSAGE` naming the attachment, before the run sees it; a `start` with attachments is refused with `UNSUPPORTED_REQUEST` until T1.11 gives the core start attachments (E2). Fetched data passes admission; data admission refuses ends the run (`Run::end`, then `RUN_FINISHED`) with the refusal; a reply the run does not await gets the run's own refusal before any data is read. Admission also takes `dictionary<K, large_utf8>` as `dictionary<K, utf8>`, the `large_*` rule inside a dictionary, and refuses a value the admitted type cannot hold (a `timestamp[s]` or `[ms]` past an int64 of microseconds, offsets past int32) with the new contract code `VALUE_OUT_OF_RANGE`, kind `unsupported`, naming the column; a message the core would write past the cap is `INTERNAL_ERROR`, and an error message too large for the cap loses its cause, then its fields and message | The design names the rules (cap, admission, containment, busy, ownership) but not the calls; bytes in and out keep the codecs and the cap in one place for every binding, and a refusal of fetched data is the run's answer, not a provider error. The overflow refusals keep admission lossless, as B-D6 requires | orchestrator, owner to confirm; the cap and start-attachment clauses revised by H5 and H7 |
 | E14 | The 64 KB control cap applies to the `start` message too, which carries `validate_query`'s query text and schema; a request past it is refused with `INVALID_MESSAGE`, which refuses input the reference accepts (very wide schemas, very long queries). Proposed as register entry HOST-1 for the owner, with the recommendation to move a start's schema (and long text) into an attachment before S0 switches in Phase 3 | The cap is the design's; the refusal it implies for wide schemas surfaced while testing the cap, and under the owner's rule it is a regression until decided | superseded by H5; register HOST-1 rejected by owner 2026-10-08 |
+| E15 | Contract version 3 (T1.7b), the bump H4 asks a row for, carrying H5, H6 and H7 and the shapes they need: `ValidateQuery.query` and `.schema`, `Materialize.schema` and `.query`, `RequestState.query` and a new `SourceSpec` (`describe_source`'s tables and declared keys) are bytes attachments of the JSON of their type, and `describe_source`'s result is a `DescribedSource` naming its `SourceDescription` attachment; `Operation::attachments` names each id with the kind it must be, and `sdm_core::start` refuses a missing, extra, doubled or wrong-kind attachment, or one that is not its JSON (naming the attachment, the position and the category, never the text); `CoreError.code` is the closed `ErrorCode` enum of the 22 existing codes, with `retryable` (default false) and `CoreError::provider` carrying a provider's kind, retryability, SQLSTATE and vendor code; `ProviderError` and `TransportError` lose `message` and `code`; the seed is `Seed`, signed hexadecimal text with no leading zeros and no `-0x0`, and a negative seed is refused by `sdm_core::start` with `INVALID_REQUEST`; `Span` rows are at least 1; `HostFacts.local_zone` is `{iana}` or `{posix}`; a core message past the cap is `{"message": "attached", "attachment": n}` with the attachment beside it, numbered in the run's sequence; `HostRun`'s calls give errors as control messages too; test-only operations sit behind the `test-ops` feature and outside the schema. The lock holds one working entry, version 3, hashed over the annotation-free projection; versions 1 and 2 and their files are gone; the validated-query format, which shares `Span`, moves to its working version 2 the same way, its version 1 entry and file gone (E8, H4) | H4 makes each in-phase bump a decisions row (E7 was version 2); H5 to H7 say what v3 carries but not every shape it needs: the rule that no inline field grows with table count also moves `describe_source`'s table list, and an error a binding receives must cross as bytes to arrive whole | orchestrator, owner to confirm at the T1.7b check-in |
 | H1 | Runtime cells: CI cells are named by runtime and pinned from `phase-0/support-matrix.md`, as local semantic cells, not Databricks runtime certification: `ref-pandas3` (the recorded reference environment) compared with the reference on all fields; `dbr17-pandas2` (the observed DBR 17.3 LTS set) where `python-core` equals `python-old`; `floor-pandas1.5` (Python 3.10, pandas 1.5.3, pyarrow 10.0.1, the A8 floor), S0 only. A runtime-only difference is a register entry naming the cell, never an exclusion; observation identity records platform and cell. Re-review R2 (owner answer 5): the reference stays recorded on macOS and reference comparisons run locally through `gate.sh`; CI gates platform-independent fields; a Linux reference is a later CI build | Locked check 4 never said which pandas it compares on; the first attempt ended with 165 pandas-2 exemptions | approved by owner 2026-10-08 (round 1 answer 1, round 2 answer 5); the cell versions are the orchestrator's reading of support-matrix.md |
 | H2 | Gate integrity: the checkpoint is the last reviewed landing, with no tag, serialized promotion or separate accept commit (re-review R2): `CHECKPOINT_SHA = git merge-base CANDIDATE_SHA BASE_SHA`, with `BASE_SHA` the phase-branch tip resolved at package start and both SHAs recorded and passed to every gate run, never recomputed from a ref that contains the candidate (R2 closure check); each gate run checks it out into its own worktree, overlays only its observation projection and capture (`run_python.py`, the test kit's case loader and observation writer; the pure-Rust host, providers and scripted endpoint are protected candidate code, and `KNOWN_DIFFERING` is a candidate data file accepted only as a subset of the checkpoint's), and runs its harness, comparator, ratchet, L0 scripts and expectations against the candidate's observations; `contract/protected-paths.txt` is read at the checkpoint, and a protected change passes only when the reviewer's `Reviewed-by:` trailer names it, an outcome change only with a reviewer-approved register entry, a relaxation only with an owner-approved row; before T1.14 lands the candidate's harness runs under review, with no acceptance claim; `contract/availability.yaml` fixes availability per runner and field, and "unavailable" cannot pass a locked check; the owner's local merge is the only hard approval; no signing machinery | Re-review found the gate judged by code and expectation files the candidate can edit (learnings lesson 9), and round 2 found the tag procedure could not bootstrap and let the executor authorize its own protected changes | approved by owner 2026-10-08 (round 1 answer 2, round 2 answer 1); the bootstrap, the authorization rule and the narrowed overlay, owner to confirm at T1.7b |
 | H3 | A change is one reviewed work package: its proposed baselines are reviewed with it, one final gate run judges it against the checkpoint, it lands only with evidence for its exact SHA (one rerun after review fixes), and landing is the promotion; `rust-lint` clippy skips `sdm-testkit`, so only `rust-test` builds DuckDB | A CI round trip per commit and per baseline-only commit repeats the first attempt's validation overhead; the cold Rust jobs are dominated by the bundled DuckDB build | orchestrator, owner to confirm; revised re-review R2 |