The Capability Library: Where AI Judgment Ends and Auditable Logic Begins

If an auditor asked you to explain a decision your AI made last quarter, would you hand them a prompt?

For a growing number of teams, the honest answer is yes, and it is the wrong answer. A prompt is not an accountability artifact. It has no version that maps to the decision date, no test fixtures that prove its behaviour, no owner who signed off on the change that altered an outcome. Yet as AI deployments scale, more and more organisational practice quietly migrates into prompts, because that is the easiest place to put it.

Every organisation develops practices unique to it: a specific way to do fraud screening, a particular workflow for accessing protected data, a house style for credit narratives. These practices are too valuable to re-encode in every copilot prompt, and too policy-bound to leave to the model's discretion. On Ontoz they belong in the capability library: a versioned, governed catalog the configurator picks from when wiring up any Copilot or Agentic Task.

Two Implementation Strategies

The library offers exactly two ways to implement a capability, and the choice between them is the whole discipline.

A Skill is the right choice when the work is judgment-heavy: steps vary case by case, language quality matters, and a model is genuinely useful. A Skill bundles a prompt fragment, a required set of tools, an allowed subset of task actions, optional few-shot examples, and pre and post hooks specific to that skill. Skills compose across Copilots, and a change to a Skill propagates by hot-reload to every Copilot that lists it.

A deterministic Activity surfaced as a tool is the right choice when the work is rule-driven: the same inputs must always produce the same outputs, and regulators or risk teams need to inspect the logic. The work is implemented as an Automated Activity and exposed to AI callers through the run_automated_activity platform tool. The Copilot or Agentic Task can invoke the capability. It cannot influence how the capability runs.

The Rubric

The decision compresses to a short set of questions. Same input must produce same output every time? Deterministic Activity. Auditors will inspect the logic? Deterministic Activity. Work is mostly narrative, reasoning, or judgment, and success depends on natural-language quality? Skill. Logic already expressible as rules and integrations? Deterministic Activity. Touches PHI, PCI, or financial-decisioning data with strict provenance requirements? Deterministic Activity, without exception. Steps expected to evolve as models improve? Skill.

Behind all of these sits the auditor test: if the auditor would read a prompt to understand accountability, the work does not belong in a Skill. If they would read a versioned configuration artifact with test fixtures, it belongs in the library.

Three Worked Examples

Fraud check: hybrid. Device fingerprinting, velocity checks, and consortium-list lookups are deterministic, modelled as an Automated Activity (fraud-screen-v3) and surfaced through run_automated_activity. Interpreting ambiguous social-media signals is judgment work, modelled as a Skill (fraud-narrative-review) with retrieval and explanation tools. The rule layer is inspectable line by line. The judgment layer is governed by the Skill's tools, actions, and hooks.

Healthcare data access: deterministic, deliberately. Reads of protected health information must be justified, minimum-necessary, and audited. The entire path is modelled as an Automated Activity (phi-disclosure-check). The Copilot cannot reach PHI through any other route, because field-level aiReadable flags close them. This capability is intentionally not a Skill: no version of "the model decided access was appropriate" survives a compliance review.

Credit narrative: Skill. House-style credit memos have a fixed structure but judgment-driven content. The Skill pins structure and tone with a prompt fragment and three few-shot exemplars, and grants read and rule-evaluation tools. When the house style changes, one configuration update propagates to every Copilot that uses it.

Governance and Boundaries

The library is itself a configuration artifact. Every entry carries a stable key, an accountable owner, a status of draft, published, or deprecated, an immutable semantic version, and a set of golden test cases that must pass before publishing. A capability moves to published only after owner sign-off and, where its tags imply it, compliance review. Multi-tenant inheritance applies: a base library holds the canonical set, and tenant variants patch specific capabilities.

Equally important is what the library cannot do. A capability can never widen permissions that construct flags or catalog defaults deny. It cannot replace the core engines. And capabilities are scoped to a single session: no cross-task, multi-day orchestration hides inside one.

The capability library is where an organisation's practice stops living in prompts and starts living in artifacts an auditor can actually read. That line, drawn capability by capability, is what makes AI at scale reviewable.