Capabilities and Sovereign Skills

The capability layer lists the operations that an actor can do and the conditions for each operation. A Sovereign Skill Package puts these operations together with contracts, knowledge, policies, evaluations, and provenance. The interfaces work with any model that reasons. MCP is one example of a connector between planners and capabilities, and you can replace it. Your policy controls approval, execution, and evidence.

Declared, permissioned operations

A capability states the purpose, inputs, outputs, affected resources, and limits of an operation. When a capability declares these properties, you can inspect the operation before an agent or workflow gets access to it.

Permission applies to one specific operation in one context. Access to a tool does not give permission for every function, argument, dataset, or destination behind it. The system gives access only to the capabilities that the approved task needs, and it limits their use.

To propose, to preview, and to execute are different actions with different effects. Keep them separate. A preview of a change does not approve the change. An important execution can need one more policy check and a human approval.

Sovereign Skill Packages

The proposed Sovereign Skill Package is a signed, portable capability package. A skill package can contain:

The skill package states what it does. It lists its inputs, outputs, models, tools, and allowed data classes. It also states how to evaluate it and who must approve it.

These statements give the skill package a contract. A registry, a policy authority, a runtime, and an evaluator can inspect this contract. A signature and a provenance record show where the skill package came from and that nobody changed it. Evaluation and policy decide if you can use it for a specific task.

A domain skill package can combine reusable primitives with the objects and rules of one domain. The definitions for the institution stay in portable contracts and ontology references.

Interfaces independent of models

A planner calls capabilities through stable contracts. It does not depend on assumptions about one provider. Thus, the operations that the institution permits stay separate from the model that reasons about them.

A replacement model must understand the contract and pass the same evaluations. A model that supports more tools or a larger context window does not get more permissions.

The same rule applies to workflow engines and user interfaces. An action that a human starts and an action that an agent calls can use the same governed capability. If an interface shows an action, that does not give anyone permission to do it.

Replaceable interoperability under sovereign control

MCP is one example of a way to expose capabilities to compatible components. You can replace it. MCP connects components. It does not prove that the publisher is safe or that access is least privilege. It also does not prove that the supply chain is secure or that an actor has permission.

A sovereign gateway around this interface controls authentication and routing. It also applies rules for data class, jurisdiction, secrets, provenance, and audit. External policy checks decide which operations are available for one intent and one actor.

The proposed controls are:

The system can make capability sets from the SSIL intent and from approved work orders. Then each available operation stays linked to an approved purpose.

If you replace the interoperability adapter, the capability contracts, policy links, and evidence history must stay the same.

Reference build

A reference build has these parts:

The registry describes known publishers, schemas, and attestations. Supply-chain records link each skill package to its source, dependencies, licenses, build provenance, vulnerability findings, and approved environments. A lock manifest can show the capability versions that one run used.

Workers get only the capabilities and credentials that they need. Verification examines their outputs and declared behavior. Evidence records which skill package, authority, inputs, and execution context made the result.

From the research

All topics