Core-3 Activation and Delivery Gates

C3-GATE-001 — Stable activation remains inactive

Stable Core-3 requires the inherited stable-edition obligations plus an independently reviewed kernel foundation, checked proof-object transport, adversarial proof/axiom/universe/inductive tests, verified or explicitly trusted semantic bridges, extraction preservation evidence, and the complete Intent authority/admission/replay protocol. Runtime snapshot and visible ZDE behavior must satisfy their paired test contracts. Specification delivery alone cannot activate the edition, add feature flags, select a compiler, or promote fixtures.

The foundation review must examine consistency assumptions, subject reduction, positivity and elimination restrictions, termination, and checker agreement. The specification does not claim a machine-checked metatheory. Independent checker comparison must disclose shared code and assumptions; two wrappers around one checker do not supply independent verification.

C3-GATE-002 — Incremental previews and truthful discovery

Future implementations may expose bounded proof-preview and intent-preview tranches. They must distinguish specification admission from implementation support and report unsupported before executing unavailable behavior. No syntax-only parser, schema validator, externally supplied receipt, solver pass, or model response is advertised as a proof kernel or Intent runtime.

Proof checking and normal builds remain usable without a model service. Runtime Intent requires explicit live authority. Existing Core-0–2 routes and ZLM1–3 identities stay unchanged; no old verified/trusted evidence receives a kernel-certified label without new checking and the appropriate bindings.

C3-GATE-003 — Specification acceptance

Delivery requires unique permanent C3 clauses; resolved local/cross-edition links; a closed grammar overlay; explicit logical typing, elimination and termination rules; all seven verification bridge obligations; complete authority/admission/failure rules; logical schema and canonical identity vectors; positive/negative conformance scenarios with expected outcomes; the complete caller routing policy; and the dependency-ordered roadmap.

The site must publish this edition as normative preview; implementation unavailable, with searchable clauses and edition-scoped navigation. Required grammar/semantic rules must not be hidden behind unresolved normative TODOs. Deferred implementation or physical packing is labeled explicitly and cannot be inferred from a schema’s existence. Specification acceptance is a user decision separate from delivery checks and future stable activation.

C3-GATE-004 — Validation and compatibility

Check clause uniqueness/references, document links, grammar nonterminal closure, strict logical-schema compilation, positive/negative schema fixtures, canonical identity bytes/hashes, public route/anchor rendering, deterministic projection, and unchanged old document objects. These checks validate the specification delivery, not the truth of future theorem examples or runtime implementation.

Docs/grammar/schema edits use the repository documentation exception to test-first ordering. Changed site or validation behavior requires a behavioral failing test before implementation and focused mutation tests after green. Run the site regression, typecheck, production build, and implementation-status check. Do not bump runtime/artifact versions, benchmark catalogs, source fixture maturity, or release/deployment metadata for this delivery.