Capability Catalog & Definition Packs
Formael organizes every capability into Definition Packs - curated, installable bundles that let your organization build exactly the operational vocabulary it needs. This page explains how packs work, how to install them, and how to manage your organization's capabilities over time.
How the catalog model works
Formael maintains a Platform Catalog - a curated library of every domain, capability, and risk profile authored by Formael. The catalog is read-only. Organizations browse it and install from it.
When your organization installs a Definition Pack, every domain and capability in that pack becomes yours. Your organization owns its own copy: your risk profiles, your parameter schemas, your governance rules. Changes Formael makes to the catalog in the future do not silently alter what you've installed - upgrades are always opt-in.
This means two organizations running finance.create.invoice may have different parameter schemas, different risk profiles, and different governance rules. The capability vocabulary is shared; the definitions are owned.
Definition Packs
Domain Packs
Each Domain Pack covers a single operational area. Install only what your organization actually needs.
| Pack | Covers | Sample capabilities |
|---|---|---|
| Finance | Invoicing, payments, subscriptions, refunds | finance.create.invoice, finance.approve.invoice, finance.issue.refund, finance.create.subscription |
| ITSM | Tickets, incidents, change requests | itsm.create.ticket, itsm.escalate.ticket, itsm.create.change-request, itsm.approve.change-request |
| Support | Cases, credits, customer refunds | support.create.case, support.issue.refund, support.issue.credit, support.apply.discount |
| Sales | Contacts, deals, quotes, proposals | sales.create.contact, sales.update.deal, sales.create.quote, sales.close.deal |
| Contracting | Drafts, signatures, amendments | contracting.create.draft, contracting.send.for-signature, contracting.sign, contracting.void |
| Identity | Account provisioning, roles, groups | identity.provision.account, identity.deprovision.account, identity.grant.role, identity.revoke.role |
| Messaging | Messages, direct messages, meetings | messaging.send.message, messaging.create.meeting |
| Document Signing | Contracts, envelopes | document-signing.create.contract, document-signing.send.envelope |
| Storage | File upload and retrieval | storage.upload.file, storage.read.file |
| Calendar | Events and bookings | calendar.create.event |
Starter Kits
Starter Kits are multi-pack bundles designed for common organizational profiles. Installing a Starter Kit installs each constituent Domain Pack in one step. Individual packs within a kit can be uninstalled independently later.
| Starter Kit | Included packs | Best for |
|---|---|---|
| SMB | Messaging, Calendar, Storage, Sales | Small teams automating everyday workflows |
| Operations | ITSM, Messaging, Identity | IT operations and infrastructure teams |
| Revenue | Finance, Sales, Contracting, Document Signing | Revenue operations and finance teams |
| Enterprise | All Domain Packs | Large organizations with broad automation needs |
Installing packs
During onboarding
The onboarding wizard walks you through pack selection as its first step. Browse by Starter Kit (for a guided start) or select individual Domain Packs. After installation, you can optionally adjust capability settings and assign domain owners before finalizing your configuration.
After onboarding
Navigate to Settings → Catalog at any time to install additional packs. Each pack card shows the capabilities included, the tier required, and any packs it depends on. If a selected pack requires another that is not yet installed, you'll be prompted to install both together.
Your organization must have at least one pack installed before any agent can submit intents. An organization with no installed packs has no capabilities to resolve against.
Semantic slots - the governance contract
In addition to a parameter shape, every capability declares a small set of semantic slots - typed roles that fields play in governance. Slots are platform-owned and versioned with the catalog. The current vocabulary is monetary_value, counterparty, principal, content, destination, classification, and volume.
Slots are what makes policy templates portable. A rule written against monetary_value applies identically to finance.create.invoice, support.issue.refund, and contracting.create.contract - without rewriting field paths per capability.
Custom capabilities you create from scratch can declare slot bindings too. Doing so is optional, but custom capabilities that emit standard slots automatically inherit every template policy written against those slots. See Policy & Governance for the full slot vocabulary and the rules that read each slot.
Your organization's capability registry
Once installed, your capabilities live in your organization's registry. This is what your agents discover when they call the Capability Discovery API, and what the policy engine evaluates against.
The registry is yours to manage:
| Action | What it does |
|---|---|
| Deactivate a capability | Excludes it from resolution - agents cannot submit intents for it. The capability stays in your registry for audit trail continuity. |
| Reactivate a capability | Makes it available for agent use again. |
| Adjust a risk profile | Change reversibility, visibility, sensitivity flags, or the human-approval default for any installed capability to match your organization's risk assessment. |
| Extend parameter schema | Add optional fields to a capability's parameters - for example, an internal reference ID your agents should include on every invoice. |
| Pin or unpin HITL approval | Set the capability's HITL override to PIN_ON, PIN_OFF, or INHERIT_PACK. Pinned capabilities always require human approval regardless of risk score. |
| Bind slots on custom capabilities | Declare which fields populate which semantic slots - this is what makes a custom capability inherit template policies. |
| Add a custom capability | Define a new capability in any of your installed domains. Useful for internal workflows or systems that Formael doesn't have a built-in connector for. |
| Add a custom domain | Create an entirely new domain for capabilities that don't fit any installed pack - for example, a clinical domain in a healthcare organization. |
What you cannot change
The (domain, action, entity) tuple of an installed capability is permanent. This three-part identifier is the stable key wired through your audit trail, policy rules, connector configurations, and IEC history. Changing it would orphan all existing records.
Customization status
Every capability in your registry carries a customization status that tracks whether it still matches what was installed:
| Status | Meaning |
|---|---|
| Stock | Unchanged since installation. Eligible for automatic upgrade when a new pack version is available. |
| Modified | Your organization has changed this capability after installation. Requires manual review during pack upgrades. |
| Custom | Created by your organization from scratch - not installed from any pack. Unaffected by pack upgrades. |
Modifying any field on a Stock capability automatically marks it as Modified. This transition is one-way - the only way to return to Stock is by accepting a pack upgrade that overwrites your changes.
Custom capabilities without connectors
When you define a custom capability (for example, clinical.create.patient), there is no Formael-authored connector for it. The capability is fully usable for policy evaluation, governance, and audit - but execution requires one of two additional steps:
- Connect a custom adapter - implement a custom integration and configure it as the provider for this capability in Settings → Integrations
- Map through an existing connector - if the capability's parameters are close enough to an existing connector's expectations, configure an Org Connector Override to route through it (see Connectors & Integrations)
Until a provider is configured, the capability appears as "Defined - not executable" in the management console. Intents submitted for it will fail at execution time with a clear NO_PROVIDER_CONFIGURED error.
Pack upgrades
When Formael publishes a new version of a pack, organizations running an earlier version receive a notification in the dashboard. Upgrades are always opt-in - Formael never silently changes your active capabilities.
The upgrade review
Navigate to Settings → Catalog → [Pack] → Review Upgrade to see a per-capability diff:
- Added capabilities - new capabilities in the pack you don't yet have
- Changed capabilities - capabilities that were modified in the new version, with the old value and new value shown side-by-side
- Removed capabilities - capabilities the new version no longer includes
Three upgrade outcomes
Clean upgrade - all your installed capabilities for this pack are still Stock (unmodified). The platform can apply the entire upgrade automatically in one step after your confirmation.
Merge required - some capabilities are Modified. For each conflict, you choose:
- Accept the new version (your modifications are overwritten; capability returns to Stock)
- Keep your version (your modifications are preserved; the new pack version is noted as skipped)
- Edit manually to incorporate both your changes and the pack's updates
Incompatible - the new version removes a capability that has active dependencies (an existing connector configuration, a live policy rule, or execution history). The upgrade is blocked for that capability until you remove or migrate the dependencies. The console shows you exactly what is blocking it.
Partial upgrades
You can upgrade individual capabilities from a pack without upgrading the entire pack. If a new version changes 12 capabilities but you only want to accept 8, review and accept each one independently.
Critical security updates
When a pack update carries a security or risk implication, the dashboard notification is elevated to a persistent banner. For the most critical updates, organization owners also receive an email notification.
Custom capabilities - those your organization created from scratch - are completely unaffected by any pack upgrade process.