Skip to content
emergent engineering

CALIPER 1.2 — conformance status

Generated by bun run conformance:render — do not edit by hand.

Denominator: pinned Coverage Map docs/conformance/maps/caliper-v1.2.json (generated 2026-06-25). See conform-ed ADR-0013 (map) and emergent ADR-0028 (overlay).

Certification readiness (by profile)

Section titled “Certification readiness (by profile)”
Profile Requirements Done Partial Other Progress
endpoint 6 6 0 0 ████████████████ 100%
entity 1 1 0 0 ████████████████ 100%
envelope 2 2 0 0 ████████████████ 100%
event 2 2 0 0 ████████████████ 100%
identifier 1 1 0 0 ████████████████ 100%
sender 6 5 0 1 █████████████░░░ 83%
serialization 3 3 0 0 ████████████████ 100%
vocabulary 3 3 0 0 ████████████████ 100%

Conformance requirements

Section titled “Conformance requirements”

endpoint

Section titled “endpoint”
Req Level Status Evidence Statement
CAL-EP-1 MUST ✅ done caliper:1.2:conf:endpoint/CAL-EP-1 A Caliper Endpoint MUST be capable of receiving Caliper data sent over HTTP POST by a Sensor over a TLS-secured connection with a valid certificate, and MUST support Bearer (RFC 6750) authentication on the HTTP Authorization request header.
CAL-EP-2 MUST ✅ done caliper:1.2:conf:endpoint/CAL-EP-2 Following receipt of a Sensor request the Endpoint MUST reply with an HTTP response message, and to signal successful receipt MUST reply with a 2xx class status code.
CAL-EP-3 SHOULD ✅ done caliper:1.2:conf:endpoint/CAL-EP-3 On success the Endpoint SHOULD use the 200 OK response and SHOULD send back successful responses with an empty body.
CAL-EP-4 MUST ✅ done caliper:1.2:conf:endpoint/CAL-EP-4 When an Endpoint replies with a non-2xx response it MUST adhere to the defined status codes: 400 Bad Request for a missing or malformed Envelope, 401 Unauthorized for an unauthorized request, 415 Unsupported Media Type for a non-application/json content type, and 422 Unprocessable Entity when it cannot support the Envelope’s dataVersion.
CAL-EP-5 MUST ✅ done caliper:1.2:conf:endpoint/CAL-EP-5 On receiving a GET status (ping) request with appropriate authorization, an Endpoint MUST respond with 200 OK and a JSON body containing its configuration parameters, including the required caliperSupportedVersions list; each configuration property MUST be included no more than once and no custom properties are permitted.
CAL-EP-6 SHOULD ✅ done caliper:1.2:conf:endpoint/CAL-EP-6 If a status (ping) request arrives without an Authorization header of the RECOMMENDED form, or with a token the Endpoint cannot validate or that lacks sufficient privilege, the Endpoint SHOULD reply with a 401 Unauthorized response.

entity

Section titled “entity”
Req Level Status Evidence Statement
CAL-ENT-1 MUST ✅ done caliper:1.2:conf:entity/CAL-ENT-1 Every Caliper Entity MUST carry a type matching the Caliper term for the entity (e.g. Person) and an id that is a unique, persistent IRI.

envelope

Section titled “envelope”
Req Level Status Evidence Statement
CAL-ENV-1 MUST ✅ done caliper:1.2:conf:envelope/CAL-ENV-1 A Caliper Envelope MUST carry the emitting sensor, the dataVersion IRI, a sendTime, and the data payload.
CAL-ENV-2 MUST ✅ done caliper:1.2:conf:envelope/CAL-ENV-2 The Envelope sendTime MUST be expressed in UTC with millisecond precision (YYYY-MM-DDTHH:mm:ss.SSSZ, no offset); the dataVersion MUST be set to the 1EdTech Caliper context IRI governing the payload; the data array MUST carry one or more Event/Entity describe objects; and each Envelope property MUST be referenced only once with no custom properties permitted.

event

Section titled “event”
Req Level Status Evidence Statement
CAL-EVT-1 MUST ✅ done caliper:1.2:conf:event/CAL-EVT-1 Every Caliper Event MUST identify the actor, the action performed, and the object it was performed on.
CAL-EVT-2 MUST ✅ done caliper:1.2:conf:event/CAL-EVT-2 Every Caliper Event MUST also carry its id, a type matching the Caliper term for the event, and an eventTime expressed in UTC (YYYY-MM-DDTHH:mm:ss.SSSZ).

identifier

Section titled “identifier”
Req Level Status Evidence Statement
CAL-ID-1 MUST ✅ done caliper:1.2:conf:identifier/CAL-ID-1 Every Caliper Event id MUST be a UUID expressed as a urn:uuid: (RFC 4122); every Entity id MUST be a unique, persistent IRI.

sender

Section titled “sender”
Req Level Status Evidence Statement
CAL-SND-1 MUST 🔲 todo — A Caliper Sensor MUST be capable of transmitting Caliper data successfully to a Caliper Endpoint over HTTP with the connection encrypted using Transport Layer Security (TLS).
CAL-SND-2 MUST ✅ done caliper:1.2:conf:sender/CAL-SND-2 Each message request a Sensor sends MUST consist of a single JSON representation of a Caliper Envelope, and messages MUST be sent using the HTTP POST request method.
CAL-SND-3 MUST ✅ done caliper:1.2:conf:sender/CAL-SND-3 A Sensor MUST set the HTTP Host and Content-Type request header fields; the Content-Type value MUST be the IANA media type “application/json”.
CAL-SND-4 SHOULD ✅ done caliper:1.2:conf:sender/CAL-SND-4 A Sensor SHOULD set the Authorization request header field using the “Bearer” authentication scheme (RFC 6750 §2.1); the b64token credential sent MUST be one the Endpoint can validate, although it MAY be opaque to the Sensor.
CAL-SND-5 MUST ✅ done caliper:1.2:conf:sender/CAL-SND-5 A Sensor MUST serialize each Event and Entity describe as a JSON-LD document, and Caliper Event and Entity data MUST be transmitted inside a Caliper Envelope (never outside one).
CAL-SND-6 MUST ✅ done caliper:1.2:conf:sender/CAL-SND-6 A Sensor MUST ensure that the Caliper data it sends is based on one of the Caliper JSON-LD context document versions listed in the Endpoint’s caliperSupportedVersions configuration.

serialization

Section titled “serialization”
Req Level Status Evidence Statement
CAL-SER-1 MUST ✅ done caliper:1.2:conf:serialization/CAL-SER-1 Each Caliper Event and Entity describe document MUST carry a top-level @context property defined as a string or an array. If a string it MUST be the Caliper remote context URL “http://purl.imsglobal.org/ctx/caliper/v1p2”; if an array the remote Caliper context MUST be listed last. The remote context’s terms MUST NOT be redefined inline as an object, nor overridden by nested local contexts.
CAL-SER-2 MUST ✅ done caliper:1.2:conf:serialization/CAL-SER-2 An Event’s entity-valued properties — the actor and object, and any edApp, generated, target, referrer or group — MUST each be expressed either as an object or as a string corresponding to the resource’s IRI (Caliper’s reference-or-inline duality).
CAL-SER-3 MUST ✅ done caliper:1.2:conf:serialization/CAL-SER-3 Within an Event or Entity each property MUST be referenced only once, and any custom attribute not described by the Caliper model MUST be added to the extensions property rather than as an ad-hoc top-level term.

vocabulary

Section titled “vocabulary”
Req Level Status Evidence Statement
CAL-VOCAB-1 MUST ✅ done caliper:1.2:conf:vocabulary/CAL-VOCAB-1 An Event’s action MUST be a term drawn from the Caliper action vocabulary (the term appropriate to the event’s metric profile).
CAL-VOCAB-2 MUST ✅ done caliper:1.2:conf:vocabulary/CAL-VOCAB-2 Caliper’s controlled vocabularies MUST be honoured: an AggregateMeasure metric is a Caliper metric term, an entity status is Active or Inactive, and a sensor declares the metric profiles it supports as Caliper profile terms.
CAL-VOCAB-3 MUST ✅ done caliper:1.2:conf:vocabulary/CAL-VOCAB-3 A Membership’s roles MUST be drawn from the Caliper role vocabulary — the eight base roles (Learner, Instructor, …) and their Base#Subrole specialisations.

Information-model coverage (vs conform-ed model)

Section titled “Information-model coverage (vs conform-ed model)”
  • 2052 literal items — 1693 modelled ✅, 0 partial 🟡, 0 gaps ❌
  • Silent gaps (in spec, not modelled): none
  • conform-ed extensions (modelled, not in spec): 177

Gotchas & notes

Section titled “Gotchas & notes”
  • caliper:1.2:conf:endpoint/CAL-EP-1
    • Interop-proven: the Endpoint receives Caliper data over HTTP POST and authenticates the Bearer Authorization header (an unauthenticated POST is 401; an authenticated one is accepted).
  • caliper:1.2:conf:endpoint/CAL-EP-2
    • Interop-proven: on success the Endpoint replies with a 2xx — the worker only marks rows sent on a 2xx, so a fully-sent batch proves the success response.
  • caliper:1.2:conf:endpoint/CAL-EP-3
    • Interop-proven: the Endpoint replies 200 OK with an empty body on success (asserted directly in the endpoint unit suite and exercised by the interop accept path).
  • caliper:1.2:conf:endpoint/CAL-EP-4
    • Interop-proven: the Endpoint returns 400 (malformed Envelope), 401 (unauthorized), 415 (non-application/json), and 422 (unsupported dataVersion), each asserted in the lane.
  • caliper:1.2:conf:endpoint/CAL-EP-5
    • Interop-proven: an authorized GET status (ping) returns 200 with a config body carrying the required caliperSupportedVersions list (and only the config properties).
  • caliper:1.2:conf:endpoint/CAL-EP-6
    • Interop-proven: a status (ping) request without a valid Authorization header is answered 401.
  • caliper:1.2:conf:entity/CAL-ENT-1
    • Interop-proven: every emitted Entity (actor / object / generated) carries a Caliper type and a persistent IRI id, asserted across all 8 metric profiles in the interop lane.
  • caliper:1.2:conf:envelope/CAL-ENV-1
    • Interop-proven: the assembled Envelope carries the emitting sensor, dataVersion, sendTime, and the data payload, and validates against conform-ed’s EnvelopeSchema.
  • caliper:1.2:conf:envelope/CAL-ENV-2
    • Interop-proven: sendTime is UTC millisecond precision, dataVersion is the Caliper context IRI, data carries one or more items, and the strict EnvelopeSchema rejects custom properties.
  • caliper:1.2:conf:event/CAL-EVT-1
    • Interop-proven: every projected Event validates against conform-ed’s validateCaliperEvent (actor / action / object present and well-typed) for each of the 8 profiles.
  • caliper:1.2:conf:event/CAL-EVT-2
    • Interop-proven: emitted Events carry an id (urn:uuid), a type, and a UTC millisecond-precision eventTime (asserted by regex against every emitted event).
  • caliper:1.2:conf:identifier/CAL-ID-1
    • Interop-proven: Event ids are deterministic urn:uuid v5 of the source idempotency key (re-deriving the id from the same sourceKey is stable); Entity ids are persistent IRIs.
  • caliper:1.2:conf:sender/CAL-SND-2
    • Interop-proven: the transport worker batches a pending outbox set into a single Envelope and issues exactly one POST (asserted: one POST request carrying all events).
  • caliper:1.2:conf:sender/CAL-SND-3
    • Interop-proven: the POST sets Content-Type application/json (Host is set by the runtime from the URL); asserted on the recorded request headers.
  • caliper:1.2:conf:sender/CAL-SND-4
    • Interop-proven: the POST sets the Bearer Authorization header with the endpoint credential, and the Endpoint authenticates it (the Envelope is accepted, not 401).
  • caliper:1.2:conf:sender/CAL-SND-5
    • Interop-proven: every Event is serialized as a JSON-LD document inside the Envelope (never outside one) and the Endpoint extracts all of them from the single delivered Envelope.
  • caliper:1.2:conf:sender/CAL-SND-6
    • Interop-proven: the worker GETs the Endpoint status ping and only POSTs after confirming our dataVersion is in caliperSupportedVersions (a GET precedes the POST; an unsupported version backs off).
  • caliper:1.2:conf:serialization/CAL-SER-1
  • caliper:1.2:conf:serialization/CAL-SER-2
    • Interop-proven: entity-valued slots (actor / object / generated / target / edApp / group) are emitted as id+type objects — the reference-or-inline duality — and validate.
  • caliper:1.2:conf:serialization/CAL-SER-3
    • Interop-proven: the strict per-event schema accepts each emitted event, proving every property is referenced once and no ad-hoc top-level term is present (custom data would go in extensions).
  • caliper:1.2:conf:vocabulary/CAL-VOCAB-1
    • Interop-proven: validateActionVocabulary confirms every emitted action is a Caliper Action term its event-type profile rule permits (drift guard against conform-ed’s ActionSchema + textual rules).
  • caliper:1.2:conf:vocabulary/CAL-VOCAB-2
    • Interop-proven (ADR-0048): all three controlled vocabularies are honoured — a de-identified package AggregateMeasure carries a Caliper Metric term (UnitsCompleted/UnitsPassed from package_progress), the emitted Membership carries an Active/Inactive Status, and every emitted event profile is a Caliper Profile term (a drift guard like CAL-VOCAB-1’s for actions). The AggregateMeasure rides an entity-describe emission path alongside events in one Envelope.
  • caliper:1.2:conf:vocabulary/CAL-VOCAB-3
    • Interop-proven: the AssessmentItem and Forum readers join offering_membership and emit a Caliper Membership (member = the pseudonymous actor, organization = the section/group) whose roles map the emergent offering role (learner/teacher/assistant/observer/mentor) to a Caliper Role term, validated against the contract’s Role vocabulary.