Skip to main content

Schema and discovery endpoints

Liskov serves generated JSON Schema for tooling:

GET /api/application-manifest/schema
GET /api/application-manifest/v5/schema
GET /api/application-policy/schema

The first describes customer-authored Manifest V4. The versioned route describes the exact retained Manifest V5 shape. The policy route describes server-materialized Policy V4; V5 explanation and effective evidence are read through the supported Application surfaces rather than inferred from this V4 schema route.

Use​

Download from the same Liskov environment you target, cache by content digest, and configure your editor or validator to reject unknown fields. Re-fetch when the published schema digest changes. The authoritative semantic validation is:

proof liskov application manifest validate --file PATH

JSON Schema can validate shape, enums, and many bounds. The Liskov validator also applies cross-field rules. Publication preflight additionally checks identity, artifact evidence, enabled capability, entitlement, and current server facts.

Compatibility​

Do not infer support from a schema property alone. Typed-but-gated fields are listed in Capabilities and limits. V4 and the exact retained V5 pair are public authoring contracts; unknown future pairs remain opaque.

These discovery routes do not announce a generally supported public REST API. Use Console and the public CLI for customer workflows unless another endpoint is explicitly documented as a stable product contract.

Console Coverage reads the adjacent proof.liskov.execution-convergence.v1 document. That is a bounded server projection consumed by the existing Overview and Executions views, not a general REST surface and not a second Action Plan. The published CLI plugin does not yet include the sibling. See Intended capacity versus remaining charges.