Core-3 Proof and Intent Edition

Status: normative preview; implementation unavailable; stable Core-3 inactive.

Core-3 adds Proof, the eighth paradigm, and Natural Language (Intent), the ninth. This edition specifies future behavior. It does not add a compiler flag, a kernel, a model service, an executable ZLM4 loader, or a release claim. The Core-2 authority and earlier editions retain their own meanings and implementation boundaries.

C3-EDITION-001 — Taxonomy and inheritance

The nine paradigms are Algorithm, Compute, State, Flow, Optimize, Hardware, Physics, Proof, and Intent. A paradigm identifies a semantic discipline; it is not necessarily a callable domain or an execution engine. Core-2’s six callable domain tags remain unchanged. Physics is a model kind, Proof is a pure logical declaration kind, and Intent is a declarative instruction kind resolved through an explicit host boundary. Neither new kind adds a row to the callable-domain matrix.

Core-3 inherits Core-0, Core-1, and Core-2 except where a C3 clause explicitly extends behavior for Core-3 only. proof-preview includes the Proof surface and inherited hardware/physics specification. intent-preview is cumulative and additionally admits runtime Intent. Neither identity denotes implemented support. The existing natural-language authoring authority remains available under its original edition; it is not retroactively gated on intent-preview.

C3-EDITION-002 — The spectrum is not a compilation chain

The following is a conceptual relationship, not an implicit conversion:

Natural language / Intent
          | approved interpretation
          v
Formal contracts -------- Proof checks claims about these contracts
          | checked realization / explicitly admitted plan
          v
Algorithm · Compute · State · Flow · Optimize · Hardware · Physics
          ^                    |
          +-- verification ----+

The seven lower entries have distinct operational or model semantics, not seven successive lowering stages. Hardware describes circuits; Physics describes physical models. Neither a proof of a model nor successful circuit simulation establishes that nature or a device satisfies its assumptions. Proof can justify a program without generating it. Only computational constructions meeting extraction rules become algorithms. Intent can execute under an explicitly runtime-checked policy without a mathematical proof; its evidence must say so.

C3-EDITION-003 — Specification and trust boundary

Within this edition the grammar governs surface syntax; the logical typing rules govern proof meaning; the boundary and artifact clauses govern authority and evidence. A syntax tree, type-correct runtime program, hash match, model answer, test pass, approval, and kernel-checked theorem are different claims. No one of them silently implies the others. Proof establishes a formal proposition under an explicit environment, not unrestricted real-world truth.

The initial foundation is Zerg-owned and verification-first. Standalone mathematics is expressible, but a large library, Lean importer, tactics DSL, primitive quotients, higher inductive types, and univalence are not in this preview. Classical reasoning is explicit opt-in. Logical ZLM4 and canonical identity encoding are specified here; physical container packing is deferred.

Reading order

1. Proof foundation and proof language.
2. Verification bridges and extraction.
3. Intent authority, runtime, and effects and boundaries.
4. Logical ZLM4, grammar, and diagnostics.
5. Conformance, activation, roadmap, and prior art and decisions.

The schema and vectors beside these documents are specification fixtures, not implementation evidence. A delivery changes no old artifact meaning, stable edition, benchmark maturity, compiler-selection state, or live capability.