Logical tables, separated identities, public projections and staged encoding.
Core-2 Checked Artifacts and Identities
Status: normative preview; ZLM3 3.0–3.4 declaration inspection and the explicit source-resolved 3.5 combinational tranche; stable Core-2 inactive
C2-ART-001 — Major family. ZLM3 is a new checked-artifact major. It neither
extends accepted ZLM2 bytes in place nor changes ZLM1/ZLM2 interpretation.
Logical schema zerglang.zlm3.logical/1 describes the checked graph below;
it is not a binary wire format. Every graph binds edition, cumulative preview,
source/interface dependency closure and feature requirements. A consumer must
reject an unknown major, unsupported minor, unsupported required feature or
inconsistent preview before execution. C2-ART-009 through C2-ART-011 allocate
minors 0–4 for declaration inspection only. C2-ART-012 separately allocates
source-resolved combinational execution in minor 5; no other executable ZLM3
minor or standalone graph loader is activated.
C2-ART-002 — Logical tables. All records have a unique table-local ID and
typed references. Name is an inherited checked identifier or qualified
symbol. Ref<T> identifies a row in table T; Digest identifies immutable
content together with its identity domain and format version. Expr is a
typed pure expression DAG or an inherited checked software region. No record
contains a pointer, credential, live capability or opaque executable string.
| Table | Required logical fields beyond ID |
|---|---|
| types | kind, nominal identity or primitive width/dimension/shape, type arguments, ownership and boundary requirements |
| components | symbol, modality, static parameters, port schema, regions, instances, public observations, constraints |
| ports | owner, name, direction, type, declaration ordinal, clock/reset/bridge association |
| nets | owner, name, type, drivers, optional resolution law |
| instances | owner, name, component reference, parameter values, ordered port bindings |
| drivers | region, target bit range, expression or process reference, resolution membership |
| processes | region, activation, read set, write set, state equations, event law |
| clock domains | owner, name, source, edge, reset source/polarity/mode, release bridge, constraints |
| regions | owner, name, discipline, initialization, clocks, delay/hazard assumptions |
| bridges | definition digest, typed endpoints, regions/domains, transfer law, state, uncertainty, timing |
| constraints | owner, name, typed predicate/law, support, assumptions, applicability |
| observations | owner, name, type/units/frame, support, phase/time/frequency, expression, allowed error |
| models | symbol, parameters, mesh/field/material/equation references, conditions, analyses, couplings, public observations and dependency identities |
| meshes | owner, frame, coordinates, topology rows, element definitions, regions/boundaries/interfaces |
| mesh topology | mesh, entity kind, stable ID, ordered connectivity, orientation, membership |
| dimensions | reduced seven-exponent vector, quantity kind, canonical unit conversion |
| fields | owner, name, dimension, shape/frame, mesh/support, location, function space |
| materials | owner, support, definition digest, parameters, constitutive relations, validity range |
| equations | owner, name, strong/weak kind, expression, bound variables/test space, support |
| operators | typed operand/result signatures, mathematical definition digest, regularity assumptions |
| conditions | owner, name, initial/boundary/interface/source kind, support, law |
| analyses | owner, name, kind, unknowns, independent variables, conditions, acceptance contract |
| couplings | member analyses, exchanged fields, projections, orientations, synchronization/convergence law |
| realizations | symbol, refined contract digest, implementation reference, profile, claim, observation map |
| claims | kind, original contract allowance, scope, norm/bound or statistical policy |
| targets | family/part/package/speed grade, feature manifest, implementation constraints |
| physical instances | target digest, issuer-scoped device ID, device revision, enrollment identity |
| solver plans | model/analysis identities, solver meshes, discretization, operators, methods, resources, acceptance |
| evidence | subjects, claim, checker/tool identities, inputs, assumptions, results, applicability, provenance |
| lineage | subjects, parent identities, generator/source/tool identities, transformations and receipts |
| promotions | contract, admitted realization, implementation/target/plan/evidence digests, previous selection, result |
Model declarations own their mesh/field/equation/analysis records. Type tables also retain inherited software nominal contracts and region references. A software realization must preserve those records’ original semantic laws.
C2-ART-003 — Canonicalization. Normalize names using inherited lexical rules and order symbols by UTF-8 byte order. Tables appear in the order above; rows sort by qualified owner, declared name and local ordinal, with duplicate keys rejected. Simultaneous next-state assignments sort by target identity. Ordered ports, connectivity, activation traces and observation sequences retain their semantic order. Unordered sets sort by typed identity; effect sets retain their edition order. Expression DAG nodes are topologically ordered, breaking independent ties by structural content, with bound variables represented by binding position rather than incidental local spelling. Integers are mathematical signed integers, dimension exponents are reduced rationals with positive denominator, and quantities retain their declared precision/rounding model. No tolerance-based float equality participates in canonicalization. NaN/infinite model constants are rejected. Source spans, comments, display units and pretty-print choices are ancillary metadata.
Canonicalization does not sort ordered behavior, merge distinct mesh entity IDs, simplify equations algebraically, or reorder floating-point operations. Equivalent mathematics may have different body identities. The common record layout below fixes scalar and row framing, selected by C2-ART-009 for minor 0. Canonical logical comparison is available before semantic hashing and must not be advertised as an interoperable contract hash.
C2-ID-001 — Identity domains. Each identity includes its kind and schema version in its preimage. Distinct kinds must never share an untagged digest namespace. A binary tranche must publish the exact framing and hash algorithm before reporting interoperable digest values. The logical dependency law is:
| Identity | Semantic inputs |
|---|---|
| contract | public nominal identity, types, domain, effects, observations, assumptions and allowed latitude; physical model equations/declared mesh/material laws when these are the contract |
| body | checked software/circuit/model structure, modality, regions, private equations and implementation constraints |
| realization | refined contract, implementation body, profile, claim and observation map |
| implementation | realization, materializer/toolchain, backend choices, target and generated body/netlist/plan |
| target artifact | exact netlist/bitstream/output bytes plus kind and target/tool bindings |
| physical instance | issuer-scoped enrolled device identity and hardware revision; measurements reference this identity |
| solver plan | model/analysis, generated meshes/projections, discretization, solver/method choices, tolerances/resources |
| evidence | exact subjects, claim, checker inputs/results and validity envelope |
| lineage | source/generator/parent/transformation records and execution receipts |
Changing target-specific implementation facts does not change the original portable contract unless that contract explicitly contains those facts. Changing an intrinsic contract’s public target/envelope does change its contract. Changing a physical model’s declared mesh changes its model contract; changing only a derived solver mesh changes the plan. Appending evidence does not alter its subject. Realization cycles are rejected, including cycles through imports.
C2-ID-002 — Exact identity framing. The identity-framing feature fixes
one interoperable SHA-256 preimage envelope independently of subject-specific
semantic encoders. All fields use unsigned little-endian encoding, with no
padding, native struct layout or trailing bytes:
| Offset | Bytes | Field |
|---|---|---|
| 0 | 24 | ASCII zerglang.core2.identity followed by one NUL |
| 24 | 2 | framing version, exactly 1 |
| 26 | 1 | domain tag, 0 through 8 in C2-ID-001 table order |
| 27 | 1 | reserved, exactly 0 |
| 28 | 4 | format-label byte length N, 1 through 127 |
| 32 | 8 | subject-payload byte length P, 0 through 8388608 |
| 40 | N | canonical ASCII subject-format label, no terminator |
| 40 + N | P | exact subject-payload bytes |
Format labels match [a-z][a-z0-9.-]*/[1-9][0-9]* and are not normalized.
The first portion names the payload schema; the decimal suffix versions that
schema independently of this envelope. The digest is SHA-256 over every byte
of the complete preimage. Malformed length fields, reserved flags, unknown
domains, invalid labels, truncation and trailing bytes reject. Unimplemented
framing versions and exceeded supported bounds are unsupported.
An identity is the complete tuple (domain, framing-version, subject-format, digest), not bare hash bytes. Tuple comparison validates its metadata before
comparing. Integrity verification checks the exact frame and recomputes its
digest; it does not authenticate the producer or validate the subject’s
semantics. A valid envelope in the physical-instance or evidence domain is
not an enrolled device or passed evidence. Unknown subject formats can be
framed as opaque data but cannot be admitted without a matching checked encoder.
The pure API emits zerglang.identity/1 with checked: framing-only,
subject_admitted: false, and authority: false. Format-specific producers
must independently fix their full semantic closure, canonical order and
dependency inputs before claiming contract/body/etc. identities. Existing
Core-0/Core-1 identities and native simulation fingerprints are not relabeled
or rehashed as portable semantic identities by this feature. This preimage is
not a ZLM3 executable frame and does not enable interface/5 or semantic/5.
The API, exact vectors and resource limits are in
docs/core2-identities.md in the repository.
C2-ID-003 — Bounded component semantic encoders. The
component-identities feature admits a public, statically specialized,
acyclic combinational component closure through the reference combinational
model checker before encoding. It supports named hierarchy, static Index
arguments, two-/four-state wire types, continuous connections and total
combinational processes. Every named observation, clock/state/bridge,
inout port or resolved net in the closure is unsupported in this tranche.
Unknown assumptions and constraints remain rejected by elaboration; the
separate C2-REAL-007 source realization proposals are not circuit behavior
and do not enter either component identity. This is not proof of software
equivalence, synthesis eligibility or permission to execute.
Contract and body use C2-ID-002 framing with kinds 0 and 1 and subject formats
component-contract/1 and component-body/1, respectively. Each subject is
the exact compact ASCII JSON payload below, with no whitespace, newline or
terminator in the hashed length. Object keys follow the specified order.
Strings contain checked ASCII identifier segments, dot-qualified paths,
closed type/operator names or canonical unsigned decimal digits; no escaping
or Unicode normalization is necessary. JSON booleans/null are lowercase.
Widths and ordinals are nonnegative JSON integers without leading zeros;
static values and expression constant values are unsigned decimal strings.
An independently owned C buffer additionally has a NUL outside its length.
The contract object has ordered keys schema (zerglang.component-contract/1),
symbol (public qualified component), domain (hardware), parameters,
ports, observations ([]), assumptions ([]), and latitude (null).
Parameters are the root’s complete named specialization, sorted by name;
each object has name, value. Ports retain declaration order; each object
has name, ordinal (zero-based), direction (in or out), and type.
Wire type objects have kind, width; kind is Bit, Bits, Logic,
LogicVector, or nominal Bool. Clock/reset associations are absent only
because this admitted profile forbids them. Port observations retain exact
wire semantics; empty extra observations/assumptions and null latitude do not
authorize approximation or invent a physical propagation bound.
The body object has ordered keys schema (zerglang.component-body/1),
root (qualified root instance), instances, parameters, regions,
signals, processes, and drivers. All arrays include the entire elaborated
closure, not just public rows. The first five arrays sort by qualified path;
all named objects start with ordered path, owner keys. Owner and region
references are full qualified paths, or explicit null where absent.
| Body array | Remaining ordered keys |
|---|---|
| instances | component (qualified declaration), modality (compiled or interpreted), public (boolean) |
| parameters | value (specialized Index string) |
| regions | discipline (combinational) |
| signals | region, type, direction (local, in, out), ordinal (null for local, declaration ordinal otherwise), storage (wire), resolution (null) |
| processes | region, guard (expression) |
Drivers are an unordered multiset sorted by their complete canonical JSON
bytes; multiplicity is preserved. Each driver has ordered owner, target,
region, process (path or null), expression. No incidental driver ID or
anonymous expression name is retained. Expressions are inline structural
trees with ordered op, type, value, signal, operands keys. Constants
retain their exact checked value string, null signal and no operands;
reference leaves have null value, the referenced signal path and no operands.
Other nodes have null value/signal and their one or two operands in original
order. Operators follow the admitted reference combinational vocabulary;
no algebraic reassociation, constant folding beyond checked elaboration,
commutative sorting or anonymous-node spelling enters this encoding.
Four-state scalar constant codes are 0, 1, 2 (X), 3 (Z); width/type remain
explicit. Parameter constants already reduced by elaboration retain their
specialization in the parameter arrays as well.
Source file paths, spans, comments, anonymous record indexes, declaration order of independent named rows/connections, simulation limits, native model fingerprints, receipts, evidence and live authority are not inputs. Ordered ports and operand order are inputs. A body-only wiring/modality change leaves the public contract unchanged. A public symbol, port schema or named static specialization change changes the contract and the corresponding body facts. Unused declarations outside the instantiated closure are not dependencies.
Each payload is bounded to 8388608 bytes. Preparation retains the existing checked model’s resource admission; its limits control success, never hash contents. Encoding additionally permits at most 65536 expression visits across process guards and drivers, with depth at most 256 (root depth zero). The sum of intermediate canonical driver byte lengths is bounded to 8388608. Bound exhaustion/allocation failure is unsupported and publishes no partial identity. Public typed views own symbol, identities and ordered ports; they never retain source/model lifetimes or create a Simulator capability.
These encoders allocate no new ZLM3 minor and do not reinterpret old native
simulation fingerprints, Core-0/Core-1 IDs, or interface/semantic versions
1–4. General observations, temporal/intrinsic/physical contract encoders and
projection/5 remain separately gated. The API and validation examples are in
docs/core2-component-identities.md in the repository.
C2-ID-004 — Portable scalar realization identity. The
scalar-realization-identities feature consumes a checked C2-REAL-008 proposal
and its actual hardware graph/preparation context. It reconstructs and compares
the native model pin and implementation symbol before invoking C2-ID-003’s
component encoders. Source and generated paths therefore share one checked
producer. Only the pure scalar/combinational C2-REAL-006 relation is admitted;
identity construction does not discharge any of its pending obligations.
The identity is C2-ID-002 kind 2, format scalar-realization/1, over compact
ASCII JSON with the following ordered keys. Formatting and numeric spelling
follow C2-ID-003. The payload length excludes the owned C terminator.
| Key | Exact value or ordered structure |
|---|---|
| schema | zerglang.scalar-realization/1 |
| symbol | qualified public realization symbol |
| refined_contract | symbol, format (core1-typed-message/2), sha256 (unchanged original Core-1 contract ID) |
| implementation | symbol, contract (C2-ID-003 contract tuple), body (C2-ID-003 body tuple) |
| profile | combinational |
| claim | kind (exact), allowance (null) |
| observations | law (serial-settled-scalar-call/1), rows |
Identity reference tuples have exactly ordered domain, framing
(zerglang.core2.identity/1), format, sha256 keys. Policy/status flags are
not tuple members. The original Core-1 contract is explicitly in its legacy
format; it is neither reframed nor relabeled as a new Core-2 contract.
Observation rows are parameter-ordinal order followed by the single result.
Each has ordered role (parameter or result), parameter (original ordinal
or null for result), parameter_name (original name or null for result),
software_type, port (qualified root port), wire_type (kind, width), and
encoding. Encodings are twos-complement/1, unsigned-binary/1 and
boolean-bit/1, with the original exact type/width/role constraints. No source
constraint display names, source positions or row input ordering are included.
The logical refinement edge does not include the old native execution model fingerprint, preparation limits, baseline software body, generator lineage, checker result or appended evidence. Changing the circuit body, original contract, realization symbol or observation mapping changes the appropriate edge identity. Rebinding an unchanged logical edge to a new baseline body or new preparation limits can preserve this identity, but cannot reuse evidence by identity alone. The exact baseline body and native model context remain separate mandatory subjects for any proof that depends on them; C2-EVID-003 invalidation applies. An old proposal cannot be attached directly to another native model/context even if a later portable body comparison could agree.
zerglang.realization-identity/1 inspection has ordered keys schema,
checked (typed-proposal-only), identity (tuple), proposal (the complete
semantic payload), evidence_context, refinement_verified,
promotion_admitted, authority, and physical_evidence. All four flags are
false. Evidence context has ordered baseline_format (core1-typed-message/2),
baseline_body_id, native_model_format (zerglang.combinational-model/1),
and native_model_id. These are dependency pins, not passed evidence records.
Changing that context changes inspection bytes without necessarily changing
the logical edge. Up to 32 parameters plus one result are admitted; payload
and inspection bounds are 65535 and 131071 bytes respectively, each plus an
owned terminator. Unknown/missing inputs, stale contexts and exhaustion fail
without publishing a partial identity. No binary minor, proof, promotion,
capability or interface/semantic projection version is activated here.
C2-ID-005 — Bounded netlist implementation identity. C2-HW-005’s canonical zerglang.combinational-netlist/1 payload is a distinct implementation subject, using C2-ID-002 kind implementation (tag 3), format combinational-netlist/1. It binds exact original component contract/body identity tuples, the closed lowerer semantics and the complete lowered typed signal/node/driver tables. It does not replace the component contract or body ID. Bit and Bits<1> remain nominally distinct even where their emitted RTL storage has equal width.
Source formatting, file labels, source spans and preparation limits do not enter this implementation identity; they may change the separate source map. Semantic component/body or lowered-node changes do change it. No source-map bytes, own implementation digest, target artifact, toolchain execution, evidence or physical instance is included in this subject’s preimage. Those retain separate identities and lineage. The lowerer identifier denotes versioned semantics, not an attested toolchain binary. Matching this hash is not proof or promotion; there is no untrusted netlist loader in this tranche. Exact payload/source-map field order and RTL text rules are in docs/core2-netlist.md in the repository.
C2-IFACE-001 — Public projections. zerglang.interface/5 exposes public
software contracts, component port schemas, physical model contracts and
declared realization claims with typed references. zerglang.semantic/5
exposes the checked logical tables, observations, feature requirements and
separated identities. Public reflection reports capability requirements, never
live authority. Evidence may be access-restricted; public projections state
availability and digest without publishing private device IDs or measurements.
An interface alone never grants execution or asserts promotion. Versions 1–4
retain their existing meanings; consumers must explicitly support version 5.
C2-IFACE-002 — Checked component-contract projection. The first supported
interface/5 profile is component-contract/1, scoped to exactly one public
component specialization, not a complete module. It may be emitted from a
C2-ID-003 checked component identity and consumed with an independently supplied
full expected contract tuple. Both paths use the same validation gate. This
profile contains no implementation body, realization, physical model, private
hierarchy, source location, live capability or passed evidence.
Canonical JSON has exactly these keys, in this order:
| Key | Required value |
|---|---|
schema |
zerglang.interface/5 |
edition |
core-2 |
preview |
hardware-preview (minimum preview; cumulative physics-preview consumers also accept it) |
profile |
component-contract/1 |
scope |
Ordered kind = component, ref = ordered table = components, id = 0 |
requires |
Exactly ["component-contract/1"] |
components |
Exactly one row, ordered id = 0, identity, contract |
capability_requirements |
[] |
evidence |
Ordered availability = not-included |
executable |
false |
promotion_admitted |
false |
authority |
false |
The identity tuple has ordered domain = contract, framing =
zerglang.core2.identity/1, format = component-contract/1, and sha256
(64 lowercase hexadecimal digits). The contract is the exact C2-ID-003 payload.
Parameters are distinct named uint64 Index specializations in ascending name
order, with canonical unsigned decimal string values. Ports retain
declaration order and matching zero-based ordinals, distinct names, in/out
direction, and nominal Bit, Bits, Logic or LogicVector types. Scalar widths
equal one; vector widths are positive. Bool is an expression type, not an
admitted port type. Parameters and ports share a collision-free namespace.
The qualified module/component symbol and member names must form a valid
source declaration; contextual identifiers use the existing source grammar.
Observations and assumptions are empty arrays; latitude is null. Empty
parameter/port lists are valid. Loading a declaration neither requires nor
invents an implementation, driver coverage, simulation state or equivalence.
The reader recomputes the C2-ID-002 digest from the canonical contract payload and compares the full tuple against both the embedded declaration and the external expectation. A matching digest is not authentication, proof, promotion or execution authority. Missing evidence in this projection says nothing about evidence elsewhere; access-restricted evidence projection is a later profile, not permission to insert private measurements here.
Transport is exact ASCII canonical JSON in the field orders above/C2-ID-003: no optional fields, insignificant whitespace, alternative escapes or trailing newline/padding/NUL. An owned C terminator lies outside the reported byte length. Readers reject duplicate/unknown/missing keys, alternate key order, malformed references, bad types, invalid names, noncanonical numbers, hash mismatches and unsupported closures. Source formatting/comments remain identity-invariant; that does not permit multiple canonical artifact encodings.
Bounds are 8388608 input/output bytes, 8192 entries in each parameter/port list,
1023 ASCII bytes per qualified symbol with segments/member names at most 127,
and 1048576-bit widths. The shared reader allows 131072 JSON nodes, nesting
depth 96, 67108864 arena/output bytes and 32000000 work units. Declaration
checking additionally uses the bounded Core-2 source parser and a synthesized
declaration at most 1048576 bytes. These limits are cumulative; satisfying
one does not guarantee admission under the others. Reflection allocates no
width-sized signal vectors. Unknown profiles/features and exhaustion report
ZL-C2-UNSUPPORTED-0001; invalid known-profile transport/expectations report
ZL-C2-ARTIFACT-0001; invalid API pointers/ordinals report ZL-OPTIONS-0001.
Existing preview/options diagnostics remain unchanged. Failed reads publish
no object. Views, port/parameter queries and serialized bytes are owned copies.
Positive vectors include wire/inverter contracts with identical interface bytes, relocated source, empty components, all four nominal wire types and uint64 endpoints. Negatives include every truncated transport, changed digest, wrong expected identity domain, rehashed duplicate names/ordinals, unsupported Bool ports, nonempty capability claims and any true execution, promotion or authority flag. Versions 1–4 and default public APIs retain their meanings. This opt-in API does not enable general compiler /5 output, semantic/5, a binary minor or stable Core-2.
C2-IFACE-003 — Checked-context component semantic projection. The first
semantic/5 profile is component-combinational/1: a checked public root
contract and its complete C2-ID-003 combinational implementation closure.
Unlike C2-IFACE-002, it contains private circuit structure and must not be
published where only the public interface is authorized. Source file paths
and spans remain excluded. This is inspection, not an executable loader.
Canonical JSON has ordered keys schema = zerglang.semantic/5,
edition = core-2, preview = hardware-preview, profile =
component-combinational/1, scope, requires, components,
contracts, bodies, observations, capability_requirements,
evidence, executable, promotion_admitted, and authority.
Scope is ordered kind = component and ref = ordered table = components,
id = 0. Requires is exactly ["component-contract/1","component-body/1"].
The three projection-local tables contain exactly one row each:
| Table | Ordered row fields |
|---|---|
| components | id = 0; contract = {table: contracts, id: 0}; body = {table: bodies, id: 0} |
| contracts | id = 0; identity = complete contract tuple; contract = C2-ID-003 contract payload |
| bodies | id = 0; identity = complete body tuple; body = C2-ID-003 body payload |
Each reference has ordered table then id; row IDs are local to their table.
Identity tuples have ordered domain, framing, format and sha256, as in
C2-IFACE-002, with body domain/body format component-body/1 where applicable.
The body payload retains its canonical instances, parameters, regions, signals,
processes and drivers, including expression operand order. It is not an
unallocated binary record table. Observations and capability requirements are
empty arrays, evidence is {availability: not-included}, and all three flags
are false. This scope claims no whole-module completeness, software/model
reflection, realization evidence or target facts.
Construction requires an actual immutable checked component identity from C2-ID-003 and successful C2-IFACE-002 contract admission. Loading requires that same kind of checked expected component context, not only external hashes or JSON declarations. The gate recomputes the entire canonical projection from the expected component’s admitted payloads and compares exact length and bytes. It cannot create a new executable graph from transport. Thus a self-consistent, rehashed substitute body still fails against the selected checked dependency; consumers must first obtain an independently checked component by the normal source/elaboration/semantic gates. Independent loading from hashes alone is not supported by this profile.
Source relocation/comments, equivalent canonical construction ordering and simulation preparation limits do not change these bytes. Meaningful body changes change the body tuple/projection while potentially preserving its contract and C2-IFACE-002 public export. The public-export API returns the separately checked interface bytes, never a filtered copy that could retain private body records.
The C2-ID-003 and C2-IFACE-002 input bounds remain mandatory. Transport has at most 16781312 bytes; contract/body payloads each retain their 8388608-byte bound. Owned copies may add a terminator outside reported lengths. Build/load, view, complete JSON, selected contract/body payload and public-interface export are owned and bounded; failures publish null/zero outputs. Byte mismatches, including unknown/altered schemas or profiles, use ZL-C2-ARTIFACT-0001 in this expected-context loader. Unsupported context/bounds use ZL-C2-UNSUPPORTED-0001; missing pointers or invalid selectors use ZL-OPTIONS-0001. Existing preview diagnostics remain unchanged; explicit cumulative physics-preview also admits this hardware-only scope without claiming physical-model support.
Positive vectors cover empty components, ownership after input destruction, relocation and public/private identity separation. Negative vectors include truncated/noncanonical bytes, wrong actual body with the same contract, rehashed body replacement, altered typed references, evidence claims and true authority/promotion/execution flags. No binary minor, default /4 API, source execution path or stable activation changes.
C2-IFACE-004 — Scalar realization claim and proposal projections. The
realization-projections feature exports two expected-context profiles:
interface/5 with scalar-realization-claim/1 for the public proposed relation,
and semantic/5 with scalar-realization-proposal/1 additionally retaining
the exact baseline/native execution context. Both require an actual checked
C2-ID-004 scalar realization identity. Neither is a proof, a promoted
implementation, a whole-module projection or an executable artifact loader.
Canonical JSON has ordered keys schema, edition, preview, profile, scope,
requires, realizations, evidence_context, capability_requirements, evidence,
refinement_verified, promotion_admitted, executable, authority, physical_evidence.
Schema is zerglang.interface/5 or zerglang.semantic/5 respectively.
Edition is core-2 and minimum preview is hardware-preview; explicitly selected
cumulative physics-preview also consumes this hardware-only scope.
Scope has ordered kind = realization and ref = {table: realizations, id: 0} in that reference field order. Requires is exactly [“scalar-realization/1”] for the public interface; semantic adds “realization-evidence-context/1” second. Realizations contains exactly one row with ordered id = 0, identity, proposal. Identity is the complete ordered C2-ID-004 tuple (domain, framing, format, sha256); proposal is its exact canonical hashed payload. The unchanged original software contract and separate portable component contract/body references retain their original identity domains and formats.
Public evidence_context is null: neither baseline-body nor native-model dependency pins are published. Semantic evidence_context has ordered baseline_format = core1-typed-message/2, baseline_body_id, native_model_format = zerglang.combinational-model/1, native_model_id, with the exact lowercase-hex dependency pins from the checked identity context. Capability requirements are []; evidence is {availability: not-included}. All five status flags are false. A proposed exact claim does not mean that its baseline or hardware satisfies the relation.
Fresh source/generated binding paths with the same checked relation and context produce identical projections. A baseline-only change, or rebinding under different preparation limits, may preserve the logical edge and public claim bytes while changing semantic context bytes. A successful public projection comparison therefore never validates or authorizes reuse of evidence. Semantic comparison must also match the exact context. Changing the actual circuit body or observation map changes the logical realization and both projections. Generator provenance remains separate.
Projection verification requires an actual checked expected identity and an explicit projection kind, regenerates canonical bytes through the same producer, and compares exact length/content. It accepts no caller JSON or raw digest as a substitute for semantic admission. Unknown/changed schemas, profiles, references, context, hashes, flags, alternate whitespace and trailing/truncated bytes fail ZL-C2-ARTIFACT-0001. Missing pointers/invalid kinds fail ZL-OPTIONS-0001; unsupported contexts and bounds fail ZL-C2-UNSUPPORTED-0001; preview diagnostics retain their existing meanings. The C2-ID-004 payload bound remains mandatory; total projection input/output is bounded at 135168 bytes. Owned buffers may add a NUL outside length and survive destruction of input owners. Failure returns no partial bytes.
Positive vectors cover source/generated and map-order equivalence, unchanged public claims under baseline/native-context rebinding, and the maximum 32 scalar parameters. Negatives cover wrong expected claim/context, every tested truncation/byte substitution, changed tuple domains, private context leaked into public output, missing context requirements and invented evidence or authority. Default /4 APIs, native realization inspection /1, binary minors, and stable activation remain unchanged.
C2-IFACE-005 — Inherited software projections. software-projections
adds opt-in interface/5 profile core1-software-contracts/1 and semantic/5
profile core1-software-inspection/1. Both require an actual closed checked
Core-1 module accepted by the unchanged Core-1 reflection and interface APIs.
They preserve the original edition/preview, declarations, contract identities
and capability requirements; they do not reinterpret these as Core-2 hashes.
The envelope describes Core-2 inspection, not a recompiled software module.
No unresolved-import/source-only module, Core-0 module, hardware/physics module
or newly admitted source form is implied. Semantic inspection retains precisely
the existing /4 inspection facts, not the complete executable IR or every
private declaration. Neither profile is a whole mixed-domain module projection.
Canonical JSON has ordered keys schema, edition, preview, profile, scope, requires, modules, evidence, executable, promotion_admitted, authority. Schema is zerglang.interface/5 or zerglang.semantic/5. Edition is core-2; preview is the minimum hardware-preview, also consumable under explicit cumulative physics-preview. Scope has ordered kind = software-module and ref = {table: modules, id: 0}, in that reference order. Requires contains “zerglang.interface/4”, “core1-typed-message/2” in that order; semantic adds “zerglang.semantic/4” last. These are explicit inherited format requirements, not a claim of new software execution support.
Modules has exactly one row, ordered id = 0, interface, contracts, semantic. Interface has ordered format = zerglang.interface/4, text = the exact unchanged interface output encoded as a JSON string. Contracts is in the original public-message/portable-instance order. Each row has ordered id (zero-based), selector, domain (one of the original five), identity, required_capabilities. Identity has ordered format = core1-typed-message/2, contract_id = the unchanged 64 lowercase hexadecimal digits. Requirements are names in the frozen Core-1 effect order, with no live handles. Declarations retain existing signature, effect, ownership, pre/postcondition and boundary facts. Scope-local row IDs do not replace the inherited contract IDs. Semantic is null in public output and the exact unchanged semantic/4 JSON object in semantic output, retaining its separate contract/body/implementation IDs and original formats. No implementation ID or body is added to the public contract rows. Evidence is {availability: not-included}; all three flags are false. Declared capability requirements never grant their capabilities.
Verification regenerates the selected projection from the actual checked expected module, compares exact length/content, and accepts neither raw hashes nor external JSON as a substitute for that context. Source formatting and relocation preserve bytes under the inherited canonicalization laws. A body change may preserve the public interface and contract IDs while changing semantic inspection. Public comparison never approves body/evidence reuse. Contract changes must match the consumer’s newly checked expected module. There is no normalization of alternate transport whitespace, field order, escapes, trailing bytes or NUL. JSON uses short escapes for quote, backslash, backspace, formfeed, newline, carriage return and tab; other ASCII controls use lowercase four-digit Unicode escapes. Non-ASCII declaration text requires a later profile and fails rather than being transformed lossily.
Each inherited interface and reflection buffer is bounded at 1048576 bytes; at most 8192 contract rows are inspected. A conservative construction budget of six times interface bytes plus reflection bytes plus 1024 bytes per row plus 2048 bytes must fit within 8388608 bytes. Transport has the same 8388608-byte input/output ceiling. Existing Core-1 checking/allocation bounds remain in force before these additional limits. Exhaustion is unsupported, never truncated success. Output is independently owned, with an optional NUL outside its length; failure returns no partial bytes. Invalid API inputs use ZL-OPTIONS-0001; transport mismatches use ZL-C2-ARTIFACT-0001; these new bounds use ZL-C2-UNSUPPORTED-0001. Existing Core-1/preview diagnostics are preserved.
Positive vectors cover all five inherited domains, original contract IDs, nonempty capability requirements, source relocation, body-only edits, multiple public messages and exact /4 declaration preservation. Negative vectors cover wrong expected contracts/bodies, rewritten IDs, erased requirements, false evidence/authority, cross-profile bytes, truncation and noncanonical transport. Default /4 APIs, ZLM1/ZLM2, binary minors and stable activation do not change.
C2-ART-004 — Staged encoding. The implementation roadmap introduces binary minors in dependency order: inherited-software/component graph; reference digital state/events; realization/target/evidence; physical model/mesh/equations; SolverPlan/coupling. Each tranche specifies exact byte rows, bounds, feature closure, round-trip vectors, tamper negatives and old-minor acceptance rules before enabling emission. Only explicitly allocated tranches are supported: C2-ART-009/010/011 declaration ZLM3 3.0–3.4 and C2-IFACE-002/003/004/005 scoped projections, plus C2-ART-012’s explicit source-resolved executable 3.5 profile. General executable ZLM3, standalone graph loading and whole-module projection/5 remain downstream.
Typed logical record registry
C2-ART-005 — Closed record vocabulary. The ordered registry at repository
path spec/editions/core-2/zlm3-record-layout.json is normative. Its schema is
zerglang.zlm3.record-layout/1. The public inspection command zlm3-schema
projects every table, field and compound value type; this is a schema description,
not interface/5 or an executable artifact. Table tags are zero-based positions
in the registry, matching C2-ART-002. Field tags are zero-based positions within
each ordered field map. Compound fields use the same rule. Enumeration tags are
zero-based positions in their enum: alternatives. Unknown tags or members are
errors; omitted optional fields are errors too: absence is explicit null.
A logical JSON document has exactly schema, edition, preview, requires,
dependencies, and tables, in that canonical order. The schema is
zerglang.zlm3.logical/1, the edition is core-2, and preview selection must
match the consumer’s explicit selection. requires is a duplicate-free list
ordered as follows: logical-records/1, hardware-records/1,
realization-records/1, physics-records/1, solver-records/1. The first is
mandatory. Nonempty tables require their registry feature. Physics and solver
records require physics-preview; physical numeric and solver-plan types also
require physics-records. Empty later-preview tables remain present.
All 31 tables occur exactly once, including empty tables. Each has kind and
rows. Each row has exactly id, owner, name, ordinal, and fields.
owner is a qualified owner or empty for a root; name is a checked identifier;
ordinal is a nonnegative mathematical integer. Anonymous records receive
explicit stable local keys; incidental transport IDs never break ordering ties.
Names on named records and qualified declaration symbols must agree with their
row keys. Typed ownership references must agree with the qualified owner.
This tranche uses inherited ASCII identifier segments and dot qualification.
Table-local IDs and expression-node IDs are unsigned 32-bit JSON numbers.
All mathematical integers, including widths, shapes, indices and ordinals, are
decimal JSON strings; exponents are integer strings or numerator/denominator.
Input may carry leading zeros, a leading plus, or a negative denominator.
Canonical integers have no plus or redundant zero, and negative zero is 0.
Rationals are reduced, positive-denominator, and omit /1. Zero denominators
and zero unit-conversion scales fail with ZL-C2-DIMENSION-0001.
Ref<T> is exactly {"table":"T","id":N}. IDs are reassigned densely from
zero after row ordering, and every typed reference is remapped. Dangling IDs,
duplicate IDs or row keys, and references to the wrong table are rejected.
Arrays marked set: sort by typed structural identity and reject duplicates;
reference identity orders by table tag then numeric canonical ID. Other arrays
preserve order unless explicitly specified otherwise. Dependencies are sorted
domain/format/digest tuples, not instructions to fetch or execute anything.
Digests have exactly domain, format, sha256; format is nonempty and
SHA-256 text is 64 lowercase hexadecimal digits. Uppercase input is normalized.
The domain vocabulary is closed; these records retain an identity supplied by
the producer, not a claim that this normalizer verified its preimage.
C2-ART-006 — Expressions and mesh ordering. Expressions have bindings
(ordered type references), nodes, and root. The registry closes the node
fields and variants: constant, reference, apply, bound, or
checked-software. Exactly the corresponding literal, subject, operator,
binding position or software digest payload is non-null. Only application and
checked-software nodes take operands. Bound positions and operator signatures
are checked against the declared types. Checked software requires a body-domain
digest in the explicit dependency inventory; the normalizer does not load that
body or attest its purity. Later admission must validate the referenced checked
region and its full boundary contract.
Nodes are topologically ordered, breaking available-node ties by typed structural
content excluding incidental node ID, then densely renumbered. Operand order is
never changed. Producers must intern identical pure nodes; duplicate structural
nodes, unreachable nodes, unknown IDs, and cycles fail closed. Bit/logic literals
use exact-width 0/1 strings, with X/Z permitted only for four-state types.
Scalar/quantity literals in this tranche are exact rationals; unsupported
aggregate literal encodings produce ZL-C2-UNSUPPORTED-0001.
Mesh topology row keys are (qualified mesh, entity_kind, stable_id) represented
by the common owner/name/ordinal fields. Entity kinds therefore retain the
inherited UTF-8 ordering, while stable IDs compare as mathematical integers.
The mesh’s coordinate records sort by canonical node identity. Connectivity
remains ordered, references lower-dimensional entities in the same mesh, and
is never reversed or merged. Aggregate membership is acyclic and stays within
the declared mesh. Node coordinates cover every declared node exactly once,
have consistent nonzero rank, and carry SI length dimensions. Element-family
well-posedness, Jacobians and discretization validity are later physical checks,
not consequences of structural normalization.
Quantities retain dimension, precision, rounding and value. Rational quantities use exact rounding. Binary32/binary64 quantities encode the IEEE bit pattern as exactly 8/16 hexadecimal digits, most significant first; uppercase normalizes to lowercase. Signed zero is preserved. NaN and infinity are rejected. This representation does not use host floating-point arithmetic or tolerance equality.
Type-argument, component-instantiation and lineage-parent graphs are acyclic; ordinary ownership back-references such as component-to-port-to-component are not cycles of those graphs. These checks do not prove combinational acyclicity, clock safety, equation well-posedness, evidence validity or execution eligibility. Those obligations remain with their domain-specific checking and admission gates.
Common byte layout
C2-ART-007 — Exact common framing. All fixed-width integers below are unsigned little-endian. Alignment is one byte; padding, unused flag bits, duplicate sections, holes, overlaps and trailing bytes are forbidden. Each minor must explicitly select this layout and its feature closure before emission is enabled. C2-ART-009 selects it for hardware minor 0.
The fixed 64-byte header is: magic ZLM3 at 0; u16 major=3 at 4; u16 minor
at 6; u32 header_size=64 at 8; u32 flags=0 at 12; u64 total_size at 16;
u64 manifest_offset at 24; u64 manifest_size at 32;
u64 string_pool_offset at 40; u64 string_pool_size at 48;
u32 table_count=31 at 56; u32 directory_entry_size=24 at 60.
The directory follows immediately. Each 24-byte entry is u16 table_tag,
u16 flags=0, u32 row_count, u64 offset, u64 byte_length.
Entries follow canonical table order. Section order is header, directory,
manifest, string pool, then the 31 table payloads. Empty tables have zero length
at the current position, not an omitted directory entry.
The manifest is u16 edition=2, u16 preview (1 hardware, 2 physics),
u16 feature_count, u16 reserved=0, followed by ordered u16 feature tags,
then u32 dependency_count and dependency compound values, each prefixed by
its u32 byte length. Feature tags follow C2-ART-005.
The string pool is u32 count, then for each string u32 byte_length followed
by its UTF-8 bytes. Strings are unique, sorted by unsigned UTF-8 byte order,
with empty string first if used. Invalid UTF-8, NUL, unused entries and duplicate
strings are rejected. No Unicode normalization changes identifiers or values.
Each row is u32 payload_length followed by that many bytes:
u32 canonical_id, u32 owner_string_index, u32 name_string_index, encoded
nonnegative integer ordinal, u16 field_count, u16 reserved=0, then fields.
Every field is u16 field_tag, u32 payload_length, then its exact typed
payload. Every registry field appears once in order. Compound values start
with u16 field_count, u16 reserved=0, followed by the same tagged fields.
Type identity comes from the enclosing registry position, never an ambient
schema guess. References encode u16 table_tag then u32 row_id.
Scalar encodings are: row-id as u32; boolean as u8 0 or 1; enumeration as
u16; strings/names/qualified names as u32 pool indices; hex:64 as the 32
digest bytes in hexadecimal display order. Mathematical integers encode
u8 sign (0 nonnegative, 1 negative), u32 magnitude_length, then minimal
unsigned big-endian magnitude bytes. Zero has sign 0 and length 0; a nonzero
magnitude cannot begin with zero. uint forbids sign 1. Rationals concatenate
encoded numerator and positive, nonzero denominator, already reduced.
Optional values encode u8 presence (0 absent, 1 present), then only for
presence 1 the underlying payload. Arrays encode u32 count followed by
elements, each with u32 payload_length and exact typed payload; pair: and
vector7: additionally require lengths 2 and 7. The fixed logical precision and
rounding tags determine the meaning of quantity value strings; the common
layout deliberately retains their canonical rational/bit text in the pool.
No implicit conversion to host floats is permitted.
There is no semantic digest in this common frame. File/transport checksums may
describe exact bytes, but contract/body/implementation identity framing remains
separate and must be specified before interface/5 or interoperable hashes ship.
Zero encodes as 00 00 00 00 00; -256 as
01 02 00 00 00 01 00; Ref<ports>(7) as 02 00 07 00 00 00.
These are scalar framing vectors, not complete ZLM3 files.
C2-ART-008 — Bounded inspection contract. zlm3-normalize and the public
C API zl_zlm3_logical_normalize_v3 perform structural record validation and
canonical JSON serialization only. They do not materialize an AST, compile
source, emit binary ZLM3, compute semantic/contract hashes, load dependencies,
grant capabilities, solve physics, evaluate proof claims or promote a realization.
The existing software loaders do not gain ZLM3 admission through this API.
The current supported envelope is 8 MiB input, 32,768 records, 131,072 JSON nodes,
96 nested levels, 256 decimal digits per integer, 64 MiB tracked arena allocation
and 32 million charged work units. Callers may lower, not raise, these limits;
zero means zero, not unlimited. Input storage and bounded parser/BN-library
scratch are separate from the arena; the CLI’s read buffer is capped at 8 MiB
plus one overflow byte. Integer arithmetic is exact and work-charged before
entering the bounded native arithmetic operation. Unsupported limits, depth or
work exhaustion fail closed, with no partially returned normalized artifact.
Malformed JSON/records use ZL-C2-ARTIFACT-0001; unsupported features or resource
envelopes use ZL-C2-UNSUPPORTED-0001. A successful result owns its bytes and
remains valid after the input is released.
C2-ART-009 — Hardware minor 0 and transport inspection. ZLM3 3.0 selects
the exact C2-ART-005 registry and C2-ART-007 framing, with edition 2 and preview 1.
The selected row/field/type/tag definitions are frozen for this minor; later
registry extensions require a distinct minor selection and preservation of the
3.0 decoder, not reinterpretation of existing bytes.
The ordered required-feature set is either [logical-records/1] or
[logical-records/1, hardware-records/1]. All 31 directory entries are present;
physics, realization, solver and evidence feature tables remain empty under
C2-ART-005’s feature-closure rules. Common typed constraints, observations,
operators and lineage may refer only to the admitted closure. This does not
prove a process law, CDC safety, target validity, evidence claim or refinement.
Unknown majors/minors and required features fail with
ZL-C2-UNSUPPORTED-0001, never an older-format fallback.
zl_zlm3_binary_encode_v3 and zlm zlm3-encode normalize a hardware-preview
logical document and emit owned canonical bytes plus their SHA-256. The digest
preimage is exactly the whole emitted file, without prefix or excluded fields.
This is an external transport byte pin, not a contract, body, evidence or
target-artifact identity, signature, proof, or source of authority. No digest is
embedded in the frame. zl_zlm3_binary_decode_v3 and zlm zlm3-decode require
the caller’s expected 32-byte SHA-256 and verify it before decoding. Digest-valid
malformed records still fail. A hardware or cumulative physics-preview consumer
can inspect this hardware artifact; the artifact retains preview 1 and the
caller’s options remain unchanged. A physics-preview document cannot be encoded
as minor 0 merely because this consumer is cumulative.
The decoder independently bounds the header, directory, sections, row/field/item
lengths and counts before interpreting their payloads. It validates the typed
graph, recomputes canonical encoding, and requires exact equality to the input:
nondense IDs, reordered fields/sets, unreduced rationals, unused pool entries,
invalid UTF-8, nonminimal integers and trailing bytes are rejected, not repaired.
Encode and decode each use one shared C2-ART-008 resource envelope for all stages,
including checksum work, canonicalization and returned-output allocation; wire
input/output are each limited to 8 MiB. Decoder integer scratch is at most 107
magnitude bytes before enforcing the 256-decimal-digit limit. Lowered limits
are binding; failure returns no partial artifact. Null required API arguments
use ZL-OPTIONS-0001 when a diagnostic destination exists.
The CLI creates a new output file only after validation, never overwrites an
existing destination, and reports write failure rather than successful emission.
An I/O failure may leave its newly created partial output; that file is not a
successful artifact and must not be trusted. Decode emits canonical JSON to
stdout and performs no dependency fetch or execution. Discovery separately
reports structural_artifacts=[{major:ZLM3,minors:[0],executable:false}];
accepted_artifact_majors describes executable admission separately; minor 0
never contributes to that list. The later explicit minor 5 is described under
C2-ART-012. Old ZLM1/ZLM2 entry points reject ZLM3, and stable Core-2 remains inactive.
The independent empty-file vector is a 64-byte header, 31 empty directory entries,
14-byte manifest (feature tag 0, no dependencies), and four-byte empty pool: 826
bytes total. Its SHA-256 is
3d78abfe786546121177a85bcc24ac9ca122da25385d308d72e25d7e062c9b23.
Positive vectors retain every hardware table, clock/phase/discipline/bridge
metadata, typed operator DAGs, Unicode strings and integers wider than 64 bits.
The populated clocked_document transport fixture in
tests/cli/test_zlm3_binary.py locks the 3.0 registry with 4,069 bytes and SHA-256
c86a0b255b6b3bdf58ea0aa67bced9904c71d06a9ca60aad867aa1a1d97686a9.
Unlike the independently assembled empty vector, this is a serialization
regression vector, not independent semantic or equivalence evidence.
Negative vectors recompute transport pins after corrupting lengths, counts,
references, ordering, reserved bits, presence tags, string pools and minor tags.
C2-ART-010 — Cumulative declaration transport minors. ZLM3 3.1, 3.2 and 3.3 select the unchanged record-layout/1 field, compound and enumeration tags and C2-ART-007 byte framing. They extend structural inspection, not executable admission. Minor 0’s exact bytes and accepted feature envelope remain frozen.
| Minor | Artifact preview | Available required-feature tags |
|---|---|---|
| 0 | hardware | 0 logical, 1 hardware |
| 1 | hardware | 0–2, adding realization/target/evidence declarations |
| 2 | physics | 0–3, adding physical model/mesh/equation declarations |
| 3 | physics | 0–4, adding solver declarations |
Required tags are strictly ascending, begin with logical tag 0, and need not be contiguous. Populated tables still require their own feature. Solver transport also explicitly requires physics records. The canonical encoder selects minor 3 when solver records are required, otherwise 2 for a physics-preview document, otherwise 1 when realization records are required, otherwise 0. A nonminimal minor is noncanonical and rejected. Unknown minors/features and incompatible artifact previews are unsupported; malformed ordering/closure is an artifact error. A hardware consumer cannot inspect physics artifacts; a physics consumer can inspect hardware artifacts without changing their declared preview.
All 31 tables retain exact rows, ordered connectivity, expression binding positions, strong/weak forms, coupling metadata, methods/resources, subject digests and declared evidence results. Layout/1 identities are supplied declarations, not verified preimages. In particular its digest-only plan links do not establish local model/analysis/target binding; use C2-ART-011 when that stronger structural relationship is needed. No declaration transport creates a native checked model, SolverPlan, passed evidence or promotion. The exact 8 MiB transport and shared construction/decoding budgets remain unchanged.
C2-ART-011 — Bound declaration graphs, minor 4. ZLM3 3.4 selects
zerglang.zlm3.logical/2 and zerglang.zlm3.record-layout/2. The normative
zlm3-record-bindings.json overlay appends fields to layout/1 without changing
any earlier tag or scalar encoding. All 31 table tags remain fixed. Appended
field tags follow each old field list; old fields are neither optional nor
reinterpreted. The common framing remains C2-ART-007. Both explicit previews
are possible, subject to the same physical feature restrictions. Tag 5,
binding-records/1, is mandatory along with tag 0. Logical/1 cannot require
tag 5 or carry appended fields. Logical/2 always selects minor 4, including an
empty bound graph. Its complete field inventory is available through
zlm3-schema --record-layout=2; the default schema command/API remains layout/1.
This is binding inspection of declarations, not semantic subject admission. Every identified local row has a distinct declared domain/format/SHA-256 tuple. Models, analyses and target definitions use contract; meshes use body; realizations, physical instances, solver plans, evidence and lineage use their respective domains. A target-definition contract is not a target artifact. Every digest used in a row resolves either to an identified local row or to the explicit immutable dependency inventory. The loader checks these relationships, not an absent subject preimage or producer signature. An attacker can manufacture a mutually consistent declaration graph and its transport checksum; neither becomes trusted by inspection. The caller’s independently selected exact byte pin prevents replacement of a selected artifact. Later native semantic/evidence admission must additionally check actual subject bodies, applicability and authority, and must not manufacture checked native handles from these rows.
Each model owns its fields, material/equation/condition rows and analyses. A
mesh with null normative is original; a derived mesh references an original
mesh owned by the same model and supplies lineage that explicitly retains its
own identity and that normative parent. Fields, original observations, materials,
equations, conditions and model-owned constraints stay on normative geometry.
Their frame and support cannot silently move to a
derived or foreign mesh. Ordered element orientations cannot be absent, and
node orientation is none. This checks declared topology, not Jacobians,
conservative transfer accuracy, geometry validity or numerical conditioning.
Strong equations cannot carry weak test spaces; weak equations require an explicit body-identified test space and nonempty positional bindings, matching their expression bindings. Referenced fields and support remain model-local. Analyses retain their equation and member inventories. Coupled membership is acyclic and model-local; its unknowns are exactly the member union. Explicit couplings require at least two same-model analyses, one orientation per exchange, member-owned endpoint fields and declared projection operators. Each exchange’s projection has one source operand and a result matching the destination field’s dimension, shape and frame. Field-reference expressions retain their physical field’s frame as well as its dimension and shape. Cross-model coupling needs a later profile; it is not inferred from compatible dimensions. Operator body pins are not numerical implementations or regularity proofs.
A plan’s typed model and analysis references must match its two declared pins and analysis ownership. Its row owner is the selected analysis’s qualified name. The complete transitive analysis closure supplies all original unknown meshes and acceptance checks; checks belong to the same model. Normative meshes are exact and every one has exactly one declared solver-mesh choice, either itself or a same-model derived mesh pointing back to it. Missing/extraneous checks or meshes fail. Discretization operators must occur in the plan operator inventory. Methods are explicit dependency pins; resource names are unique and their declared integer bounds positive. These declarations do not grant resources or establish method compatibility; the separate native SolverPlan constructor does that for its supported profile. Plan lineage must name the exact plan. Optional target reference and target contract pin must be present together and agree.
Claims retain their original contract pins and explicit allowance/policy fields. Realizations bind the same original contract as their claim, and any selected plan belongs to their implementation model and selected target. Physical instances bind a target row matching their target contract digest; a stored enrollment pin is not enrollment authority. Evidence has explicit optional model/target/plan/realization context slots. Referenced contexts occur in exact subjects; locally identified contextual subjects cannot evade binding by nulling the corresponding slots. Plan/realization context must agree throughout, including a realization’s implementation model when its plan is null. Result observations remain in the selected model, and provenance relates to an actual subject. This finite profile has one context of each kind per evidence record; multi-context evidence requires a later profile.
Local lineage parent references and parent identities agree in both directions;
cycles reject. Imported lineage is retained as a dependency pin, not fetched or
certified acyclic across unavailable bodies. Promotion declarations preserve
the selected realization’s contract, target and plan; evidence must resolve to
local records bound to that realization. Result/status values, including a
declared pass or admitted result, are unverified claims and never change the
transport’s executable:false, authorize promotion or satisfy a native evidence
gate. Access control for private device identities or measurements belongs to
the caller; this complete inspection format is not a public redacted interface.
Bound graphs use the existing cumulative parser, allocation, work, record and depth ceilings, including traversal and identity lookup work. Outputs are owned; failure publishes no partial graph. This profile adds no live runtime state, snapshot side store or execution lifecycle. Old source/module loaders, ZLM1/2, default interface/semantic versions and stable Core-2 activation are unchanged.
C2-ART-012 — Source-resolved executable hardware, minor 5. ZLM3 3.5 selects
the closed source-resolved-combinational/1 profile. Its root is a public
component admitted by C2-ID-003’s acyclic combinational producer, with its entire
instantiated closure. Two-/four-state wires, static specialization, ordered
ports, hierarchy, connections and total combinational processes retain that
producer’s exact laws. State, clocks, async/intrinsic disciplines, bridges,
inout/resolution, named observations, physical models, SolverPlans and arbitrary
software bodies are unsupported. Broader native profiles are not implicitly
artifact profiles. Existing structural minors and semantic/5 bytes remain frozen.
The host must independently select exact artifact bytes, native model identity and all six simulation limits, and resolve the actual source closure through the checked parser/elaborator. No digest-only dependency, stored pass flag or mutually consistent invented record graph can replace those preimages. The loader checks framing and selected SHA-256/model pins, reconstructs both portable semantic preimages and the exact native model from that closure, and requires complete canonical byte equality before publishing an owned model. A missing dependency, substituted private body, changed port contract, stale native model or limit mismatch rejects before execution. This is not standalone graph loading or a fallback from failed artifact validation to source execution.
Minor 5 selects a new fixed 192-byte header, not C2-ART-007’s structural table directory. Unsigned integers are little-endian; there is no padding, embedded checksum, optional field or trailing data:
| Offset | Encoding | Exact meaning |
|---|---|---|
| 0 | bytes[4] | ASCII ZLM3 |
| 4, 6 | u16, u16 | major 3, minor 5 |
| 8, 12 | u32, u32 | header size 192, flags 0 |
| 16 | u64 | total byte length |
| 24, 26 | u16, u16 | edition 2, hardware preview 1 |
| 28, 30 | u16, u16 | profile 1, source resolution required 1 |
| 32, 36 | u32, u32 | contract/body payload lengths |
| 40, 44 | u32, u32 | max records, max individual width |
| 48, 56 | u64, u64 | max aggregate value bits, max work per step |
| 64, 68 | u32, u32 | max samples, max trace bytes |
| 72, 104 | bytes[32] each | C2-ID-003 contract/body tagged SHA-256 |
| 136 | bytes[32] | exact zerglang.combinational-model/1 identity |
| 168 | u32 | root byte length, 1–1023 |
| 172 | u32 | required feature mask, exactly 15 |
| 176 | bytes[16] | zero |
| 192 | consecutive bytes | root, canonical contract JSON, canonical body JSON |
Required bits 0–3 are component-contract/1, component-body/1,
zerglang.combinational-model/1 and fresh model-scoped Simulator admission.
Unknown or missing bits, previews, minors or profiles reject as UNSUPPORTED.
The root and both payloads omit NUL terminators. Each payload is at most 8 MiB;
the whole file is at most 16 MiB + 1215 bytes. Invalid length/reserved fields,
noncanonical data or pin/preimage mismatches reject as ARTIFACT. The external
SHA-256 covers every file byte without a prefix; it is not authentication,
evidence or any of the portable semantic identities. Native model pins bind
the existing versioned profile, checked record fingerprints, root and exact
limits, not a compiler binary or host ABI. Costs are freshly derived native
reservations, not artifact-supplied authority; source-unit partitioning can
change source-map allocation costs without changing semantic identities.
Portable contract/body identities do not become machine execution authority.
Preparation is a bounded composition of the existing semantic producer, its real combinational model check, one native model build, payload copying/hashing and (on load) complete comparison. Existing record/width/value-bit/preparation work bounds apply; each semantic payload also bounds expression expansion to 65,536 visits and depth 256. This is distinct from structural arena/work accounting and grants no unbounded work. Limits are exact and zero is binding; failure returns no partial bytes or model. Actual source closure and input storage remain caller-owned; successful output models survive their release.
Ordinary explicit-profile build/check and explicit source-package build/check perform pure preparation, not authority issuance. New output files are created exclusively after validation; failed writes may leave a clearly unsuccessful new partial output. Direct checked-source and artifact runs use identical reference semantics, with live model-scoped Simulator checks at open and every step. Expiry/revocation and attempted-work accounting remain unchanged, including atomic frame publication and charged admitted failures. Artifact/pin/metadata bytes cannot revive or issue capabilities, infer physical evidence or promote stable Core-2. Hardware and cumulative physics consumers may admit this hardware artifact without changing its preview; hardware consumers gain no physical solve.
Discovery lists ZLM3 in executable majors only together with minor 5’s exact
profile, mandatory source resolution and fresh authority requirement. Structural
0–4 remain separately advertised non-executable; old Core-0/Core-1 source, ZLM1/2,
ABI, version and structural-decoder routes keep their meanings. Canonical
runtime/ZDE observations must retain bounded admission provenance distinct from
live authority. Operational guidance and the implementation evidence ledger are
in docs/core2-hardware-artifacts.md; byte, semantic, invalid dependency, stale
pin, compatibility, property and mutation gates are required before completion.