# Relationship capability catalogue

Discover the service's current permission definitions when constructing an
integration or a capability-selection interface. Definitions describe actions
and profiles; they do not authenticate a caller, enroll it or grant project
access.

| Route | Authentication | Request | Success |
| --- | --- | --- | --- |
| GET `/v1/capabilities.json` | None | No request fields | Raw JSON catalogue, without the protected-operation response envelope. |

```bash
curl --fail-with-body --silent --show-error \
  'https://api.relationship.service.m7.org/v1/capabilities.json'
```

The document includes integer `catalogue_version`, `families`, primitive
`capabilities`, `presets` and `role_defaults`. A primitive names its `id`,
`family` and `operation` (`read` or `write`). Presets provide exact capability
expansions with an `expansion_version`; role mappings identify a preset and
its expansion revision or null. Additional metadata may describe definitions.
Catalogue versions identify coherent snapshots; fetch the current catalogue
rather than hardcoding an inventory from an example.

Explicit profile selections replace role fallback. Unknown selections grant
nothing, and an explicit nonempty unknown profile does not fall back to a more
permissive role. Use the selected primitive set as input to your own permission
logic. Relationship itself still checks current admission, project membership,
capabilities, role and workspace boundaries.

The response uses `Cache-Control: no-store`. If the catalogue cannot be loaded
or validated, discovery returns HTTP 503 and a failure envelope with
`status: 0` and `data.code: 503`. Treat it as unavailable rather than as an
empty grant list. See the
[common response rules](https://m7.org/docs/api/api.relationship.service.m7.org/README.md#requests-and-responses).