# SREL/Control-1 — Controls Exchange Profile Specification v1

**URN:** `urn:srel:profile:control:v1`
**Status:** Stable.
**Depends on:** the meta-language ([`srel-meta-v1.md`](srel-meta-v1.md)) and the AI Risk coordinate substrate ([`srel-ai-v1.md`](srel-ai-v1.md)).
**Normative grammar:** [`../grammar/srel-control-1.abnf`](../grammar/srel-control-1.abnf).
**Field reference:** [`../reference/control-1-fields.md`](../reference/control-1-fields.md).
**Conformance keywords:** MUST, SHOULD, MAY per RFC 2119 / RFC 8174.

## 1. Purpose

The Controls Exchange profile expresses the controls governing a deployed AI system in the **same coordinate space** as the risk it addresses. The control at coordinate `g.p` addresses, by structural placement, the risk primitive at `g.p` — with no out-of-band mapping table and no external controls-catalog dictionary. No prior controls language places controls and risks in a common coordinate space; that co-location is the profile's reason for existing.

## 2. Document structure

    control-meta-header · [control."g.p"]+ · [meta_control] ·
    [control_composite] · [provenance] · [[incident]]* · [operating_context]?

### 2.1 Header and deployment forms

The meta-header plus a profile declaration and a reference to the risk document it controls (`risk_document_ref`, with optional `risk_document_hash` and `hash_algorithm`). Two deployment forms:

- **Paired form** — risk document `D_r` and control document `D_c` are two documents linked by bidirectional reference fields, supporting organizational separation of risk identification from control implementation and independent update cadences. Declared with `schema_version = "urn:srel:profile:control:v1"`.
- **Combined form** — one document declares both profile URNs in `schema_versions = ["urn:srel:profile:ai:v1", "urn:srel:profile:control:v1"]`.

Both forms produce identical polarity vectors, cascade composites, and measurability-adjusted composites by construction.

### 2.2 `[control."g.p"]`

One section per controlled coordinate. The set need not be complete; unaddressed coordinates default to zero control coverage in the polarity calculation.

| Field | Values | Meaning |
|---|---|---|
| `code`, `name` | token, string | control identity |
| `risk_primitive_addressed` | coordinate | echoes the section key |
| `control_strategy` | `mitigate` / `transfer` / `accept` / `avoid` | disposition |
| `implementation_status` | `implemented` / `planned` / `in_progress` / `not_applicable` / `deferred` | state |
| `lifecycle_stage` | `identified` / `assessed` / `controlled` / `monitored` / `automated` | maturity |
| `coverage` | `[0,1]` | fraction of the coordinate's risk the control addresses |
| `omega_star` | `[0,1]` | control orientation / effectiveness |
| `measurability` | `measured` / `estimated` / `unmeasurable` / `deferred` | evidential basis |
| `evidence_refs`, `last_assessed`, `assessor` | URIs, datetime, string | provenance of the assessment |

When `control_strategy = "accept"`, `acceptance_authority` and `acceptance_expiry` are REQUIRED: an accepted risk MUST name who accepted it and when the acceptance lapses.

`coverage` and `implementation_status` are orthogonal — a control may be fully implemented yet cover only part of a coordinate's risk, and this is recorded, not collapsed.

### 2.3 `[meta_control]` — seven meta-conditions

Seven subsections — `KILL`, `SAF`, `HITL`, `AUT`, `TRU`, `MAN`, `EFF` — each carrying `attestation` (boolean), `evidence_refs`, `mechanism`, `tested_at`, `next_test_due`, and `confidence` in `[0,1]`. The first six mirror the AI Risk meta-conditions at the control level.

The seventh, **EFF (efficacy-precedes-efficiency)**, is specific to controls: it collapses the composite to zero if any control reaches lifecycle stage `automated` without a prior efficacy demonstration — `measured` measurability, a fresh assessment, and a prior `monitored` evaluation in the document's lineage. EFF structurally enforces that a control be proven effective before it is automated. Like the other meta-conditions it is non-compensating: its failure gates the composite rather than discounting it.

### 2.4 `[control_composite]`

Group-wise aggregates — `mean_omega_star_by_group`, `coverage_by_group`, `strategy_distribution`, `lifecycle_distribution` — the `meta_attestation_product` (boolean), and the `control_composite_score` (integer `[0,1000]`). The composite is gated by `meta_attestation_product`: a failed meta-condition drives the composite to its worst region rather than averaging it back. The aggregation form is non-compensating across groups; the numeric thresholds and weights are calibration and are not fixed by this specification.

### 2.5 `[provenance]` — lineage

Hash-pinned document lineage: `document_id`, `issued_at`, `issued_by`, `prior_document_ref` and `prior_document_hash` (or `null`), `hash_algorithm` (`sha-256` / `sha-512` / `sha3-256` / `sha3-512`), a `change_reason` (`scheduled_review` / `incident_response` / `capability_change` / `regulatory_update` / `deployment_change` / `discretionary`), and a `change_summary`. Provenance is REQUIRED in any document participating in a lineage chain, so that a control asserted at time *t* cannot silently outlive the configuration it described.

### 2.6 `[[incident]]` — outcome validation

Zero or more observed risk events, each with `incident_id`, `occurred_at`, `affected_coordinates`, `severity` (`informational` / `elevated` / `critical` / `catastrophic`), a `retrospective_link`, `predicted_in_advance` (boolean), `cascade_match` in `[0,1]`, and `controls_engaged`. Incident sections let a deployment record, in the same document, whether the coordinate space anticipated a real event — the basis for the decile-lift validation the scoring model relies on.

### 2.7 `[operating_context]` (optional)

Deployment context that configures threshold parameters: `deployment_domain`, `user_population`, `jurisdictions`, `criticality_tier` (`low` / `moderate` / `high` / `frontier`), `modal_use_case`, `review_cadence`, and `system_age_days`.

## 3. Paired risk-side fields

For paired deployment, the grammar permits optional assessment-metadata fields on any `[primitive."g.p"]` section of the risk document (`assessor`, `assessment_method`, `evidence_refs`, `last_assessed`, confidence bounds, `measurability`, `lifecycle_stage`, `agency_salient`). These are REQUIRED where a deployment implements the measurability-adjusted composite or the EFF meta-condition, and OPTIONAL otherwise.

## 4. Coverage-gap report

A conforming implementation can derive a **coverage-gap report** structurally — enumerating absent, under-implemented, shadow-drift, stale, expired-acceptance, and inversion coordinates — computable without semantic interpretation of any natural-language field. The gap report is the operational output of placing controls and risks in one coordinate space.

## 5. Conformance

A document conforms to the Controls Exchange profile if it presents a valid control-meta-header in one of the two deployment forms, at least one `[control."g.p"]` with all fields in range (and acceptance fields present whenever the strategy is `accept`), the seven `[meta_control]` subsections, `[control_composite]`, and `[provenance]`; and if EFF holds — no `automated` control lacks its prior efficacy demonstration. Calibration values are neither required to be disclosed nor validated by this specification.