Soulstone: The Forged Local Engine

"A Portal is a whisper from the remote sky, but a Soulstone is a daemon in a bottle. It lives on local iron. It burns local electricity. It answers only the Magus."

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 name is one domain concept, not a Python decomposition into Soul + Stone. Soulstone is the only service term ending in “Stone”; shared deployment code uses the literal QuadletConfig name. Soulstone and Phoenix already embed that minimum value under quadlet without sharing Domain or Rune ancestry, while future Tether or Veil Runes may compose it without changing their identities.

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.

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.