Provider keys held with scope, audit, and rotation.
Provider credentials are scoped to the integration. The scope, the rotation cadence, and the access window are policy-defined and recorded.
Extensions / 3.3
API governance & provider management.
H.A.R.I. governs the API surface between authorized providers and the actions that follow. Access control, traceability, and the explicit refusal to make uncontrolled calls.
01Designed to integrate with authorized systems
H.A.R.I. is designed to integrate with authorized systems, APIs and data sources when access is granted. The construction of the sentence is deliberate. Integration is not a default state — it is a property that exists when, and only when, the upstream principal has formally authorized it. Where access has not been granted, the platform does not have the access. There is no claim of integration prior to authorization.
02Provider management
AI provider connections — including connections to providers such as Anthropic's API and other major model vendors — are managed through a controlled API management surface. The provider management discipline is the same one applied to federation APIs, league APIs, and infrastructure APIs.
Every call is policy-evaluated.
An outbound call to a provider does not happen unless the policy preconditions for the call are satisfied. Otherwise, the call is deferred or refused, and the deferral is chained.
Inputs in, outputs out, on the chain.
Provider calls and their responses (subject to provider terms) are recorded against the chain so that the role of the provider in any past decision is reconstructible.
03API calls governed by H.A.R.I., never black-box automation
The headline claim of this page: no API call into a consequential downstream system happens outside the platform's governance. The kernel evaluates the call's preconditions; the AGL routes any required authorization; the chain records the event. Black-box automation — a model output silently triggering an outbound call, an external integration making opaque side effects — is excluded by architecture.
Operational consequence
If a provider integration is to be added, the integration is added with policy, scope, and authority — and only then. A pilot does not "leak" into uncontrolled call patterns. An auditor inspecting any decision can read the provider calls that participated in it, in order, in scope, signed.
04Design-ready integrations, pending authorization
The list below describes integration shapes the platform is engineered for. Each is marked clearly: design-ready, pending authorization. None of them are claimed as live or as in-effect partnerships. The list is not exhaustive; new integrations follow the same provider-management discipline.
| Integration shape | Examples | Status |
|---|---|---|
| AI providers | Anthropic API, other major model vendors | Design-ready, pending authorization |
| Federations | Federation match-data and competition APIs | Design-ready, pending authorization |
| Leagues | League match-data, fixtures, and discipline APIs | Design-ready, pending authorization |
| Clubs | Club operational and medical APIs | Design-ready, pending authorization |
| VAR infrastructure | VAR review event APIs, video-feed metadata | Design-ready, pending authorization |
| Tracking systems | Player tracking, ball tracking, stadium telemetry | Design-ready, pending authorization |
| Smart devices | Authorized wearables, field devices, glasses | Design-ready, pending authorization |
| Public safety | Emergency operations centre APIs (where authorized) | Design-ready, pending authorization |