5 Schema Definition

5.1 JSON Schema

CLE is formally specified by a Draft 2020-12 JSON Schema.

Each published version of the specification is accompanied by a versioned meta-schema at a stable URI:

https://cle.example.com/schema/cle-<major>.<minor>.<patch>.schema.json

Every CLE document MUST include a top-level $schema field whose value is the URI of the meta-schema for the version it follows.

The $schema field serves two purposes:

  • Validation – It allows tooling to validate that the document is structurally correct and conforms to the CLE specification.
  • Version Signaling – It identifies the version of the CLE specification the document follows, so consumers can parse and interpret it accordingly.

5.2 Top-level Fields

Table 1: Required Fields
Field Type Description
$schema string URI identifying the JSON Schema document that describes the version of the CLE schema to use.
identifier string or array[string] Component identifier(s) in the PURL format. When an array is provided, each identifier alias must identify the exact same bits from the same software but distributed differently.
updatedAt string ISO 8601 timestamp indicating when this CLE document was last updated.
events array Ordered array of Event objects representing the component's lifecycle events. MUST be ordered by ID in descending order (newest events with highest IDs first).
Table 2: Additional Fields
Field Type Description
definitions object Container for reusable policy definitions that can be referenced throughout the document.
index string URL pointing to the index file that lists all CLE pages for this component. Only allowed to be present when pagination is used.
next string URL pointing to the next CLE page containing newer events (higher event IDs).

5.3 Definitions Object

The definitions object allows specification of reusable policies and calculations that can be referenced by events.

5.3.1 Support Definitions

The support object defines the support policies provided for a specific version or version range of a component. This may include first-party manufacturer support or third-party support options endorsed by the manufacturer.

Support policies are immutable once defined - the semantics and meaning of a support policy MUST NOT change over time for a given support policy ID. This ensures consistent interpretation of support commitments across the component's lifecycle.

Table 3: Support Policy Fields
Field Type Required Description
id string Yes Unique identifier for the support policy.
description string Yes Human readable description of the policy.
url string No URL to detailed documentation about this support policy.

5.4 Event Object

The base object that represents a discrete lifecycle event. All events share these common fields.

Events are immutable once created - the content and meaning of a specific event MUST NOT change after it has been published. Additionally, the ordering of events across shards MUST NOT change.

Table 4: Event Required Fields
Field Type Description
id integer A unique, auto-incrementing integer identifier for the event.
type string The type of lifecycle event. MUST be one of the defined Event Types.
effective string The time when the event takes effect, as an ISO 8601 formatted timestamp in UTC.
published string The time when the event was first published, as an ISO 8601 formatted timestamp in UTC.