This directory is the public reading map. Authority is separated by kind so that implementation evidence, future plans, and normative semantics are not mistaken for one another.
| Question | Document |
|---|---|
| What is zkc, and what direction does it pursue? | Project Overview |
| What does the current checkout claim? | Current Status; the Repository README is a summary |
| How does the target architecture fit together? | Architecture |
| How does zkc relate to relation compilers, formal systems, backends, and zkVMs? | Ecosystem |
| How do I build it? | Getting Started |
| What comes next? | Roadmap |
| What are the exact artifact and judgment semantics? | Specification Overview |
| What formal evidence is currently recorded? | Formalization Evidence |
Project Overview explains the stable project model and target direction without reporting current implementation support. Architecture is the non-normative target guide to system layers, artifact lifecycle, and trust boundaries; it intentionally includes unimplemented parts of the target design. Ecosystem applies those generic boundaries to concrete external projects without making a compatibility claim. Current Status owns the public capability and evidence dashboard. The setup guide owns the normal development workflow, while the roadmap owns dependency order; neither overrides the specification.
The current specification corpus is:
- Protocol Kernel
- Soundness Kernel
- Compiler Core
- Vocabularies
- Relations
- Boundaries
- Endpoints
- Carrier
- Versioning and diagnostic allocation
Specification Overview is the compact reading map. The individual specifications own intended semantics. Implementations and tests are conformance evidence; registry JSON and encoded artifacts remain subject to the validation and identity rules those specifications define.
Formalization Evidence explains the receipt and drift checks attached to Soundness Kernel rules, the pinned formalization readings, and the conditions for theorem-backed admission. The machine-readable annotations and pin files remain authoritative for their own contents; the document does not override the specification.
- Evaluation overview — active integration evidence and the provenance of source-derived regression fixtures.
- Pinned Plonky3 replay/prover harness — current fixture-scoped upstream evidence.
- FRI generation benchmark record — measured wall-clock and allocation evidence for one emitted prover against the pinned upstream prover, scoped to its named machine, revision, and instance.
These records preserve the exact scope and residual trust of experiments. They do not override Current Status, mint general backend conformance, or define protocol semantics.
- Current public capability and evidence claims belong in
status.md; future direction belongs inroadmap.md. - Exact schemas, judgments, identities, and refusal rules belong in
spec/. - A demonstrated run establishes only the facets and fixed inputs it records.
- Soundness, completeness, zero knowledge, relation satisfaction, backend conformance, and implementation correctness are separate claims.
- A placeholder, proposal, citation, receipt, or passing test does not acquire stronger authority through proximity or detail.