Capability configuration

Capability packages move workflow behavior out of the agent runtime. The same workflow-independent agent can handle different work by changing its installed recipe.

Capability plus Constitution

A Capability is one installable workflow product presented through four authoring sections: Vocabulary, Rules, Actions, and Sources. Vocabulary, Rules, and Actions are carried by the required Knowledge package on the current wire; Sources are carried by an optional Sources package when the workflow reads or attests external state. Users install and inspect one Capability card—not two unrelated products—while every wire component retains its own body and fingerprint. The grouping is a rulith-capability/1 catalog manifest, not another package type.

Knowledge

Defines the vocabulary, rules, and Actions for a workflow. Vocabulary gives facts stable names and typed argument positions. Rules derive conclusions from supported inputs. Actions define what must already be true and what state transition follows. An Action that leaves the board references one versioned Tool and one Source; it never contains an Adapter, executable path, SQL statement, endpoint credential, or Connection ID.

Sources

Defines where evidence comes from and which predicates a source may attest. Database, file, HTTP, MCP, sensor, compute, and human sources are explicit connections rather than hidden prompt context.

A Source package declares identity, type, attestation scope, and a non-secret territory hint. Installing it creates an unbound Agent-local Source instance. Governance then binds that instance to one Worker Connection owned by the same Agent. A reusable package never names or creates a Connection. Credentials and machine-specific locations stay with the Worker.

Tool and Adapter boundary

A Tool is a versioned capability contract referenced by an Action, for example acme.orders.lookup@1. A Worker Tool Manifest binds that stable Tool ID to a local implementation and the same Source named by the Action. Rulith pins only the Tool ID, manifest digest, and Source to the Agent-owned Connection.

An Adapter is the Worker's quickest way to implement a Tool. The standard adapters are http, mcp, db-query, db-exec-fenced, and run. Adapter configuration is local deployment material: it may contain a relative program path, request template, SQL template, or other implementation detail, but it is never published in a Capability and is never sent to the model. A Worker may expose a broader adapter library than one workflow needs; only Tools present in its pinned manifest are callable for that Connection.

Constitution

Defines constraints that must hold before an outward action can proceed, including conditions that require an approved source or human review. Constitution is independent of a Capability so the same organizational policy can constrain several capabilities and can change under a separate governance decision.

Recipe and case materialization

An agent's recipe is the selected Capability plus any independent Constitution packages. The Agent-owned Source bindings and Connection are deployment configuration, not portable Capability content. When a case opens, the host materializes the recipe into the case board as part of initialization. Validation and composition failures change no configuration. The hosted installer also attempts to restore the prior configuration after a storage failure and reports explicitly when operator recovery is required; a single crash-atomic storage transaction is still planned.

Existing sealed cases keep the package fingerprints they ran with. Editing the agent recipe affects new cases; it does not rewrite history.

Rulith Cloud accepts package changes only through the signed-in governance surface in Console. A REPL, MCP client, or Worker may select an Agent and use its current recipe, but it cannot submit package bodies or change the law lock while opening a case. Self-hosted authorities may choose their own governance workflow; the local runtime's --recipe option is for that deployment shape, not a Cloud fallback.

Design rule

Put reusable workflow semantics in Knowledge, including Action-to-Tool references. Put reusable evidence policy in Sources. Keep case data in the case. Keep Adapter implementations, credentials, and machine-specific locations in the Worker. Keep Connections Agent-owned. Do not encode workflow-specific behavior in the generic agent loop or Worker.

Authoring workflow

Open an agent's Configuration tab in Console to create and validate each part. Start from the smallest vocabulary and rule set that can decide one real workflow. Add executed Actions only after their preconditions, board-bound parameters, Tool reference, Source, and receipts can be stated precisely. Implement the referenced Tools locally with the Worker Tool Manifest.

For every supported field, atom shape, built-in operator, default, and advanced editor section, use the Capability field reference.

Official examples appear in the same Capability market as community packages and install through the same governance endpoint. Their publisher is the platform identity Rulith, with an Official badge and content fingerprint. Individual maintainer accounts may update the source repository, but they are not presented as the product trust root.

The market presents complete Capabilities first, with separate views for Constitutions and standalone reusable components. Installing a Capability resolves its manifest and sends each typed component through the ordinary governance installation path. Validation or composition failure stops the installation before commit. Storage or projection failures remain visible and may require governance repair. There is no privileged bundle installer.

domain in existing protocol payloads

Some current Board Protocol payloads still use packType: "domain" as the legacy wire identifier for a Knowledge package. New product copy calls the user-facing concept Knowledge. Clients should treat domain as a compatibility identifier, not as a fifth configuration area.