Authority Contract¶

An Authority record answers exactly one question: "who or what decides, for this domain?" This contract defines the schema every Authority record must satisfy. The populated instances live in the Portfolio Registry; the domain-level registry data is also stored in Authority-Registry.yaml (validated by Authority-Registry.schema.json). Note: Authority-Registry.md referenced in older documents does not exist — use Authority-Registry.yaml directly.

1. Required Fields¶

Field	Type	Description
`id`	string, unique	e.g. `AUTH-SECRETS-001`.
`domain`	string	The concern this authority governs, e.g. `Secrets`, `Source Control`, `Runtime Compute`.
`authority`	string	The system or entity that decides, e.g. `1Password`, `GitLab`, `Terraform`.
`kind`	enum	`SOURCE` (owns the definition) or `OPERATIONAL` (owns execution) — see Authority Boundary Rules §1. Never both on one record; a domain needing both gets two records.
`scope`	string	What is and isn't covered — precise enough that a second reader can determine whether a given concern falls inside or outside it.
`standard`	string	The governing document (ADR, standard, or agreement) that established this authority.
`escalation`	string	Who/what resolves a conflict when two authorities both claim this domain.
`status`	enum	`ACTIVE`, `PROPOSED`, `SUPERSEDED`.

2. One Authority Per Domain-Kind Pair¶

A (domain, kind) pair resolves to exactly one ACTIVE authority record. If evidence suggests two, that is a DRIFT_DETECTED condition (per Mutation Gates §Operating Law — standards/agents/mutation-gates.md does not exist anywhere in this repository, OBSERVED 2026-08-19; the concept is used operationally in decision-records/ADR-0004-consume-contractplane-as-service.md but has no canonical document. Route: REGISTRAR_PLATFORM_ENGINEERING_MISSING_DOCS_001) requiring an Architecture-role decision, not a documentation footnote.

3. Relationship to Capability¶

An Authority record never itself describes what is provided — that's a Capability record. An Authority is referenced BY capability records (Capability.authority_ref), never the reverse.

4. Worked Examples (real entities, migrated from Authority-Registry.md)¶

- id: AUTH-SECRETS-001
  domain: Secrets
  authority: 1Password
  kind: OPERATIONAL
  scope: Secret lifecycle (storage, rotation, injection at runtime)
  standard: Agreement 12
  escalation: Bluefly Security
  status: ACTIVE

- id: AUTH-SOURCE-001
  domain: Source Control
  authority: GitLab
  kind: SOURCE
  scope: Git history, MR workflow, protected-branch merge
  standard: ADR-0005
  escalation: Engineering Standard governance
  status: ACTIVE

- id: AUTH-RUNTIME-001
  domain: Runtime Compute
  authority: OCI (Oracle Cloud Infrastructure)
  kind: OPERATIONAL
  scope: Running infrastructure (VMs, disks, networking)
  standard: ADR-0005
  escalation: Engineering Standard governance
  status: ACTIVE

This contract governs Authority structure only. See Capability Contract for what Authorities provide, and Portfolio Object Model for how Authority relates to Product/Pack/Deployment.