Capability record template
Action, surface, preconditions, verification method, and verification date.
MEC-17 Capability catalog
Keep a discovery surface separate from the grant register so a system can reason about what it could do without being empowered to do it.
Permanent link /mechanisms/patterns/capability-catalog
Where it fits
Filters and handoffs
Tagged for Governance, Policy with validator handshakes. Includes 3 steps, 3 reusable assets, and 4 snippet blocks.
Copy citation (APA/BibTeX)
Cite this page Formats: APA, MLA, Chicago, BibTeX, RIS
APA
Ethotechnics Institute Research Team. (2026). MEC-17 Capability catalog. Ethotechnics Institute. https://ethotechnics.org/mechanisms/patterns/capability-catalog
MLA
Ethotechnics Institute Research Team. "MEC-17 Capability catalog." Ethotechnics Institute, 2026, https://ethotechnics.org/mechanisms/patterns/capability-catalog.
Chicago
Ethotechnics Institute Research Team. "MEC-17 Capability catalog." Ethotechnics Institute. Jan 9, 2026. https://ethotechnics.org/mechanisms/patterns/capability-catalog.
BibTeX
@misc{mechanism_capability-catalog,
title={MEC-17 Capability catalog},
author={Ethotechnics Institute Research Team},
year={2026},
howpublished={Ethotechnics Institute},
url={https://ethotechnics.org/mechanisms/patterns/capability-catalog},
version={v1.1.0}
}
RIS
TY - WEB TI - MEC-17 Capability catalog AU - Ethotechnics Institute Research Team PY - 2026 UR - https://ethotechnics.org/mechanisms/patterns/capability-catalog ER -
Specification overview
At-a-glance details for planning and handoffs.
Capture the scope, assets, and validator handshakes before diving into the steps.
Spec essentials
What ships with this mechanism
- 3 steps with checklist-ready owners.
- 3 reusable assets for briefs and runbooks.
- 4 reuse-ready snippet blocks.
- 3 glossary anchors for shared terms.
Filters & validators
Where this spec sits in the system
Tagged in 2 filters with 1 linked validators.
Glossary anchors
Link back to the definitions.
Jump to the glossary terms that frame this mechanism.
Steps
Put the mechanism in motion.
Start with the field cues, then use the assets to keep the work legible.
3 steps with checklist-ready owners, plus linked assets for handoffs.
0 of 3 steps complete
Assets
Keep outputs reusable.
Link or copy these assets into design docs, runbooks, and briefs so the mechanism travels with the work.
Discovery endpoint contract
Read-only interface that returns capabilities and their grant status without granting anything.
Refusal message pattern
Standard wording that cites the capability, the required grant, and its state.
Reuse-ready snippets
Copy policy, audit, and incident language.
Use these snippets in requirements, audits, and postmortems with the mechanism permalink.
Policy requirement
Policy requirement (MEC-17 Capability catalog) - Maintain a catalog of what the assembled system can do, separate from the register of what it is permitted to do. - Discovery of a capability confers no authority; execution requires a grant in the allowed state. Reference: https://ethotechnics.org/mechanisms/patterns/capability-catalog
Product requirement
Product requirement (MEC-17) - Capability discovery succeeds for actions the system cannot lawfully perform. - A refusal names the capability, the required grant, and the grant's current state.
Audit evidence checklist
Audit evidence checklist (MEC-17) [ ] The catalog lists capabilities reachable through tools and sub-agents. [ ] Each capability records its verification method and date. [ ] Attempts to execute ungranted capabilities are refused and logged.
Postmortem trigger
Postmortem trigger (MEC-17) Trigger review when a newly reachable capability was exercised without a grant being issued for it.
Example usage
An agent that can see the payout tool it may not use
A concrete scenario to help teams see how the pieces fit together.
How it plays out
An operations agent discovers the payout tool in the catalog, reads that the matching grant is in review_required, refuses the action citing the grant identifier and state, and files a request for authorization instead.
Anti-patterns
Common failure cases and counterfactuals
Use these to avoid superficial compliance and clarify what success requires.
Discover equals permit
Anything the system can reach is treated as something it may do, so capability growth silently widens authority.
Counterfactual: Discovery and authorization are separate surfaces, and execution checks the grant.
False-positive warning: Hiding a capability is not a substitute for refusing it; a hidden capability that executes is still ungoverned.
Catalog without verification
Capabilities are listed from documentation, so the catalog describes intent rather than what the system can actually do.
Counterfactual: Each entry records how the capability was tested and when.
False-positive warning: Verification can be sampled; the record should say which entries are asserted rather than tested.
Validators
Pair validators with this mechanism.
Use these tools to size risk and keep the stewardship path visible.
Validator
System Audit & Guardrail Synthesizer
Evaluates AI system prompts, architectures, and automated decision logic against 80+ governance failure modes and synthesizes executable guardrail code and legal SLA clauses.