Project standards

The platform should be compatible with as many of the relevant standards as possible.

Point-by-point implementation status lives in ../conformance/index.md (generated, per ADR-0028 — the spec-by-spec readiness tracker that supersedes the coarse Status: prose tags below). This page remains the narrative index of which standards we target and why; the generated conformance pages are the authoritative “where exactly are we” view, each measured against the literal published schema (conform-ed ADR-0013). Open Badges 3.0 is the first spec wired through it.

Critical technologies for initial version

LTI (Learning Tools Interoperability) Latest Version: LTI Advantage (LTI 1.3) Status: in-progress (paused; resumes next wave, Tool-side first) This is the gold standard for secure “plug-and-play.” LTI 1.3 uses modern security (OpenID Connect and OAuth2) to let a student click a link in your platform and be instantly logged into an external tool. The “Advantage” services also allow for the secure exchange of grades and roster data. Resumption (after the credential-lane v1 slice ships): Tool side — Deep Linking 2.0 + AGS grade passback for QTI assessments, validated against the conform-ed lti13 suite. The original blocker (no deliverable content) is gone now that QTI delivery exists. Platform side (hosting external tools) waits for a named product need. https://github.com/lti-tool/lti-tool
LRS learner record store See runbook: ../runbooks/lrs-conformance-suite.md Hard requirement: the spec-facing LRS is not complete or production-ready until the relevant upstream ADL conformance batteries are green, with full-suite compliance required before the LRS is treated as validated.
CLR (Comprehensive Learner Record) (which is a kind of LER (Learner Experience Record)) Standard, full spec: https://www.imsglobal.org/spec/clr/v2p0/ Status: validated (built & conformance-validated 2026-06-15; slices 5a–5c) The CLR assembler follows the Open Badges v1 slice (single signed AchievementCredential first); both share the issuer-profile, custody, and proof decisions in ADR-0015/0016/0017. Built to clr-export-v1.md (slice 5 of the credential lane): one platform-transcript ClrCredential per learner, bundling their granted-award achievements, signed on the existing issuer/KeySigner/JWKS machinery — adds no schema — with a conformance lane against the official 1EdTech CLR 2.0 schema (bun run test:clr:conformance).
xAPI/cmi5
- xAPI (Experience API / Tin Can) Latest Version: v2.0 (IEEE 9274.1.1) Designed to track learning “anywhere.” It uses “Actor-Verb-Object” statements (e.g., “Jane read the manual”). It is essential for tracking mobile learning, simulations, and offline activities. https://opensource.ieee.org/xapi/xapi-base-standard-documentation
- cmi5 Current Iteration: Sandstone (v1.0) Think of this as the “bridge” between SCORM and xAPI. It provides the structured rules of SCORM (launching, sequencing) but uses the powerful tracking engine of xAPI. If you are building a modern LMS, cmi5 is your future-proof choice. https://github.com/xapijs/cmi5
Caliper Analytics Latest Version: v1.2 Status: in-progress (planned for launch; reverses the earlier deferral — ADR-0041/0042) 1EdTech’s learning-analytics EVENT model and the parallel alternative to xAPI: a Sensor emits Envelopes of Events (actor/action/object) drawn from controlled metric-profile vocabularies. Product now wants maximal coverage before launch, so Caliper is adopted in both roles — emergent becomes a Caliper Sensor (emitter) and a Caliper Endpoint (receiver, extending the LRS into a dual-protocol telemetry store). Caliper rides a single shared telemetry projection seam off the session/event-log model (ADR-0007) that also gives emergent its first xAPI emitter; it stays a cheap derived projection, never a second instrumentation pass. All 15 metric profiles are claimed, building the missing surfaces (Media, Search, Survey) as real features. Done = internal conformance lane (test:caliper:conformance against the official 1EdTech Bootcamp schema) + dossier; the 1EdTech Caliper certification submission is a separate later milestone. Plan: caliper-conformance-v1.md Decisions: ADR-0041, ADR-0042 https://www.imsglobal.org/spec/caliper/v1p2

Mid-term implementation standards

SCORM (Sharable Content Object Reference Model) Latest Version: SCORM 2004 (4th Edition) The “old reliable.” It handles how a piece of content (a “package”) is launched and how it reports a single score or “completion” status back to your platform. While older, it remains the most widely used standard for corporate compliance training.
Open Badges Latest Version: v3.0 (on VC Data Model 2.0) Status: validated (slices 1–4 built & conformance-validated 2026-06-13) V1 slice: one OB 3.0 AchievementCredential per granted qualification_award, learner-pulled, sign-on-export. Proofs are VC-JOSE (JWT) with Ed25519 (ADR-0016); issuer keys are platform-custodial in Supabase Vault behind a KeySigner seam (ADR-0017); issuers are per-org Profiles with JWKS endpoints (ADR-0015). Verification is external via JWKS only in v1. The OB conformance lane is wired early (bun run test:ob:conformance), validating the signed export against the official 1EdTech OB 3.0 JSON Schema — not endgame QA. Status detail: slices 1–4 implemented & integration/conformance-validated 2026-06-13 (issuer/Vault/KeySigner/JWKS; OB assembly + learner-pulled export; conformance lane vs the official 1EdTech schema; Achievement.alignment to durable CASE node URIs). The CLR 2.0 assembler (slice 5) has since landed, so the credential-lane v1 milestone is complete. Starting brief: credential-export-v1-brief.md Design: credential-export-v1.md Runbooks: credential-issuer-keys.md, ob-conformance-suite.md https://www.imsglobal.org/spec/ob/v3p0/
CASE (Competency and Academic Standards Exchange) Latest Version: v1.1 Status: validated (core reshape, consumer, and provider/export all landed 2026-06-12/13; round-trip totality gate green — tests/integration/case-roundtrip.integration.test.ts) Boundary adapter over the neutral competency core, never the core itself (ADR-0018, repeating the ADR-0012 pattern): CFPackage consumer via staging + reconcile (file transport; REST lane deferred), CASE GUIDs/URIs as boundary bindings, and a CFPackage provider/export projection gated by a round-trip totality test. CASE’s deepest lesson is absorbed into core: durable Competency Nodes + per-edition revisions, cross-framework associations with the CASE association-type vocabulary, and the descriptive field set (neutral education_level/subject registries shared with OneRoster). Brief: case-competency-v1-brief.md; design: case-competency-v1.md
OneRoster Latest Version: v1.2 Status: validated (CSV + REST-delta consumer, full REST rostering provider, CSV export, gradebook + resource services, and the deferred-items campaign all landed 2026-06-12/13; round-trip CI gate green — tests/integration/oneroster-roundtrip.integration.test.ts) Perimeter: This standard automates the “rostering” process. Instead of manually uploading CSV files of students, your platform can securely pull class lists and student identities directly from a school’s Student Information System (SIS). Consumer/provider design: oneroster-consumer-v1.md, oneroster-provider-v1.md. Genuine residue (recorded, not blocking): resources → core projection and demographics projection stay boundary-only until a product need arrives; literal SIS-id passback awaits a concrete external target.
QTI (Question & Test Interoperability) Latest Version: v3.0.1 Status: planned The interoperability standard for assessment items and tests. QTI 3.0.1 ASI is adopted as the canonical internal assessment model (a superset: QTI core plus namespaced extensions), giving lossless interchange for items, tests, response processing, results reporting, usage data / item statistics, and CAT. Contracts are owned in conform-ed (@conform-ed/contracts, MIT); the runtime is a headless core (MIT) plus an emergent Mantine skin. See ADRs: 0001, 0002, 0003. https://www.imsglobal.org/spec/qti/v3p0/impl
CAT (Computer Adaptive Testing) Latest Version: v1.0 Status: validated (basic-but-real engine built & conformance-validated 2026-06-23; reverses the earlier “deferred” tag — ADR-0037) Not a QTI feature: per ADR-0005 CAT is the measurement-precision mode of the single Selection Policy. We ship a small, owned TypeScript engine (Rasch/1PL + EAP, max-info/randomesque selection, three-way stopping rule) behind the exact CatV1_0 seam an industrial engine would later occupy — the real @conform-ed/contracts/cat/v1_0 Zod contracts, invoked in-process. Item parameters are author/import-supplied and frozen per Item Version (no calibration data exists yet); a CAT Pool is gated to require a parameter set on every item. Server-anchored only (offline-complete CAT is a validation error). emergent claims the platform/delivery role and ships the reference engine, proven by the in-process interop lane; the standardized REST/OAuth transport binding is deliberately deferred (it lights up when an external engine is wired — the seam swap). Authoring (admin item-pool curation + teacher offering assignment) and the learner adaptive player are built across all three role UIs. See ADR: 0037. Conformance: cat-v1.0.md (6/8 — delivery + section done, operations partial pending the REST binding). https://www.imsglobal.org/spec/cat/v1p0/impl/

Deferred standards (decision recorded, no lane open)

SCORM 1.2 / 2004 Status: deferred (no contracts yet). Import/run only as opaque External Packages (ADR-0009), tracked via xAPI; never an authoring or export target.

Implementation mapping docs

Use these documents to map standards capabilities and events into the internal data model:

Where standards code lives (emergent vs conform-ed)

The schema/contract layer for every standard above already lives in the MIT @conform-ed/contracts package and is consumed by emergent. For the rule on which logic (artifact assembly, signing, conformance lanes) is reusable enough to promote to conform-ed versus which is bespoke Emergent glue (DB, custody, authz, sync), see Externalisation Boundary V1. Summary: the per-lane wire.ts is the extraction line; conformance lanes and VC-JOSE signing are the clear externalisation candidates, the OneRoster reconcile/provider engine is not.

Implementation status guidance

Status values used across architecture/integration docs:

planned: target documented but not implemented
in-progress: implementation started and partially validated
validated: implementation verified by automated tests and/or conformance checks

For xAPI and LRS-facing work, validated requires the relevant upstream ADL LRS Conformance Test Suite coverage in addition to internal tests; internal contract tests alone are not enough.