Source-owned finite Optimize sets

Evidence correction: historical kill counts from the native Core-1 mutation runner before 9a63b70ff4 are withdrawn pending fresh replay. Stale binaries could produce false kills. This qualifies all such counts below; see docs/mutation-evidence.md. Test inventories are not execution evidence.

This living implementation note covers the additive finite-space extensions to the frozen Core-1 Optimize preview. It does not rewrite that preview’s normative corpus or activate stable Core-1.

Current bounded profile

The implemented profile includes ordered scalar sets, two-factor products, tagged scalar sums, fieldless named enums, two-field named scalar records, identity-bound proposal prefixes and body-local scalar Decision<T> values. Both evaluators preserve checked source/artifact/package behavior and owned receipts. Adaptation seals reachable problem identities and retains receipts through promotion and fallback; see the final section below.

All six fixtures named by ZER5-28 have separately pinned offline promotions:

Fixture	Catalog	Dedicated mutation controls caught
`finite-set-space`	0.10.0	16/16
`product-space`	0.11.0	54/54
`sum-space`	0.12.0	61/61
`proposal-in-identity`	0.13.0	72/72
`record-space`	0.14.0	55/55
`decision-nonescape`	0.15.0	59/59

These are conformance promotions, not model-quality measurements or changes to the default published catalog. Arbitrary nested spaces and nominal Decision readouts remain outside this bounded implementation. Stable Core-1 activation is a separate gate. The sections below retain milestone-specific history; their earlier “remaining” statements describe those revisions, not this summary. The Sprite runbook records revision-specific full verification results and unsuccessful attempts separately.

Body-local scalar Decisions

The additive ZLM2 2.32 / ZLA2 1.24 allocation admits immutable Decision<T> locals in non-portable compiled Optimize signals with the optimize effect:

let decision: Decision<Int64> = Decision<Int64>.capture(candidate);
return decision.readout;

T is exactly Bool, Byte, Int8/16/32/64, UInt8/16/32/64 or Index. Capture is a distinct checked type operation, not a cast: an Int64 cannot initialize a Decision, and a Decision cannot be returned or passed as its underlying scalar. Only .readout yields the ordinary owned scalar. Immutable local aliases are allowed; message parameters/results, stored fields, Result payloads, borrowed views and other domains cannot carry a Decision. No capture issues Search or Optimizer authority.

Both evaluators retain initializer order and faults even for unused Decisions. Recursive evaluation memoizes shared local dependencies; batched evaluation independently materializes the ordered graph. Exact scalar readouts, problem identities and ordered evidence survive checked artifact decoding and package relocation. A Decision changes the checked signal graph and hence problem identity; it does not change space membership, gates or budgets. The decoder reconstructs the complete scalar graphs from the checked tree before accepting Decision-bearing artifacts, so a refreshed checksum cannot authorize changed readouts. Older descriptor APIs and non-Decision artifact allocations retain their behavior.

This allocation does not admit nominal enum or record Decision readouts. Decision fixture promotion and adaptation evidence are separate later milestones documented below.

Source and execution

Named enum and record spaces

ZLM2 2.33 / ZLA2 1.25 adds Space.enum(Choice) and Space.record(Pair, left: Space.set(9, -4), right: Space.range(0, 1)). The enum must be public and fieldless, with 1–256 variants. The record must have exactly two public immutable scalar fields, using the existing packed record layout (at most 32 bits total). Each field factor has at most 256 values, all representable by that exact field type. Field labels must appear in declaration order; the right field varies fastest. Empty set factors are allowed. Record construction requires a transparent, effect-free structural initializer with no guard or reordered assignments.

Both signals receive one argument of the declared enum or record type, not anonymous Int64 coordinates. Enum equality requires the same enum type. Record projections keep their exact scalar types; Int64.widen(candidate.left) losslessly projects Byte, Int8/16/32/64 or UInt8/16/32 in compiled Optimize bodies. It rejects Bool, UInt64, Index and nominal values. The scalar C signal boundary uses one enum tag word or two declaration-ordered field words and rejects out-of-type inputs even when a signal ignores them.

Named type identity and declaration order participate in problem/body identity and survive checked artifact round-trips. Reflection retains variant names and typed fields. This bounded allocation does not add arbitrary nested records, nominal Decision readouts or stable activation. Fixture promotion is documented separately below.

zl_module_optimizer_run_evidence_v5 preserves named candidates in independently owned typed receipts. The public view includes search results, nominal kind and candidate-type identity. zl_optimize_evidence_candidate_type_json_v5 returns a copy of the declaration-ordered enum variants or record field names and scalar types; it stays readable after module and optimizer release. The former scalar and coordinate evidence APIs reject named candidates instead of erasing types.

Canonical ZOE5/1 serialization keeps the coordinate header’s 160-byte prefix (with new magic and engine identity), appends the 32-byte type identity, a u32 kind and a u32 descriptor byte length, then exact UTF-8 descriptor JSON and the ordered 40-byte observation records. Its hash domain is zerglang.optimize-evidence.v3; the two algorithms are source-nominal/proposal-order/exhaustive-recursive/v1 and source-nominal/proposal-order/batched4-materialized/v1. Both support checked proposal prefixes and the default declaration order. Empty records, gate rejections, exact Int64 preferences, first ties, budgets and fault prefixes retain their named type. Hashes describe identity, not authenticity or authority.

Benchmark-exec/15 exposes this as zerglang.optimize-evidence/4, with candidate_type and candidate_type_identity alongside the coordinate fields. It accepts only checked, public source/roundtrip entry points, rejects host type, budget and proposal overrides, and bounds receipts to 512 observations plus a 4096-byte descriptor. The native descriptor ceiling is 131072 bytes and the native observation ceiling remains 4096. Earlier request profiles stay closed.

Task zerglang.benchmark-task/13 selects request/15 and the typed receipt consumer. Its input closure is the same checked source/roundtrip boundary as Task/10–12; it cannot supply a type, space, proposal list or budget override. The consumer independently checks declaration-ordered type identities, exact descriptor bytes, coordinate bounds, headers, counters, observation order, first-tie selection and fault/budget prefixes before a trusted oracle runs. Task-owned source and oracle pins remain separate from these consistency checks; generated candidates may replace only their source closure. The new closed JSON schema is benchmarks/schemas/optimize-nominal-task.schema.json.

Ordered scalar sets

module example.ordered_set;
public value Problem {
    public compiled optimize message accept(type: Class<Self>, candidate: Int64)
        -> Bool effects { optimize } { return true; }
    public compiled optimize message follow(type: Class<Self>, candidate: Int64)
        -> Int64 effects { optimize } { return 1; }
    public compiled optimize message definition(type: Class<Self>)
        -> Int64 effects { optimize } {
        return Optimization.problem(
            281, Space.set(9, -4, 3), Problem.accept, Problem.follow, 8, 16
        );
    }
    public interpreted algorithm message run(type: Class<Self>)
        -> Int64 effects { optimize } { return Optimizer.run(Problem.definition); }
}

Set elements are distinct Int32 literals, widened to Int64 candidates. The profile admits zero through 256 elements. Source order is canonical order: the compiler does not sort the values or silently remove duplicates. Thus the example’s equal preferences select 9, with three candidate evaluations and six signal observations. Space.set() is an empty source-owned set, not a request for a host-supplied space. It returns no selected candidate, dimension count one, zero evaluations/observations, and NO_ACCEPTED_CANDIDATE termination; neither signal executes, even if its body would fault.

Both existing Optimize evaluators preserve this order, hard acceptance gates, separate candidate/observation budgets and signal-failure termination. Execute through zl_module_optimizer_run_source_i64_v2 with an opened opaque optimizer. The host-space zl_module_optimizer_run_definition_i64_v2 entry point rejects attempts to substitute another space. Missing optimizer authority rejects even for empty sets. The existing v2 report representation remains unchanged.

Complete package closures can import the definition and its signals separately. The checked Optimizer.run target edge remains valid when package linking makes the imported selector private. This also repairs imported definitions using the older Space.range profile, without exposing those private targets as public entry points.

Artifact and identity

Schema 2.28 uses ZLA2 physical layout 1.20 and is allocated separately in spec/extensions/core1-optimize-set.json. Only a closure containing a set selects it. Earlier formats, descriptors and bodies without sets retain their existing allocations. The CLI default remains minor 20. Explicit --minor=28 and zl_zlm2_wire_schema_v10 expose the new read-only descriptor; v9 still rejects 28.

In minor 28 each Optimize row retains its first 32 bytes and adds this tail:

Offset	Bytes	Meaning
32	4	Kind: 0 for legacy/range, 1 for set; other tags reject
36	4	Set element count, 0–256
40	1024	256 signed little-endian Int32 slots in source order

A set has zero range fields. Unused slots must be zero; a legacy/range row has an entirely zero set tail. All rows are 1064 bytes in this minor, including legacy ranges in a mixed closure. Padding does not grant additional elements. The decoder checks duplicate values, bounds, unused slots and the complete checked-source-to-region binding before publishing a module. Merely refreshing the outer checksum cannot authorize changed values, count, kind or order.

The ordered count/values extend the existing checked body identity; changing membership or order changes that identity, while whitespace and the public contract identity remain unchanged. Reflection exposes finite_space with kind: set, element_type: Int64, and the ordered values, including an empty array. This is checked metadata, not runtime authority.

Checked source problem identity

zl_module_optimizer_problem_identity_v3 exposes a read-only 32-byte identity for a complete source-owned scalar problem through its public Optimizer.run boundary. The opt-in zl_module_optimize_problems_json_v3 projection exposes public definitions under zerglang.optimize-source-problems/1, declaring the arithmetic semantics and ordered problems rows containing schema zerglang.optimize-source-problem/1, the selector, identity, numeric problem_id, and both budgets. Use build --emit=optimize-problems for source or checked artifacts, or package-source-build --emit=optimize-problems for a linked package entry. Default --emit=reflection, zl_module_reflect_json_v2, semantic/4 bytes and existing benchmark artifact-observation pins remain unchanged. This works for existing ranges as well as empty and nonempty sets. It does not grant optimizer authority or execute either signal.

The identity binds the arithmetic profile, problem label, canonical space kind/order, candidate and observation budgets, the definition’s checked contract, and every reachable accept/follow signal’s signature, contract and executable scalar graph. Calls retain their ordered targets and operands. A transitive helper edit or call rebinding changes the identity even if the numeric problem label is unchanged. Deterministic discovery ordinals replace relocated function slots, so whitespace, declaration order, unrelated helpers and package relocation do not change it. Equivalent closed scalar problems can share an identity across module/receiver names: it describes the checked computation, not a module’s nominal identity.

Identity framing uses the existing SHA-256 length-framed semantic-ID primitive, with separate zerglang.optimize-source-problem.v1 and zerglang.optimize-source-signal.v1 domains. These are derived facts; existing ZLM2/ZLA2 allocations, checked body IDs and v2 report layouts are unchanged. Exact and modular overflow behavior cannot share an identity just because their scalar graphs match. The v2 report’s numeric problem_id is still only a label, not this digest. Host-supplied spaces and unresolved package signal imports do not claim a source-bound identity. The read API rejects incomplete/non-source boundaries and zeroes the output identity on failure.

Ordered scalar evidence

zl_module_optimizer_run_evidence_i64_v3 is the opt-in exact-Int64 source execution path. It returns an opaque, owned zl_optimize_evidence_i64_v3 report. Unlike the unchanged v2 binary64 preference ABI, it compares Int64 preferences without conversion to double: 9007199254740993 outranks 9007199254740992. Equal preferences still select the first candidate in canonical source order. Existing v2 callbacks, report layouts and requests 1/5 retain their behavior.

The caller supplies a live optimizer, checked module, public Optimizer.run selector, and an observation-allocation ceiling in 1…4096. The ceiling is not a search budget. Before executing signals, the API bounds the maximum possible records by both checked budgets and source cardinality. A larger transcript rejects with ZL_OPTIMIZE_ERROR_EVIDENCE_LIMIT_V3 / ZL-OPTIMIZE-0003; it is never silently truncated. Ranges are enumerated by ordinal, not allocated in full, so a huge range with a small checked budget remains bounded. Empty sets still require live optimizer authority.

Read copies with zl_optimize_evidence_view_v3 and zl_optimize_evidence_observation_v3; serialize an independent buffer with zl_optimize_evidence_serialize_v3. Destroy reports with zl_optimize_evidence_destroy_v3 and serialized copies with zl_buffer_destroy. Reports remain readable after both module and optimizer are destroyed. Failed reads clear their output; invalid execution or allocation failure publishes no report.

Signal failure instead returns ZL_STATUS_RUNTIME_ERROR and ZL_OPTIMIZE_ERROR_SIGNAL_FAILED_V2 with a valid partial report. Its last observation identifies the failing signal and candidate, with a normalized zero value. Earlier observations and any previously selected candidate remain intact. Rejected candidates have only an accept observation; accepted candidates have an accept followed by a preference unless the observation budget ends between them. Failed calls consume an observation, and no later candidate runs.

Both evaluators bind the same checked problem identity and preserve observation order. Engine identities name versioned algorithms, not binary builds, hardware, signatures or authority:

Executor	Identity input
`optimize-exhaustive`	`source-i64/exhaustive-recursive/v1`
`optimize-batched`	`source-i64/batched4-materialized/v1`

The engine hash uses domain zerglang.optimize-engine.v1. The evidence hash uses zerglang.optimize-evidence.v1 and one part containing the complete serialized report. Framing is SHA-256 of the UTF-8 domain, one NUL byte, the part’s little-endian UInt64 byte length, and the part bytes. Source and admitted artifact executions have identical evidence; changing engines changes engine/evidence identities, not the canonical observation sequence.

ZOE3 revision 1 format

This standalone report format does not allocate another ZLM2/ZLA2 minor. All integers are little-endian. The 152-byte header is followed by exactly signal_observations records of 32 bytes, with no trailing data.

Header offset	Bytes	Meaning
0	8	`ZOE3` followed by UInt32 revision 1
8, 40	32 each	Checked source problem identity; versioned engine identity
72	8	UInt64 numeric problem label
80, 88	8 each	Checked candidate and observation budgets
96, 104	8 each	Actual candidate evaluations and signal observations
112	4	Termination: exhausted-space 0, candidate-budget 1, signal-budget 2, no-accepted-candidate 3, signal-failure 4
116	4	Outcome: completed 0, signal-failure 1
120	8	Selected count: 0 or 1
128, 136	8 each	Int64 selected candidate and preference; zero when unselected
144	8	Repeated observation count

Record offset	Bytes	Meaning
0	8	Zero-based contiguous observation ordinal
8	4	Zero-based candidate ordinal in the canonical space
12	1	Signal: accept 0, follow 1
13	1	Outcome: value 0, signal-failure 1
14	2	Reserved zero bytes
16, 24	8 each	Int64 candidate and observation value

Benchmark boundary

Task zerglang.benchmark-task/10 selects request zerglang.benchmark-exec/12; the transport wrapper remains zerglang.benchmark-result/1. The new result kind is optimization-evidence with schema zerglang.optimize-evidence/1. Its closed fields are executor, three identities, numeric problem label, selected list, nullable Int64 preference, both budgets and counters, termination/outcome, and evidence_hex plus evidence_byte_length. Integers are canonical decimal strings. The driver limits evidence to 512 observations to retain the 64 KiB response cap.

Task input is a typed record requiring source_path, source_files and input_kind (source or roundtrip), with one optional selector. Files must belong to the pinned source pool and use canonical package paths. Without an explicit case selector, the qualified public selector comes from the execution contract, preserving the original three-field form. An explicit selector is bounded to 1024 characters and must name the selected root module; the native compiler still checks the exact public module/type/message boundary. This allows distinct authored source problems in public and held-out cases. Host spaces, replacement budgets and authority claims are not request fields. Direct native revision-12 requests also accept a single source without source_files.

Synthesis candidates must preserve this task’s complete declared source pool and entry. Their UTF-8 source bytes receive fresh file pins. Original property-oracle pins are retained, not refreshed from candidate or modified oracle bytes. A candidate cannot replace an oracle, prompt or interface, even if a task also lists that protected path as source. Prompt/interface pins participate in the dataset identity but their files are not staged as execution inputs. Existing non-Optimize synthesis paths retain their pin handling.

An outer transport pass means a complete report was captured, not that the search succeeded. A captured signal fault has signal-failure outcome and termination inside its hashed evidence. Compile/authority/admission failures have no report. Task/10 uses a property or diagnostic oracle, validating wire framing, identities, counters, exact selection, hard gates, tie order and fault/budget prefixes before invoking it. Digest consistency is not authentication: the consumer cannot prove an opaque problem identity describes the intended source. Independent source/behavior oracles remain necessary.

benchmarks/schemas/optimize-task.schema.json reuses common revision-2 definitions without changing them. Frozen corpus pins, default reflection bytes, existing schemas and fixture maturity levels remain unchanged.

Verification and remaining scope

Named native tests cover ordered selection, hard gates, both budgets, faults, empty sets, Int32 endpoints, the 256/257 boundary, byte-exact artifact round trips, checksum-valid tampering, imported definitions and authority rejection. Generated cases exercise real source and decoded artifacts through both evaluators. The behavior-mapped mutation suite is optimize-set.

The set-only verification run passed all 320 portable CTest checks and all 16 focused checks on each LLVM and LLVM ASan/UBSan build. All 14 native behavior mutants were killed. Generator checks cover closed allocation, byte limits, base identity, independent descriptor copies, key order, and stale-output detection. Its isolated mutmut campaign killed 197 of 212 mutants, with no uncovered or timed-out cases. The 15 reviewed survivors change diagnostic/help wording or are equivalent fixed-map ordering/JSON encoding defaults; none alters the accepted registry, generated descriptor, or write/check result. No installed toolchain or unrelated mutation configuration was changed for this campaign.

The source-identity extension passed all 325 portable checks and 25 focused checks on each LLVM and LLVM ASan/UBSan build. Three 30-example properties per build cover declaration relocation, ordered sets, and source/artifact identity round trips. All 15 identity behavior mutants were killed, including arithmetic profile erasure, transitive signal erasure, and projection/API disagreement. The frozen artifact-observation corpus retains its original pins.

The ordered-evidence extension passed all 331 portable CTest checks and all 31 focused checks on each LLVM and LLVM ASan/UBSan build. The final portable benchmark harness passed 485 tests with three existing platform/provider skips. Earlier timeout failures passed on an isolated rerun without deadline changes, followed by the clean complete portable run. Each build also passed three 40-example native evidence properties and 24 task-schema property examples covering field/file order and input kind.

The ASan/UBSan runs use ASAN_OPTIONS=detect_leaks=0. An optional LeakSanitizer run remains unverified: the local macOS toolchain deadlocked in exit-time dyld processing. These results do not claim a successful leak check.

The extension kills all 20 native behavior-mapped mutations. Its final isolated Python consumer campaign kills 621 of 684 mutations, with no uncovered, timed-out or invalid results. The 63 reviewed survivors comprise 34 diagnostic-text changes and 29 equivalent changes at the public boundary:

Equivalent change	Count	Why admission and output are unchanged
Relaxed empty/NUL text checks	2	Closed path syntax and exact input-kind membership still reject these values.
Case changes in the size-only request envelope	10	These ASCII changes preserve byte length; the returned request fields do not change.
A 21-character decimal limit	1	Every admitted integer still satisfies a bound whose canonical representation is at most 20 characters.
Signed hash-length framing	1	Every framed length is positive and far below the signed 64-bit limit.
Slightly wider counter or byte limits	5	Exact record length, the remaining observation limit, and record/candidate accounting impose the same accepted bound.
Wider selected-candidate bounds	5	Selection must equal a recorded candidate, and every recorded candidate still satisfies the Int32 profile.
Equivalent initial values and truthiness	4	The previous candidate is overwritten before a legal preference; false/None flags are used only by truthiness.
Signed observation header decoding	1	Legal tags and ordinals have identical encodings; high-bit alternatives still fail tag, order or reserved-byte checks.

These equivalences are specific to the current complete validator, not approval to remove its individual checks. Digest-valid attacks independently exercise gate order, fault-finality, reported readouts, counter/record disagreement, and false budget or termination claims.

ctest --test-dir out/build/core2-portable -R optimize --output-on-failure
python -m pytest tests/properties/test_optimize_sets.py
python tools/run_core1_mutation_checks.py --suite optimize-set
python -m tools.zlm2_optimize_set_layout --check
python -m pytest tests/properties/test_optimize_identity.py
python tools/run_core1_mutation_checks.py --suite optimize-identity
python -m pytest tests/properties/test_optimize_evidence.py tests/properties/test_optimize_evidence_schema.py
python -m unittest tests.benchmark.test_optimize_evidence_forgery
python tools/run_core1_mutation_checks.py --suite optimize-evidence

The separately pinned ZL256 0.10.0 finite-set fixture exercises 26 source/artifact cases on both engines. Its source guide is benchmarks/revisions/0.10.0/README.md. It promotes only optimize/finite-set-space; prior corpus revisions and default publication remain unchanged. Its fixture controls refresh source pins before testing real behavior, so an immutable-catalog mismatch cannot stand in for a semantic kill. All 16 fixture/runner controls are killed. Its separate Python audit covers five changed functions across four modules: 321 of 356 selected mutations are killed, with 35 reviewed cosmetic or public-boundary-equivalent survivors and no inconclusive results. The revision guide records the exact scope and review. Candidate tests include nested source paths, authoring assets also listed as source, public-only repair feedback and the unchanged C/AOT synthesis path. All 334 portable groups have passing results across the full run and serial rechecks; the final aggregate passed 502 tests with three existing skips. This is not a claim of one clean complete run: the initial parallel run and first aggregate recheck hit existing C-execution timeouts, which later passed with unchanged code and deadlines. Both LLVM and ASan/UBSan builds passed 34 focused groups, and each of the three builds passed 218 generated property examples. The revision guide records the rerun sequence and sanitizer limits.

Enums, general/nested products, records, proposal-bound problem identity, Decision<T> lifetimes, proposal-bearing evidence and adaptation checks still require implementation. These scalar milestones are not completion of the remaining finite Optimize surface, and the other three associated scaffold promotions remain outstanding.

Bounded two-factor products

The next opt-in profile accepts exactly two scalar leaf factors:

Space.product(Space.set(9, -4), Space.range(2, 3))

Each factor is a Space.set of zero through 256 distinct Int32 literals or an inclusive Space.range of 1 through 256 Int32 values. Both signals take two Int64 arguments in factor order; accept returns Bool, and follow returns Int64. For example, accept(x, y) = true and follow(x, y) = x + y select [9, 3] with preference 12, four candidate evaluations and eight observations. The first factor is outermost; the right factor varies fastest. Equal preferences select the first candidate. Hard gates, separate budgets and signal-fault prefixes are retained by both evaluators.

An empty set in either factor makes an empty product: two dimensions, no selected candidate, zero evaluations and observations, and NO_ACCEPTED_CANDIDATE. Neither signal executes. A live optimizer remains necessary even for this case, and the host-space boundary cannot replace either factor.

The existing V2 source-run API returns both coordinates in its owned selected array, without changing that ABI or its binary64 preference representation. The scalar V3 evidence rejects products with ZL-OPTIMIZE-0002, including empty products; it never drops a coordinate or publishes a misleading scalar receipt. The separately versioned V4 coordinate evidence contract below records both coordinates without changing the scalar contract. Product fixture promotion is the separate, pinned corpus change documented at the end of this guide.

Product artifacts and inspection

ZLM2 2.29 and ZLA2 1.21 are allocated in spec/extensions/core1-optimize-product.json, which pins the unchanged set extension. The new payload minor admits the product carrier grammar without backporting it into 1.20. Old scalar source/artifact/evidence formats, descriptor bytes, corpus pins and the CLI default minor 20 remain unchanged. zl_zlm2_wire_schema_v11 and zlm2-schema --minor=29 expose the new descriptor; v10 still rejects minor 29.

Every Optimize row in minor 29 retains its first 1064 bytes and adds:

Offset	Bytes	Meaning
1064	4	Product kind: 0 for earlier spaces, 1 for a product
1068	4	Dimension count: 0 for earlier spaces, exactly 2 for a product
1072	1040	First factor
2112	1040	Second factor

A factor contains little-endian kind/count/Int32 lower bound, four reserved zero bytes, and 256 Int32 value slots. Range kind 0 has a positive bounded count and zero slots. Set kind 1 has a zero lower bound, exact ordered distinct members and zero unused slots. Earlier spaces require the entire product tail to be zero; products require all earlier range/set fields to be zero. Other kinds, reserved bytes, out-of-bound counts and mismatches with the checked carrier reject even after the outer checksum is refreshed.

Reflection projects finite_space.kind: product, dimension_count: 2 and an ordered factors array, retaining each leaf’s kind and values or lower/count. Both the checked body identity and source problem identity bind factor order, membership, shape and range bounds. Whitespace, package source order and linked signal relocation preserve the source problem identity; the public definition contract remains unchanged. This is inspection, not optimizer authority.

Native source/artifact cases cover gates, budgets, faults, ties, empty factors, Int32 endpoints, the range 256/257 boundary, imported definitions, and legacy scalar evidence rejection. The artifact tests check exact wire/reflection values and re-signed corruption. Sixty generated source/artifact cases exercise both evaluators, with 40 additional descriptor key-order examples. All 16 native behavior-mapped controls are killed under LLVM ASan/UBSan (detect_leaks=0); this does not claim LeakSanitizer verification. The first Apple-toolchain baseline stalled in sanitizer initialization before test entry and was not scored.

The product descriptor’s isolated Python mutation campaign kills 200 of 215 mutants, with no uncovered, timed-out or invalid cases. The 15 reviewed survivors are three equivalent fixed-map key-order changes, two equivalent default/ASCII encoding changes, eight diagnostic-text changes, and two help/stale-message wording changes. Ten direct generator tests and the key-order property cover closed allocation, independent output ownership, bounded filesystem reads, base identity, malformed input, write/check behavior and preserved error payloads.

The initial product check passed all 43 focused LLVM ASan/UBSan CTest groups and all 100 generated product/descriptor examples. The site passed 328 tests and type checking, with 54 public documents projected. At that milestone the larger unsanitized regression campaign remained unverified: executable launches stalled with process samples showing only macOS _dyld_start, including unchanged Core-2 tests. A separate Clang 22 portable build passed its first 29 checks before encountering the same condition. Stalled runs were stopped, and a bounded unsanitized LLVM retry also timed out. A later sanitizer rerun after a test-only identity-copy cleanup stalled before test entry as well, so that rerun is not claimed as passing. These are not assertion failures, mutation kills, or a claim that all 343 regression groups passed. No host security settings, installed toolchains, or test behavior were changed to bypass the issue. The later completed coordinate-evidence regression below closes this verification gap without claiming a diagnosis for the earlier startup stalls.

ctest --test-dir out/build/core2-portable -R optimize_products --output-on-failure
python -m unittest tests.cli.test_optimize_product_artifact tests.benchmark.test_optimize_product_layout
python -m pytest tests/properties/test_optimize_products.py
python -m tools.zlm2_optimize_product_layout --check
python tools/run_core1_mutation_checks.py --suite optimize-product

This bounded profile does not implement nested products, structured tuple/record candidates, enums, sums, proposals, or Decision<T> lifetimes. This runtime milestone does not promote another fixture, change default publication, or activate stable Core-1. The separate corpus promotion follows the coordinate-evidence milestone below. The remaining Optimize ticket stays in progress.

Ordered coordinate evidence

zl_module_optimizer_run_evidence_i64_v4 executes source-owned scalar ranges, sets, or the bounded two-factor product above. It returns an opaque, owned zl_optimize_evidence_i64_v4 report. Both evaluators compare preferences as exact Int64 values, retain the first candidate on ties, and record every coordinate in canonical factor order. The right factor varies fastest. The checked source problem identity is the same read-only identity exposed by V3; it binds the complete product, signals, arithmetic profile and budgets.

The caller must supply a live optimizer, a checked module, its public Optimizer.run selector and an observation ceiling in 1…4096. The ceiling bounds allocation, not search semantics. The maximum record count is the smaller of the source observation budget and twice the smaller of source cardinality and candidate budget. Excess capacity rejects before signal execution with ZL-OPTIMIZE-0003. Even an empty product requires authority and a valid ceiling. No host space or replacement search budget is accepted.

zl_optimize_evidence_view_v4 copies the public report: dimension_count is one for scalar spaces or two for products, including empty products; selected_count is zero or one candidate, not the number of coordinates. Its two-element selected array contains the coordinates, with the unused scalar slot zero. Unselected reports zero both slots and preference. Read each observation with zl_optimize_evidence_observation_v4; its candidate array has the same padding. Failed reads clear their output. All reads are copies, not mutable access to the owned report.

zl_optimize_evidence_serialize_v4 returns an independent buffer released with zl_buffer_destroy. Reports outlive both module and optimizer and are released with zl_optimize_evidence_destroy_v4. Invalid execution publishes no report. A signal fault returns ZL_STATUS_RUNTIME_ERROR with a valid partial report: the final row identifies both candidate coordinates and the failing signal, normalizes its value to zero, and retains any earlier selected candidate. Hard rejections have only an accept row. Accepted candidates have a follow row unless the observation budget stops execution between the two signals.

ZOE4 revision 1 format

This standalone format adds no ZLM2/ZLA2 allocation. A 160-byte header is followed by exactly signal_observations 40-byte records, with no trailing data. Integers are little-endian. Header offsets 8 through 119 retain the ZOE3 meanings above.

Header offset	Bytes	Meaning
0	8	`ZOE4` followed by UInt32 revision 1
120	4	Selected candidate count: 0 or 1
124	4	Dimension count: 1 or 2, even when unselected
128, 136	8 each	Int64 selected coordinates, with zero unused slots
144	8	Int64 selected preference; zero when unselected
152	8	Repeated observation count

Record offset	Bytes	Meaning
0	8	Contiguous zero-based observation ordinal
8	4	Zero-based candidate ordinal
12, 13	1 each	Accept/follow kind and value/signal-failure outcome, as in ZOE3
14	2	Reserved zero bytes
16, 24	8 each	Int64 candidate coordinates, with zero unused scalar slot
32	8	Int64 observation value; zero on signal failure

Engine identities use domain zerglang.optimize-engine.v1 with input source-i64-coordinates/exhaustive-recursive/v1 or source-i64-coordinates/batched4-materialized/v1. Evidence identity uses the separate domain zerglang.optimize-evidence.v2 over one part containing the complete wire report, with the existing length framing. Source and admitted artifact executions produce identical receipts for the same engine. The older scalar identities, ZOE3 bytes, V2 ABI and V3 execution behavior are unchanged.

Coordinate benchmark boundary

Task zerglang.benchmark-task/11 selects request zerglang.benchmark-exec/13 and result schema zerglang.optimize-evidence/2. The outer result remains zerglang.benchmark-result/1, with kind optimization-evidence. The closed result extends the scalar fields with canonical decimal-string dimension_count; selected is empty or contains exactly that many canonical Int32 coordinate strings. Preference remains a nullable canonical Int64 string. The process boundary retains the 512-observation limit and 64 KiB response cap.

benchmarks/schemas/optimize-coordinate-task.schema.json reuses the unchanged Task/10 source-input and execution definitions. Complete source pools, optional root-qualified public selectors, source/artifact input kinds and source pins have the same requirements. Neither revision can inject host spaces, budgets or authority. Task/10 still uses request 12 and rejects products.

Before invoking a property oracle, Task/11 validates exact wire framing, both coordinates of every accepted/follow pair, ordinals, zero padding, identities, exact first-tie selection, counters, hard gates, budget termination and final fault prefixes. Rehashing malformed coordinates or counters does not bypass these checks. This proves internal consistency, not source authentication: an opaque source identity still needs pinned source and independent behavioral oracles. Synthesis candidates receive fresh source pins but cannot refresh oracle pins, replace protected authoring files, or change the declared source pool. These tests use deterministic fixture responses, not paid model calls.

Native lifetime/invalid/limit/partial tests, real source/artifact and package cases, independent wire fixtures, Task/11 and synthesis tests cover the public boundary. Generated cases vary ordered factors and compare both evaluators and source/artifact receipts; task properties vary field and file order. The optimize-coordinates campaign kills all 24 behavior-mapped native/integration controls under LLVM ASan/UBSan (detect_leaks=0). This is not a leak-check claim. The isolated Python receipt-validator campaign kills 545 of 600 mutations, with no uncovered, timed-out or invalid results. The 55 reviewed survivors consist of 39 diagnostic-text changes and 16 public-boundary equivalents:

Equivalent change	Count	Why admission and output are unchanged
A 21-character decimal limit	1	All admitted numeric bounds still fit canonical strings of at most 20 characters.
Signed hash-length framing	1	Framed data lengths are positive and far below the signed 64-bit limit.
Wider counter or byte limits	5	Exact wire length, the other observation limit and record/candidate accounting retain the same accepted bound.
Wider selected-coordinate bounds	5	Selected coordinates must equal recorded coordinates, which independently satisfy Int32 bounds.
Equivalent initial values and false flags	3	Legal acceptance overwrites the previous coordinates before a follow; false/None flags are used only by truthiness.
Signed record-header decoding	1	Legal tags and ordinals encode identically; high-bit alternatives still fail order, tag or padding checks.

These equivalences describe the complete validator, not permission to remove checks individually. The added attacks rehash zero identities, invalid empty dimensions, rejected-candidate coordinates and Boolean values, mismatched fault labels, and malformed record tails. Tests also admit exact Int32/Int64 endpoints and valid one-observation budget prefixes.

The coordinate milestone passes one complete serial portable run of all 349 CTest groups, including the benchmark aggregate’s 532 tests with three existing platform/provider skips. The aggregate used a 900-second outer CTest ceiling; its internal case deadlines were unchanged. The earlier 60-second outer probe had cut off this long suite and is not counted as a passing run. The aggregate completed in 360 seconds and the full run in 789 seconds.

Both LLVM and LLVM ASan/UBSan builds pass all 49 focused Optimize, artifact-observation, reflection and package groups. Each of the three builds also passes 332 generated examples: 64 coordinate/task examples, 100 product/descriptor examples, 120 scalar-evidence examples and 48 legacy Task/10 examples, plus two schema-rejection tests. The final host recheck passes all 15 Task/11 and scalar/coordinate synthesis tests; the mutation harness passes its 23 direct tests and three outcome properties. The site passes all 329 tests and type checking, with 54 public documents projected. These are local verification results, not a deployment or a stable Core-1 activation.

ctest --test-dir out/build/core2-portable -R optimize_coordinate --output-on-failure
python -m unittest tests.benchmark.test_optimize_coordinate_validation
python -m pytest tests/properties/test_optimize_coordinate_evidence.py
python tools/run_core1_mutation_checks.py --suite optimize-coordinates

Coordinate evidence alone does not promote a product fixture or activate stable Core-1. The separately pinned promotion below uses that receipt boundary; it does not implement the remaining structured candidates, proposal-bound identities, Decision<T> ownership and adaptation contracts.

Product-space conformance corpus

The separately pinned ZL256 0.11.0 product-space fixture has 36 source/artifact cases and promotes only optimize/product-space from scaffold revision 2 to verified revision 3. The other 255 task manifests and their file identities are unchanged from 0.10.0. Earlier catalogs, default publication, ZL512 and stable Core-1 activation remain unchanged. Full corpus details are in benchmarks/revisions/0.11.0/README.md.

Eighteen authored products cover declared factor/element order, exact Int64 ties and preferences, gates using both coordinates, empty factors, independent budgets, accept/follow faults, all-rejected spaces, 256-candidate grids, 256-element leaves, Int32 endpoints and three invalid factor constructions. Each has source and serialized/decoded-artifact cases on both engines. The public and held-out partitions have nine distinct source problems each; the prompt discloses all requirements, so these are conformance partitions rather than unseen-input claims.

Signals use the admitted scalar expression graph, not short-circuit Boolean signals. The combined gate is x * y < 0: it depends on both coordinates and prevents division by zero in rejected candidates. Short-circuit control flow is not silently added to the source-identity profile by this fixture.

Task/11 property oracles assert the complete selected coordinate pair, exact preference, label, dimension, budgets, counters, termination, outcome and every ZOE4 observation row. Every oracle has independently wrong-field and wrong-wire controls. Mutation controls refresh source/oracle pins before native execution so a catalog mismatch cannot substitute for a behavioral failure. A deterministic model-adapter fixture also checks faithful candidate source, public and held-out order errors, and prohibited oracle replacement; it makes no model-quality claim.

All 54 corpus mutation controls are killed: 20 source behaviors and 34 oracle checks, with no survivors. One clean serial portable run passes all 352 CTest groups, including the 544-test benchmark aggregate with three existing skips. Both LLVM and ASan/UBSan builds pass 52 focused groups; LeakSanitizer is disabled. Portable, LLVM and sanitizer builds pass all 17 selected property-suite tests, including the new 36-example corpus property. The site passes 330 tests and type checking. The revision guide records this verification scope separately from the unchanged runtime and receipt-validator campaigns.

This corpus retains the existing synthesis allocation and remains ineligible for performance measurement. It changes no executor or wire schema. At this revision, the other four associated scaffold promotions—sums, records, proposals and Decision<T>—remained outstanding. The sum promotion follows below; enum/general-product and adaptation work are still not complete.

Bounded tagged scalar sums

The next additive source profile uses ZLM2 2.30 and ZLA2 1.22 for Space.sum(left, right). Each of its two ordered branches is a leaf Space.set(...) or Space.range(lower, upper) with at most 256 Int32-bounded values, observed as Int64. A sum has at most 512 candidates. It is a disjoint union, not a Cartesian product: all values from branch 0 precede all values from branch 1, and each branch retains its existing leaf order.

return Optimization.problem(
    330,
    Space.sum(Space.set(9, -4), Space.set(9, 3)),
    Problem.accept, Problem.follow, 32, 64
);

Both signals take two Int64 parameters, in order: branch_tag and the branch value. The example’s four candidates are (0, 9), (0, -4), (1, 9) and (1, 3). Equal values in different branches are distinct candidates; duplicate values within one set are still invalid. An empty first branch leaves the second branch tagged 1, and an empty second branch leaves the first unchanged. Two empty branches retain two coordinates but produce no selection, zero candidate evaluations and zero observations. They never evaluate signals.

The public V2 source report and the V4 coordinate report both retain the tag and value. Sum execution uses exact Int64 selection, including preferences beyond 2^53; the legacy V2 report only converts the selected preference to its existing double display field. V4 retains the exact preference. First-in-order ties, hard gates, separate budgets and partial reports on signal failure retain their existing meaning. A rejected candidate has no follow observation. Unsupported signal graphs reject before sum execution; short-circuit Boolean signals are not admitted by this profile.

The reference enumerator walks each branch and its leaf positions directly. The batched enumerator constructs up to four tagged candidates from ordinal positions and then evaluates them in canonical order. Signals retain the independent recursive and materialized evaluators. Both source and round-tripped artifacts use these same checked boundaries, including package-imported signals and definitions. Missing optimizer authority or a host replacement space still rejects. The scalar V3 evidence API rejects sums, even empty ones; the V4 owned coordinate API emits the unchanged ZOE4 revision 1 bytes.

Reflection exposes finite_space.kind = "sum", dimension_count = 2, coordinates = ["branch_tag", "value"] and an ordered branches array with the ordinary leaf descriptions. It never presents these branches as product axes or loses their positions when one is empty. Source problem identity uses a distinct sum kind and binds branch kind, order and members. The checked body uses the distinct ZLOU frame. Membership changes leave the callable contract unchanged but change the problem and body identities; source whitespace and package relocation preserve the problem identity.

The additive allocation is core1-optimize-sum.json. The 3152-byte Optimize record keeps the physical 2.29 layout, including its historical product_kind, factor_0 and factor_1 field names. Minor 2.30 adds kind 2 for a sum and retains two canonical branch records. The decoder compares these rows with the checked u.2 carrier, so changing a sum to a product, changing members, or forging unused slots rejects even with a refreshed outer digest. Earlier minors and the v11 schema API remain closed to sums; the new v12 schema API preserves their descriptor bytes.

This is a bounded tagged scalar sum, not a general typed union: nested sums, record-valued branches and enum-typed signals remain unimplemented. Records, general/nested products, proposal identities, Decision<T> ownership and adaptation contracts also remain pending. The frozen Core-1 edition files are unchanged; the additive implementation contract is documented separately. By itself, this runtime extension does not promote the sum-space fixture or expand the closed benchmark problem/evidence descriptor schema. The pinned 0.11.0 corpus, its 98 verified / 23 executable / 135 scaffold tasks and performance allocation remain unchanged. The separately pinned sum promotion below supplies its own corpus and evidence gates.

The sum extension passes 64 focused LLVM groups and the same 64 groups under ASan/UBSan, with LeakSanitizer disabled. All 19 selected property-suite tests pass on portable, LLVM and sanitizer builds: 658 generated examples plus two ordinary schema checks per build, including 100 new sum examples. The site passes 331 tests and type checking. The native campaign kills all 32 new sum controls, and the unchanged product and coordinate behaviors kill all 16 and 24 regression controls. The Python layout campaign examines 196 mutants: 178 killed, eight equivalent and ten cosmetic after review, with no unreviewed, invalid or timed-out results. All 23 direct mutation-harness tests pass. One complete serial portable run passes all 364 CTest groups in 1312.17 seconds, including the 554-test benchmark aggregate with its three existing platform/provider skips. The aggregate takes 402.23 seconds. No deadlines or runtime implementation were changed during that run.

Pinned tagged-sum conformance corpus

The separately pinned ZL256 0.12.0 sum-space fixture has 40 source/artifact cases and promotes only optimize/sum-space from scaffold revision 2 to verified revision 3. The other 255 task manifests and file identities are unchanged from 0.11.0. The catalog retains all 256 tasks, now 99 verified, 23 executable and 134 scaffold, with 949 cases. Its dataset-bound profile and identities are in benchmarks/revisions/0.12.0/README.md. Earlier catalogs, default publication and stable Core-1 activation are unchanged.

The 20 source problems have disjoint ten-problem public and held-out partitions. Every problem runs both directly and after artifact serialization/decoding under the exhaustive and batched engines: 80 case/executor observations, including 12 diagnostic observations. Seventeen independent property programs assert the selected tag and payload, exact preference, dimension, numeric label, budgets, counters, termination, outcome and every ordered ZOE4 observation row.

These cases cover distinct branch and leaf order, equal payloads in different branches, inclusive ranges, exact preferences above 2^53, both empty-branch positions and an entirely empty sum, hard gates, separate budgets, accept/follow faults with partial reports, all-rejected spaces and Int32 endpoints. A gate depending on tag + item < 0 rejects branch 1 payload -1 as well as zero, so dropping the tag changes observable acceptance. Zero payloads never reach its division-based follow signal.

A 128-plus-128 sum and a single 256-member branch exercise 256 candidates and 512 observations. A further 512-member sum is deliberately limited to its first 256 candidates and 512 observations; it is not a full 512-candidate evidence run. This preserves the existing 512-observation benchmark limit. Oversized leaves, within-branch duplicate members and nested sums reject with ZL-OPTIMIZE-0001. No branch flattening, deduplication or truncation substitutes for these errors.

Task/11 continues to use request/13 and coordinate evidence/2 without a new benchmark descriptor. The main fixture passes source-package construction, byte-exact artifact normalization and public branch reflection through ZLM2 2.30. Every oracle rejects independently altered fields and observation columns. Fresh-pin controls separate source/oracle semantics from catalog-digest checks. A deterministic external model-adapter fixture tests faithful candidate sources, public and held-out order errors, and prohibited oracle replacement. These are disclosed conformance partitions, not claims of model quality or secret inputs.

The source authoring draft initially used the reserved word value for a signal parameter and correctly received ZL-PARSE-0002. Renaming that parameter to item required no runtime change or change to expected observations.

The corpus passes 67 focused LLVM groups and the same 67 groups under ASan/UBSan, with LeakSanitizer disabled. All 20 selected property-suite tests pass on portable, LLVM and sanitizer builds: 698 generated examples plus two ordinary schema checks per build. The site passes 332 tests and type checking, and all 23 direct mutation-harness tests pass. Public and held-out synthesis controls change only member order; the tightened held-out control passes its targeted recheck on all three current builds. The fixture mutation campaign kills all 61 controls—23 source behaviors and 38 oracle checks—with no survivors, invalid results or equivalent exclusions. These fresh-pin fixture controls are separate from the runtime and host-validator campaigns recorded above.

Final EOF cleanup refreshes only the interface-dependent catalog/profile pins; all eight sum revision/oracle/synthesis tests and the 40-example relocation property pass again on all three builds. Source and oracle bytes are unchanged. The latest full portable run is not an all-green gate: the existing backend.c_scalar_entry group exceeds its 180-second deadline. An isolated generated executable also exceeds its ten-second deadline, with a sample showing 885 _dyld_start samples and no application frames. A trivial C control also shows loader delay but exits successfully. The host startup investigation remains open under ZER5-132; no timeout or host protection is weakened. The same full run also reports four ten-second algorithm-c timeouts in benchmark.adaptation_revision; their individual startup causes are not established by the separate generated-executable probe. The older benchmark mutation gate fails before mutations on a 30-second fake-executor startup timeout and supplies no score. Installed-package verification stalls without a deadline in relocated zlc version --json; after a loader-only sample, that owned child is explicitly terminated and packaging remains failed. The successful sum-specific evidence above does not turn these broader failures into passes. The fresh portable-without-LLVM gate is also explicitly interrupted after thirteen Rust build-script children stall for three minutes; samples of two show only _dyld_start. The completed serial run records 362 of 367 groups passing in 2059.26 seconds: three failed groups and two interrupted packaging groups, retained as failures. Its 562-test benchmark aggregate passes with three existing skips. A controlled host is needed to investigate the outstanding gates; these results do not establish a common cause for every timeout.

The synthesis/performance allocations remain 128/32. The sum task retains synthesis eligibility and remains ineligible for performance measurement. The other three associated scaffold promotions—records, proposals and Decision<T>—still require implementation. Enum-typed/nested sums, general/nested products and composite/proposal adaptation are also outstanding.

Checked proposal order (additive runtime profile)

ZLM2 2.31 / ZLA2 1.23 adds an optional seventh source argument:

return Optimization.problem(
    331, Space.set(9, -4, 3), Problem.accept, Problem.follow,
    8, 16, Optimization.propose(2, 0)
);

Proposals are distinct ordinals in the original canonical space, not new candidates or external authority. This example visits 3, 9, then -4. The prefix may contain zero through 256 entries; each must be an in-range UInt32. After the authored prefix, remaining candidates retain their original order. Empty lists are valid, even for empty spaces, and differ in identity from an absent proposal argument. Existing scalar ranges, sets, bounded products and bounded sums support this profile.

Hard gates, separate candidate/observation budgets, exact Int64 preferences, first-visited tie selection, partial fault reports and live optimizer authority are unchanged. Reference traversal walks the prefix and then skips its members in canonical order; batched traversal uses bounded rank selection. Neither materializes a potentially multi-billion-member scalar range. Source evidence uses these independent traversals and retains its V3/V4 wire layouts with proposal-specific engine identifiers.

Problem and checked-body identities append ZLOQ, a count and ordered UInt32 ordinals. Contract identity does not change for an order-only edit. Package linking, source/artifact execution and reflection preserve the list; reflection adds proposal_ordinals alongside the unchanged finite_space. Checked decoders reject mismatched, duplicate, out-of-range, noncanonical or nonzero unused proposal slots even when the artifact checksum is refreshed. Earlier minor descriptors and APIs remain closed and byte-identical.

Coverage includes exact transcripts, ties, gates, both budgets, faults, empty spaces, the 256/257 boundary, near-UInt32 cardinality with bounded evaluation, package relocation, body/contract identities and artifact tampering. Generated permutation properties exercise both executors before and after serialization. This runtime allocation does not itself promote the proposal benchmark fixture or extend its closed problem-descriptor format. Records, enum-typed/general nested spaces, Decision<T> ownership and adaptation remain separate work.

Closed proposal evidence protocol

Task zerglang.benchmark-task/12 selects request zerglang.benchmark-exec/14 and result zerglang.optimize-evidence/3. Its fields, authority limits, source-file pins and ZOE4/1 coordinate wire format are unchanged from Task/11. The new profile requires an explicit Optimization.propose(...), including an empty list, and binds engine IDs to source-i64-coordinate-proposals/{exhaustive-recursive,batched4-materialized}/v1. The native executor checks the actual engine identity before publishing a receipt. Requests 12/13 reject proposal-aware algorithms; request 14 rejects an absent proposal argument. Older profiles cannot silently acquire a new ordering algorithm.

The host validates the closed schema and engine identity, exact wire bytes, ordered observations, budgets, readout and digest before invoking a property oracle. It does not infer source authenticity from a self-consistent receipt: trusted source/oracle pins and an independent behavioral oracle remain required. Neither task inputs nor requests admit host-supplied spaces, proposal lists or budget overrides. Generated candidates receive their own source pins while trusted authoring files and oracles retain the task’s pins.

Public-interface tests cover source/artifact equality, both engines, explicit empty lists, identity-preserving traversal with identity-distinct authored prefixes, partial budgets, faults, stale pins and rehashed forged receipts. Property tests check every observation against independently constructed finite Cartesian products and verify that field permutation preserves a Task/12 request while the older JSON schema rejects it. This protocol allocation alone does not promote the still-scaffolded optimize/proposal-in-identity fixture.

ZL256 0.13.0 proposal-in-identity fixture

The separately pinned proposal corpus promotes only optimize/proposal-in-identity, with 40 source/artifact cases under both native engines. The other 255 task manifests and their source pins remain unchanged. Task/12 retains the closed request/14 and evidence/3 profiles; this fixture allocates no further runtime or wire schema.

Authored observations cover scalar ranges, bounded products and tagged sums, proposal prefixes and their complements, exact preferences, gates, empty input, budgets, faults and the 256/257 proposal boundary. Four otherwise identical problems distinguish zero-length, one-entry and two differently ordered two-entry proposal lists in their semantic IDs. Empty and identity prefixes can have identical traversal while remaining different problem identities. Stable semantic-ID vectors supplement, rather than replace, the authored readouts, complete observation rows and cross-source identity comparisons.

The new catalog contains 100 verified, 23 executable and 133 scaffold tasks, with 988 cases. Synthesis/performance allocations remain 128/32, and this task remains ineligible for both. Older catalogs, sealed ZL512 import and default publication are unchanged. All 72 fixture mutants were killed on the private Linux Sprite at 83d84abc05534563761c03a661a5007ff88e4511, with no survivors, invalid mutants or equivalent exclusions. This is separate from the runtime 26/26 and process-boundary 7/7 campaigns.

At that revision, record-space and decision-nonescape remained scaffolded. The later typed-space and scalar Decision implementations are described above; the record fixture promotion below verifies the named-space slice separately.

ZL256 0.14.0 record-space fixture

The separately pinned record corpus promotes only optimize/record-space to verified revision 3. Its 48 cases cover source and artifact execution of named records, including Bool and mixed-width fields, with enum declaration-order contrast. Both engines retain exact types, selections, gate/fault prefixes, proposal order and all observations through the Task/13, request/15, evidence/4 boundary. Six invalid source problems have exact diagnostic expectations. The other 255 tasks and all earlier corpus pins remain unchanged; default publication and stable activation are not changed.

The catalog contains 101 verified, 23 executable and 132 scaffold tasks, with 1,034 cases. Existing synthesis eligibility is retained, not newly granted; this is offline conformance evidence rather than a model-quality or performance measurement. Fresh-pin fixture tests, adversarial oracle checks and forty generated permutation/relocation examples accompany the authored cases. The 55-control fixture mutation plan is separate from native typed-space and process-boundary campaigns. The executed fixture campaign caught 55/55 controls at 366f7991d2, with zero survivors, invalid controls or equivalent exclusions.

At that milestone, decision-nonescape fixture promotion and adaptation acceptance remained outstanding; both are covered in the later sections below. General nested records and nominal Decision handles remain outside the current bounded preview implementation.

ZL256 0.15.0 decision-nonescape fixture

The separately pinned Decision corpus promotes only optimize/decision-nonescape, preserving all other 255 tasks and earlier corpus identities. Its 54 source/artifact cases exercise fourteen successful body-local readout problems and thirteen exact ownership failures. The positive problems retain aliases, repeated readouts, exact preferences, gate/budget/fault prefixes and product/proposal order. Negative cases reject message, Result, borrow, stored-field and enum-payload escapes, along with mutable or forged handles and missing Optimize authority.

Both executors pass the authored cases. Independent oracles reject altered identities, fields and wire rows; forty generated examples check permutation and relocation. The separate fixture mutation campaign caught all 59 controls at 20644db3fc, with zero survivors or invalid controls. The catalog now has 102 verified, 23 executable and 131 scaffold tasks, with 1,087 cases. The Decision task remains ineligible for synthesis and performance, and the total allocations remain 128/32. No default catalog, release or stable activation changes.

That revision completed the six named fixture promotions; adaptation acceptance is covered in the next section. The current bounded Decision profile admits scalar readouts; nominal Decision readouts and arbitrary nested spaces are not claimed here.

Adaptation of sealed finite problems

Adaptive closure contracts now bind every reachable source-owned Optimize problem identity, including private package dependencies. Space order, named types, proposals, signal graphs (including Decision operations) and budgets cannot change during a modality conversion merely because an unrelated scalar replay passes. Such a candidate is rejected before the generation swap, with ZL_ADAPTIVE_ERROR_CONTRACT_CHANGED_V2; generation, lineage and prior evidence remain unchanged. Ordinary scalar replays remain required where supplied.

Optimize-bearing closures use zerglang.adaptive-closure-contract.v2 and zerglang.adaptive-closure-implementation.v2. Closures without Optimize retain their v1 identities, and the dispatch ABI, artifact minors and report formats are unchanged. The interpreter-only Optimizer.run boundary stays sealed; the owning Algorithm wrapper can change authoring modality. This does not grant LLVM execution to an interpreted dependency closure.

The additive public functions zl_adaptive_dispatch_optimizer_run_evidence_i64_v4 and zl_adaptive_dispatch_optimizer_run_evidence_v5 execute a public boundary reachable from the active dispatch root. They require the caller’s live optimizer and bounded observation ceiling. The former keeps scalar/coordinate receipts and the latter named-type receipts. Neither accepts an unrelated public boundary or silently erases a named candidate into scalar evidence. Owned reports remain readable through promotion, quarantine/fallback and dispatch/optimizer destruction; partial fault receipts retain the prior prefix. Successful executions count as one adaptive observation, while failed or partial executions do not increment the success counter.

Native coverage exercises sets, sums, products, enums and records under both executors, including source-artifact input and complete linked packages. Twenty generated package offsets check order, relocation, promotion and fallback invariance while changed preferences change problem identity. The adaptation mutation campaign caught all twelve controls at 6aaa8eb208, with zero survivors, invalid controls or equivalent exclusions. Its first two attempts stopped on noncompiling controls and are not complete scores. Native ASan/UBSan verification at 8ab62dd462 passed 205/205 selected test groups. The complete Optimize property suite passed 39 tests and six subtests. Full portable/LLVM gates are reported separately. Fixture campaigns also caught 55/55 record controls at 366f7991d2 and 59/59 Decision controls at 20644db3fc. These results do not activate stable Core-1 or widen the bounded preview.

Nominal and owned Decision follow-up (ZER5-233)

The 2026-09-09 audit leaves ZER5-233 dependency-blocked, not delivered. Its full acceptance includes nominal readouts, non-Copy transfer, reads after move and confinement through nested owned containers. ZER5-221, the named rich-owned-aggregate prerequisite, is still undelivered. The completed scalar Decision profile and nominal candidate spaces above remain supported; neither is evidence that nominal or general owned Decisions work.

Reproduced boundary

Public zlc check --edition=core-1 --preview=optimize --diagnostics=json probes used the clean archived compiler source at 3cf6d107e4b899500b0c79cd2461a87a866fa8b8 (version 0.1.1-preview.4, LLVM disabled), built with Apple Clang 17.0.0 on arm64 macOS. The audit worktree was b494233bc2; its only intervening change was Dynamic documentation.

Probe	Observed result
Fieldless `Choice` with `Space.enum(Choice)`	Accepted
Two-field `Pair` with `Space.record(Pair, ...)`	Accepted
Scalar Decision with an immutable alias and repeated readouts	Accepted
`Decision<Choice>` capturing the enum candidate	`ZL-OWN-0003`: `Decision requires one exact scalar readout type`
`Decision<Pair>` capturing `move(candidate)`	Same exact-type rejection, before capture/move checking
Ordinary stored `Box<Int64>` or `Array<Int64>`	`ZL-PARSE-0004` at the generic field type; not admitted owned carriers

The current native Decision, nominal and adaptation groups passed 27/27 with a 90-second per-test deadline, in 2.12 seconds. They cover the already admitted surfaces, including checked artifacts and package/adaptation evidence; they do not exercise successful nominal Decision readouts. An initial CTest filter selected no tests and is not verification; the corrected filter was ^runtime.core1_optimize_(decisions|nominals|adaptation)_, with --no-tests=error. Probe sources/results and the complete native output are retained locally under /private/tmp/zerglang-233-decision-audit.6onftK/.

Why scalar aliases cannot supply owned semantics

src/parser.c admits only a closed scalar type in a Decision declaration or capture. src/core1_optimize.c recognizes the same scalar spellings, and src/ir.c checks capture/readout using distinct scalar-kind-based Decision states. The frozen ZLM2 2.32 / ZLA2 1.24 descriptor allocates opcodes 43/44 to those exact scalar kinds and a single integer-word carrier. It has no nominal type reference, recursive owner layout or readout-consumption state.

The nominal-space extension is a separate contract: it validates a fieldless enum or a canonical two-field packed value, and exposes enum tags or two field words to the scalar signal boundary. Named receipt identity does not supply the missing Decision owner. Fieldless enums are structurally Copy, but user values are non-Copy; zl_ir_type_ref_is_owned classifies value descriptors as owned. Small or runtime-trivial fields do not authorize copying a record owner. Existing scalar aliases and repeated .readout operations therefore cannot be extended mechanically to all nominal values. Likewise, rejection of an unimplemented nested container does not prove recursive nonescape.

Conditions for resuming implementation

Retain ZER5-28 and all frozen scalar artifacts/corpus pins unchanged. An enum-only additive tranche is technically separable, but is not completion of this ticket’s record, wider-owned and nested-container acceptance.
Coordinate with the admitted ZER5-221 owner/layout tranche. Resolve capture, alias and readout transfer explicitly for non-Copy values, preserving named-owner move, use-after-move rejection and exactly-once cleanup on success and fault exits. Do not infer Copy from packed representation or introduce hidden allocation, implicit cloning or a borrowed readout.
Bind each new Decision to the exact nominal/instance identity, including package origin and declaration layout. Use an additive checked artifact allocation; do not reinterpret the old scalar opcode immediates. Source, package relocation and digest-valid artifact rechecking must agree.
Reject Decisions in parameters, results, fields, variants, Result, durable checkpoints and all newly admitted nested containers. Unwrapping may yield the admitted ordinary owned readout, never Search/Optimizer authority or a borrowed view that outlives the body.
Reproduce typed readouts and mismatched captures through public interfaces first, then implement both executors. Cover unused faulting captures, evaluation order, alias/consumption rules, empty and invalid cases, package reload, promotion/fallback receipts and retained reports. Add generated identity/relocation/nonescape properties and behavior-mapped mutations; timeouts and invalid controls are not kills.

This audit changes documentation only (the test-first/mutation exception), not the language, artifact allocation, runtime, benchmark promotion or stable activation. ZER5-233 remains in Icebox pending the ownership prerequisite and the complete acceptance work above.

Recursive finite-space follow-up (ZER5-232)

The 2026-09-09 audit leaves this implementation ticket in Icebox, dependent on ZER5-221’s admitted nested owned carriers. Arbitrary recursive spaces and their typed candidates are not delivered by the flat profiles. A recursive descriptor-only or scalar-only subset would not satisfy the named nested record, nominal-value and owned-receipt acceptance. ZER5-28 remains complete for its original bounded scope.

The parser’s leaf reader accepts only Space.set and Space.range. Product/sum parsing invokes it exactly twice, and record parsing invokes it for exactly two fields. zl_optimize_region_node_v2 stores two flat factors, not child descriptors; zl_optimize_space_count_v6 computes one sum or product of their counts. Each factor is bounded to 256 values. This makes the current arithmetic bounded, but is not a recursive cardinality/depth check.

The frozen product and sum allocations (ZLM2 2.29/2.30) store two 1040-byte leaf records. The nominal allocation (2.33) appends one nominal kind/reference to that flat space. V4 evidence has capacity for two coordinates, and V5 named evidence wraps those same coordinate observations with an owned declaration descriptor. Neither representation admits a recursive candidate tree. Merely raising the dimension constant or flattening nested values would change old artifacts/ABIs and lose branch structure or nominal ownership.

Reproduction and retained baseline

Public source probes used clean archived compiler 3cf6d107e4b899500b0c79cd2461a87a866fa8b8, version 0.1.1-preview.4, Apple Clang 17.0.0 on arm64 macOS, LLVM disabled. Worktree 7c073b08df differed only by the two intervening documentation commits.

Probe	Observed result
Two-leaf product and sum	Accepted
Product with an empty set factor; sum with two empty set branches	Accepted
Nested product; nested sum; sum inside product; enum factor	`ZL-OPTIMIZE-0001`: `Space.product requires two leaf Space.range or Space.set factors`
Duplicate proposal ordinals in an admitted product	`ZL-OPTIMIZE-0001`: `Optimization.propose requires distinct in-range candidate ordinals`
Record with a fieldless-enum field	`ZL-TYPE-0004`: `unsupported bounded Stage0 value form`

Nested-space probes retain the old two-argument signal signatures only to locate the first rejection: parsing fails before nested candidate typing. They do not propose a new nested-signal ABI. A separate two-record probe stopped earlier with ZL-NAME-0002 at the second value declaration; it is not evidence of a specific nested-field ownership check.

The existing set/product/sum/proposal/nominal native groups passed 47/47 in 2.16 seconds with --timeout 90 --no-tests=error and filter ^runtime.core1_optimize_(products|sums|proposals|spaces|nominals)_. Their source/artifact/package, order, gate, budget, empty and tamper checks verify only the existing profiles. Probe sources/results and native results are retained under /private/tmp/zerglang-232-space-audit.TJqOdv/.

Restart requirements

Admit the candidate owner/type layouts with ZER5-221 first or in explicit paired delivery. Keep nominal identity, field/variant order and owner transfer/drop rules through nested containers; do not reinterpret them as anonymous scalar coordinates.
Allocate an additive closed typed space descriptor and source/artifact profile, with explicit child references, checked cardinality arithmetic, depth/size/work limits and exact diagnostics. Reject cycles and malformed references before traversal; empty products/sums retain their typed shape and positions without evaluating signals.
Specify nested declaration order and first ties explicitly. Check proposal membership against the exact typed space and retain the source proposal order; reject duplicates and wrong nominal values without implicit deduplication, coercion or reordering.
Implement independent reference enumeration and batched execution, with equal ordered observations, separate budgets, fault prefixes and selected owned values. Add bounded, independently owned recursive receipt views and checked serialization; preserve every old descriptor, ABI and corpus pin.
Start with public behavioral failures, including nested records, empty branches, cardinality overflow, wrong nominal membership and maximum depth. Add generated order/identity/relocation properties, separately versioned corpus fixtures and behavior-mapped mutations. Baseline passes above are not substitutes for that acceptance evidence.

This is a documentation-only dependency audit, using the test-first/mutation exception. No recursive implementation, new schema, corpus promotion, publication or stable activation is claimed.

Rich signal and report follow-up (ZER5-231)

The 2026-09-09 audit leaves ZER5-231 in Icebox pending its named ZER5-227 first-class domain-result/host-boundary prerequisite. Structured signal lowering is additional work, not supplied by that prerequisite. The current typed nominal candidate receipts are not arbitrary typed Signal<Query, Observation> or ordinary source OptimizationReport<Readout> values. Delivering scalar branch evaluation alone would leave the ticket’s typed result, observation and sealed-evaluation outcome incomplete.

Public source/artifact observations

A local diagnostic harness used only zl_compile_source_v2, checked module serialization/deserialization, public signal execution and a live optimizer with zl_module_optimizer_run_source_i64_v2. Both executors were exercised before and after checked round-trip. It linked the clean archived library at 3cf6d107e4b899500b0c79cd2461a87a866fa8b8, version 0.1.1-preview.4, built with Apple Clang 17.0.0 on arm64 macOS, LLVM disabled. Worktree cd5699589b had only subsequent documentation changes.

Probe	Observed result
Pure `return item * item` with input -6	Both executors return 36, source and round-trip
`if (item < 0) { return -item; } else { return item; }`	Compiles and round-trips; both executors reject with `ZL-DOMAIN-0003`: `message has no dedicated checked scalar region`
Whole-body `return Optimizer.run(Problem.definition)`	Both executors select a candidate after two evaluations/four observations, source and round-trip
`let report: Int64 = Optimizer.run(...); return report;`	Compiles and round-trips; both public optimizer admissions reject with `ZL-OPTIMIZE-0002`: `selector is not a checked source-owned Optimizer.run boundary`
`Signal<Int64, Bool>` parameter or `OptimizationReport<Int64>` result	`ZL-TYPE-0001`: type does not resolve to a supported scalar or enum
Problem whose `follow` returns a named enum observation	`ZL-TYPE-0001`: problem signals require Bool gates and Int64 preferences

The local-Int64 probe locates the current whole-body adapter restriction; it does not propose Int64 as the type of a future first-class report. Likewise, successful source checking or serialization does not establish executability of a branch-bearing signal. Unsupported region admission clears the scalar output/report instead of executing the branch through an unrelated backend.

src/core1.c currently lowers straight-line scalar operations, bounded same-domain calls, scalar Decision locals and the nominal projections above. Unsupported operations leave no materialized scalar graph. Its recursive and batched evaluators operate on that closed graph; admitting source branches requires checked control flow and branch-local evaluation, not unconditional evaluation of both sides. src/core1_optimize.c separately requires Bool/Int64 problem observations and an exact two-instruction interpreted Algorithm Optimizer.run wrapper. C status/out-parameter report ownership is real, but does not make those reports composable source values.

The existing Optimize, identity, receipt and adaptation groups passed 16/16 in 3.00 seconds, with 90-second per-test deadlines. This includes the runtime observation wrapper’s three Python tests; it is not a new ZDE test campaign. Full native logs, diagnostic sources and corrected probe output are retained under /private/tmp/zerglang-231-signal-audit.22pA7J/. An initial diagnostic printer relied on the host’s null-string formatting on success; the retained corrected run explicitly prints empty optional diagnostics instead.

Requirements for resuming

Pair explicit, bounded source result/readout and host-handle ownership with ZER5-227. Define exact query/observation identities, success/error/empty carriers and cleanup; do not silently convert them to tags or Int64 values.
Add checked structured pure regions to both independent evaluators. Specify finite work bounds, branch-local faults, gate rejection, first ties and separate candidate/observation budgets before artifact allocation. Avoid evaluating untaken faulting branches or changing ordered observations when processing a batch.
Implement any permitted Algorithm/Compute/model evaluation through an explicit sealed pure boundary. C1-BOUND-005 is not permission for direct State/Flow mutation, live Intent calls, external solver side effects or ambient capability creation.
Preserve complete reachable implementation/type identity through package relocation, checked round-trips and adaptation. Reject malformed typed receipts even with refreshed digests, and retain owned fault-prefix reports.
Start with public behavioral failures and add empty/error/budget/reordered batch cases, generated identity/order properties and behavior-mapped mutations. Keep prior corpus and artifact meanings fixed. Extend the ZER5-241 canonical snapshot/ZDE projection and tests for any new first-class runtime state; its delivered bounded profiles alone do not cover new types.

This documentation-only audit uses the test-first/mutation exception. It does not widen the source/runtime contract, publish an ABI, or turn a selected sample, external solver success or finite-profile result into a general proof or global-optimality claim.