AIM / FCAPS / Configuration
AIM · C · Configuration
What AIM watches, and who may ask it, is written down.
AIM's configuration is three versioned files and a set of identity clients, all reviewed like code. Nothing AIM does is decided by a setting someone changed in a screen and forgot about: what it collects, what counts as an alarm and who can read or act on it are all in files you can diff.
Targets registry
Every application AIM watches, and exactly what it reads from each.
The registry names each managed application, its tenant, how often AIM collects (every 60 seconds), the identity AIM collects with, and the exact endpoints it reads. Endpoint paths are validated when the file loads, so a path can never move AIM's credential to another server, and a repeated application ID is refused.
aim.collector.fiduciaryConnector health, assurance cadence and measurements, plus Prometheus /metrics.aim.collector.arConnector health, plus a second hop: A&R's own endpoint probes, mirrored rather than re-run. Prometheus /metrics.aim.collector.testpulsePrometheus /metrics over TLS, trusting only TestPulse's own pinned CA, with the hostname checked.One identity per application, bound to that application. A collector token is accepted only by its own application's monitoring endpoints. The same token is refused on a user route, and another application's collector token is refused outright. Both refusals were checked live.
Alarm conditions
Versioned, digest-pinned, and never a second copy of a threshold.
AIM's condition registry lists every alarm condition it can see: four connector conditions and two security conditions. For each it records only what AIM itself needs: the severity and disposition to display, and which permission an acknowledgement would require. The thresholds stay with the application that evaluates them. The file carries a version, and a test pins its digest, so any edit is a visible, reviewed change.
Operator policy
The directory supplies groups. AIM decides what they mean.
Groups → roles
Derived locally, never asserted
Keycloak tells AIM which groups a person is in. AIM's own policy file turns groups into roles, permissions, allowed purposes and a clearance ceiling. Clearance and purpose are never accepted from a token, so a compromised identity provider can't grant itself more.
Tenants
Read everywhere, write in one place
The aim_administrator group can read all three tenants but write only to one. The policy loader refuses a vague "own tenant" setting, and a write whose token names a different tenant from the target is refused.
Gates
Every route declares its gate
Each operator route names its own permission, role, purpose and data classification. A route without a gate stops the service at startup instead of quietly serving.
Identity clients
Each client has one job
aim-api (the service), aim-ui (a public browser client: authorization code with PKCE, no password grant), a token-exchange client for Fiduciary, and the three collector clients. Each is declared in a reviewed file.
Built, and what's next
The registry, the condition file, the policy file and the identity clients are all built and in use on the lab. Changing configuration from AIM's own screen is planned: today every change is a reviewed file change, applied by the operator.
Talk to us about applying FCAPS to your AI.
If you run an operations team that already speaks FCAPS, AIM gives the AI the same five lenses: Fault, Configuration, Accounting, Performance and Security.