10. Extensions and profiles

This section is normative.

Extensions add data, profiles add rules. Neither may change what the core means.

10.1 Extensions

• Each key in extensions MUST be a namespace: a reverse-DNS name such as com.acme.jira or an absolute URI. Its value MAY be any JSON value.
• Extensions MUST NOT change the meaning of core fields.
• Consumers MUST ignore namespaces they do not understand and MUST NOT reject a record because of them. When storing or forwarding a record, consumers MUST preserve all extensions unchanged, because digests cover them.
• Extensions are part of the record. For intents, they are therefore covered by the intent digest, and changing them requires a new version.

"extensions": {
  "com.acme.jira": { "issueKey": "PORTAL-1187", "sprint": "2026-21" }
}

10.2 Profiles

• A profile is a published document, identified by an absolute URI, that adds constraints to the core. It can make optional fields required, narrow enumerations, require signing or define extension namespaces with their schemas.
• A profile MUST NOT relax any core requirement.
• A record that lists a profile in profiles MUST satisfy that profile.
• A profile SHOULD publish a JSON Schema that composes with Appendix B through allOf.
• Profiles are listed in a registry in the public repository.

As an example of the intended use, a profile for regulated industries could require risk on every intent, a human actor for every intent-approval and release decision, signed passports, and no production datasets as test inputs.