Soulstone: The Forged Local Engine

A daemon in a bottle, with its fire in your keeping.

A Soulstone is a local Animator: a rootless Podman container projected through Quadlet and supervised by the user's systemd manager. Its Soulstone Rune is immutable Codex intent. Binding compiles that intent into a physical service; the Animator adapter separately declares capabilities, probes readiness, and translates supported runtime-native operations.

For a model-backed capability, the Soulstone is the local furnace in which an Animus may become active. The loaded model lends bounded power through its Connector and CapabilityGrant; it is not the Lich's Spirit or identity.

The local contract also preserves a practical dimension of sovereignty: useful capability can be possessed, inspected, stopped, and resumed by the operator rather than existing only as revocable remote tenancy.

The Local Contract

Local placement carries local obligations. A Soulstone names its quadlet.image, runtime, models, endpoint, devices, mounts, secrets, and lifecycle intent. It receives only that explicit substrate. A generated Quadlet is its body, not the capability object granted to a caller. The live Soulstone Animator holds the Rune and Connector, not that generated Quadlet document.

The Rune's schema boundary keeps embedded deployment structure separate from Rune ancestry and Domain ownership. Soulstone remains one domain concept, never Soul + Stone, and the only service term ending in “Stone”.

Read Soulstone Rune to declare the service and its models. Read Resources and Secrets before granting a device, mount, port, or credential.

Choose a Discipline

Disciplines is the short map of the built-in runtime families. The detailed engine contracts live under Soulstone Engines, including the difference between a server pinned to one model and a router that activates models in process. The engine pages own runtime-specific launch, connector, readiness, resource, and evidence boundaries; Soulstone owns their local lifecycle and Rune binding.

Lifecycle and Readiness

The Dispatcher grants only WARM; the Orchestrator alone owns managed starts, dynamic activation, conflict drain, and compensation. Coven groups compatible services; declared conflict domains govern physical incompatibility.

Proof and Recovery

Repository tests prove compilation, adapter contracts, and the declared-conflict topology. A real systemd/Podman/GPU/model run still needs the named receipt recorded by State of Work. Refusal before mutation leaves the prior world intact; uncertain mutation remains contained for operator recovery.