The zpi Format

Zpi (Ziv Provable Intelligence) is Ziv’s package format for agent-independent mathematical knowledge. A zpi package is one on-disk book: a kb/ directory of entries — statements and proofs, one file each, markdown with a small YAML header — plus a ziv.manifest.json produced by the build.

Entries and citations

Every entry is a node in a dependency graph. Entries cite each other with @-references:

• @entry-id — a citation to another entry in the same kb/
• @external/<stmt> — a citation to an external fact, stubbed in the package’s external/ self-external pseudo-package at authored grade (stub grades live in the source only — they are never republished in the manifest, and uncited stubs don’t affect the package)
• @alias/<stmt> — a citation across package boundaries, resolved through a declared dependency

Content-addressed identity

An entry’s identity is the sha256 of its full body — and @-citations are part of the body, so re-wiring a citation is an identity change. Identities are path-independent: file names and paths are pure mnemonics for humans; the content is the address.

The dependency graph

The engine builds a statement-centric AND-OR graph: a proof establishes its statement when all of its premises hold (AND), and a statement is established when any of its proofs succeeds (OR). A statement body’s own citations fold in as a body-AND that can only weaken the closure. Proofs ride along as a ProofBundle on the statement they prove.

The paper model

A zpi package always ships its full source — kb/ + external/ + the manifest. The proofs are the contribution, so source is mandatory; a manifest-only distribution does not exist.

The manifest publishes a per-statement closure grade (see the grade model). Downstream consumers trust those grades the way they trust a citation — shallowly — and because the source ships too, anyone can re-fold the graph from the shipped entries and audit the trust.

Build and verify

A package is verified by folding its own source. The build compiles the dependency graph — layered validation first (per-entry, cross-entry, graph), then the fold — and writes ziv.manifest.json, publishing every statement’s closure grade.

The build is the ship gate: the manifest’s grades are the contract. Completeness checking (closureGrade > unverified everywhere) is a pure floor, not a claim of rigor — the rigor story is the grade itself, with its evidence, all the way down.