Capabilities

Before choosing a service, name the operation the work needs. A capability is the exact versioned contract a caller may request from an Animator: what it may ask for, and which typed inputs and results may cross the grant. Model, endpoint, container, tool, Rune, Coven and application purpose each answer a different question.

The interface/profile design described below remains Designed until source, migrations, adapters, tests and operator receipts establish delivery.

The delivered v1 surface

CapabilitySpec uses the key {animator}:{family}:{model_id}, seven closed families, coarse input/output modality strings, and one compatibility grant class. chat grants carry a hydrated Pydantic AI model and only explicitly declared agent-loop toolsets; tool_execution grants require a non-empty toolset surface. The other five family labels remain routing metadata and fail closed at issue. That v1 shape supports the proved chat/model path, narrow toolset compatibility, and readiness mechanics. It does not prove executable audio, visual, embedding, rerank, service-job, or host-tool routes. State of Work owns that boundary.

A capability carries the registrant_id assigned to its runtime or Portal definition during extension assembly. The same identity accompanies its granted specification and Nexus response row. It identifies the contributing package, separately from the Provider and capability key; it grants no authority. Direct adapter injection without registration reports None rather than claiming Core ownership.

Interface, profile, and operation

For the designed interface/profile path, distinguish the contract you need from the exact implementation that can fulfill it and the act you are requesting now:

The interface owner defines request and result schemas, operations, typed facets, failure and recovery meaning, and domain-specific validation. A profile pins exact code, model, weights, runtime, workflow or graph, configuration, dependencies, licenses, language and format support, resource evidence, and proved limits. The operator Rune chooses a concrete deployable instance and references those admitted definitions.

Image input may enrich model.chat@1; it does not become precise Sight. Audio output from a chat model does not become an eligible speech synthesizer. A Comfy graph that can produce an image and a video exposes two proved interfaces or operations only when each contract closes. tool is not an interface that means every side effect.

Capability demand

CapabilityDemand@1 asks for:

• exact interface and operation;
• typed input and output contract references, required facets, formats, language, and limits;
• required feature facts such as tools, token streaming, audio-frame streaming, progress, cancellation, timestamps, seeds, masks, or live clocks—never one ambiguous supports_streaming bit;
• optional exact or eligible profile revisions;
• invocation mode: model_round, call, durable_job, or live_session;
• source classification, local-only or eligible Portal policy, purpose, consent, and cost ceiling; and
• run, station-attempt, deadline, priority, and reservation requirements.

The interface owner validates domain constraints before demand and after return. Core matches the resulting exact declared and admitted facts. For example, accepting a motion format cannot establish that its skeleton satisfies the requested retarget map; that compatibility must already be expressed in the domain contract.

Declaration, evidence, observation, and grant

Four records keep assertion, proof, readiness, and permission distinct:

A Rune declaration is routing intent, not quality proof. Admitted evidence closes exact code, weights, workflow, dependencies, dialect, licenses, language or format corpus, hardware profile, and measured limits. Drift may produce findings but cannot promote; Assimilation may repair foreign craft but does not own every capability. The target interface/profile owner admits or promotes evidence under its policy. Dispatcher consumes that decision without becoming a benchmark judge.

A grant exposes neither its Animator nor its Connector. The designed union separates four callable surfaces:

The grant contains only its exact operation surface. A ModelGrant cannot be cast to a job driver; a JobGrant supplies no arbitrary HTTP client; a SessionGrant grants no source-device or world effect not present in its interface. Live models, connectors, SDK clients, iterators, sockets, sessions, and grants never enter Graph checkpoints or delegated payloads.

Readiness is not compatibility

The six observed phases remain:

is_dynamic remains a deployment trait: a reachable runtime may still need profile activation. It is not a readiness, quality, or capacity claim.

Liveness of one URL, process, /health, or /models route does not prove every declared model, dialect, operation, language, or profile warm. A fixed single-profile runtime may share one readiness observation only when the pinned adapter proves those surfaces are inseparable. A probe may downgrade or invalidate a declaration; it cannot invent one. Conformance evidence survives a temporary cold state, while a warm observation never substitutes for conformance.

Dispatch and lease

The Dispatcher resolves one CapabilityDemand@1 deterministically against eligible admitted specifications and fresh state. Before grant it applies source, Sigil, local/Portal, egress, purpose, consent, cost, and reservation policy owned by their proper boundaries. Selection is not quality ranking unless a separately admitted policy supplies comparable evidence.

Dispatcher never starts, stops, loads, evicts, submits an effect, or waits on a provider job. Orchestrator owns readiness convergence. The interface owner or Worker invokes the granted surface. A waiting Graph holds no live grant. Runtime models and toolsets are bound only while issuing an admitted grant. Capability, specification, and state reads expose detached declarations and observations. The registry keeps runtime handles private; callers obtain model and toolset bindings only through the scoped grant path. Control-plane activation and readiness operations do not expose a second public binding route.

One process generation

One loaded AnimatorRegistry is one sealed process generation. Successful loading is one-shot; changing declarations, runtime adapters, or exact Portal definitions requires constructing a new application generation rather than mutating the live registry underneath admitted Runs. A failed staged first load publishes nothing and remains retryable; it does not leave a partly sealed catalogue.

Calls, durable jobs, and live sessions

Immediate calls retain a scoped process-local lease only during use. Every asynchronous effect, local or remote, must persist ServiceJobAttempt@1 before first submit so timeout or process death can reconcile the same request rather than repeat it. Work on managed resident or scarce local substrate additionally transfers an exact Orchestrator-visible reservation and fence to that attempt; live work uses a bounded session record. Current process-local leases cannot provide those guarantees, so durable service work remains Designed.

There is no universal SessionAttempt yet. Echo Resonance, Riffmaw Jam, LiveSight, LiveKinesis, and Foundry Playtest each own their chronology, clocks, epochs, participants, queues, stopping, reconciliation, and evidence. Core's future SessionGrant supplies only exact technical admission, lease/reservation, and late-output fencing requirements. A common mechanical session envelope may be accepted only after those owners expose genuinely shared invariants; until then their records remain distinct and Designed.

Stable identity

The designed v2 key is:

{animator}:{interface_id}:{profile_ref}

profile_ref is a safe stable id plus exact immutable revision or content digest; an unversioned mutable label is not a profile reference. The selected operation is pinned in the demand and grant rather than multiplied into endpoint identity. Mutable provider handles, deployment paths, and floating tags are not keys.

Identity components are ASCII lowercase slugs with digits, dots, underscores, and hyphens; colon, whitespace, path separators, controls, and empty components are forbidden. An interface ends in an integer @revision. A profile reference is profile-id@revision or profile-id@sha256-<lowercase-hex>; the referenced record still carries the full digest. Parsing is structural, never a split of an unrestricted provider string.

Existing v1 keys remain legible only through an explicit compatibility projection from exact family/model pairs to exact interfaces and profiles. A migration never silently reinterprets a persisted key, and no unknown family is converted to a generic service.

Runes, Runes in groups, and placement

A Soulstone or Portal Rune will declare first-class [[capabilities]] entries referencing exact interface, profile, driver, dialect, evidence, resource, and containment definitions. Current [[models]] blocks remain compatibility sugar for the proved model interfaces; non-model services never invent a model id or LLM generation overlay merely to load.

One Rune may belong to several Covens. A Coven names compatible local services that may rise together; it does not choose semantic capability, reserve resources, schedule a job, pool VRAM, or authorize a Portal. Current conflict domains remain the conservative executable law.

The later ResourceEnvelopeRef records measured idle, active and transition-peak GPU memory, host RAM, disk, devices and topology, bandwidth, warm-up and unload time, concurrency, and measurement conditions. A PlacementProfile relates exact envelopes and required headroom under one host or Legion topology. A future CapabilitySetRequest@1 may ask Orchestrator to converge several exact bindings through one serialized desired-world transaction. Physical effects are not atomic: the request uses those profiles and existing drain, attest, compensation, restoration, and containment law rather than turning a Coven into a second scheduler or promising rollback that hardware cannot prove.

Composition boundary

A capability supplies an exact technical interface; a Spell defines the semantic action at a Pattern station. The consuming Composition retains application records, judgment, policy, and effects. Domain jobs and results may share grants, attempt recovery, and artifact custody without collapsing into a generic MediaJob, tool_execution, or universal OpenAI adapter.

Connectors owns invocation dialects and the current chat-only implementation boundary. Dispatcher (22) owns matching and leases; Orchestrator (23) owns physical readiness; and Workers (14) owns durable attempt settlement.