# SREL Meta-Language — Specification v1

**URN:** `urn:srel:meta:v1`
**Status:** Stable.
**Normative grammar:** [`../grammar/srel-meta-v1.abnf`](../grammar/srel-meta-v1.abnf) (ABNF, RFC 5234).
**Wire format:** TOML 1.0.0 (`.srel`), with JSON, YAML, or XML embodiments satisfying the same grammar also conformant.
**Conformance keywords:** MUST, SHOULD, MAY are interpreted per RFC 2119 / RFC 8174.

## 1. Purpose

SREL (Semantic Risk Exchange Language) is a meta-language for exchanging AI risk and control information as structured, verifiable documents. The meta-language defines the document skeleton — a typed header and a body of named sections — and hosts domain **profiles** that add their own required sections. This document specifies the meta-language only; the AI Risk profile and the Controls Exchange profile are specified separately.

The design goal is that a document's meaning never depends on where it was served from. Identity is carried by URN, not URL; integrity is carried by content hash, not origin.

## 2. Document model

An SREL document is a meta-header followed by one or more sections:

    srel-document = meta-header 1*section

### 2.1 Meta-header

Every document MUST begin with four header fields, in order:

| Field | Value | Meaning |
|---|---|---|
| `schema_version` | a profile version-URN | the profile the document conforms to |
| `assessment_id` | UUID string | unique identity of this assessment instance |
| `timestamp` | ISO-8601 datetime | when the assessment was produced |
| `system_id` | identifier string | the assessed system |

Additional header-extension lines MAY follow. A profile MAY require further header fields (for example, the AI Risk profile requires a `register` declaration).

### 2.2 Version-URN

    version-urn = "urn:srel:profile:" profile-name ":v" 1*DIGIT

The `schema_version` value identifies both the profile and its integer version, e.g. `urn:srel:profile:ai:v1`. A document declaring multiple profiles (see the Controls Exchange profile's combined form) uses a `schema_versions` array of version-URNs.

### 2.3 Sections

    section = section-header *key-value-line

Sections are TOML tables. A single table is written `[section.path]`; an array-of-tables is written `[[section.path]]` and MAY repeat. Section paths are dot-separated; a subsection component MAY be a quoted key, which is how coordinate-addressed sections are written — e.g. `[primitive."III.P3"]`.

Keys are `identifier = value`. Values are the TOML value types (string, number, boolean, array, inline-table, datetime). Lexical primitives are inherited from TOML 1.0.0 and are not redefined here.

## 3. Identity and integrity

- **URN identity.** Profiles are identified by URN per RFC 8141. A document is interpreted against the profile named in its `schema_version`, regardless of serving location.
- **Content integrity.** Every normative artifact of the specification is listed with its SHA-256 digest in [`../integrity/SHA256SUMS`](../integrity/SHA256SUMS); any copy can be verified against it with `sha256sum -c`. Signed releases are planned; until a signing key is published, the manifest provides integrity (tamper evidence), not authenticity (proof of publisher).
- **Canonical text.** The canonical specification is the text at `srel.net`. Copies mirrored on code-hosting platforms are collaboration venues and are labeled as such.

## 4. Profiles

The meta-language hosts multiple domain profiles. Each profile inherits this document model and adds its own required sections and semantic constraints. Profile identifiers follow `urn:srel:profile:<domain>:v<N>`. Two profiles are specified today:

- **AI Risk** — `urn:srel:profile:ai:v1` — [`srel-ai-v1.md`](srel-ai-v1.md)
- **Controls Exchange** — `urn:srel:profile:control:v1` — [`srel-control-v1.md`](srel-control-v1.md)

Additional profiles (cybersecurity, model risk, climate, biological risk, infrastructure) are planned. Optional extensions add single keys to coordinate-keyed sections without changing any required section; an extension is declared by including its URN in a `schema_extensions` array, and a validator unaware of an extension MUST ignore its keys.

## 5. Conformance

A document conforms to the meta-language if it presents a well-formed meta-header followed by one or more well-formed sections, and its `schema_version` names a profile version-URN. Conformance to a *profile* additionally requires the sections and constraints that profile specifies. Constraints expressed as ABNF comments (for example, that a numeric field lies in `[0,1]`) are semantic and are enforced by the validator, not by the grammar.