Skip to main content
  • Kind: Observation | Actuation | Projection | Dependency | Custody
  • Version: 1
  • Fleet Manager owner: <name>, <Slack channel>
  • Counterpart owner: <name or unassigned>, <team>, <Slack channel>
  • Last reviewed: <YYYY-MM-DD>

​
What flows

Observation: the endpoints or recording rules Fleet Manager reads, the fields it depends on, the polling cadence, and the freshness it assumes. Actuation: the job types the caller creates today, the OAuth client and scopes it holds, the guardrails Fleet Manager applies, and the failure-code contract the caller must honour. Projection: the endpoints, event subjects, SDK managers and schema versions consumed, the freshness Fleet Manager commits to, and the deprecation window for breaking changes. Dependency: the service Fleet Manager calls to do its work (storage, secrets, messaging), what Fleet Manager stores or fetches there, and what fails when it is unavailable. Custody: the engagement mode and a pointer to the commercial agreement. No terms are restated here.

​
What breaks if this changes

One paragraph: which Fleet Manager state or counterpart behaviour degrades, and how it shows up to operators.

​
Enforcement

  • Principal: the identity this relationship runs under (one per consumer).
  • Mechanism: how each side authenticates today, both directions. Towards Fleet Manager: the FM OAuth client in the hub roster, or an Auth0 or uni-identity service account once Fleet Manager moves onto the company identity platform. Towards the counterpart: the credential Fleet Manager presents to it and the 1Password item or secret that holds it, so a 401 on that side is traced to the right credential.
  • Pact or contract test path, OpenAPI components, CODEOWNERS line.

​
Gaps

Anything this relationship needs that does not exist yet, stated plainly.

​
Change log

  • <YYYY-MM-DD> v1: created; describes present behaviour.