What is AI capability declaration?
AI capability declaration is a machine-readable manifest of what each agent, tool, and model in a system can do: its inputs and outputs, the permissions it holds, the data classes it touches, and its blast radius if it misbehaves. The defining word is machine-readable. The capabilities of most AI systems are described — if at all — in prose scattered across design docs, a wiki page, and the memory of whoever built the thing. A declaration puts that description in a structured, queryable form that lives next to the capability itself.
It answers a question prose cannot answer reliably: what, exactly, is this system allowed to do? Not what we intended, not what the README says — what the manifest declares, checked against what the code actually wires up.
Why does prose policy fail where a manifest doesn't?
Prose policy fails for a mechanical reason, not a discipline one. A policy document is written once, at a moment when it is true, and the system keeps changing while the document does not. Drift is not a risk; it is the default. By the time anyone re-reads the policy, it describes a system that no longer exists, and nobody finds out until an incident review.
A declared manifest inverts that. Because it lives beside the capability and is checked at build time, drift surfaces as a failed check the moment code and declaration disagree — in the pull request, not in the post-mortem. It is also queryable: “which capabilities can write to production?” or “which touch personal data?” become questions the system answers from its own manifests, rather than questions an analyst answers from memory. The policy stops being a document you maintain alongside the system and becomes a property of the system.
How does it compose with MCP and Agent Cards?
It extends them rather than competing with them. The Model Context Protocol (MCP) declares that a tool exists and how to call it — its name, parameters, and invocation. That is exactly the right scope for a tool-calling protocol, and it deliberately stops short of governance. Capability declaration adds the metadata MCP leaves out: the permissions the tool holds, the data class it reads or writes, and what it can reach. The same tool definition then carries both “how to use it” and “what it is allowed to touch.”
This is the role of an open, machine-readable card format. We publish that layer as open specifications — the Kinetic Gain Protocol Suite includes Agent Cards and an MCP Tool Card spec precisely so a capability's governance metadata travels with its definition instead of living in a separate spreadsheet. An open format is what lets MCP, the card, and the build check compose instead of collide.
What does declaring capabilities give you operationally?
Three things you cannot get from prose. First, build-time enforcement: the build can fail if a capability touches regulated data without a classification, or grants a permission no one declared — so the policy is enforced by CI, not by review attention. Second, a queryable inventory: the set of capabilities, their permissions, and their data exposure is a dataset you can ask questions of, which is what makes an audit a query instead of an archaeology project. Third, drift detection: when code and manifest diverge, you find out immediately.
Declaration is one of the three properties that separate a governed control plane from an accidental one. The other two are verifiable evidence (proving what a capability actually did) and regulatory classification (which rules each capability falls under). They are introduced together in what a governed control plane actually looks like, and applied in our AI governance practice.