Profile authoring¶
A profile is a versioned schema module that refines one or more valid OCLP Core
records. Its profile binding appears at profiles[profile-id]; it cannot add
arbitrary top-level Core fields or weaken a Core invariant.
Minimum conformance package¶
Every published profile should provide:
| Component | Why it is needed |
|---|---|
| Normative specification | Defines meaning, applicability, compatibility, dependencies, and rules beyond structural validation. |
| Stable ID and independent version | Lets a producer make an unambiguous conformance claim. |
| JSON Schema where applicable | Makes the bounded binding or payload shape portable. |
| Valid and invalid vectors | Gives every implementation an executable contract. |
| Canonical JSON and digest values | Required when the profile defines a canonical JSON payload. |
| Semantic verifier | Covers rules that JSON Schema cannot express, such as cross-record resolution or event ordering. |
The profile author owns this package. Producers and consumers implement only the profiles they claim to support. A frontend renderer is not the profile definition; it is merely one consumer implementation.
Composition¶
Profiles may declare explicit dependencies on other profile IDs and compatible versions. Independent profile bindings can coexist on one Core record when their declared extension surfaces do not conflict. A profile must state which Core kinds and surfaces it governs—for example an Artifact payload, an Execution binding, or named Event data.
Start from this repository¶
The three maintained profiles provide practical templates. Copy their
specification, schemas, vectors, and verifier structure into the profile
owner's repository. Do not place new domain semantics in Core annotations if
they are intended to be interoperable; publish a profile contract instead.