Skip to main content
One file per system Fleet Manager observes, is actuated by, projects to, depends on to run, or shares custody with. The decision and the rules are in ADR-0046 (docs/adr/0046-fleet-manager-relationship-register.md). Each file records present behaviour as read from the code and the OAuth client roster in deployment/charts/hub/values.yaml; it is not a negotiation.

​
Adding or changing a relationship

  1. Copy the template to <counterpart-slug>.mdx and fill every section. A relationship gets a page only once it runs; planned integrations are opened by the counterpart team when they land. Unknown counterpart owners are written as unassigned, never guessed.
  2. Open a pull request. GitHub requests both owning teams for review; an approval from either satisfies the code-owner gate today, so counterpart approval is a convention until a ruleset enforces it. Raise the request in the engineering work-request channel so the counterpart team sees it.
  3. Land the OAuth client, scopes and any pact or contract test in the same change where the relationship is new.
  4. When either side changes the behaviour a file describes, change the file in the same pull request and bump its version.
Every actuation or projection page lists the principals the counterpart uses to reach Fleet Manager. One principal per relationship is the goal, not the current state: CHAD lists three clients, Radar and OpenStack list two, and Reservation lists none. Custody pages have no principal. Today a principal is an OAuth client in the hub chart roster; when Fleet Manager’s service authentication moves onto Auth0 and uni-identity, the page keeps its principals and only the mechanism line changes. Nothing lapses because a relationship is quiet. Only counterpart ownership of an actuation or projection page lapses, and the freeze is a manual procedure, not automation. The thirty-day clock starts when the Fleet Manager squad learns the counterpart owner has left, through that team’s offboarding notice or, failing that, the quarterly register review; a departure right after a review can therefore go unnoticed for up to a quarter. Once the clock runs out with nobody claiming the page, the squad removes the write scopes of the counterpart’s principals listed on that page by pull request to the hub chart roster and records it in the change log. Read scopes are never frozen, and observation, dependency and custody pages are never frozen because their principals are Fleet Manager’s own agents or none. The Fleet Manager side of a page may be owned by the squad; a named engineer is a claimant, not a precondition.