AIM · the umbrella · its own service, screen in review
Operating the AI with the same discipline you'd expect for the network under it.
AIM (Agentic Integrated Management) is the BMI2 pillar that applies operator-grade discipline — Fault, Configuration, Accounting, Performance, Security — to the AI itself. FCAPS is the operating framework network engineers already trust. AIM is what happens when you apply it to a persona, a workflow, a spend ceiling, a signed release, and an audit chain, rather than to a switch and a link. Alongside FCAPS sits Business & Risk Assurance: an AI risk register mapped to the NIST AI RMF, with control evidence, incidents and release decisions — kept separate from operational health.
New · AIM's own screen · in review
One screen that says whether AIM itself can be trusted, then what each application answered.
AIM now has a screen of its own, separate from the Fiduciary console it grew up inside. It reads top to bottom in the order an operator should trust it: AIM's own health first, because if the collector has stopped, everything below it is old news. Then each application it watches — Fiduciary, A&R and TestPulse — with whether AIM could reach it, what each endpoint actually answered, and how fresh that answer is.
Order of trust
AIM's own health comes first.
The first thing on the screen is AIM's own collector heartbeat. A monitoring screen that cannot say whether the monitor is alive will report a stale "all clear" for as long as nobody checks.
Per application
Reachability, per-endpoint outcome, freshness.
Each application gets its own card: could AIM reach it, what did each endpoint answer, and how old is that answer. A&R's own probe results appear mirrored, labelled as A&R's, not re-stated as AIM's.
No borrowed credentials
The screen holds no application token.
The browser only talks to AIM. Collection happens in AIM's service, under one collector identity per application. Nothing on the screen can call Fiduciary, A&R or TestPulse directly.
Honest wording
"Reachable" never means "healthy".
Reachable says AIM got an answer. It does not say the application is well. Health is what the answers say, endpoint by endpoint, and the screen keeps the two words apart.
Five lenses, applied to the AI itself
FCAPS for the persona, not just the port.
Every FCAPS lens is a real operational question a compliance-adjacent team asks about the AI in production. AIM is where the answer lands.
F · Fault
Is the AI actually healthy right now?
Persona liveness, watcher health, queue depth, envelope inventory, audit-chain integrity. Alarms are evidence-backed and route to a human queue — not a shared inbox.
Fault (Alarms) →C · Configuration
What is deployed, at what revision, signed by whom?
Signed image manifests, adapter registry, policy revision, workflow revision. A configuration change is a signed record — the audit shows who changed what and why.
Configuration →A · Accounting
What has this AI cost, per tenant, per workflow?
Per-tier, per-provider spend measured against the ceiling the operator set. Budget breaches at 25 / 50 / 75 / 100% land with the responsible human. Tier 3 calls blocked above ceiling.
P · Performance
Is the AI meeting its stated SLA?
Envelope SLA watcher, review-window enforcement, retrieval latency, model latency. Envelopes past SLA are escalated or expired, never quietly held.
Performance, with live Grafana metrics →S · Security
Is the boundary intact?
OIDC identity, per-workflow role, RLS enforcement, secrets isolation, signed release verification, NetworkPolicy egress lockdown. Every boundary has a live check, not a checkbox.
Security →Why AIM matters
Without an operating framework, AI drifts silently.
Regulated teams learned this on networks in the 1990s: without FCAPS, an operating environment produces confident results long after it has stopped being healthy. AIM makes the AI itself observable the same way. Fault, Configuration, Accounting, Performance, Security — every lens is a real question the operator can answer with evidence, not a status page.
Same governance spine. AIM inherits Fiduciary's audit journal, countersignature gate and rails. It is not a separate tool — it is the operational surface for the same AI that reasons over the artifacts.
Status, honestly
AIM runs as its own service. Its screen is in review.
What exists now
AIM now runs as its own service: its own namespace, its own database, and one collector identity per application it watches. It has its own screen, in review, which shows AIM's health first and then Fiduciary, A&R and TestPulse. Fault (Alarms) is the first view on that screen, and has its own page.
Configuration, Performance (with live Grafana metrics from the lab) and Security now have their own pages too: Configuration, Performance, Security. Each page marks what is built and what is planned. The rest is still being ported. Accounting, Business & Risk Assurance, Remediation, and the day-to-day screens for the lenses above still live in the AIM console embedded in Fiduciary, alongside the watchers, the spend ceiling, the audit journal, the OPA-PEP enforcement, the connector-watcher and health-watcher that ship with Fiduciary today. Each moves to AIM's own screen, and gets its own page here, as it is ported and signed off. Until then, the unported ones are marked "coming soon" in the menu.
Talk to us about applying FCAPS to your AI.
If you already run an operations team that speaks FCAPS, and you're evaluating an AI worker for a regulated workflow, this is a short conversation. If you're building the AI itself and need an operating surface with actual teeth, that's a longer one.