AI Capability Discovery and Planned-Contract Automation: What the Assistant Can Actually Do, With No Guessing

An internal AI assistant that reaches across a whole company's systems is only trustworthy if it can say, precisely, what it is and isn't authorized to touch — for a specific person, right now. An assistant that either refuses everything out of excess caution, or one that tries anything and only discovers a limit by failing loudly mid-task, both erode the same thing: confidence that the assistant understands its own boundaries as well as the person operating it does.

Letting a language model infer its own boundaries from a natural-language system prompt works until the number of systems, actions, and risk levels grows past what a prompt can reliably encode — and an internal assistant that reaches Maestro's live ad campaigns, a support inbox's real customer replies, and Axis's client notifications has exactly that scale problem. A registry that a human decides, rather than one a model infers, is the only way to guarantee a specific, auditable answer to "is this action available, and how risky is it" that does not depend on a prompt being worded well enough to survive every future addition.

Every capability Axiom might ever call — from a generic "read a module's table" through a specific "pause this ad campaign" — lives in one registry, versioned as `centriu.capabilities/1`. Each entry is classified by a human, not inferred by a model, into one of four risk classes: read (executes freely once authorized), compute (consumes AI quota and cost but never alters business state — a simulation or an analysis), write (alters a customer's data, follows the approval policy), and high-impact-write (an effect outside the platform, or one that cannot be undone — money moving, a message actually sent, personal data touched) — always an explicit human approval, on every surface, no exception.

Of the 37 entries in the registry today, 26 are marked `disponivel` — confirmed against the live code, not aspirational — spanning three generic cross-module actions (read a table, describe its schema, write to it, all under the caller's own row-level security), a dozen capabilities native to Axiom itself (listing and searching its 140 specialists, running an expert panel, reading a vision analysis, discovering what's available), and real actions inside other modules: pausing, updating or reviving a Maestro ad campaign, replying to a support ticket by email or WhatsApp, messaging a client through Axis, building a governance or operational report as a draft, and reading or sending through a connected Gmail account. The remaining 11 are marked `planejada` — a contract published in the exact same format for Gauge (a financial summary, where margin leaks), Dash (a funnel summary, a forecast with its methodology stated), Helix (open risks, calculated scenarios), Oracle (project status, ICP readiness), Link (a service-volume summary, and an ombudsman summary that explicitly never carries the actual complaint text), and Flow (governed-collection status) to implement on their own timeline. Calling any of those 11 today returns a specific, typed "not implemented" response — never a plausible-sounding invented figure standing in for real data.

A dedicated discovery function answers "what can THIS person do, here, right now" by checking which modules are enabled for them, whether they hold a privileged owner/admin role that bypasses per-module scope checks, the organization's own feature flags, and which surface is asking. What comes back is never a silent, unexplained gap: something that exists but isn't reachable for this person comes back in a distinct "blocked" list WITH the actual reason — a module not enabled, a feature flag switched off — because a capability that simply disappears reads, to the person using it, as "the assistant doesn't know how," when the truth might be "you haven't connected that module yet."

One rule holds regardless of any of that: a capability needs an explicit flag to be offered on the ChatGPT surface at all, and independently of that flag, every single high-impact-write capability is refused there unconditionally — confirmed directly in the Edge Function's own header comment, not just in a type definition: if an action needs approval on Axiom's own screen, it needs it when the request comes from ChatGPT too, and since ChatGPT has no screen for someone to click Approve, the honest consequence is that the action simply does not happen from there. There is no flag that loosens this. The two AI-consuming actions that ARE offered to ChatGPT (running an expert panel, running a vision analysis) delegate to the exact same owning Edge Functions the main app calls — quota, feature flags and rate limits are decided once, in one place, not reimplemented a second time for the ChatGPT path.

Someone asks Axiom, through ChatGPT, for a Gauge margin summary for last quarter. The capability exists as a published contract — the exact shape of the answer is already defined — but its transport is marked `nao_implementado`. Axiom does not estimate a plausible-sounding margin figure to be helpful; it reports that the capability is planned but not yet built, using the same typed response every other unbuilt contract returns, so the person asking knows to go check Gauge's own dashboard rather than trust a number Axiom never actually computed.

A person working with Axiom gets a specific, honest answer about what it can do FOR THEM, right now, rather than a generic capabilities list that ignores their own role and enabled modules — and a specific, honest answer when something isn't built yet, rather than content that looks like a real number. Every powerful, external-effect action stays behind the same approval requirement no matter which surface asked for it, which means adding a new AI-facing integration can never quietly become a second, looser way to reach the same live ad budget or the same real customer inbox.

A team hoping to reach a Gauge, Dash, Helix, Oracle, Link or Flow capability through Axiom today will get an honest "not implemented" rather than a working integration — the contract is published, the build is the owning team's own roadmap decision, not something this page claims is already delivered. A team hoping to authorize a high-impact action (a real send, a real spend change) from inside a ChatGPT conversation specifically will not find a setting to enable that — it is refused by design, on every surface, with no override.

Asking a language model to infer, from a system prompt, what it is and isn't allowed to do works until the number of systems and risk levels outgrows what a prompt reliably encodes — and then a boundary gets crossed not out of malice but because the model reasonably assumed a described capability was real. Centriu Axiom instead keeps one explicit, human-classified registry with a typed answer for exactly what is live, what is only a published plan, and what is blocked and why — and one rule, checked in code rather than left to a prompt's wording, that no external-effect action ever reaches production through a surface with no approval screen.