Implementations
Status: Informative. Spec version: 1.1-rc.1 Last updated: 2026-07-22
Tools that produce, consume, or validate LC-JSON (Learning Content JSON).
To list a new implementation, open a PR adding an entry below. Implementations are listed in alphabetical order within each section. Inclusion does not imply endorsement.
Producers
Tools that emit LC-JSON documents.
- Lesson Commons — Authoring and delivery platform for structured learning content. Emits courses and question sets in LC-JSON 1.0. https://lessoncommons.com
Consumers
Tools that ingest LC-JSON documents.
- Lesson Commons — Imports LC-JSON 1.0. Extension-preserving consumer per NORMATIVE §7 (unknown
x-*members round-trip through a load/save cycle), §6.4 (reserved-type questions preserve their type-specific bodies), and §12.1 (accessibility-preservation floor). https://lessoncommons.com
Reference tools
Distributed alongside the specification in this repository. They are
non-authoritative reference implementations: they implement the contract stated
in NORMATIVE.md, the companion normative documents, and the schema
constraints — they do not define it. Where a validator and a normative source
disagree, the source governs and the validator is a defect.
Exit-status contract
All four validators share one exit contract:
| Exit | Meaning |
|---|---|
0 | The document was fully checked (schema and domain) against the publication it declares, and conforms to it. |
1 | The document was fully checked and does not conform. |
3 | Validation unavailable / indeterminate — the check could not be completed, so nothing is claimed about the document either way. |
Exit 0 is always a statement about the declared publication. §8.4 makes a
document’s $schema URL the binding validation target, so a document declaring an
earlier publication is validated against that publication’s schemas — which the
published tree carries for every release it has ever served. The validators will not
check a 1.0 document against 1.1 schemas and then exit 0; that would assert a
conformance nobody established.
Exit 3 covers every case where the tool cannot complete the check:
- the
jsonschemadependency is missing (install withpip install -r tools/requirements.txt); - a schema required for the document’s artifact type — including one reachable through
$ref— is absent from the publication. A missing schema is an infrastructure failure; reporting it as exit1would blame the document for the tool’s problem; - the document declares a publication this tree does not carry. The result is then indeterminate: use a validator built for that publication.
The validators deliberately do not fall back to a reduced pass and exit 0 in any
of these cases. A note on stdout saying the schema pass was skipped is invisible to the
CI job or script reading the exit status, which would then treat an unchecked document
as conforming.
Domain-only operation is available as an explicit opt-in, --domain-only. It runs the
hand-written domain rules alone, skips every schema stage, reports DOMAIN-ONLY OK
rather than VALID, and is not a conformance check — a conformance claim under
NORMATIVE.md §10 requires the schema pass to have run. The flag is an
explicit request, so it takes precedence over schema availability: it behaves the same
way whether or not the schemas could have loaded.
validate_course.py— Python reference validator. Runs documents through the published JSON Schemas (jsonschema≥ 4.18) plus a hand-written domain pass for rules JSON Schema cannot easily express (HTML allowlist, gap-marker counts, points consistency). Default mode is lenient — pre-1.0 document shapes (wrapped envelopes, bare payloads) are tolerated with warnings so legacy/pre-1.0 documents can still be ingested during migration. The--strictflag is the public-conformance mode: those shapes become fatal errors, and the full set ofNORMATIVE.md§3.2 / §4.1 rejections is enforced. Public conformance claims underNORMATIVE.md§10 are evaluated in--strictmode.lc_collection.py— Reference validator forsubjectCollectiondocuments. Checks member identity, category/tag/objective closure, and alignment-claim vocabulary (the SC-* rules cataloged inVALIDATION.md§15).--validate FILE; exits 0 when the document conforms, non-zero on a violation.lc_pack.py— Reference validator forcurriculumPackdocuments. Checks step/pacing/checkpoint shape, taught-before-used sequencing, term capacity, and — given--collection FILE— coverage against the referenced Subject Collection (the CP-* rules inVALIDATION.md§16). Separates errors (exit non-zero) from advisory warnings (surfaced, exit 0).lc_glossary.py— Reference validator forglossarydocuments. Checks the gloss rule and the declared translation-inventory rules (the GL-* rules inVALIDATION.md§17);--validate FILE.assemble_pack_bundle.py— Packages a Curriculum Pack manifest into a self-contained bundle (embedding referenced documents identity-verbatim) and back (--strip), so bundle round-trips are reproducible by third parties. Before writing, it runs the shared emission gate: the pack’s own schema and domain rules, plus the schema and domain rules of every embedded document, dispatched on that document’sdocumentType.run_corpus.py— Conformance corpus harness for spec maintainers and contributors. Readstests/manifest.jsonand runs every fixture through the reference validator matching itsdocumentType(--strictfor course/questionSet), asserting that valid fixtures pass and invalid fixtures fail with non-zero exit. The spec repo’s CI runs it as a gating step on every push and PR — a corpus regression blocks deployment. Contributors SHOULD run it locally before opening a PR that touches the spec. LC-JSON consumers (tools that read/write LC-JSON documents in their own applications) do not need it; they can ignore it and treattests/manifest.jsonplus the fixture files as the canonical test set for their own implementation tests.
Conformance claims
Implementations may state conformance per NORMATIVE.md §10:
- Conforms to LC-JSON 1.1 as a producer
- Conforms to LC-JSON 1.1 as a consumer
- Conforms to LC-JSON 1.1 (both producer and consumer)
The version names the contract a tool implements; a tool implementing only the 1.0 artifact types states 1.0. Conformance is scoped per artifact type (NORMATIVE §5.1) — a tool that reads only courses claims only that.
The conformance test corpus at tests/ lets implementations self-verify.
Extension namespaces
Registered x--namespaced extension prefixes (NORMATIVE §7). Listing a namespace here documents its owner and intent so other tools can interoperate or avoid collision; it does not make the extension part of the core format.
x-lessoncommons— Lesson Commons. Carries tool-specific authoring metadata that has no place in the interchange core; member details are documented in the Lesson Commons developer docs. Consumers outside Lesson Commons MUST ignore these members (NORMATIVE §7.4) but are encouraged to preserve them across round trips so authoring provenance survives a transfer through third-party tools.