Core-1 previewnormative preview; stable Core-1 inactive

ZLM2 regions, typed identities, interfaces, and reflection.

Core-1 Checked Artifacts and Reflection

Status: normative preview

C1-ART-001 — New major. A Core-1 checked artifact begins with ZLM2. ZLM1 schemas, including schema 1.9, remain Core-0 and are never reinterpreted as containing Core-1 domains.

C1-ART-002 — Typed-message table. ZLM2 schema 2.14 contains one closed typed-message row per ordinary callable or portable semantic template. A row carries the v2 primary domain tag, optional canonical portable-instantiation set, declared effect set, explicit authoring modality, and closed region kind. Portable instances expand in canonical domain order and receive independent identities. Unknown tags, nonzero reserved bytes, a domain unavailable in the artifact’s cumulative preview, a mismatched region, malformed embedded checked semantics, or a failed artifact digest reject with ZL-MODULE-0003.

Schema 2.14 also carries one length-framed callable-origin entry per message. Public origins must equal the root module; imported private origins must equal the module component framed into their canonical linked selector. Missing, trailing, NUL-containing, mismatched, or noncanonical origin data rejects. This keeps package identity available even when the embedded Core-0 payload uses a legacy schema that did not encode callable origins.

C1-ART-003 — Region kinds. Region tags are algorithm CFG=0, compute dataflow/index=1, state transaction/dependency graph=2, flow history graph=3, and optimize problem/evidence graph=4. Each later preview must replace any shared-frontend placeholder with its checked region before claiming domain execution conformance.

C1-ART-005 — Checked semantic graph. Schema 2.14 carries a canonical, source-independent checked semantic node table and an ordered operand-edge table in addition to lowered regions. The graph omits locations, comments, and formatting. Its operation, ordered operands, type-context, scalar, and domain-region facts are digest-protected and participate in body identity. An operand either names an earlier node in the same callable or the canonical control-merge marker. A decoder independently rebuilds operand edges from the checked semantic operation stream and rejects disagreement before lowering executable IR from those authoritative facts. Interpreted execution reads this retained representation. An adaptive artifact is therefore sufficient input to an agent conversion even when original source text is unavailable.

The checked AST originates during parsing and remains authoritative through contract stripping, ownership cleanup insertion, package relocation, and domain-region lowering. It preserves source distinctions that scalar CFG lowering erases, including the logical-and and logical-or short-circuit operators. Nodes inserted by semantic elaboration, such as deterministic cleanup, are added explicitly to that table.

C1-ART-006 — Dedicated region tables. Schema 2.14 stores compute nodes in the closed tensor dataflow table, durable flow definition nodes in a flow table, finite optimization definitions in an optimize table, and the bounded state and standalone scalar-signal profiles in a distinct scalar graph table. Scalar rows contain a checked operation, input or predecessor node indexes, immediate, and scalar kind. Every predecessor is earlier in canonical order. Region offsets are domain-table-relative; an invalid operation, forward edge, input, output, scalar kind, reserved field, or domain/table pairing rejects. A callable with no materializable body records an empty region and is not executable through a typed domain boundary. Schema 2.7 adds scalar CALL nodes with zero, one, or two canonical predecessor arguments. The target is a closure-wide function index, must remain in the caller’s domain, and must itself have a scalar region; evaluation uses the common bounded call-depth law.

Compute-to-compute calls remain represented as ordinary typed semantic-AST calls and are inlined into the closed compute node vocabulary before ZLM2 is emitted. Package compilation repeats region lowering after selector relocation, so imported scalar call indexes and imported compute inlining are canonical for the complete linked closure.

Schema 2.8 adds the domain-specific semantic node kinds compute-fma and compute-reduce-sum. Their structural payload carrier remains an internal typed call so the embedded Core-0 artifact is not reinterpreted; the ZLM2 AST and compute region retain the distinct operation and therefore preserve strict numeric intent through reflection, identity, linking, and round-trip decoding.

Schema 2.9 adds state-transact. Its structural carrier names exactly one checked state transition, while the semantic node records that the call is an algorithm-to-state Store.transact boundary rather than a direct call. The carrier and target are checked and relocated as one closure; execution still requires a live store and cell authority supplied by the embedding runtime.

Schema 2.10 adds device-run. Its structural carrier names exactly one checked compute kernel, while the semantic node preserves the algorithm-to-compute boundary. Typed admission requires a live Device; erasing the boundary kind while retaining its carrier is non-canonical and rejects during decoding.

Schema 2.11 adds flow-activity and flow-engine-start. A dedicated flow row binds the durable node ID, typed activity target, source input, schema, retry limit, and deduplication policy. The source boundary requires live FlowEngine authority. File-journal start records bind a canonical definition node digest, so restart attachment with different inputs or policies rejects.

Schema 2.13 adds parser-originated logical-and and logical-or nodes while retaining optimization-problem and optimizer-run. A dedicated optimize row binds problem identity, typed hard-gate and preference signals, and separate candidate and observation budgets. The source boundary requires live Optimizer authority and returns the ordinary canonical evidence report.

Schema 2.14 adds the ordered operand-edge table and checked-AST JSON schema 4. Its Flow rows use the formerly reserved tail to distinguish a run-argument input from an earlier durable node result and to name that predecessor. The closed Flow node kind also distinguishes typed activities, timers, and signal waits; timer durations may depend on earlier nodes, while signal schemas are bound directly in the row. Schema 2.13 remains accepted without reinterpretation; its operand edges are reconstructed and checked from its canonical semantic nodes and structural payload, and re-encoding a decoded 2.13 artifact preserves schema 2.13 bytes.

Schema 2.15 activates the Optimize row’s finite-space tail. A zero count retains the host-supplied legacy preview space; a nonzero count binds one source-owned inclusive Int32-bounded range as its signed lower bound and canonical value count. Only source definitions that use Space.range select 2.15. Schemas 2.13 and 2.14 retain zero reserved bytes and are accepted and re-encoded without reinterpretation.

The C1-LIFE-003 aggregate tranche is executable from checked source but is not representable by ZLM2 schemas through 2.15, because their embedded algorithm payload is limited to the Core-0 schema-1.8 value form. Serialization therefore rejects it with ZL-MODULE-0003; it must never relabel multiple fields as ZLM1 1.8. A later ZLM2 minor must add a logical aggregate region and round-trip vectors before adaptive or package-artifact use is admitted.

Schema 2.16 supplies that representation for the bounded aggregate tranche. Its algorithm payload begins with ZLA2, not ZLM1, and is accepted only inside a digest-valid ZLM2 2.16 envelope. ZLA2 retains declaration-order field records, variable-arity value construction, exact field ordinals and scalar annotations, owned paths, and cleanup edges. Its 1.8 physical-layout version is a ZLA2 layout number and does not reinterpret ZLM1 schema 1.8. Standalone ZLM1 readers reject ZLA2, schemas through ZLM2 2.15 continue to embed canonical ZLM1, and only a module requiring C1-LIFE-003 selects 2.16.

Schema 2.17 extends the digest-protected ZLA2 algorithm payload with inner layout 1.9 for C1-LIFE-004. The function type table preserves exact Ref<T> parameter spelling while retaining T’s nominal declaration reference. A BORROW_SHARED operation names one exact argument/local owned place; its canonical scalar annotation is empty, and its result is accepted only by an exact synchronous Ref<T> call parameter. Borrow results cannot be stored or returned, borrowed parameters create no owned path or cleanup edge, and field projections through them remain nonconsuming.

The parser-originated checked graph records this operation as a borrow node. Decoding independently verifies the owner type, place kind, initialization, borrow/result type, and call use before rebuilding executable IR. ZLA2 inner layout 1.9 is accepted only inside ZLM2 2.17; standalone ZLM1 remains capped at schema 1.8, while ZLM2 2.16 and all earlier artifacts retain their exact bytes.

Schema 2.18 admits C1-LIFE-005 and embeds ZLA2 inner layout 1.10. The existing function-local type table may now name an immutable Ref<T> local. Admission independently reconstructs its exact BORROW_SHARED initializer, direct-call uses, straight-line extent, origin place, and the absence of an origin move, replacement, or drop before the final child call. The local creates neither an owned path nor a cleanup edge. Inner layout 1.10 is accepted only in ZLM2 2.18; inner 1.9 and outer 2.17 retain the direct-argument-only rule.

Schema 2.19 admits C1-LIFE-006 and embeds ZLA2 inner layout 1.11. A FIELD_GET_COPY may name a function-local Ref<T> place only in this layout, must select an immutable scalar field declared by exact T, and extends the reconstructed loan interval through that projection. Inner layout 1.11 is accepted only in ZLM2 2.19. ZLM2 2.18 / inner 1.10 retains lexical direct-call use without lexical field projection.

Schema 2.20 admits C1-LIFE-007 and embeds ZLA2 inner layout 1.12. Admission requires the lexical borrow initializer to precede every branch, verifies that every jump target is strictly forward, and reconstructs one conservative loan interval through the latest checked call or projection use. Inner layout 1.12 is accepted only in ZLM2 2.20. ZLM2 2.19 and earlier continue to reject any control edge in a function containing a lexical shared-view local.

C1-ID-001 — Contract identity. A typed-message v2 contract identity is domain-separated SHA-256 over framed canonical facts including module, owner, the owner’s ordered public field-schema identity when present, selector, cumulative preview, domain, effects, parameters, result, and callable kind. Formatting, source trivia, modality, and execution tier do not participate. A domain change always changes the identity.

C1-ID-002 — Body and implementation identity. A body identity hashes the contract identity, authoring modality, canonical checked semantic nodes and operand edges, and every behavior-bearing dedicated-region fact. Flow policy, typed activity targets, Optimize budgets and signal targets, scalar graph facts, and Compute numerical profiles therefore change body identity. An implementation identity additionally names the materializer or checked interpreter. Reflection exposes all three identities; the historical v2 semantic_id field is an exact compatibility alias for contract_id.

C1-IFACE-001 — Versioned interface. A Core-1 generated interface uses zerglang.interface/4, names its cumulative preview, and emits every callable’s exact domain and canonical effect set. The v1 interface API rejects Core-1 modules rather than printing algorithm. Interface/3 also prints every message’s explicit authoring modality.

C1-REFL-001 — Versioned reflection. Core-1 reflection uses zerglang.semantic/4 and exposes preview, domain, effects, typed-message identity, and region kind. The v1 reflection API rejects Core-1 modules. Reflection additionally exposes modality plus contract, body, and implementation identities.

C1-ART-004 — Admission. Generic algorithm entry APIs admit only algorithm messages. Non-algorithm messages require their explicit typed runtime boundary, even if their current implementation uses an algorithm-shaped scalar CFG.

Projected fromspec/editions/core-1/checked-artifacts-and-reflection.md