Standardization: the LPV1 suite

The ten LPV1 documents under docs/standards/ are the project's normative target specifications — every one is explicitly headed "Status: Normative target specification; implementation conformance is not yet established." They describe where the project is going, with stable requirement identifiers (CFG-004, ABI-012, CLI-007, ...) that don't change when prose is clarified. They are not, by themselves, a claim that main implements everything written there — that's what this page and docs/standards/requirement-matrix.json are for.

As of this session, across all ten documents:

Status Count
implemented 53
blocked 24
not_started 13
not_assessed 152
Total requirements 242

not_assessed is the largest bucket by far — most requirements haven't been individually checked off against the code yet, not because they're known to be missing. Treat the table below as "how much of this document's territory has been walked," not "how much is broken."

# Document Requirements Implemented
01 Identity, terminology, source consolidation, and conformance authority 22 1
02 Architecture, ownership, lifecycle, and separation of concerns 23 11
03 C ABI, linker contract, native artifacts, and build reproducibility 24 8
04 The single Polycallfile: grammar, schema, validation, and migration 20 7
05 CLI command registry, parsing, output, and process behavior 22 13
06 Polymorphic dispatch, exact value types, and protocol version 1 24 12
07 Language bindings, program-first adapters, and polyglot integration 27 0
08 Security boundaries, transport correctness, and resource safety 27 1
09 Bottleneck investigation, observability, and performance acceptance 27 0
10 Verification, archive migration, version 1 completion, and Git publication 26 0

Every requirement's full text, implementation paths, and verification evidence live in docs/standards/requirement-matrix.json — this page summarizes it rather than reproducing all 242 entries.

Reading a requirement ID

Each spec uses a short prefix per concern area, not per document number: ID-* (identity), ARC-* (architecture), ABI-*, CFG-* (configuration), CLI-*, PRO-* (protocol), BND-* (bindings), SEC-*, PER-* (performance), MIG-*/REL-* (migration/release). A requirement referenced elsewhere on this site (for example CFG-021 for local-auto) can be found by searching that ID across docs/standards/*.md.

CFG-021 exists in code and comments, not yet in the published LPV1-04 text

security.mode = "local-auto" is real and used throughout this site's tutorials, and the implementation refers to it as CFG-021 in several source comments, but the published 04-polycallfile-grammar-and-configuration.md doesn't yet define it formally alongside token/mtls in its security.mode table. This is a documented case of implementation slightly ahead of the written spec, not a discrepancy to "fix" by disabling the feature.

LPV1-01: Identity, terminology, source consolidation, and conformance authority

Defines what "LibPolycall" and "version 1" mean, and that this repository is the one conformance authority — historical repository names (trial, alpha, beta, -v1trial) are migration inputs, not parallel authoritative cores.

LPV1-02: Architecture, ownership, lifecycle, and separation of concerns

The core/CLI/binding/transport split described in Core concepts: the reusable core owns configuration, dispatch, protocol, and lifecycle; the CLI translates operator input into those interfaces; a binding translates language values; a transport moves bytes.

LPV1-03: C ABI linking and build artifacts

Covered in C library and ABI.

LPV1-04: Polycallfile grammar and configuration

Covered in Polycallfile reference.

LPV1-05: CLI command and subcommand contract

Covered in CLI reference.

LPV1-06: Polymorphic dispatch, types, and protocol

Defines the wire protocol provider.py and math_provider.c both implement: frame length prefix, JSON envelope, HELLO/AUTH/REGISTER/ INVOKE/RESULT/ERROR message kinds, and the tagged-value encoding ({"type": "i64", "value": "5"}) that keeps 64-bit integers exact instead of round-tripping through a JSON number.

LPV1-07: Language bindings and polyglot integration

Names the mandatory (C, Python, Node) and optional (Lua, Go, Java, COBOL) language set — see Language integration for which of those are actually demonstrated today (two: C and Python). Currently the only document with zero requirements marked implemented in the matrix.

LPV1-08: Security, transport, and resource safety

Defines authentication, authorization, transport framing limits, and resource bounds. What's real today: shared-credential authentication (token or local-auto, see Polycallfile reference), per-request authorization against [grant.*] entries (deny-by-default — math_provider.c's README documents a denied registration when a grant omits "register"), and bounded frame sizes (runtime.max_frame_bytes). What's aspirational: encrypted transport (mtls mode is refused rather than silently downgraded — see Polycallfile reference), and the fuller resource-exhaustion and observability guarantees this document describes. Do not read "zero-trust" language in older project material as a claim that encryption is implemented; it isn't yet.

LPV1-09: Bottlenecks, observability, and performance

Telemetry today: [telemetry].enabled/include_payloads are parsed and validated (include_payloads must be false in baseline — payload content is never captured), but telemetry snapshot itself reports unavailable (no Phase F management protocol yet), so there is currently no way to read back a metric snapshot. This document's performance acceptance criteria have not been benchmarked against main.

LPV1-10: Verification, migration, and release

Governs archive migration and release acceptance. The historical migration guide on this site is the practical companion to this document's migration requirements.