Specification acceptance, independent evidence and inactive stable Core-2.
Core-2 Activation and Conformance
Status: normative preview; stable Core-2 inactive
C2-GATE-001 — Stable activation. Stable Core-2 must remain inactive until all inherited Core-1 stable obligations are met, hardware has a canonical reference simulator and an independent synthesis/materialization path, intrinsic behavior has real-device evidence, physical models have independent solver evidence, and ZL512 passes the required profiles. All allowed and forbidden boundaries must be covered. Canonical ZLM3 binary/projection tranches must have round-trip, identity and tamper evidence. No non-equivalent behavior-bearing mutant may survive in the admitted behavior set, and Core-0, Core-1, ZLM1, ZLM2 and ZL256 compatibility must remain green. Self-hosting remains a separate compiler-provenance claim, not an extra edition gate.
C2-GATE-002 — Preview admission. An implementation advertises the exact cumulative preview and feature set it supports. Hardware preview cannot admit physical models or solvers. Physics preview cannot omit inherited hardware laws. Preview implementations may support bounded subsets but must reject unsupported constructs before materialization or execution. A stub, parsed keyword, source example, synthetic receipt or fixture callback is not evidence of an executable component, FPGA deployment or physical solve.
C2-GATE-003 — Specification acceptance. Specification delivery requires unique permanent clause definitions; complete document links and grammar references; positive/negative semantic examples and diagnostics; identity change/no-change vectors; documented evidence applicability; the complete boundary matrix; and a dependency-ordered implementation roadmap. Published pages must clearly separate specified and implemented behavior. The spec-only delivery can be accepted independently of stable activation. Acceptance must not set compiler feature flags or promote benchmark maturity.
C2-GATE-004 — Independence and observability. An independent materializer or solver must not simply wrap the reference executor or reuse the same unverified result. Evidence identifies shared dependencies and the independent check performed. Hardware/solver runtime implementations expose ownership, lifecycle, selected realization, authority requirements, progress, evidence, uncertainty and instability through the canonical snapshot and ZDE in the same PR or an explicitly paired follow-up. Both snapshot contracts and visible ZDE behavior require tests. Realization invalidation, indeterminate fabric actions, solver divergence and quarantine must remain visible to the user.
C2-GATE-005 — Compatibility evidence. Before release, run old source and artifact fixtures through their original edition routes and compare their specified outputs/identities. Preserve old public routes and suite versions. New logic must not reinterpret old enum tags or reuse old diagnostic meanings. Pure documentation changes require link/projection/status validation, not a claim that all future semantic examples execute. Tooling behavior changes follow the repository’s test-first and focused mutation workflow.