Skip to content

I1025 — The federated model and its two projections are an architecture decision

Record the decision to compose the authoritative registries into one typed graph and to render it as two projections, with the alternatives that were real and the consequences that follow.

DONE wave 1 · p1 · implementation profile · parallel safe

Part of capability-graph — One capability graph, two projections, and no second inventory of what this repository can do.

Objective

Record the decision to compose the authoritative registries into one typed graph and to render it as two projections, with the alternatives that were real and the consequences that follow.

Why

The choices here — composing rather than centralising, generating rather than fetching, progressive enhancement rather than a client application, availability as metadata rather than a condition in a page — will each look arbitrary to somebody later. ADR 12 decided the Cockpit is a projection; this decides what it is a projection of.

Current state

ADR 12 establishes the Cockpit as a projection of the registry. ADR 13 establishes that web surfaces are discovered from their producers. Neither covers the composed graph or the static projection.

Desired state

One record states the decision, extends rather than restates the two it follows, and says what would have to change to revisit it.

Scope

  • .ai/repo/adrs

Out of scope

  • Restating ADR 12 or ADR 13
  • An ADR that documents the implementation instead of the decision

Dependencies

What waits on this

Acceptance criteria

  • The record follows the repository's ADR format and frontmatter exactly and relates to the decisions it extends
  • It states the federated composition, the dual projection, progressive enhancement, availability as metadata and the conditional exposure of runtime surfaces
  • The alternatives — one central manifest, a client-side application fetching the API, a separate site generator — are recorded with why they were not taken
  • The consequences state what a new subsystem must do to appear, and what it costs when it does not

Validation

  • bin/majordomus doctor
  • bash test/run.sh

Evidence required

  • adr_recorded

Evidence

coverstypecommandresultat commit
adr_recordedtestbin/majordomus adr check; bin/majordomus doctor; bin/majordomus context validate; bash test/run.sh 99_adradr-0018 written at .ai/repo/adrs/0020-the-capability-graph-is-composed-not-centralised-and-projecte.md: adr check accepts the whole set with every identity unique and every reference resolving, doctor reports no failure, context validate reports no problem, and the ADR behavioural case passes665f1c4

Risk

Written last, it becomes a summary of the code. It is written when the choice between composing and centralising is still open.

Timeline

started
2026-09-06T16:23:01Z
verified
completed
2026-09-06T16:54:54Z

Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.

Canonical record: .ai/repo/project/issues/I1025.yaml. Read it back with majordomus plan show I1025.