Six callable domains, physical models, inheritance and preview identities.
Core-2 Hardware and Physics Edition
Status: normative preview; syntax, bounded hardware structure, ZLM3 3.0 structural inspection and native combinational/clocked simulation available; stable Core-2 inactive
Core-2 specifies spatial circuits and physical models alongside the five
software domains. These documents are authority for future implementations.
The ordinary software compiler emits ZLM1/ZLM2. Its explicit Core-2
source-resolved-combinational/1 build/check route additionally prepares the
bounded source-resolved ZLM3 3.5 profile under C2-ART-012, without enabling
general Core-2 source compilation or standalone artifact graph loading.
Separate native APIs provide bounded guarded hardware simulation, scalar
evaluation, netlist/RTL export and scalar datapath proposals. These do not
activate general Core-2 compilation, target synthesis or promotion.
Separate structural artifact inspection retains the ZLM3 3.0–3.4 tranches below.
A discovery surface is available through zerglang/core2.h
and zlm features --edition=core-2 --preview=hardware-preview --json (or
physics-preview). Its separate admitted and supported fields distinguish
specification membership from implementation support. Profile admission,
domain metadata and syntax-only source inspection (zerglang/core2_source.h,
zlm source-parse / source-print) are implemented. Syntax trees do not
establish typing, elaboration, evidence or executable support. The separate
zlm hardware-elaborate / zerglang/core2_hardware.h surface resolves bounded
component closures and checks typed wiring, ownership, cycles and unbridged
crossings. Its structural-only format is not ZLM3 or an evidence gate; extended
logic and timing/bridge/physical contracts remain unsupported. The implemented
tranche is documented in the repository’s docs/core2-hardware-structure.md.
General source compilation features remain unsupported; the version command continues to describe
the executable Core-0/Core-1 surface. The checked-in implementation-status
record is tested against both live preview descriptions.
zlm zlm3-schema and zlm zlm3-normalize expose the bounded typed logical-record
registry and canonical JSON form described in Artifacts.
Both require explicit Core-2 preview selection. Logical-record validation does
not compute contract hashes, load dependency bodies,
prove physical models or promote a realization. Its public C surface is
zerglang/zlm3_logical.h.
zlm zlm3-encode / zlm3-decode and zerglang/zlm3_binary.h now provide
bounded hardware ZLM3 3.0 byte transport under C2-ART-009. They verify external
SHA-256 byte pins and canonical framing, not semantic identities or evidence.
Feature discovery separates non-executable structural_artifacts from
accepted_artifact_majors; old loaders and stable activation remain unchanged.
The operational guide is docs/core2-zlm3-binary.md in the repository.
The distinct source-resolved 3.5 route is described in
docs/core2-hardware-artifacts.md; it requires actual checked source closure,
selected byte/native-model pins and fresh Simulator authority for execution.
zlm hardware-value / zerglang/core2_values.h provide owned, arbitrary-width
two/four-state reference values under C2-LOGIC-004.
The hardware-values feature covers pure operations, checked conversion and
finite resolution folds, not source compilation or a running hardware session.
Its operational guide is docs/core2-values.md in the repository.
physical-quantities in zerglang/core2_quantities.h provides exact SI
dimensions, affine unit conversion and checked scalar/vector/tensor values
under physics-preview. Explicit nonsingular frame maps preserve tensor variance.
This pure mathematical layer is not physical-model compilation, solver
execution or physical evidence. Its bounded profile and verification commands
are in docs/core2-quantities.md.
physical-mesh in zerglang/core2_mesh.h provides bounded canonical affine
geometry, explicit oriented topology and named support sets, plus typed field
placement bound to an owner and geometry identity. An interface-law identity
remains an obligation for model admission, not proof that the law is valid.
This pure value layer does not start a solver or compile a physical model.
Its supported element families and limits are in docs/core2-mesh.md.
physical-model-typing in zerglang/core2_model.h owns bounded typed strong/weak
equations, material relations, conditions and five analysis forms. Structural
checks retain unresolved well-posedness and regularity obligations; they do not
admit a solver or compile physical source. See docs/core2-model.md for the
explicit native profile, norm contracts, limits and verification commands.
physical-mesh-transfer in zerglang/core2_transfer.h preserves normative
model/field geometry through exact one-dimensional cell-average refinement and
remeshing. Checked overlap maps, explicit frame transforms and owned lineage
produce inspectable finite-reference error evidence. This is not solver
execution or a physical-fidelity claim. See docs/core2-transfer.md for the
bounded profile and unsupported interface/higher-dimensional transfers.
zlm boundaries / zerglang/core2_boundaries.h provide pure boundary-policy
inspection of all 36 callable cells and explicit effect inclusion. Physics stays
outside that matrix. An allowed policy route is not a live execution grant.
See docs/core2-boundaries.md in the repository for the bounded API/CLI contract.
The separate capability-guards feature is the trusted-host issuance/lifetime/
resource-meter API in core2_capabilities.h, not physical execution or source
boundary lowering. Its native metadata is explicitly paired with the canonical
runtime snapshot and ZDE follow-up cards.
action-journal implements the bounded native owned-command/receipt protocol in
core2_actions.h, including real State post-commit release, sealed evaluator
stimuli and separately authorized crash-gap reconciliation. The guide is
docs/core2-actions.md. This is not compiled source lowering, a device/solver
adapter, durable Store recovery or exactly-once physical execution evidence.
hardware-simulation implements bounded native combinational execution in
core2_simulation.h: checked acyclic hierarchy, typed simultaneous inputs,
four-state resolution, freshly guarded steps and owned replayable traces.
The guide is docs/core2-simulation.md. This native API does not make ZLM3
3.0 executable, add a source compiler, simulate clocked/
async/intrinsic regions, or provide physical/formal evidence. Its canonical
snapshot and ZDE projections are explicitly paired follow-up work.
The separate hardware-simulation-cli host adapter issues only ephemeral,
model-scoped Simulator grants under explicit caller opt-in and finite budgets,
as allocated by C2-CAP-002; it is not a general authority issuer.
The explicit clocked-simulation native factory in core2_clocked.h now
adds named edges, one pre-event register snapshot, simultaneous next-state
updates and reset polarity/assertion/priority. Its first complete input batch
establishes clock/reset baselines and initialized state, not an invented edge.
Unsafe asynchronous reset release and undeclared crossings fail closed;
typed bridge execution uses a separate factory. See docs/core2-clocked.md.
cdc-reference-values in core2_cdc.h supplies pure, immutable digital
transition laws for scalar uncertainty synchronization, coherent handshake/FIFO
transport and reset release. It is not source bridge admission or live circuit
execution. Source admission and guarded simulation are separate from this pure
value feature. See docs/core2-cdc.md.
The separate cdc-source-structure feature now checks source-defined reference
bridge contracts, explicit domain bindings, ownership and temporal
reconvergence. It does not enable bridge execution. See
docs/core2-cdc-source.md for the bounded definitions and complete source fixture.
cdc-simulation in core2_cdc_simulation.h admits these source-bound laws into
a separately identified, capability-guarded native execution profile. Ordinary
registers and word transfers sample pre-state; scalar synchronizers also
observe coincident post-register source changes. Reset-release pipelines hold
registers through their finishing edge. State/trace publication is atomic and
digital uncertainty is not analog metastability evidence. Explicit profile
limits and paired snapshot/ZDE work are in docs/core2-cdc-simulation.md.
async-reference-values in core2_async.h supplies pure bounded transport and
inertial scheduling, explicit interval choices and simultaneous logical event
commits. It does not admit source async networks or grant Simulator authority.
See docs/core2-async-values.md for the pure queue contract.
The separate async-source-structure feature checks initialized source targets,
timing laws and optional protocol/fork bindings without executing them. See
docs/core2-async-source.md; source-only inspection remains distinct from
guarded clockless execution and physical evidence.
async-simulation now provides separately identified, capability-guarded native
horizons with explicit interval schedules and atomic state/queue/trace publication.
See docs/core2-async-simulation.md for its bounded reference contract. Physical
evidence and the paired canonical snapshot/ZDE projections remain downstream.
realization-bindings in core2_realization.h resolves authored/generated
proposals against actual checked software contracts and native hardware models.
It preserves the original contract ID and separate baseline/model pins; it does
not admit observation mappings, equivalence, promotion or live authority. See
docs/core2-realization-bindings.md. Full realization-source compilation,
portable realization IDs and intrinsic/physical bindings remain unsupported.
scalar-observation-maps checks explicit fixed-width pure Algorithm-to-
combinational port projections against actual binding pins. It rejects missing,
aliased or mistyped coverage; equivalence, no-trap and progress obligations
remain pending. See docs/core2-scalar-observations.md. This does not enable
effectful/temporal realization maps or promotion. The separate
scalar-observation-source feature resolves named local component constraints
through that same mapper. Its owned proposal tables retain source lineage with
pending software/proof status; they do not change native circuit identities.
realization-proposals assembles a single owned canonical proposal by rechecking
the binding and typed map against actual dependencies, including stale map pins.
See docs/core2-realization-proposals.md; all evidence obligations remain pending.
identity-framing fixes the nine-domain, versioned SHA-256 envelope and typed
integrity comparison. It admits only framing, not subject semantics or /5
reflection; see docs/core2-identities.md.
component-identities adds checked canonical public specialization/port contracts
and full combinational circuit bodies. Their identities exclude source locations
and simulation limits; unsupported observations/temporal profiles fail closed.
See docs/core2-component-identities.md; general projection/5 remains downstream.
scalar-realization-identities adds portable checked scalar proposal IDs;
exact baseline/native-model pins remain separate mandatory evidence context.
See docs/core2-realization-identities.md; a digest never proves refinement.
component-interface adds the first scoped interface/5 profile: a single
public component contract with checked hashes, canonical transport and owned
port/specialization reflection. It contains no private body, evidence approval
or live authority. See docs/core2-interface.md; whole-module projections and
general semantic/5 remain downstream, and default public formats remain /4.
component-semantic adds checked-context semantic/5 for that component’s
contract plus combinational body. It includes private circuit structure and
requires the actual checked expected component when loading transport; hashes
alone do not admit a new body. See docs/core2-semantic.md.
realization-projections adds scoped /5 scalar claims and semantic proposals
from checked C2-ID-004 identities. Public output excludes baseline/native-model
context; semantic verification binds it explicitly, without asserting proof or
promotion. See docs/core2-realization-projections.md.
software-projections retains unchanged Core-1 declarations, contract IDs and
capability requirements in scoped /5 contracts/inspection. The actual checked
module supplies verification context; public output excludes body inspection.
See docs/core2-software-projections.md; no new source or execution support.
scalar-evaluation compares complete bounded scalar input spaces under fresh
Simulator authority, retaining separate outcomes and original dependency pins.
Its native functional report is not attested target evidence or promotion;
see docs/core2-scalar-evaluation.md and C2-EVID-004.
The pure checked-report wrapper is allocated separately by C2-EVID-005 as
scalar-reference-evidence/1 in evidence domain 7. It binds the entire report
and independently checked baseline/model context; it does not admit evidence,
authenticate a checker or grant authority. See docs/core2-scalar-evidence.md.
combinational-netlist provides pure bounded two-state primitive lowering,
an independent implementation identity, sized Verilog and separate unattested
source mapping. It does not enable target synthesis or promotion. See
docs/core2-netlist.md, C2-HW-005 and C2-ID-005.
Authority
- Grammar — source declarations and inherited productions.
- Hardware — components, logic, clocks, async and intrinsic regions.
- Physics — quantities, meshes, fields, equations and analyses.
- Libraries and bridges — multiphysics and mixed signals.
- Realizations — refinement claims and evidence admission.
- Boundaries — effects, capabilities and the callable matrix.
- Artifacts — ZLM3 logical tables and semantic identities.
- Adapters — toolchain and fabric contracts.
- Solver plans — inspectable numerical execution.
- Diagnostics — fixed Core-2 failure meanings.
- ZL512 — successor corpus and publication migration.
- Activation — preview and stable evidence gates.
- Conformance examples — specified positive/negative cases.
- Glossary, design decisions, prior art, and roadmap.
C2-DOM-001 — Domain admission. The callable domain order is algorithm,
compute, state, flow, optimize, hardware, with tags 0 through 5.
Hardware owns continuously active spatial structure and its evolution laws.
physical model denotes a non-callable model kind; it has no callable tag.
Parallel execution alone does not change a software declaration’s domain.
C2-DOM-002 — Inheritance. Core-2 inherits the Core-1 authority and its Core-0 dependencies as they stand in this repository’s Core-2 introduction commit. Only explicit Core-2 replacement clauses alter that inherited behavior for Core-2 inputs. Existing Core-0/Core-1 sources, tags, diagnostics, artifacts and public projections keep their old interpretation. Later inherited semantic changes require an explicit edition revision and compatibility review; inheritance is not a floating reference to whatever a compiler happens to implement.
C2-PREVIEW-001 — Cumulative identities. Selection is the pair
(core-2, hardware-preview) or (core-2, physics-preview). Hardware preview
includes inherited software authority and hardware, realizations and adapter
contracts. Physics preview includes all of hardware preview plus physical
models, physical libraries, SolverPlans and physical bridges. The physics
effect is reserved in both but admitted only in physics preview. Recognizing a
token does not imply support. Missing preview, later-preview use and unsupported
implementation features have distinct diagnostics. Bare core-2 requires the
stable gate.
C2-SRC-001 — Source axes. interpreted and compiled remain authoring
modalities; simulation, synthesis, FPGA configuration and numerical solving
are implementation choices. A component has an authoring modality; a physical
model is a declarative mathematical object and has none. Native materialization
requires an admitted compiled closure, including generated replacement bodies.
Source changes never silently convert a modality or grant authority.
C2-SRC-002 — Grammar and specification maturity. The grammar is an additive overlay with explicitly replaced productions. A syntax-only parser is available; semantic examples remain future conformance expectations. The value-message replacement spells out inherited C1-MOD-001 without modifying Core-0/Core-1 grammar files. Logical artifact records are normative; binary encoding is staged separately, with hardware minor 0 available for structural inspection. Specification publication must not claim executable Core-2, executable ZLM3 admission, implemented standard libraries, or verified ZL512 tasks.