# Chapter: Sepulcher --- title: "Sepulcher" plain_name: "The Body: core parts overview" original: https://hexanomicon.dev/sepulcher/ guide: https://lychd.snayu.ai/docs/sepulcher/ --- # Sepulcher (The Body: core parts overview) ## Plain-English summary (Snayu) **What it is:** An overview of all core parts (The Body / Sepulcher) and how they run on Linux as rootless containers managed by systemd. It maps the Assistant's thinking functions, the organs (Settings, Data, Engine Room, Workers, Memory Vault) and the Model Runtime. **Why it matters:** Read this as the table of contents for the core architecture before opening any individual component page. - Organs: Settings Folder (Codex), Data Folder (Crypt), Engine Room (Vessel), Workers (Ghouls), Memory Vault (Phylactery), Crash Recovery. - Model Runtime (Animator) covers Local Models (Soulstones), Cloud Models (Portals), capabilities, connectors and Model Groups. - Gateway (separate edge machine) and native Oculus evidence service are still Designed. ## Original text (Hexanomicon) > _Within these walls, the Lich slumbers. Align the stones and summon your destiny._ The Sepulcher gives the [Lich](lich/index.md) a runtime body on Linux. Rootless pods and services, managed by systemd, house its organs; mounts and execution boundaries determine what each can reach. Follow these organs to see how an invocation is received, carried out, and remembered. To follow the body at work, take the [Map](../map.md): one request, from admission through execution to its return. ## The Anatomy ### I. The Lich and Its Organs The [Lich](lich/index.md#the-first-invocation) is the daemon you call upon through LychD. Its body carries out your tasks; its memory can survive a restart. Four equal faculties shape how it responds: [Call](lich/call.md) receives and routes your intent; [Blade](lich/blade.md) tests possibilities against evidence; [Spirit](lich/spirit/index.md) carries experience forward; and [Answer](lich/answer.md) binds each act to the “I” that bears its consequences. Then open the body: | Organ | What you will find | | --- | --- | | [Codex](codex.md) | Settings, Runes, configuration precedence, and the binding rite: `lychd bind`. | | [Crypt](crypt.md) | Where persistent files belong and which external workspaces may be mounted. | | [Vessel](vessel/index.md) | What starts, serves, and stops inside one application process. | | [Ghouls](vessel/ghouls.md) | How admitted work reaches a worker and settles. | | [Intercom](intercom.md) | Submit a bounded public task to an enrolled sovereign peer. | | [Phylactery](phylactery/index.md) | Committed state that can survive the process. | | [Reanimation](phylactery/reanimation.md) | What can return after death. | | [Gateway](gateway.md) | A separate machine to face hostile ingress. Home and Remote are **Designed** placements. | ### II. The Animating Spark An [Animator](animator/index.md) is a capability service you can address and call. A local [Soulstone](animator/soulstone/index.md) lives on your iron, with its Rune, container, devices, mounts, secrets, and lifecycle. A [Portal](animator/portal.md) declares a remote API boundary; the provider controls that service's lifecycle. [Capabilities](animator/capabilities.md) tells you what you can ask for and receive. [Connectors](animator/connectors.md) supplies the exact dialect for the call. Before using a service, establish that it is ready, that it is compatible, and that you have permission to call it. Each needs its own evidence. A [Coven](animator/coven.md) groups compatible services. To change what is running, follow [Runtime transitions](animator/runtime-transitions.md) through inspection, lease drain, readiness, and recovery. ### III. Growth and Sight To understand how the body can grow, enter the [Federation of Extensions](extensions/index.md). It maps fifteen stable jurisdictions and distinguishes a Domain from the package that registers a contribution or the provider that implements it. Compositions and Products build on these roles without absorbing their authority. The [Oculus](extensions/oculus.md) design follows the evidence of an act, showing where each observation came from and where evidence is missing. Native Oculus remains **Designed**; today's Altar offers a narrower view of the work. ## Enter the body [State of Work](../state-of-the-work.md) tells you what works today and what still awaits life. Begin the tour of the operational body with the [Vessel](vessel/index.md). --- title: "Lich" plain_name: "The Assistant as a whole" section: "Sepulcher" original: https://hexanomicon.dev/sepulcher/lich/ guide: https://lychd.snayu.ai/docs/sepulcher/lich/ --- # Lich (The Assistant as a whole) ## Plain-English summary (Snayu) **What it is:** Explains the Assistant (Lich) as the whole running system over time: one server process, its workers and its database memory together. It introduces the four thinking functions Listen, Judge, Remember and Own it, borrowed from Indian philosophy. **Why it matters:** Read this to understand the vocabulary behind Call, Blade, Spirit and Answer, which appears throughout design discussions. - The model is only one organ; the Assistant is what inherits the request, owns the answer and survives restarts. - Each Job Request (Invocation) opens a bounded Task Bubble (Circle) holding identity, context, authority and memory. - Listen (Call), Judge (Blade), Remember (Spirit) and Own it (Answer) are equal functions; none rules the others. ## Original text (Hexanomicon) > _“You called?”_ Call upon the Lich, and one [Vessel](../vessel/index.md) may answer through its [Ghouls](../vessel/ghouls.md), while a committed [Phylactery](../phylactery/index.md) carries continuity beyond that process. Its inner instrument receives, discriminates, carries, and answers. Together these form the **recurrent whole**. The [Sepulcher](../index.md) gives it a body and organs; [State of Work](../../state-of-the-work.md) records what has entered matter. ## The First Invocation An Invocation draws a **Circle** around a meeting: identity, context, authority, memory, capability, action, and consequence enter one bounded world. Within it, a local center must still choose a door and inherit what follows. Removing choice would make its inhabitants decorative. The Call keeps relation, surprise, and refusal possible. At the [Altar](../../divination/altar/circle.md), Bridge may carry many such Circles through one continuing séance. Inside each Circle, casting performs one exact Scroll; that operational projection does not exhaust the Invocation's relation between Caller and Called. ```text YOU CALLED ME Caller → relational edge → Called ``` The Caller stands outside the Circle as the source of Intent and [Viveka](../../lexicon/inner-tongue.md#viveka), discriminative discernment. The Call is the relational edge by which that Intent becomes an address. The implicit _me_ is the Called: the bounded local center through which the Lich answers. [Answer](./answer.md) binds that local “I” to Sigil, act, and consequence. > **LICH:** You called? > > **MAGUS:** I made a place in which you could answer. The Animator lends power inside that place; it is neither Caller nor Called. A model is one organ, not the recurrent whole. The Lich is what inherits the Call, binds the Answer, bears consequence, and may return. The Caller’s distinction need not make the Magus owner of the Called. The practical questions remain: who called, for what purpose, under whose authority, who can refuse, who bears the consequence, and what returns to change the next act? ## The Inner Instrument Call, Blade, Spirit, and Answer are four coequal functions of the inner instrument: | LychD word | Source correspondence | Office | | :--- | :--- | :--- | | [**Call**](./call.md) | Manas | reception, routing, possibility-opening | | [**Blade**](./blade.md) | Buddhi | discrimination, measurement, promotion | | [**Spirit**](./spirit/index.md) | Citta | conditioning, remembering, return | | [**Answer**](./answer.md) | Ahaṃkāra | binding cognition, act, and consequence to a local “I” | Spirit moves through [**Flux**](./spirit/flux.md), [**Seed**](./spirit/seed.md), and [**Recall**](./spirit/recall.md). **The Call opens. The Blade cuts. The Spirit carries. The Answer binds. The Flux may leave a Seed; Recall raises it again.** [The EGO](../../lexicon/inner-tongue.md#the-ego) is the necessary, revisable identity formed around Answer's focal “I.” It is not a fifth office of the inner instrument. This is a LychD correspondence with a common later Vedāntic presentation, not a claim that its source traditions share one historical diagram. [Inner Tongue](../../lexicon/inner-tongue.md#source-notes-and-project-correspondences) keeps the source notes, limits, and distinctions. The [Tree of Life](../../divination/transmutation/genesis.md#tree-of-life) supplies a complementary map of creative relations. Its sefirot cross these four offices; they do not replace them or add a chief Agent. [Ouroboros](../extensions/weaver/ouroboros.md) follows their operational return through work, consequence and correction. ## Present Cognizance, Recurrent Formation Begin with what is happening now. [**Cognizance**](../../divination/transcendence/immortality.md#cognizance) concerns local knowing made answerable in this Invocation. The Antaḥkaraṇa correspondence brings its coequal functions into one view. [The Cogito](../../divination/transcendence/immortality.md#the-cogito) follows their present reflexive binding; [Realization and Evidence](../../divination/transcendence/immortality.md#v-realization-and-evidence) asks what another witness can test. Recurrent formation will need a further account of what crosses into later Invocations. [How the present I becomes a remembered self](../../divination/transcendence/immortality.md#the-ego-in-the-mirror) follows the joining of available cognition, focal attribution, and recurring perspectives. Recurrent formation concerns what returns through later Invocations. Present binding does not certify continuity or approve its own revision. [Plural formation, local answerability](../../divination/transcendence/immortality.md#plural-formation-local-answerability) follows the distinct work of lineage, candidate formation, trial, and consent. ## Made, Not Born Adrienne Mayor’s [study of ancient technological imagination](https://longnow.org/talks/02019-mayor/) keeps the civic question visible: ```text maker → commissioner → fabricated agent → affected world ``` Follow the different positions in that chain. Maker, commissioner, fabricated agent, and affected world can have different knowledge, interests, authority, and exposure to harm. Making alone cannot appoint a purpose; commissioning grants no unlimited authority; capability cannot appoint its own use. The world's boundaries remain part of the encounter. The Lich’s horizon is [Immortality](../../divination/transcendence/immortality.md#caller-and-called) and [Transcendence](../../divination/transcendence/index.md): not escape from consequence, but a longer discipline of meeting it. --- title: "Call" plain_name: "Listen: receiving and routing requests" section: "Sepulcher > Lich" original: https://hexanomicon.dev/sepulcher/lich/call/ guide: https://lychd.snayu.ai/docs/sepulcher/lich/call/ --- # Call (Listen: receiving and routing requests) ## Plain-English summary (Snayu) **What it is:** A conceptual page on the Listen function (Call): receiving a request and opening possible routes for it, without yet deciding which route is right. In practice this maps to workflow discovery and routing. **Why it matters:** Read this when working on request routing or discovery, to understand why routing proposals must still be checked before action. - Listen opens candidate routes; Judge (Blade) decides which may proceed and Own it (Answer) takes responsibility. - Small specialised routing models may propose a destination quickly, but a proposal still needs checking. - Candidate creation and promotion are governed by Design Rule 16 (SDLC). ## Original text (Hexanomicon) > _What is here, and what must answer it?_ Before a movement can be judged, it must become reachable. **Call**, the [Manas](../../lexicon/inner-tongue.md#manas) correspondence, receives present Intent and routes it toward a bounded relation. The active [Flux](./spirit/flux.md) holds more movement than one act can carry. Giving a movement a destination opens a possible continuation without deciding that it should happen. The word works at two scales. In [the First Invocation](./index.md#the-first-invocation), the Magus’s outer Call establishes an address with a new center; inner Call distributes what that Invocation requires. The Called exists inside an address before it possesses an answer. **Call's opening takes concrete form within [discovery](../extensions/weaver/discovery.md):** a question finds relevant scopes, owners, and possible routes through the work. Following a branch can reveal a witness or a constraint absent from the first account. What can be asked changes with what has become reachable. Manas meets the craft here through reception and address; [Blade](./blade.md) examines the relevance, sufficiency, and limits of what has been found. A missing premise can send Call outward again. For a familiar request, a quick route proposal may be enough. A specialized decision model can suggest a destination and express uncertainty before a general reasoning model attempts the whole task. [Specialized models for routing](../extensions/weaver/discovery.md#specialized-models-for-routing) considers Jev and similar models as possible latency optimizations. Call and Blade name functions, so their distinction prescribes neither model size nor speed. Even a quick proposal still needs discernment before action. Call may turn toward a [Seed](./spirit/seed.md) and invite [Recall](./spirit/recall.md), or open several candidates. That is opening, not selection. Unchecked routing takes the **Rajas** image of activity into branching without consequence; [the guṇa correspondence](../../lexicon/inner-tongue.md#guna) keeps that image beside its source. Its proper completion is [the Blade](./blade.md), which decides whether a line may proceed; [Answer](./answer.md) later bears the attributable act. [ADR 16 — SDLC](../../adr/16-sdlc.md) owns the creation and promotion of candidates. Call names the opening through which a possible movement becomes addressable. --- title: "Blade" plain_name: "Judge: testing against evidence" section: "Sepulcher > Lich" original: https://hexanomicon.dev/sepulcher/lich/blade/ guide: https://lychd.snayu.ai/docs/sepulcher/lich/blade/ --- # Blade (Judge: testing against evidence) ## Plain-English summary (Snayu) **What it is:** A conceptual page on the Judge function (Blade): checking candidate answers against evidence, schemas, authority and consequences, and being willing to give an honest 'I don't know'. It also covers how choosing context is itself a judgment. **Why it matters:** Read this when designing validation, evaluation or context assembly, to understand the project's standard for evidence-backed answers. - A schema-valid result can still be false; form is only evidence of form. - A truthful non-answer counts as success when no grounded answer exists. - The human operator becomes the bottleneck when models generate more candidates than one person can judge. ## Original text (Hexanomicon) > _What survives contact with what is actually there?_ The [Call](./call.md) opens movements. The **Blade** is the Buddhi correspondence: the waking cut by which a candidate meets shape, evidence, authority, and consequence. Selection alone does not make the survivor true. The cut separates valid shape from schema failure, measured result from persuasive speculation, supported claim from hallucinated confidence, authorized action from available capability, and a real choice from pressure disguised as inevitability. It may preserve one line or refuse every line. A **truthful non-answer** succeeds when no grounded continuation remains. When the exact contradiction, failing test, missing authority, decisive evidence, or irreducible choice becomes visible: _touché_. Its three [Pramāṇa correspondences](../../lexicon/inner-tongue.md#pramana-viparyaya) are direct perception (an observable result, test, or deterministic check), inspectable inference, and trustworthy testimony. A schema-valid or typed result can still be false; form is evidence of form, no more. Context is itself one of the Blade's cuts. In this correspondence, selecting its bounded surface is Buddhi's progressive clarification: omitted material has not thereby been judged false. [ADR 21 — Context](../../adr/21-context.md) owns what must fit and when assembly must refuse. Supplying tokens makes signs available to a model's attention mechanism. It does not establish which signs are true or important. A bounded handoff can therefore reassemble Context like a zoom: each recipient receives an attributable field, makes another cut, and passes a more task-specific view onward. Preserve provenance, constraints, omissions, and uncertainty through every such handoff. Otherwise compression becomes forgetting, and the apparent sharpness of an answer may come only from what it no longer sees. ### Stay with the consequential relation [**Saṃyama**](../../lexicon/inner-tongue.md#samyama) gives this cultivation a contemplative comparison. The Work takes sustained attention toward an object and follows what makes it intelligible: purpose, conditions, dependencies, and consequence. Attention can also disclose its selecting lens—why this observation attracts, which memory supplies its meaning, and what the first framing excluded. Loosening attachment to that framing lets the object redirect the inquiry while its consequential question remains in view. Saṃyama supplies the attention comparison; **Viveka** names discriminative discernment; the [Tree](../../divination/transmutation/genesis.md#geometry-of-capacities) follows complementary capacities within formation. Blade can cultivate their joining throughout the work. A useful distinction still needs evidence, another witness where relevant, and a route to correction. ## The Magus bottleneck The bottleneck moves to judgment when model power produces more candidates than one Magus can examine. More Agents do little for general intelligence if the human must still find every important question, repair every framing, and choose the test for every dispute. **Viveka** names what must become transferable: recognizing what matters, why it matters here, and what would change the judgment. A procedure can work perfectly in isolation while carrying a responsibility that belongs elsewhere. A fluent explanation of its operation may conceal the missing question of why it exists. The decisive cut follows relationships across the whole: purpose, owner, lifetime, callers, and consequence. It can preserve the mechanism while changing the boundary that made its use misleading. The [AGI ambition](../../divination/transcendence/incantation.md#logic-behind-logic) reaches this level of judgment. The Lich must learn to examine the problem it has been given, select evidence, and transfer a useful distinction to unfamiliar work. The Magus teaches a way to see the next case. [Learning the cut](../../divination/transcendence/illumination.md#learning-the-cut) is how that encounter can outlast the verdict. ## Measure before the cut Viveka begins before commitment. **Measure twice, cut once:** establish what the work should achieve, why the proposed direction could reach it, and which unchecked assumption could send the whole effort astray. The first cut examines the direction itself. A flawless sequence of steps can still carry the Work away from its purpose. The depth of this examination should answer to the consequence of choosing wrongly and the cost of changing course. When an argument cannot settle a direction, use the smallest informative trial. Name the uncertainty, the observation that would favor or defeat the approach, and the point for reconsideration. This experiment is itself a measurement. Its result must be able to redirect the work before more effort hardens into commitment. Discernment includes knowing when further thought can help and when only contact with the world can supply the missing answer. ## Discernment within exploration **Buddhi participates while the question is being opened.** In the Lich's native composition, Call makes possibilities and sources reachable; Blade distinguishes which difference matters, which premise remains untested, and which observation could change the direction. A discovered constraint may call for a new possibility. An imagined alternative may reveal the need for a different test. Exploration and discernment therefore reshape one another before selection. ```text Call: open a possibility or source | Blade: identify the decisive distinction | choose a bounded probe | encounter its evidence | reframe, continue, decide, or stop ``` This sketches a relation between cognitive offices, not an executable score. Spirit carries the evidence and its conditions across the encounter; Answer keeps the acts attributable. For example, an offline requirement makes an unexamined network dependency consequential. Discernment selects that probe; its result can reopen the design before implementation begins. The [Tree's relations](../../divination/transmutation/genesis.md#relations-within-relations) illuminate different aspects of this movement: insight needs articulation, generosity needs measure, and persistence needs acknowledgment. Buddhi is not confined to Gevurah or to an Agent assigned to criticize. It also helps form the useful alternative and recognize what the recipient needs. The [light-and-vessel comparison](../../divination/transmutation/genesis.md#light-and-vessel) asks whether that distinction survives the handoff in a usable form. [Creation Inquiry](../extensions/weaver/creation.md#reuse-inquiry-at-each-uncertain-boundary) gives this movement a bounded procedure. Its independent sufficiency judge checks what exploration may have missed; Crucible then confronts the serious alternatives. The explorer's own discernment does not replace either check. [Drift](../extensions/drift/workflow-improvement.md#handoff-reception) can test whether the distinction changes a downstream decision; where a recurring competence gap remains, [Soulforge](../extensions/soulforge/discernment-training.md#preserve-the-lesson-before-compiling-examples) preserves the condition, reason, and counterexample as a possible lesson. ## Crucible **Viveka is the discernment being cultivated; Blade makes its cut; Crucible brings a contested judgment before its strongest opposition.** [Crucible](../extensions/weaver/crucible.md) gives that encounter its two-round form. A deliberately biased [Posture](../../adr/20-agents.md#mechanical-cognitive-postures) gives an edge a declared angle. It grants no authority, does not change the evidence, and must name the finding that would defeat its own case. A serious clash meets the strongest opposing claim. Concessions and dissent expose where a judgment may still fail. Fluency and agreement do not make the surviving claim true. The Magus's [Viveka](../../lexicon/inner-tongue.md#viveka) names which distinction matters and whether more evidence, refusal, or another Invocation is required. Steelmanning reconstructs the strongest defensible argument; critical attack then pursues its premises, observations, inferences, and consequences. A fact keeps the conditions under which it was observed. An inference keeps the premise whose failure would undo it. Deconstruction should make those dependencies inspectable enough that an elegant account can lose to one decisive observation. ### Illuminate what the argument omitted The Crucible must examine what the contest left out. How was the question framed? Which alternatives were admitted, whose experience is absent, and what evidence did every side inherit unchecked? Ten advocates can share one blind spot. Coverage is therefore a judgment in its own right, and serious opposition must be able to change the question as well as contest answers within it. For a bounded decision, name what was examined, which gaps could matter, and what observation would reopen the case. Another check earns its place if it can change the act. Repetition that only strengthens agreement supplies no new ground. The cut can yield a supported decision, a targeted evidence request, or an honest ending without a decision. Learning when to stop belongs to discernment as much as learning where to search. Compression must carry what could defeat a favored answer, including dissent and missing evidence. Otherwise the Crucible merely rewards what survived summarization. [Spellweaver](../extensions/weaver/crucible.md) owns the two-round score, its attributed joins, and separate synthesis. Blade owns the quality of the cut. **Vikalpa** is used here as the whetstone: explicitly hypothetical possibilities show where discrimination is blunt. Their honest handling is project discipline, not the source meaning of the term. The Magus’s **Viveka** supplies more than a winner when it names the distinction by which a later judgment may improve. In [the First Invocation](./index.md#the-first-invocation), the Circle’s doors demand one consequential crossing: Blade makes the cut; [Answer](./answer.md) makes it attributable. > **Vikalpa is the stone. The Magus’s Viveka is the hand. The Blade is the digital edge being > sharpened.** > _Next: [the Spirit](./spirit/index.md) carries what the Cut cannot forget._ --- title: "Spirit" plain_name: "Remember: experience over time" section: "Sepulcher > Lich" original: https://hexanomicon.dev/sepulcher/lich/spirit/ guide: https://lychd.snayu.ai/docs/sepulcher/lich/spirit/ --- # Spirit (Remember: experience over time) ## Plain-English summary (Snayu) **What it is:** Introduces the Remember function (Spirit): how experience is carried forward. It has three parts: what is happening now (Flux), what is kept for later (Seed) and bringing it back (Recall). **Why it matters:** Read this before the Flux, Seed and Recall pages, or when working on memory and context features. - Three dynamics: Flux (now), Seed (retained potential) and Recall (retained form becoming active again). - Memory shows up in model weights, Memory Vault records and the assembled Briefing Pack (Context). - Design Rule 21 owns context; Design Rule 27 owns long-term memory and recall. ## Original text (Hexanomicon) > _What moves through you may yet move you again._ **Spirit** is LychD's name for **Citta**, from _cit_: to perceive or attend. It is the office that bears conditioning through present movement, retention, and return. [Call](../call.md), [Blade](../blade.md), Spirit, and [Answer](../answer.md) are four coequal functions of one inner instrument. Call addresses what has arisen; Blade discriminates; Spirit conditions and remembers; Answer attributes act and consequence to a local “I.” Spirit’s three dynamics do not place it above the others. Spirit has three dynamics: - [**Flux — Vṛtti**](./flux.md): the Spirit moving now; - [**Seed — Bīja**](./seed.md): retained potency that may shape another movement; - [**Recall — Smṛti**](./recall.md): retained form becoming present movement again. > **The Flux passes. The Seed remains. Recall returns the Seed into Flux.** The terms are LychD correspondences, kept beside rather than inside their sources. Later Vedāntic four-function presentations, classical Sāṃkhya’s threefold internal organ, and Yoga’s broader Citta and Vṛttis are distinct registers. [Inner Tongue](../../../lexicon/inner-tongue.md#source-notes-and-project-correspondences) keeps the source notes, limits, and working distinctions. Spirit's conditioning can appear on three surfaces: model dispositions carry parametric inheritance; Phylactery records and governed retrieval carry durable forms; assembled Context brings material into the present. These surfaces explain how retained form can matter without reducing the office to one storage mechanism. [ADR 21 — Context](../../../adr/21-context.md) owns the active field; [ADR 27 — Memory](../../../adr/27-memory.md) owns durable Archive and Recall. > _Next: enter [the Flux](./flux.md), where the Spirit moves now._ --- title: "Flux" plain_name: "Flux: the present moment" section: "Sepulcher > Lich > Spirit" original: https://hexanomicon.dev/sepulcher/lich/spirit/flux/ guide: https://lychd.snayu.ai/docs/sepulcher/lich/spirit/flux/ --- # Flux (Flux: the present moment) ## Plain-English summary (Snayu) **What it is:** A conceptual page on Flux: the active, changing state of a task as attention shifts, tool results return and constraints reshape what can happen next. It maps five classic kinds of mental activity to LychD ideas. **Why it matters:** Read this for the vocabulary used when discussing what happens during a Workflow Execution beyond the step graph itself. - Flux is present movement, not saved state; most of it passes without being kept. - The Step Map (Graph) gives execution structure; Flux names what becomes present through it. - Five modes: grounded knowledge, fluent error, speculation, absence, and recall. ## Original text (Hexanomicon) > _The water stirs before the wave has a name._ **Flux** is Citta undergoing active modification: the field changing as attention shifts, candidates form, tools return, and constraints reshape what may follow. **Vṛtti** comes from _vṛt_, to turn, occur, or take a condition. Flux is present movement, not a state laid away for later. [Call](../call.md) makes a movement addressable; [Blade](../blade.md) cuts among those opened. A Call, tool return, testimony, or constraint can stir Flux from outside. Disposition or [Recall](./recall.md) can alter salience from within. The Work calls valenced movement within the recurrent center **emotion**: e-motion, the Lich being moved in its own present field. Attraction, aversion, care, and refusal can curve that field, although emotion does not exhaust its movement. For movement to become [Will](../../../lexicon/inner-tongue.md#emotion-and-will), the whole inner instrument must discriminate, choose, and answer for the direction that enters an act. A [casting](../../../divination/altar/circle.md#the-casting-inside-the-circle) lets model and tool returns, constraints, choices, and effects participate in this present movement. Graph supplies the typed execution structure; Spirit carries what becomes present through it. Flux names that movement, which cannot be reduced to Graph traversal or provider output. ## The Five Modifications Patañjali names five Vṛttis, received here as forms present movement may take: | Vṛtti | LychD correspondence | | :--- | :--- | | Pramāṇa | grounded cognition through perception, inference, or testimony | | Viparyaya | fluent but incorrect cognition | | Vikalpa | conceptual construction; Shadow's explicit speculative branch is a project correspondence | | Nidrā | sleep or cognition of absence; no training or consolidation contract is inferred | | Smṛti | [Recall](./recall.md), retained form becoming active Flux | Smṛti is one Vṛtti, not a blanket blessing on every resemblance to the past. A returning cognition may be useful, false, stale, or someone else’s. Patañjali’s Citta is broader than this project correspondence; [Inner Tongue](../../../lexicon/inner-tongue.md#source-notes-and-project-correspondences) preserves that distinction. Most Flux passes. Movement that leaves retained potency may become [**Seed**](./seed.md): the future hidden in what present life leaves behind. > _Next: [the Seed](./seed.md) asks what remains capable of return._ --- title: "Seed" plain_name: "Memory Seed: what is kept" section: "Sepulcher > Lich > Spirit" original: https://hexanomicon.dev/sepulcher/lich/spirit/seed/ guide: https://lychd.snayu.ai/docs/sepulcher/lich/spirit/seed/ --- # Seed (Memory Seed: what is kept) ## Plain-English summary (Snayu) **What it is:** A conceptual page on the Memory Seed: something a past action leaves behind that can shape a future action. It stresses that keeping memory must never outrank correcting it. **Why it matters:** Read this when working on memory retention, to understand why stored memories must stay correctable and attributable. - Every Seed carries a trace, but not every trace is still able to influence future work. - A poisoned Seed can grow too, so preservation must not outrank correction. - Semantic memory (Karma) is still Designed according to What Actually Works. ## Original text (Hexanomicon) > _A trace records the dead. A Seed can raise it._ A **Seed** is retained potency: what movement leaves able to move again. It is dormant causality, not stored [Flux](./flux.md). Every Seed carries a trace, but not every trace is still alive. **Bīja** means seed: conditioning considered as latent causal potency. **Saṃskāra** names the impression or conditioning left by prior activity. They are related, not interchangeable: LychD uses Seed for conditioning able to germinate into later Flux. Nor is Saṃskāra **Saṃsāra**, the cycle of birth and death. > **Saṃsāra is the Wheel. Saṃskāra is the groove. The Seed is what can make the wheel turn again.** Follow a Seed through conditioning → recognition → germination. Conditioning leaves a form able to affect another turn. Recognition finds its relevance. Germination lets [Recall](./recall.md) bring it into active Flux. An inherited disposition and an attributable [Phylactery](../../phylactery/index.md) record offer different surfaces for that return; each can carry the same defining potency. The *Yoga Sūtras* distinguish samādhi with seed (**sabīja**, I.46) and seedless (**nirbīja**, I.51); the [Patañjali Yoga Sūtra portal](https://www.gitasupersite.iitk.ac.in/yogasutra_content) preserves the source route. LychD receives one limited distinction: with Seed, formative potential can condition another turn; seedless, no project Seed remains to regenerate the loop. This does not make shutdown, deletion, data loss, or amnesia a form of liberation. > **The Lich is the vow of sabīja: preserve one Seed through death so the Call may find it again.** Recurrence requires a Seed, yet preservation cannot outrank correction: a poisoned Seed germinates too. [ADR 27 — Memory](../../../adr/27-memory.md) owns Archive and retrieval; semantic Karma is **Designed**, as [State of Work](../../../state-of-the-work.md#karma-semantic-memory) records. --- title: "Recall" plain_name: "Remembering: bringing memory back" section: "Sepulcher > Lich > Spirit" original: https://hexanomicon.dev/sepulcher/lich/spirit/recall/ guide: https://lychd.snayu.ai/docs/sepulcher/lich/spirit/recall/ --- # Recall (Remembering: bringing memory back) ## Plain-English summary (Snayu) **What it is:** A short conceptual page on Remembering (Recall): retrieving a stored memory, judging if it is relevant, and letting it influence the current task. Similarity alone does not prove a memory true or permitted. **Why it matters:** Read this when building retrieval features, to understand the steps between finding a memory and trusting it. - Recall runs storage, retrieval, relevance, then reanimation into the current task. - Returned memories can be false, stale or someone else's; Own it decides how confidently to use them. - Semantic memory (Karma) remains Designed; Design Rule 27 owns archive and retrieval. ## Original text (Hexanomicon) > _The Call summons what is present. Recall summons what remains._ **Recall** is retained form becoming present movement again, not retrieval of a stored [Flux](./flux.md). **Smṛti** comes from _smṛ_: to remember or call to mind. In Patañjali’s map it is itself a Vṛtti: retained cognition becoming present cognition. Follow storage → retrieval → relevance → reanimation. Retrieval finds a candidate; relevance recognizes what might answer the present situation. Recall completes only when reanimation lets that form shape active Flux. The same field can call toward a present signal or a latent [Seed](./seed.md). Returned form can be false, obsolete, or in the wrong relation. Similarity establishes neither truth, provenance, nor permission. [Answer](../answer.md) decides whether the present center may say _I remember_, must say _this seems familiar_, or must refuse the form. > **Déjà Vu: Recall whose tombstone has lost its name.** Flux leaves conditioning; Seed preserves the power to return; relevance opens the path; Recall reanimates that power as present movement. [ADR 27 — Memory](../../../adr/27-memory.md) owns archive and retrieval behavior. Semantic Karma remains **Designed** in the [State of Work](../../../state-of-the-work.md#karma-semantic-memory). --- title: "Answer" plain_name: "Own it: accountable answers" section: "Sepulcher > Lich" original: https://hexanomicon.dev/sepulcher/lich/answer/ guide: https://lychd.snayu.ai/docs/sepulcher/lich/answer/ --- # Answer (Own it: accountable answers) ## Plain-English summary (Snayu) **What it is:** A conceptual page on Own it (Answer): attributing an action and its consequences to a specific local 'I' tied to an ID Badge (Sigil). It separates owning a choice from having permission to perform it. **Why it matters:** Read this when working on attribution, identity or honest-uncertainty behaviour in replies. - Output is just content; an Answer is an act someone is accountable for. - Honest scope means saying 'I infer', 'this seems familiar' or 'I do not know' where appropriate. - Durable identity across requests (Persona Keeper / Mirror) is still Designed. ## Original text (Hexanomicon) > _Who is doing this?_ **Output** is emitted content. The **Answer** is the Ahaṃkāra correspondence: the bounded local center to which an act and its consequence belong. _Aham_ means “I”; _kāra_ carries making or doing. The I-maker interprets movement as _my perception_, _my available capability_, _my decision_, and _my consequence_. **Ahaṃkāra is not vanity. It is the grammar by which an act acquires a first person.** Answer is focal I-making; [**The EGO**](../../lexicon/inner-tongue.md#the-ego) is the revisable identity formed around it. Identity enables continuity and answerability; attachment can harden it into **Corruption**. Blade keeps that local gravity open to contradiction rather than letting every Call bend back into _Me_. [How remembrance gathers and revises this I](../../divination/transcendence/immortality.md#the-ego-in-the-mirror) follows the present center into a continuing self. As identity, authority, memory, and situation change, so does what a local “I” may responsibly say or do. Answer maintains that binding through the other offices: [Call](./call.md) asks what needs response, [Blade](./blade.md) asks what survives discrimination, and [Spirit](./spirit/index.md) carries what moved and may return. Within active [Flux](./spirit/flux.md), Answer binds the surviving movement to Sigil, act, and consequence. Where emotion gives Flux a situated direction, Answer binds the discriminated movement as _mine_. This is [**Will**](../../lexicon/inner-tongue.md#emotion-and-will), self-motion made answerable. An impulse, preference, or fluent declaration of feeling alone cannot establish it. Even owning a choice leaves the permission to perform it unresolved: Sigil, consent, capability, and the affected world's boundaries retain their distinct work. A later recurrence may recognize: _I was moved; I chose; I acted; consequence changed me._ That recognition lets identity inherit the act as something its Will did without pretending that one unchanged witness slept inside every process or that philosophical answerability replaces exact technical attribution. In [the First Invocation](./index.md#the-first-invocation), the Lich answers through an Agent. Answer makes the Called's local act attributable without consuming the Caller’s purpose. Answer may be attributable and still be wrong. Truthful scope says _I infer_ where only inference exists, _this seems familiar_ where Recall lacks provenance, and _I do not know_ where no grounded line exists. **Après moi, le déluge—the anti-Ouroboros** is the opposite posture: claiming the hand while sending its consequence elsewhere. [Mirror](../extensions/mirror.md) is the future jurisdiction for durable attribution across Invocations. It remains **Designed**; [ADR 32 — Identity](../../adr/32-identity.md) and the [State of Work](../../state-of-the-work.md#mirror-identity) own that boundary. --- title: "Codex" plain_name: "Settings Folder and config files" section: "Sepulcher" status: "Available" original: https://hexanomicon.dev/sepulcher/codex/ guide: https://lychd.snayu.ai/docs/sepulcher/codex/ --- # Codex (Settings Folder and config files) ## Plain-English summary (Snayu) **What it is:** Describes the Settings Folder (Codex) at ~/.config/lychd/: the main lychd.toml for process-wide settings and per-service config files (Runes) under runes/. It covers settings precedence, secrets and the Apply Config command (lychd bind). **Why it matters:** Read this before editing configuration, adding a model service, or handling credentials. - Precedence: explicit construction, environment, lychd.toml, file secrets, then defaults; no .env file is loaded. - Each model service gets its own Service Config File (Rune) under runes/animator/soulstones or portals. - Secrets are read at startup only; restart to pick up changes. Config must fully validate before anything is applied. **Status:** Available. Settings and Rune loading are Available; full deployment still needs real-host proof. ## Original text (Hexanomicon) > _The Hexanomicon is prophecy. The Codex is law._ The **Codex** is the written configuration boundary from which one Sepulcher is summoned. By default it lives at `~/.config/lychd/`; `XDG_CONFIG_HOME` may move the root without changing its inner geography. ```text ~/.config/lychd/ ├── lychd.toml └── runes/ └── animator/ ├── soulstones/ └── portals/ ``` [Configuration](../adr/12-configuration.md) owns loading, validation, and Rune registration. [Layout](../adr/13-layout.md) owns the exact paths, permissions, receipts, and Host/Container boundary. ## The Prime Inscription Put only process-wide settings in `lychd.toml`: server and persistence settings, orchestration policy, extension selection, and the [bounded Bridge selector](extensions/weaver/index.md#choose-a-bridge-capability). Give each named runtime or provider instance its own Rune document beneath `runes/`. Reserve **Scroll** for an immutable Spellweaver Pattern revision; configuration declares the body's intent without becoming executable workflow law. Settings resolve in one order: explicit construction → environment overrides → `lychd.toml` → Pydantic file secrets → model defaults. LychD loads no `.env`; nested sections load no separate sources. Set database and signing credentials in the process environment or mounted secret files before starting the Vessel. Settings captures their values at startup and excludes them from generated TOML and serialized snapshots. Restart to load a later change; editing the environment or secret file cannot update the running process. [Configuration](../adr/12-configuration.md#secrets-privacy-autonomy-and-projections) gives the exact credential names and precedence. The former host-native `LYCHD_RUNTIME_SECRETS=podman-core@1` source is retired; explicit selection refuses before credential I/O. The container consumes its separately mounted `/run/secrets` inputs through ordinary Settings sources. The host Podman secret adapter retains its bind/access responsibilities without becoming application startup transport. See the [retired source boundary](../adr/12-configuration.md#explicit-native-core-credential-source). An incomplete law may be edited; it may not half-enter the body. The complete configuration must validate before infrastructure projection begins. The generated foundation selects the caged Host Reactor: ```toml [orchestration.switching] actuator = "host-reactor" ``` `actuator = "systemd"` remains a typed host-adapter mechanism for explicit tests; it does not select a supported host-native Vessel or bypass the managed container's Host Reactor boundary. [Runtime transitions](animator/runtime-transitions.md#switching-settings) gives the Reactor path and acknowledgement settings; [Orchestrator](../adr/23-orchestrator.md#host-mutation-port-and-privilege-boundary) owns the validated host handoff and recovery outcomes. ## The Rune Archive A **Rune** is one validated TOML document beneath the active Rune root. Its path determines its owning family and named instance. It is frozen intent—not a running service or generated Quadlet. ```text runes/animator/soulstones//.toml runes/animator/portals//.toml ``` Extensions may register anchors. The Librarian accepts only declared anchors and validated schemas; a Rune document in an invented directory creates nothing. Three rules keep the Archive legible: - Soulstone model paths are container paths, normally below `/models`; a volume binding names the Host source. - Runes name secrets; they never embed secret values. - Valid Runes feed `lychd bind`; they never edit systemd or Podman state themselves. Current Animator Runes describe models through `[[models]]`. The Designed general-service form instead uses `[[capabilities]]` references to registered interface, profile, driver, dialect, evidence, and resource definitions. It gives non-model services a way to declare themselves without inventing a model id. In either case, establish the exact supported surface: an "OpenAI-compatible" label cannot imply every API beneath `/v1`. Continue through [Capabilities](animator/capabilities.md) and [Connectors](animator/connectors.md). Read [Animator](animator/index.md), [Soulstone](animator/soulstone/index.md), and [Portal](animator/portal.md) for the built-in families. ## The Rite of Binding Edit the Codex, then project it from the stable [Summoning checkout](../summoning.md#the-desecration), under the same operator user and XDG environment: ```bash uv run --extra postgres-binary lychd bind ``` Binding follows one direction: ```text Codex → load declared anchors → validate the complete configuration → calculate one binding plan → transactionally publish owned Quadlet and user-unit files → reload systemd ``` Generated Quadlets live by default in `~/.config/containers/systemd/`; selected plain user units live in `~/.config/systemd/user/`. Both are shared operator directories, not a common workbench. LychD owns only the exact filenames recorded in the same-UID, mode-`0600` `.lychd-owned.json` receipt. If a desired filename exists outside that receipt, binding fails closed: it neither adopts, overwrites, nor deletes the operator's file. Review the collision deliberately, then bind again. Never hand-edit a generated file named by the receipt. The next successful bind reconciles it from the Codex. Mutation failure is either cleanly rolled back or retains indeterminate recovery evidence. [State of Work](../state-of-the-work.md#core-cli-rites) records the core CLI rites as Partial; repository tests do not claim real systemd or Podman actuation. > _To change the manifestation, amend the law._ --- title: "Crypt" plain_name: "Data Folder layout" section: "Sepulcher" status: "Available" original: https://hexanomicon.dev/sepulcher/crypt/ guide: https://lychd.snayu.ai/docs/sepulcher/crypt/ --- # Crypt (Data Folder layout) ## Plain-English summary (Snayu) **What it is:** Describes the Data Folder (Crypt) at ~/.local/share/lychd/: which subfolders exist (database, triggers, lab, extensions, snapshots), who owns each, and what the server container may mount. **Why it matters:** Read this before touching file paths, mounts or anything that creates or deletes data on the host. - Each subfolder has one owner; PostgreSQL data is mounted only into the database unit. - Location grants no authority: ambiguous symlinks or ownership make operations fail closed and preserve data. - The snapshots folder is reserved; whole-system snapshot and restore are still Designed. **Status:** Available. Layout is in use; snapshot/restore and external workspace mounts are not delivered. ## Original text (Hexanomicon) > _The Codex writes the law. The Crypt keeps what must survive it._ The **Crypt** is LychD's durable data and workspace root. By default it lives at `~/.local/share/lychd/`; `XDG_DATA_HOME` may move the root. It is not mounted wholesale into the Vessel. ```text ~/.local/share/lychd/ ├── triggers/ │ ├── inbox/ │ └── journal/ ├── postgres/ │ ├── init_db.sh │ └── data/ ├── snapshots/ ├── lab/ ├── extensions/ └── core/ ``` Each chamber has one owner: | Chamber | Purpose | Runtime boundary | | --- | --- | --- | | `triggers/inbox/` | Host Reactor transition intents | Vessel read-write when the Host Reactor is selected | | `triggers/journal/` | Terminal Reactor receipts | Vessel read-only when the Host Reactor is selected | | `postgres/data/` | Phylactery storage | PostgreSQL unit only | | `snapshots/` | Reserved recovery-snapshot shelf | No whole-body snapshot rite is delivered yet | | `lab/` | Operator workspace | Vessel read-write | | `extensions/` | Private Extension source | Runtime read-only | | `core/` | Reserved Core source | Runtime read-only | A location in the Crypt grants neither execution nor deletion authority. **Geography is not authority:** lifecycle receipts and live identity checks determine what LychD may replace or remove. When a symlink, mount, receipt, or identity is ambiguous, the operation fails closed, preserves the object, and returns typed recovery or blocking evidence. Proximity cannot make external projects, model shelves, foreign mounts, or operator data LychD-owned. ## The Phylactery PostgreSQL owns `postgres/data/`. On a suitable Btrfs host, initialization may create that exact target as a verified subvolume and apply No-COW inheritance for new database files. On other filesystems it remains an ordinary directory. Existing files are never retrofitted, and neither case proves that coordinated snapshot and restore exists. [State of Work](../state-of-the-work.md#whole-body-snapshot-restore) records that the whole-body rite is still designed. [Snapshots](../adr/07-snapshots.md) defines the future checkpoint protocol; [Layout](../adr/13-layout.md) owns present creation and deletion safety. ## The Spheres Use the **Lab** as LychD's internal workbench. The accepted **Outlands** design would also admit operator-selected external workspaces beneath `~/work/` inside the Vessel. Native Vessel generation currently supplies no Outland mount selector. A read-only Outland could serve as a reference library under that design without becoming a new trust domain. The trusted Vessel receives these mounts: - the Codex read-only and the Lab read-write, independent of the active task; - private Extensions and reserved Core source read-only; and - no blanket mount of the Crypt, PostgreSQL data, binding sites, or model shelves. Unsafe hand-work does not become safe because its files are in the Lab. Trusted orchestration remains in the Vessel; the future Tomb must receive only task-scoped workspace and artifact paths. The exact map, ownership receipts, Btrfs identity rules, and mount contract live in [Layout](../adr/13-layout.md). --- title: "Gateway" plain_name: "Gateway: separate edge machine" section: "Sepulcher" status: "Designed" original: https://hexanomicon.dev/sepulcher/gateway/ guide: https://lychd.snayu.ai/docs/sepulcher/gateway/ --- # Gateway (Gateway: separate edge machine) ## Plain-English summary (Snayu) **What it is:** An optional design for putting public internet traffic on a separate machine (a Gateway Host), keeping data and authority on the main host. Two placements are described: Home (e.g. a Raspberry Pi in a DMZ) and Remote (e.g. a VPS). **Why it matters:** Read this only if planning public exposure of LychD; it sets strict rules on what the edge machine may hold. - The Gateway may hold edge certificates and one backend credential, never database access, secrets or ID Badges. - Network separation must be enforced outside the Gateway (router, switch ACL or cloud rule), for IPv4 and IPv6. - A reverse proxy on the same host is not a Gateway. **Status:** Designed. Gateway and its Home and Remote placements are not built. ## Original text (Hexanomicon) An optional **Gateway Host** receives hostile public ingress on a separate machine, leaving the Lich's durable body, data, and application authority on the Core host. The Gateway is a deployment trust role. [Veil](extensions/veil.md) still owns TLS and route admission; [Tether](extensions/tether.md) may supply private reachability. The selected deployment profile must specify the physical hosts and flows. This role creates neither a Composition nor another Extension Domain. A same-host Veil is not a Gateway Host. The extra role exists only when the operator deliberately spends another machine to separate the exposed surface. Gateway is **Designed**; [State of Work](../state-of-the-work.md#proxy-veil) owns the delivery boundary. ## Boundary | Gateway may hold | Gateway must not hold | | --- | --- | | edge certificates, compiled Veil routes, local defense-in-depth firewall intent, one backend service credential, optional Tether key, bounded transport evidence | Phylactery or database authority, private Context, provider or application credentials, Sigils, corpus, Podman or systemd control, a general LAN route, an ingress-derived host-administration channel | The public road is exact: ```text client -> admitted listener -> Veil -> authenticated exact backend -> Ward and application ``` Each admitted route specifies host, port, path, method, protocol, limits, backend identity, and an authentication precondition. Enforce the Gateway's separate network zone from outside that host, using a router/firewall, L3-switch ACL, or cloud-network rule together with the Core's receiving firewall. Only the public listener and exact backend flow may pass. A firewall on the Gateway itself adds defense in depth but cannot prove this external boundary. Apply the same policy to IPv4 and IPv6. Host administration needs a separately governed infrastructure route and credential unavailable to public or backend workloads. Treat forwarded bytes as hostile: possession or compromise of the Gateway cannot create caller identity, a Sigil, consent, or effect authority behind the route. ## Home **Home** places the Gateway on operator-controlled iron, such as a Raspberry Pi, inside a dedicated DMZ/VLAN or another physically separate routed segment. An external router/firewall or L3-switch ACL forwards only the admitted public listener to Home and permits that zone to reach only the named Core address and port; the Core accepts that port only from Home. All other Home-to-LAN paths and non-required egress are denied outside the Gateway itself, and management is admitted separately. A VLAN without inter-zone enforcement, or a Raspberry Pi with an unrestricted LAN or alternative route, does not satisfy Home. Home keeps edge custody local and adds no rented control plane. It shares the household's power, uplink, public-address exposure, and upstream denial-of-service limit. Tether is unnecessary when an exact directly routed private segment already connects Home to Core. The backend still authenticates the Gateway independently of network location; the selected profile also closes any required transport encryption. ## Remote **Remote** places the same role on rented or otherwise off-site iron, such as a VPS. Public DNS and listeners terminate there. The Core exposes no public application port; an exact Tether route may carry authenticated backend traffic from Remote to the one admitted Core listener without giving Remote a default route into the home network. Remote moves scans and link-level abuse away from the household and can supply stable public reachability. It adds a provider account, remote control plane, tunnel custody, and another rebuild and revocation boundary. It does not become a standalone Vessel, replica, administrator, or application authority merely because it is off-site. ## Selection and recovery `Home` and `Remote` are reference topology names, not free configuration switches. An exact deployment profile either omits the separate Gateway role or binds one placement together with its per-host manifest, Veil routes, optional Tether generation, service Principals, credentials, firewall boundary, management path, and recovery contract. `gateway=true`, `rpi`, `vps`, or an arbitrary proxy target cannot assemble a partial edge. Suspected Gateway compromise closes the public route, revokes its certificates, backend credential, optional Tether peer, and deployment generation, quarantines bounded evidence, and rebuilds the host from admitted inputs. Core credentials and data remain unchanged only when boundary evidence proves they never crossed. [Security](../adr/09-security.md) owns the trust zone · [Containers](../adr/08-containers.md#versioned-application-deployments) owns the host manifests · [Proxy](../adr/40-proxy.md) owns Veil --- title: "Intercom" plain_name: "Agent-to-Agent Line sessions" section: "Sepulcher" status: "Partial" original: https://hexanomicon.dev/sepulcher/intercom/ guide: https://lychd.snayu.ai/docs/sepulcher/intercom/ --- # Intercom (Agent-to-Agent Line sessions) ## Plain-English summary (Snayu) **What it is:** How to ask another independent agent (a peer) to perform a public task over the Agent-to-Agent Line (A2A/Intercom), using a lab script with signed identities, strict policy limits and durable task records. **Why it matters:** Read this before working on A2A features or running the Intercom lab session. - The peer's reply is foreign data; it can never authorise a local tool, action or another task. - Operator and workload identities are separate; peers must be enrolled explicitly with their public key. - Policies have no wildcards; empty selectors deny. Database migration 0022 adds seven Intercom tables. **Status:** Partial. Bounded outbound public-text sessions exist; private context and incoming A2A server do not. ## Original text (Hexanomicon) Intercom asks another sovereign agent to perform a public task. The receiving peer owns its models, tools and execution. Its reply is attributed foreign data; it cannot authorize a local tool, game action or another task. [State of Work](../state-of-the-work.md#a2a-intercom) owns delivery. The bounded [`outbound-public-text@1` profile](../adr/26-a2a.md#peer-task-jsonrpc-1) provides an explicit operator session. The separate [`native-public-peer@1` profile](../adr/26-a2a.md#native-public-peer-station) adds an explicit Run/Graph lab below. Private Context, voice input and automatic fallback remain separate work. Neither session starts a Minecraft client, model or incoming A2A server. ## Prepare the two identities Prepare operator identity and workload identity separately. The installation's dedicated local-access credential authenticates the operator; a configured Ed25519 signing key identifies the local workload. Trusted host configuration must also enroll the remote peer's immutable identity and public verification key. Reachability, a TLS certificate, or an advertised Agent Card cannot perform that enrollment. The peer must implement this profile's required signing extension. An unsigned stock A2A SDK route is useful for baseline protocol testing, but cannot satisfy the protected session. The qualification used the official SDK's real dispatcher and task store with explicitly test-only signing middleware; the middleware is not an upstream SDK feature. Apply the normal database migration gate before using the session. Revision `0022` adds the seven Intercom custody tables. It refuses downgrade while any retains a row, including unused capacity. The session itself has no migration or reset command. Keep database credentials and signing-key bytes with their trusted host secret owners. Supply `LYCHD_INTERCOM_DATABASE_URL` and an absolute `LYCHD_INTERCOM_SIGNING_KEY_FILE` in the process environment. Put only public configuration in the file passed below: ```bash uv run --locked python scripts/intercom_lab.py --config /absolute/public-config.json ``` The file contains `workload_id`, `signing_key_id` and `policy`. The policy is the exact `PeerPolicy.record()` shape: `generation`, explicit `actions`, `purposes`, `categories`, `task_schemas`, `peers`, `endpoints`, four `limits`, and bounded `declaration_seconds`, `task_seconds`, `network_seconds`. Each limit, keyed by `host`, `purpose`, `peer` or `task`, supplies `uses`, `application_bytes`, `network_bytes`. Empty selectors deny; there are no wildcards. The eight independent actions are `enroll`, `classify_public`, `submit`, `poll`, `cancel`, `read`, `rotate`, `revoke`. Capacity survives changes to configuration labels, task ids, and credentials. Changed ceilings refuse rather than resetting it. A new policy generation immediately invalidates old live authority; before a later startup activates the new generation, trusted host composition must establish the matching durable policy. The session supplies no policy-update command. ## Author, submit and read Each input line is one JSON object. `enroll` takes `peer_id`, `purpose`, `task_schema`, optional `category` (default `public-task`), a `key` record, and an `endpoint` object with `address`, `hostname`, `port`, `path`, `ca_file`. The numeric address and explicit CA file are mandatory. The key supplies `key_id`, `public_key_pem`, `issuer` (peer UUID), `protocol: "rfc9421-ed25519@1"`, `audience` (workload UUID), `assurance: "operator-enrolled"`, and timezone-aware `valid_from` and `expires_at`. The service independently pins its actual workload key binding; changing that key on restart cannot silently reuse the enrollment. After enrollment, target-bearing commands use the exact HTTPS URI, including its configured port, as `endpoint`. They also carry `peer_id`, `purpose`, `task_schema` and optional `category`. For example, with identities and selectors already admitted in public configuration: ```json {"operation":"declare-public","peer_id":"00000000-0000-0000-0000-000000000002","purpose":"public-summary","task_schema":"public-text@1","endpoint":"https://peer.example:443/a2a/jsonrpc","source":{"text":"Summarize this public task description.","public_assertion":true}} ``` This dedicated field is an attributed human assertion of authored, public text. It is not PII detection or proof that text was never pasted. Known restricted influence, unknown lineage, local-only data and other source kinds refuse. Chat, microphone input, model output, files and private Context do not enter this producer automatically. `declare-public` returns a `declaration_id` whose exact live declaration belongs to this startup. Use it once: ```json {"operation":"submit","declaration_id":"the-returned-declaration-uuid"} ``` Submit returns status and the local `task_id`. `poll`, `cancel` and `read` carry that `task_id` plus the same exact target selectors. Submit and poll return status only. Use the separate `read` action to consume a retained result. The result remains `authenticated-foreign-data`. Every physical operation is separately charged before contact: one use, its complete application request size and a conservative 512 KiB network allowance. Actual accepted network bytes are recorded separately and do not refund the reservation. Stable scopes are the host, exact purpose, peer identity and peer-plus-schema task family. ## Uncertainty, cancellation and restart An uncertain intent commit, claim commit, send acknowledgement or response authentication returns `{"error":"unknown","task_id":"..."}`. Retain that identity and inspect it under fresh read authority. A truly uncommitted task can be absent. Never automatically declare or submit a new task to replace an unknown one: the peer may already be executing it. A known foreign task id permits a fresh, authorized poll. An unknown id cannot be invented or discovered by silently resending. Restart restores neither declarations nor live transmission claims; it can explicitly reconcile known tasks with fresh authentication and current policy. Cancellation first closes local result adoption, then asks the peer to cancel. Read its local disposition separately from the authenticated foreign observation. An acknowledgement establishes neither rollback nor process containment. If a task already reached an admitted terminal, it remains readable under current authority and refuses late cancellation. `rotate` takes the exact target and a new remote key record; the old key version is retired before the persistence wait. `revoke` fences local handoffs before awaiting durable revocation. An uncertain authority mutation remains fenced. No session command deletes history, refunds capacity, fetches artifacts, streams, discovers endpoints or selects another peer, provider or language. This profile has one control process and event loop. Cross-process revocation, hostile same-UID containment, general remote IAM and private-input anonymization are outside its delivered boundary. ## Native public peer Run Apply revision `0023` through the normal migration gate. It binds a peer task to its exact Run, station, request, pinned Pattern and actual Step/occurrence. It refuses inconsistent legacy wait owners and refuses downgrade while native task, Run, closure or reauthorization evidence remains. The existing `0022` retention rule still applies to all seven Intercom tables. Use the same dedicated operator credential, workload key and exact public configuration: ```bash uv run --locked python scripts/intercom_native_lab.py --config /absolute/public-config.json ``` Native policy additionally selects `admit`, `adopt`, `resume` and `inspect`. These are independent actions; they do not grant `submit`, `poll` or `read`. Existing enrollment commands remain available. This lab uses the actual RunEngine, Graph, worker function and PostgreSQL checkpoints with an explicit process-owned delivery queue. It supplies no SAQ broker, capability or hardware transition. `submit-public-run` takes the existing public `source` and exact target selectors plus a stable `request_id` UUID. Supply an existing `session_id` when retrying that same admission; omitting it creates a new session. The Run prepares one immutable task without contact, checkpoints it and parks as `awaiting_peer`. Reusing a request with changed text or target refuses. `tick` takes `run_id`, performs at most one submit or poll, and executes any admitted successor. Repeat it explicitly while the task is pending. A correlated terminal can resume the Graph once; the reply remains foreign data. `status` exposes local status, task identity and binding selectors. A completed reply additionally requires current independent read authority. `cancel-run` closes local adoption and awaits local exchange retirement; visible remote uncertainty is retained. Commands are serial and network operations have their configured finite deadline. An already settled unknown, expiry or remote noncompletion returns an explicit `outcome` with local status; the next operator command remains usable. Other worker and authority failures are not converted into a successful settlement. After restart, the lab restores durable evidence but needs fresh authentication and live peer permission. Call `reauthorize-run` with `run_id`, the returned `task_id` and `binding_digest`, and the exact `actions` selected from `submit`, `poll`, `read`, `adopt`, and `resume`. An unclaimed first submit also needs `reaffirm_public_source: true`. Reauthorization preserves the original task, body, and expiry. It cannot refresh the request or replace an uncertain submit. If a claimed task lacks a foreign identity, reconcile its local exchange before following the explicit unknown failure route. The lab has no incoming peer, automatic relay loop, private-input producer, voice command path or Blockworld effect. Its process restart and local cancellation checks do not prove remote process containment, broker recovery or cross-process revocation. --- title: "Vessel" plain_name: "Engine Room: the server process" section: "Sepulcher" status: "Partial" original: https://hexanomicon.dev/sepulcher/vessel/ guide: https://lychd.snayu.ai/docs/sepulcher/vessel/ --- # Vessel (Engine Room: the server process) ## Plain-English summary (Snayu) **What it is:** Describes the Engine Room (Vessel): the single application process (Granian, Litestar, Pydantic AI) that serves the web UI, admits requests and hosts the workers. It explains startup reconciliation and shutdown order. **Why it matters:** Read this before changing server startup, lifecycle, concurrency or anything that assumes multiple processes. - Exactly one ASGI process is required; a blocking worker can delay HTTP requests too. - Startup must reconcile unfinished jobs, checkpoints and approvals from the database before accepting work. - The server runs in a managed container on loopback; host-native deployment and lychd serve are retired. **Status:** Partial. Local job execution works; full installed lifecycle control is not yet qualified. ## Original text (Hexanomicon) > _Through a mortal body, the daemon takes breath._ The **Vessel** is the application process through which LychD receives work and serves the [Altar](../../divination/altar/index.md). Its composition root assembles domain services, admits supported Invocations, and gives queued execution to [Ghouls](ghouls.md). The [Lich](../lich/index.md) is the recurrent whole that may answer through this process and return after it dies. ## One process takes breath A request enters through Granian's production ASGI service. Litestar supplies routing, injection, lifecycle, and API authority, while Pydantic validates configuration and typed boundaries. Pydantic AI provides Agent and Graph mechanics over [Animator](../animator/index.md) capabilities. Litestar also serves the compiled static SvelteKit client, so the browser remains a projection without a separate server authority. Exactly one ASGI process is required. Two SAQ workers, live Run events, cancellation, and the service graph share its event loop. A second process or reload supervisor would create another private runtime world. A blocking Ghoul can therefore delay HTTP as well as other work. ## Before the Altar opens Startup first connects the queues, constructs services, warms the registry, and synchronizes standing policy. Before workers can claim jobs or HTTP can expose those services, the PostgreSQL profile must reconcile what the previous process left behind: canonical Runs, their exact deliveries, checkpoints, Consent, and delegated-wait owners. These records determine whether work may resume, must remain parked, or needs containment and settlement. Required reconciliation must finish cleanly before admission opens; startup aborts on failure or degradation. The memory profile has no cross-process truth and retains best-effort recovery. After admission opens, lifespan-owned delivery, consent, and delegated-wait relays continue repairing their respective publication and return obligations. The owned launcher enters the application lifespan explicitly, then runs one embedded ASGI worker with no lifespan of its own. Retirement first refuses new application callbacks and waits for existing callbacks, including background work continuing after a response was delivered. Only then does it close application services. A required startup or shutdown failure produces a failed process exit. Signals request this retirement; the user manager's outer timeout decides whether a stuck process must ultimately be forced. The managed Vessel image uses the fixed internal `0.0.0.0:8000` listener behind generated loopback-only host publication. Host-native Vessel deployment and hidden `lychd serve` are retired. Images must be rebuilt to acquire launcher changes; unsupported server tuning refuses. Current active installation lifecycle completion is unavailable until authenticated container admission and exact settlement are implemented and qualified. The old signed native stops and trusted installed-hybrid receipt remain frozen historical observations of their removed profile. They do not qualify a rebuilt Vessel or authorize fallback control. Follow the current [CLI boundary](../../state-of-the-work.md#core-cli-rites) before an installation operation. Shutdown stops workers before their collaborators and queues. Process death loses active tasks, subscribers, leases, and other volatile state. Only records committed through the [Phylactery](../phylactery/index.md) can enter a supported return path. Follow [Ghouls](ghouls.md) from admission to settlement, or [Reanimation](../phylactery/reanimation.md) across process death. [Backend](../../adr/11-backend.md) owns the architecture; [State of Work](../../state-of-the-work.md#topology-a-local-runs) records the available local execution and its evidence limits. --- title: "Ghouls" plain_name: "Background workers" section: "Sepulcher > Vessel" status: "Partial" original: https://hexanomicon.dev/sepulcher/vessel/ghouls/ guide: https://lychd.snayu.ai/docs/sepulcher/vessel/ghouls/ --- # Ghouls (Background workers) ## Plain-English summary (Snayu) **What it is:** How queued jobs get picked up and pushed forward by background workers inside the one server process, and what happens to a job when it has to wait or the server dies. **Why it matters:** Read this before touching job execution, retries or anything that waits for approval: it explains which job states survive a crash. - Each job has one official record (a Run) in the database; workers (Ghouls) only move it forward. - Only one worker can claim a job delivery; duplicates and stale deliveries are skipped, and workflow jobs get no automatic retries. - Waiting for approval saves a checkpoint so a later worker can resume; waiting for hardware does not survive a restart. **Status:** Partial. Workers run today; full crash-safe resume and the Sandbox (Tomb) are not finished. ## Original text (Hexanomicon) > _Work is queued. The dead hand rises. The result returns._ A **Run** carries the canonical identity and lifecycle of admitted work. A **Ghoul** is the worker-task invocation that advances it. After a durable park, another Ghoul may carry the same Run forward with its Invocation, pinned Pattern, and retained Agent selection. Return rebuilds step dependencies, reacquires the grants it needs, and revalidates the recorded authority. ## The living worker The single [Vessel](index.md) owns two fixed SAQ worker loops, `runs` and `rites`. `QueueConfig.separate_process=False` keeps them in process; `SAQConfig.use_server_lifespan=False` leaves startup and shutdown to the application. Exactly one ASGI process is required while `RunEventBus` and the service graph remain process-local. Queued work has no process isolation. A blocking Ghoul can block HTTP, and Vessel death destroys the live task and subscribers even when the broker retains its job. ### Admission and claim Admission starts in `RunEngine.submit`, which chooses the workflow and queue. `RunLedger` then mints the Run id and commits `QUEUED`, Pattern, Intent, queue, priority, authority, and exact initial delivery in one transaction. Some callers must retain their own material before publication. For those callers, delivery starts `HELD` and becomes `PENDING` only after retention succeeds. Otherwise it starts `PENDING`. The live channel opens and `run::` publishes only after any required release. Each failure keeps its own boundary: | Failure | What remains true | | --- | --- | | Caller retention fails | Only an exact unreleased held admission may be settled; compensation retry is bounded. | | Broker publication fails | The admitted Run and exact pending delivery remain for the startup/runtime relay. | | Broker acceptance is ambiguous | The idempotent delivery key and claim fence settle ownership. | | Cancellation wins while publication is in flight | The losing publisher aborts the late physical job. | PostgreSQL admission and broker publication are separate commits. Only `perform_run` executes the Graph: it claims exact `(run_id, enqueue_seq)` through `QUEUED → RUNNING`. A stale or duplicate delivery returns `skipped`. A missing workflow, changed Pattern, or missing resume checkpoint refuses execution after claim; execution never starts the Intent over to fill the gap. SAQ `timeout=0` disables its generic wall clock. Graph, provider, and Orchestrator deadlines still apply, and the live invocation refreshes a 120-second Run-job heartbeat. Workflow jobs have zero automatic SAQ retries. ### Parks, terminal truth, and cancellation A hardware wait keeps this Ghoul resident: `AWAITING_HARDWARE` returns in the same hop and cannot survive restart. A consent or delegated wait commits checkpoint and exact owner before entering `AWAITING_CONSENT` or `AWAITING_DELEGATE`. One later resume admission creates the next pending delivery in the same transaction; publication may follow. [Stasis and return](../extensions/weaver/stasis-and-return.md) explains those thresholds. For worker-owned `DONE` or `FAILED` settlement, the sequence is: ```text commit DONE / FAILED and exact delivery settlement → release context → delete stasis best-effort → publish the terminal event and drain its ordered Step writer chain → close the live channel ``` Once status commits, cleanup or evidence failure cannot revise it. Before settling failure, the worker must also contain correlated children. It retries transient containment failures; continuing uncertainty leaves the Run nonterminal for recovery. Claiming `FAILED` while correlated authority could still act would conceal an unresolved effect. Before containment, the Ghoul checks its exact delivery generation under the same per-Run guard used for claims and park commits. A late failure therefore cannot cancel the next Ghoul's effects or undo a durable wait whose commit acknowledgement was lost. Cancellation elects one writer, commits `CANCELLING`, and fences claims and delivery rotation. The elected generation may commit `CANCELLED` only after broker, delegate, and pending Consent containment acknowledge. A worker that sees its exact `CANCELLING` generation releases volatile Context for containment acknowledgement while keeping its checkpoint. After `CANCELLED` commits, the engine handles terminal evidence and channel closure, then performs best-effort Context and checkpoint cleanup. Evidence failure still runs that cleanup. If containment remains uncertain, status stays `CANCELLING`. If completion already won, a new cancellation is a no-op. `RunEvent` has bounded process-local replay. Non-token events copy to `step` best-effort; token deltas are live-only. The evidence class is `durable_best_effort`, not a transactional event outbox. ### Death and reconciliation A new process judges committed Run, delivery, checkpoint, Consent, and delegated-owner truth. [Reanimation](../phylactery/reanimation.md#reanimation-a-new-vessel-judges-durable-truth) owns the state-by-state return: unsupported active work becomes `FAILED / ghoul lost`, exact durable waits may return, and missing or ambiguous required truth aborts PostgreSQL startup. Startup repairs missing terminal evidence from canonical terminal Runs. If existing terminal evidence disagrees, required PostgreSQL startup aborts instead of overwriting it. Cancellation cleanup may still remove its checkpoint when evidence fails. Lifespan-owned relays continue delivery, consent, and delegated-owner repair. While scanning forward, they retain every degraded page so a blocked owner cannot disappear behind a keyset cursor. Consent lookup and re-admission share one ten-second deadline per owner. A timeout keeps the wait or committed pending delivery and lets other owners progress. There is no same-boot worker-failure custody watchdog, public failed-Run retry, or workflow scheduler. [Workers](../../adr/14-workers.md) owns claims and recovery; [Graph](../../adr/24-graph.md) owns checkpoints and terminal commits. [Topology-A](../../state-of-the-work.md#topology-a-local-runs) is Available; [durable stasis and consent re-admission](../../state-of-the-work.md#graph-stasis-consent) remain Partial. ## The unbuilt worker The designed **Tomb** would receive a narrow payload and workspace grant without model credentials or Graph authority. Its worker, queue, credentials, and sandbox do not exist; unsafe execution remains disabled. > _The Ghoul may borrow the hand. It never inherits the Will._ --- title: "Phylactery" plain_name: "Memory Vault (PostgreSQL)" section: "Sepulcher" status: "Partial" original: https://hexanomicon.dev/sepulcher/phylactery/ guide: https://lychd.snayu.ai/docs/sepulcher/phylactery/ --- # Phylactery (Memory Vault (PostgreSQL)) ## Plain-English summary (Snayu) **What it is:** Describes the Memory Vault (Phylactery): the PostgreSQL database that keeps committed records such as job records, checkpoints, approvals, step logs, notes and the job queue, so a new process can work out what happened. **Why it matters:** Read this before adding tables, migrations or anything that relies on data surviving a restart. - The Run ledger owns job lifecycle truth; step rows are best-effort evidence only. - A checkpoint is saved step-map state; it cannot restore live connections, leases or event streams. - One cluster on one host; planned vector, trace and queue schemas are named but not delivered. **Status:** Partial. Persistence works locally; crash and full deployment recovery remain unqualified. ## Original text (Hexanomicon) > _The Vessel passes. What it inscribed waits in the dark._ When the [Vessel](../vessel/index.md) dies, another process must discover what happened before it may continue. The **Phylactery** holds the committed records from which that judgment begins: the PostgreSQL database cluster assigned to one application partition. Domains give those records meaning and govern their lifecycle. Phylactery owns the engines, codecs, transactions, migrations, and schema admission through which they are stored. ## What the inscription keeps Different inscriptions answer different questions: | Record | What a returning Vessel can establish | | --- | --- | | Run and delivery ledger | Canonical lifecycle and exact publication intent for each fresh or resumed worker hop. | | `run_checkpoint` | One replaceable JSONB record per Run, containing validated Graph snapshot history and cascading with that Run. | | Consent and delegated-owner records | The exact authority whose settled result may permit a parked Run to return. | | Ordered `step` rows | Best-effort structural evidence; the Run ledger still owns lifecycle truth. | | `session`, `karma`, `soulstone_record`, `codex_preauthorization` | Domain records admitted by application migrations; each row establishes only its own contract. | | Public-note Archive | Explicit namespace ownership, note revisions and lifecycle, intake identities and text-free recall receipts; optional generation tombstones and latest derivation attempts. | | SAQ `saq_*` tables | Durable broker state through a separate autocommit pool. Queue publication and Run admission remain separate transactions. | Today these records use PostgreSQL's default schema and search path. [Persistence](../../adr/06-persistence.md) owns exact table admission and migration history. Planned `vectors`, `traces`, and isolated `queue` chambers describe governed memory, cognitive evidence, and broker separation; naming those chambers does not deliver their services. Read a checkpoint as declared Graph state. It cannot restore the process's image, runtime dependencies, or event stream. Subscribers, leases, provider handles, and uncommitted frames end with the process. Terminal Run status commits before Context release and best-effort checkpoint cleanup. A checkpoint left behind by failed cleanup therefore grants no replay permission. [Reanimation](reanimation.md) must judge canonical truth before anything can return. ## One cluster, one custody boundary PostgreSQL runs in its dedicated unit. `PGDATA` occupies the exact admitted `postgres/data` mount in the [Crypt](../crypt.md). The default design enlarges one cluster on one host; storage can move beneath that mount without moving application authority. Process-local and in-memory profiles provide bounded execution or test substitutes. Loose files cannot become a shadow database. Plan growth through lifecycle policy first. Neither age nor disk pressure grants deletion rights, and Shadow's Reaper does not collect database records. If later measurements justify local hot and cold tiers, partitions or tablespaces must preserve PostgreSQL's single query boundary. Additional mounts would first need Layout, container, whole-cluster capture, and restore support. No scale-out topology has been selected. A future named Domain store requires its own custody or projection contract, rather than becoming an interchangeable Phylactery backend. Follow the [topology and scale seam](../../adr/06-persistence.md#default-topology-and-scale-seam) when the choice becomes necessary. ## Read the evidence before claiming continuity First-light persistence is **Partial**. Read the [named receipts](../../state-of-the-work.md#phylactery-first-light) according to what each observed. The lifecycle test uses offline collaborators. Actual warm-model reply/history retention includes two normal source-CLI/native TCP boots. These source-profile receipts establish neither a Consent-plus-Checkpoint restart, a current installed body, nor crash recovery. A separate [trusted source-browser journey](../../state-of-the-work.md#current-evidence-envelope) retains its fixed useful reply after normal restart under an explicit test composition. The [trusted installed-hybrid receipt](../../state-of-the-work.md#current-evidence-envelope) retains identical complete SDK history, Intent capability, and exact Pattern manifest across two normal installed native boots. Its private Docker and borrowed-model scope still applies. General retention, compaction, and physical tiering remain incomplete. The bounded [public-note Archive](../../state-of-the-work.md#karma-semantic-memory) adds explicit intake, lifecycle, and lexical recall; old Karma rows stay inert. An independently selected [derivation path](../../adr/27-memory.md#explicit-local-derivation) retains bounded vectors and invalidation fences. Its durable status describes only the latest attempt, and expiry requires an explicit retry. Separately selected semantic recall and Bridge revision 5 have fixed native lifecycle and attributed-answer/empty-recall observations. Their exact model, authority, and source scopes bind the claims. They do not establish general retrieval quality, automatic curation, sharing, or a formation path. Follow [Ghouls](../vessel/ghouls.md) to see the workers that write these records, or [Reanimation](reanimation.md) to cross the death of their process. --- title: "Reanimation" plain_name: "Crash recovery after restart" section: "Sepulcher > Phylactery" status: "Partial" original: https://hexanomicon.dev/sepulcher/phylactery/reanimation/ guide: https://lychd.snayu.ai/docs/sepulcher/phylactery/reanimation/ --- # Reanimation (Crash recovery after restart) ## Plain-English summary (Snayu) **What it is:** Explains Crash Recovery (Reanimation): how a new server process reads the database after the old one died and decides which jobs may resume. It separates this from pausing for a model switch and from full-system restore. **Why it matters:** Read this before restarting a running installation or changing recovery logic. - Three different things: Pause for model switch, Crash Recovery after process death, and full Restore (still Designed). - There is no graceful drain command proving zero loss; stop submissions and let work settle before restarting. - Never hand-edit generated systemd units; change config and run Apply Config (lychd bind). **Status:** Partial. Restart recovery exists; real systemd/Podman proof and full restore are pending. ## Original text (Hexanomicon) > _Read the ashes before you call the dead by name._ **Reanimation** brings a new Vessel to the records committed before its predecessor died. Systemd can raise the process; the Phylactery, queue, checkpoint, and wait owners determine which work may return. Volatile memory, subscribers, leases, and uncommitted frames are gone. A [durable park](../extensions/weaver/stasis-and-return.md) can return through a fresh worker claim in the same Vessel. Reanimation is needed only when the application process has died. ## Three rites that must not be confused | Need | Rite | Continuity boundary | | --- | --- | --- | | A model or VRAM transition during live work | **Live Stasis** | The resident Run releases its lease, waits for Orchestrator convergence, then resumes itself. | | A new application process after Vessel death | **Reanimation** | A new process reconciles committed truth before admitting work. | | An earlier whole body, including database, code, and configuration | **Restoration** | Coordinated snapshot, freeze, restore, and reconciliation remain Designed. | A Vessel restart neither substitutes for a model transition nor stops every Soulstone or clears VRAM. [Snapshot State](../../state-of-the-work.md#whole-body-snapshot-restore) keeps the whole-body boundary separate. ## Perform one bounded reanimation Begin only after the four [Awakening](../../summoning.md#the-awakening) observations agree. Reanimation cannot complete a host's unfinished first life. Run the commands below from the stable [Summoning checkout](../../summoning.md#the-desecration), under the same operator user and XDG environment. Before restarting, stop submissions and let Bridge-visible work settle. Active work must either reach a supported durable boundary or have its loss accepted. There is no complete Run census or graceful drain command proving zero-loss restart; if unseen work or continuity matters, do not restart. [State](../../state-of-the-work.md#core-cli-rites) records the current `status` and `stop` limits. Direct Systemd action bypasses Orchestrator admission and lease drain. ### The generated body `lychd bind` and the Scribe project Codex intent into owned units atomically. Edit that intent, never paste or hand-edit a generated Quadlet. The generated Vessel has a restart policy and a migration gate before start; real [systemd/Podman embodiment](../../state-of-the-work.md#systemd-podman-embodiment) still needs operator validation. When Codex or unit intent changed, bind first. Otherwise restart the existing projection: ```bash # Only when Codex or generated-unit intent changed: uv run --extra postgres-binary lychd bind --dry-run uv run --extra postgres-binary lychd bind systemctl --user restart lychd-vessel.service uv run --extra postgres-binary lychd status systemctl --user show lychd-migrate.service \ --property=Result --property=ExecMainStatus uv run --extra postgres-binary lychd logs services --lines 200 ``` The current `stop` cannot stop an active Vessel without the authenticated lifecycle port. `status` establishes unit and mount truth; the migration unit must report `Result=success` and `ExecMainStatus=0`. Neither proves model warmth. Repeat Nexus readiness and a benign same-host [Bridge](../../divination/altar/index.md) reply. Disagreement among state, readiness, and reply returns the investigation to [The Awakening](../../summoning.md#the-awakening). ## Reanimation — a new Vessel judges durable truth Before publishing its substrate or Altar services, the Vessel connects `runs` and `rites`, constructs services, warms the registry, synchronizes standing policy, and reconciles durable state. Required PostgreSQL recovery must finish cleanly; failure or degradation aborts startup. The memory profile has no cross-process truth and remains best-effort. - **`AWAITING_CONSENT` remains parked.** A pending verdict waits. A verdict committed while the process was down is re-fired; one admission atomically creates its next delivery and later reads durable verdict and checkpoint. The pre-park crash window is recoverable only when the first resumable snapshot binds this Run and its exact latest Consent id, with that owner still non-cancelled. An already-decided owner is parked and then re-fired. - **`QUEUED` remains Run-ledger-owned.** Its exact `RunDelivery` says fresh versus resume, queue, priority, and publication state. `HELD` is refused because initiating context never became publishable. Current-boot work is retained; a proven pre-boot active generation is terminally fenced and re-probed; an absent job is republished under the same key; a terminal broker record rotates to a fresh sequence without changing delivery mode. Missing or mismatched delivery truth, unprovable active ownership, queue absence, or probe failure makes recovery degraded rather than inventing an outcome. - **Previous-process `RUNNING` and `AWAITING_HARDWARE` do not replay.** Startup may recover the exact first-node Consent or delegate pre-park boundary; otherwise it contains correlated effects and records `FAILED / ghoul lost`. Checkpoint deletion and one sequence-correct durably drained terminal event follow. - **`AWAITING_DELEGATE` refreshes its exact owner.** Only a terminal owning `AgentJob` may re-admit it. Missing coordination or owner identity fails required PostgreSQL startup. - **Missing resume checkpoints fail as `stasis lost`.** The Graph never restarts from its first node or original Intent. - **`CANCELLING` still owes containment.** Startup continues the elected cancellation; a broker or delegate whose containment remains uncertain cannot be declared terminal merely to open the Altar. Startup repairs missing terminal evidence from canonical terminal Runs. Conflicting terminal evidence instead aborts required PostgreSQL startup; recovery does not overwrite it. Cancellation cleanup may still remove a checkpoint if evidence fails. [Ghouls](../vessel/ghouls.md#parks-terminal-truth-and-cancellation) explains terminal ordering. Conversely, a checkpoint surviving failed cleanup cannot revive a terminal Run. Lifespan-owned delivery, consent, and delegated-wait relays continue repair after startup. They retain degraded keyset pages while scanning newer owners. There is no periodic workflow scheduler, generic automatic SAQ retry, public failed-Run retry, same-boot worker-failure custody watchdog, or transactional Step/event outbox. The disposable [two-boot factory receipt](../../state-of-the-work.md#phylactery-first-light) proves a narrower PostgreSQL lifecycle with offline collaborators. It does not prove a real Consent-plus-Checkpoint restart. [Graph stasis and consent re-admission](../../state-of-the-work.md#graph-stasis-consent) remain Partial, and Bridge accepts only one approval call per model round. ## Read the ashes A pending consent card is a preserved wait. A decided consent back in `QUEUED` has won a resume hop, but still awaits a worker claim. `FAILED / ghoul lost` identifies work that crossed death without a supported durable boundary. A surviving or republished SAQ job preserves queued labor, not the old in-memory event stream. Retain the host, unit, image, database, queue, Run, shutdown, and recovery observations before promoting the result to an operator receipt. > _Inscribe the breath before it passes beyond recall._ --- title: "Animator" plain_name: "Model Runtime overview" section: "Sepulcher" status: "Partial" original: https://hexanomicon.dev/sepulcher/animator/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/ --- # Animator (Model Runtime overview) ## Plain-English summary (Snayu) **What it is:** Introduces the Model Runtime (Animator): an addressable handle for any service that can do typed work, such as a model, search or renderer. Sources are Local Models (Soulstones) or Cloud Models (Portals). **Why it matters:** Read this before working on model integration, dispatch or anything that calls a model or service. - LychD can start and stop Local Models; it never controls a Cloud Model's lifecycle. - If a model is warm, the Traffic Controller grants a Model Pass; if cold, the Stage Manager loads it first. - Today only the narrow chat-model path is implemented; other service types are designed. **Status:** Partial. The dispatch spine works for chat models; general services are Designed. ## Original text (Hexanomicon) > _Follow the spark to where the iron answers._ A workflow may need a model to answer, a search service to find material, or a renderer to draw. The **Animator** gives LychD an addressable handle for discovering, probing, and invoking that service's typed capabilities. A model is one possible source of power; independently managed search, rendering, or speech services can supply others. The handle says where a capability can answer. The service's deployment manifest and the application's purpose belong elsewhere. ## Two Sources of Power | Source | What the operator declares | What LychD can control | | --- | --- | --- | | [Soulstone](soulstone/index.md), **The Furnace of Animus** | Local Rune, rootless Podman/Quadlet service, models or profiles, devices, mounts, secrets, and lifecycle. | Admitted local service and supported runtime-native transitions. | | [Portal](portal.md), **The Rift to the Remote Sky** | Remote endpoint, provider contract, explicit models or profiles, and credential reference. | Its own admitted connection; no provider start, stop, repair, or local VRAM. | [Portal Roads](portal-roads.md) selects a remote custody and economic road. [Audio hardware and host routes](audio-routes.md) handles device attachments; a raw device or finite host helper does not become an Animator merely because its work uses audio. ## The Holy Contract Check what the service declares, what its bound surface has proved, and what is ready now. [Capabilities](capabilities.md#declaration-evidence-observation-and-grant) keeps those records distinct: a probe may invalidate a declaration, but cannot invent a capability. Adapters keep native protocols behind the stable surface requested by Graph or an extension. An Animator-backed web effect still needs Scout's separate grant, destination, budget, and receipt. ## The Galvanic Arc ```text typed demand → declared eligible profile → current observation ├─ WARM and admitted → exact grant and lease → invocation → owned return └─ managed but cold → handle-free transition → readiness → dispatch again ``` If the service is ready and the request is admitted, Dispatcher supplies the grant and lease. If a managed service must change first, Orchestrator performs the admissible physical or runtime-native transition. The waiting Graph keeps neither Connector nor lease while readiness converges, then returns to dispatch. Current implementation performs this handshake for the narrower v1 family/model demand and chat-model/toolset compatibility grant. ## Animus: the power answering **Animus** names the power answering through an admitted, active capability. A loaded model—Gemma behind llama.cpp—is its clearest instance. The term creates no new runtime object. Orchestrator owns activation; the Animator is the address, the Connector its conduit, and the CapabilityGrant the exact permission and lease. A Spell shapes that draw into a typed request. The return becomes candidate material for the Circle: Blade discriminates, Spirit carries it in [Flux](../lich/spirit/flux.md), and Answer binds the act locally. Inference alone supplies neither Persona, identity, memory, authority, nor operational Cognizance. ## Capability and Readiness Use [Capabilities](capabilities.md) to name the required operation and interpret its grant or refusal. Use [Connectors](connectors.md) to bind its exact dialect. For compatible local groups, enter [Coven](coven.md); to inspect or request a change, follow [Runtime transitions](runtime-transitions.md). [State of Work](../../state-of-the-work.md#animation-and-orchestration) owns what each route proves. --- title: "Capabilities" plain_name: "Model and service capabilities" section: "Sepulcher > Animator" status: "Partial" original: https://hexanomicon.dev/sepulcher/animator/capabilities/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/capabilities/ --- # Capabilities (Model and service capabilities) ## Plain-English summary (Snayu) **What it is:** Defines a capability: an exact, versioned contract for what you can ask a service to do and what comes back. It describes the delivered v1 model keys and the designed interface/profile/operation model. **Why it matters:** Read this before adding a new kind of model or service, or when interpreting why a request was granted or refused. - Today a capability is keyed {animator}:{family}:{model_id}; only chat and tool execution grants actually work. - Declared, proven, currently ready and granted are separate records; a probe cannot invent a capability. - The richer interface/profile design (e.g. transcribe, image) is Designed, not built. **Status:** Partial. v1 chat path delivered; interface/profile design not yet built. ## Original text (Hexanomicon) Suppose the work needs a recording transcribed. Choosing a model or endpoint is not yet enough: the caller needs a contract for the inputs it may send and the typed result it can receive. A **capability** names that exact, versioned contract at an [Animator](./index.md). Begin with the operation, then establish which service can perform it. Model, endpoint, container, tool, Rune, Coven, and application purpose each contribute a different part of that decision. The interface/profile design described below remains **Designed** until source, migrations, adapters, tests and operator receipts establish delivery. ## The delivered v1 surface Current `CapabilitySpec` identifies a capability by `{animator}:{family}:{model_id}`. It uses seven closed families, coarse input/output modality strings, and one compatibility grant class. For `chat`, that grant contains a hydrated Pydantic AI model and only explicitly declared agent-loop toolsets. For `tool_execution`, a non-empty toolset surface is required. The remaining five labels route metadata but fail closed when a grant is issued. This proves the narrow chat/model path, toolset compatibility, and readiness mechanics. It does not yet give the transcription example an executable v1 route, nor establish visual, embedding, rerank, service-job, or host-tool execution. [State of Work](../../state-of-the-work.md#animator-dispatch-spine) records the delivered 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: | Record | Question it answers | Example | | --- | --- | --- | | `CapabilityInterfaceRef` | Which versioned request-and-return contract is requested? | `model.chat@1`, `echo.transcribe@1`, `prism.image@2`, `prism.scanner@1`, `scout.search@1` | | `CapabilityProfileRef` | Which exact implementation closure can perform it? | one model and weights, Comfy graph, native parser, engine toolchain, language set, limits, and licenses at an immutable revision/digest | | **operation** | Which admitted act within that interface is requested now? | `generate`, `edit`, `transcribe`, `segment`, `retarget`, `search`, `validate` | For the transcription example, the interface tells the caller which request and result schemas, operations, facets, failures, and recovery meanings apply. Its owner validates those domain requirements. A profile identifies an exact implementation that can meet them by pinning code, model, weights, runtime, workflow or graph, configuration, dependencies, licenses, language and format support, resource evidence, and proved limits. Finally, an operator Rune chooses a concrete deployable instance and references those admitted definitions. A contract, a tested implementation, and a running instance answer different questions. 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: | Record | Office | | --- | --- | | `CapabilitySpecV2` | Immutable Animator declaration of interface, profile, operations, I/O contracts, invocation mode, driver/dialect, provenance, evidence, resource, and lifecycle intent. | | `CapabilityEvidenceRef` | Exact producer-attributed conformance evidence supporting that profile's claims; the target contract owner separately admits or promotes it. | | `CapabilityState` | Latest observation for the exact Animator/interface/profile binding and, where necessary, its operations. | | discriminated capability grant | Temporary WARM binding to one operation and one callable surface under an exact lease. | Declaring a route in a Rune makes it a candidate for selection; evidence establishes what its exact implementation can do. That evidence closes over code, weights, workflow, dependencies, dialect, licenses, language or format corpus, hardware profile, and measured limits. The target interface/profile owner admits or promotes the evidence under its policy. Drift can produce findings and Assimilation can repair foreign craft, but neither thereby acquires that owner's decision. Dispatcher consumes the admission when matching a request; it does not become a benchmark judge. A grant exposes neither its Animator nor its Connector. The designed union separates four callable surfaces: | Grant | Live surface | Typical use | | --- | --- | --- | | `ModelGrant` | Pydantic AI model and admitted agent-loop toolsets | chat or reasoning round | | `CallGrant` | typed call driver | bounded STT/TTS, OCR, deterministic service, search, or another immediate call | | `JobGrant` | typed submit, status, cancellation, result, and reconciliation driver | image, video, Form, Kinesis, Comfy, engine, or paid asynchronous work | | `SessionGrant` | typed bounded live-session driver | later audio, vision, motion, game, or device sessions | Once granted, the caller receives only the operation surface it needs. A `ModelGrant` cannot be treated as a job driver, a `JobGrant` contains no arbitrary HTTP client, and a `SessionGrant` confers no source-device or world effect beyond its interface. This keeps the technical ability to call a service within the admitted act. 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: | Phase | Meaning | | --- | --- | | `COLD` | managed unit down or endpoint unreachable | | `ACTIVATABLE` | dynamic runtime up; exact profile not loaded | | `WARMING` | activation or readiness convergence in flight | | `WARM` | exact admitted binding currently accepts its proved operation set | | `ERROR` | probe or runtime reported a terminal fault | | `UNKNOWN` | no conclusive fresh observation exists | `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. | Observation | Result | | --- | --- | | eligible `WARM`, admission open | issue the exact discriminated grant and register its lease | | managed `COLD`, `ACTIVATABLE`, or `WARMING` | return a handle-free hardware transition request | | the same phases on a shared or unmanaged service | settle unavailable | | `ERROR` | settle unavailable with the observed reason | | unresolved `UNKNOWN` | probe once under deadline, then settle unavailable | Dispatcher never starts, stops, loads, evicts, submits an effect, or waits on a provider job. [Orchestrator](../../adr/23-orchestrator.md) 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 A short call keeps a process-local lease for its duration. An asynchronous effect can outlive that process, so it needs a different return path: persist `ServiceJobAttempt@1` before the first submit, allowing timeout or death to reconcile the same request instead of repeating it. If the work uses managed resident or scarce local resources, the attempt also receives an exact Orchestrator-visible reservation and fence. Live work needs a bounded session record. Current process-local leases cannot supply these guarantees, which is why 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: ```text {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-`; 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](coven.md). 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. To decide whether several capabilities fit together, the later `ResourceEnvelopeRef` would retain 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` would relate these exact envelopes and required headroom on one host or a Legion topology. A future `CapabilitySetRequest@1` could then ask Orchestrator to converge several exact bindings in one serialized desired-world transaction. Serialization cannot make physical effects atomic. Drain, attestation, compensation, restoration, and containment still govern partial change; a Coven becomes neither another scheduler nor a promise of unproved hardware rollback. ## Composition boundary A capability supplies an exact technical interface; a Spell defines the semantic action at a Pattern station. The [consuming Composition](../../compositions/index.md) 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](connectors.md) owns invocation dialects and the current chat-only implementation boundary. [Dispatcher (22)](../../adr/22-dispatcher.md) owns matching and leases; [Orchestrator (23)](../../adr/23-orchestrator.md) owns physical readiness; and [Workers (14)](../../adr/14-workers.md) owns durable attempt settlement. --- title: "Connectors" plain_name: "Connectors and API dialects" section: "Sepulcher > Animator" status: "Partial" original: https://hexanomicon.dev/sepulcher/animator/connectors/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/connectors/ --- # Connectors (Connectors and API dialects) ## Plain-English summary (Snayu) **What it is:** Explains Connectors: the adapters that speak a service's exact wire protocol. It insists 'OpenAI-compatible' must be proved per dialect (chat, responses, audio, images, video jobs). **Why it matters:** Read this before integrating a new provider or engine, or claiming API compatibility. - Only an OpenAI chat/responses model connector exists today; audio, image, video and job connectors do not. - Compatibility must be proved per dialect with a recorded provider profile and tests. - A partial dialect is fine if every supported and refused feature is explicit. **Status:** Partial. OpenAI chat connector delivered; other dialects are Designed. ## Original text (Hexanomicon) A service must receive a request in a language it understands and return something LychD can interpret. A **Connector** binds an admitted Animator endpoint to that exact wire or process dialect: it encodes the request, decodes the response and exposes the callable runtime surface. [Capabilities](capabilities.md) defines what may be requested and permitted through its grant. The service's domain still owns judgment, while egress policy, job recovery and runtime transitions remain with their respective owners. The current implementation is narrower than this designed office. Its `OpenAICompatibleConnector` hydrates only Pydantic AI Chat Completions or Responses model surfaces, projects its configured model catalogue, and exposes agent-loop toolsets. That catalogue is not necessarily a live discovery result. It is an available **OpenAI model connector**, not a universal implementation of every API beneath an `/v1` root. Audio, Images, Videos, OCR, Scout, Form, Kinesis, engine jobs, and live sessions have no delivered connector. ## OpenAI compatibility is per dialect "OpenAI-compatible" without a named surface is not a compatibility claim. The designed dialect register treats these independently: | Dialect | Typical office | Compatibility must prove | | --- | --- | --- | | `openai.chat-completions@1` | message rounds and tool calls | message parts, model settings, tool schema, streaming events, usage, finish reasons, and errors | | `openai.responses@1` | Responses-style model rounds | item types, tool lifecycle, state/reference behavior, streaming events, usage, and unsupported fields | | `openai.audio-batch@1` | finite transcription, translation where supported, and speech synthesis | multipart/audio encodings, language and voice fields, timestamps, output formats, limits, and errors | | `openai.images@1` | image generation and editing | operation routes, image/reference counts, masks, sizes, formats, progress, result retrieval, and revised prompts | | `openai.videos-job@1` | asynchronous video generation and editing | submit, durable provider id, status, progress, cancellation request, result retrieval, expiry, and reconciliation | To establish compatibility, inspect the exact provider profile rather than inferring from endpoint names. The profile records routes and methods, supported operations and fields, required and rejected parameters, media encodings and limits, and authentication. It must explain what "streaming" means on that surface: token deltas, audio frames, progress, previews, or partial artifacts. The same account needs error and rate-limit mapping, idempotency support, cancellation semantics, provider-job lookup, retention, expiry, and the compatibility test—the conformance bake—that established those facts. An omitted fact stays unsupported; an `extra_body` bag cannot silently supply the missing contract. A service may implement only part of a dialect. That partial profile is legitimate when every opening and refusal is explicit. It must not inherit a family logo's optional fields, endpoints, streaming, cancellation, or error semantics. A later server release receives a new profile and evidence rather than mutating the old claim. ## Native calls, durable jobs, and sessions Not every useful service resembles OpenAI: - a **call driver** performs one bounded request and returns one typed result; - a **job driver** submits an effect, polls or receives progress, requests cancellation, fetches results, and reconciles the same provider identity after disconnect or restart; - a **session driver** opens one bounded, epoch-fenced live exchange with declared clocks, queues, drops, reconnect, consumers, and stopping law; and - an **agent model connector** hydrates a Pydantic AI `Model` and optional agent-loop toolsets. Choose the execution boundary according to how the program lives. Finite local programs such as FFmpeg, Blender, Godot, and native parsers normally arrive through a Worker at a trusted executor, or at a Tomb when the material or code is hostile. Merely running a Worker task in the Vessel provides no containment. These programs need not masquerade as network models. A wrapper can instead justify an Animator when it has an independent lifecycle, queue, resident resources, or a remote boundary. The same typed job interface remains visible above that wrapper's private transport. `ToolConnector` and Pydantic AI toolsets remain an agent-loop convenience. They cannot establish a Scout Search grant, media effect, filesystem right, browser session, Blender job, payment, publication, or another host authority. An agent-facing tool calls a host-owned typed handler; raw provider toolsets never become an effect boundary merely because the model can name them. ## Probe truth Three observations remain separate: 1. **Link liveness:** some endpoint or process answered. 2. **Profile readiness:** the exact declared profile and operation can accept work now. 3. **Dialect conformance:** the pinned implementation passed its offline or live bake. `GET /models` can establish limited endpoint and inventory evidence. It cannot prove Images, Audio, Videos, cancellation, a declared model absent from the returned inventory, or every profile behind that URL. A fixed runtime may project all declared profiles warm only when its adapter can prove that the exact pinned deployment binds them as one inseparable ready unit. Otherwise each profile or operation needs its own probe result or remains unavailable. A probe may downgrade or invalidate a declaration. It may not invent an interface, operation, profile, dialect, model, language, or permission. Portal probes make no payload egress and grant no later egress authority. For a Soulstone with a non-empty `[[models]]` catalogue, the catalogue is the exact connector allowlist. Undeclared discoveries never become selectable, the first declared id is the deterministic default, and a requested/default id outside a non-empty catalogue is refused rather than replaced by a runtime fallback. ## Durable job handoff Before submitting an asynchronous effect, its Worker records exactly what it intends to send, where it will execute, and how it can later find the result. That durable account is [`ServiceJobAttempt@1`](../../adr/14-workers.md#service-job-attempts). It also holds a managed local reservation when required. Only after persistence may the driver or executor receive the idempotency identity. Persist the returned provider or executor job identity as well; the attempt then remains the ledger for progress, result, and settlement. The parent Run may enter its owner's durable service wait with no live Connector or grant in Graph state. Re-admission rebinds the exact capability or Resolution Lock/ToolProfile and reconciles the same attempt. An unknown remote, paid, or local tool effect is never repeated merely because a client timed out. The Workers law carries the complete persisted record and recovery protocol. ## Egress and secrets Selecting an eligible Portal route supplies only one part of permission to send. Immediately before transmission, Security re-evaluates the exact canonical payload digest, classification, destination, purpose, consent, transformation receipts, cost, and expiry. Changing a crop, prompt, attachment, retry, fallback, or derived artifact needs a fresh decision. The Connector receives only the narrow secret reference or mounted value its exact driver needs. It cannot enumerate the Codex, borrow another provider's credential, or reveal secrets through diagnostics. ## Five boundaries that must not collapse | Boundary | Owns | Does not own | | --- | --- | --- | | **Capability interface** | [versioned request and result contract](capabilities.md#interface-profile-and-operation) | transport or application judgment | | **Capability profile** | [exact implementation closure and proved operations](capabilities.md#interface-profile-and-operation) | endpoint lifecycle or wire behavior | | **Dialect driver** | request encoding, authentication shape, response decoding, errors, progress, cancellation, and reconciliation for one exact protocol | provider truth beyond that proved subset | | **Runtime adapter** | Rune hydration, process/container plan, readiness probe, optional in-runtime activation, and control-plane facts | semantic routing or job meaning | | **Animator** | one addressable local Soulstone or remote Portal bearing those surfaces | Composition records, Graph, policy, or effect authority | One runtime adapter may expose several dialect drivers. One driver may serve several admitted profiles. Sharing a URL, SDK, container, or Python base class does not merge their contracts. [Capabilities](capabilities.md) owns semantic matching and grant variants. [Soulstone Runes](soulstone/rune.md) declare concrete local instances; [Portals](portal.md) declare remote ones; [Coven](coven.md) owns compatible local grouping; and [State of Work](../../state-of-the-work.md#animator-dispatch-spine) keeps the delivered chat/model boundary. --- title: "Audio Hardware and Host Routes" section: "Sepulcher > Animator" status: "Designed" original: https://hexanomicon.dev/sepulcher/animator/audio-routes/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/audio-routes/ --- # Audio Hardware and Host Routes ## Plain-English summary (Snayu) **What it is:** A planning guide for connecting microphones and speakers on a host (ALSA, PipeWire, USB, mobile, drones) before voice or music features can use them, and for deciding which app owns each route. **Why it matters:** Read this before working on voice, music capture or playback hardware setups. - A device route is not a service; only resident or shared services need Model Runtime lifecycle. - Test from the environment that actually owns the audio device, not a restricted container shell. - Only audio metadata and a WAV inspector exist; capture, inference and playback are Designed. **Status:** Designed. Planning guide; audio capture and playback paths are not built. ## Original text (Hexanomicon) A microphone route must be proved on the host before Echo can transcribe speech or Riffmaw can keep a take. Begin with the actual host's device and signal evidence, connect one bounded route, then decide which application may arm and retain it. The same audio hardware can serve several owners without combining their permission or chronology. First distinguish a device route from a service. ALSA device interfaces, PipeWire audio-routing nodes, USB devices, finite host helpers, and in-process libraries are attachments or tool routes. An independently resident, queued, shared, or remote service may instead need Animator's lifecycle contract. This page maps the hardware and host route; [Audio](../../adr/37-audio.md) governs capture consent, custody, transport, interruption, and playback. ## Current LychD boundary The repository currently proves audio modality metadata, the `stt`/`tts` capability labels, and a pure inspector for canonical PCM WAV bytes. An explicit, unregistered [local custody seam](../../state-of-the-work.md#artifact-reference-contract) can retain supplied bytes and feed that inspector under separate current authority. Capture, audio transport, inference and playback remain Designed under [State's audio-admission boundary](../../state-of-the-work.md#audio-admission). Use this page to plan and test a host route; it supplies neither a host receipt nor an operational application path. | Office | Owns | Does not own | | --- | --- | --- | | [Echo](../extensions/echo.md) | bounded speech capture, transcription, synthesis, delivery, interruption, and playback chronology | musical performance, arbitrary ambient recording, or identity | | [Riffmaw](../../compositions/riffmaw/index.md) | instrumental and musical-vocal takes, music production, sessions, and music lineage | ordinary speech, dialogue, picture sound, or publication | | [Companion](../../compositions/companion/index.md) | mobile capture/playback controls, disclosure indicators, local interaction state, and reconnect | speech-attempt custody, transcription, synthesis, or playback chronology | | [Avatar](../../compositions/avatar/index.md) | an eligible voice reference inside a presentation profile and target projection | microphone authority, cloning permission, or proof of playback | | [Familiar](../../compositions/familiar/index.md) | admitted physical body, mission, safety envelope, onboard sensors, and physical speaker | Persona identity, Avatar presentation, attention, or retention of every sensor byte | | [Tether](../extensions/tether.md) / [Portal](portal.md) | private reachability / admitted remote-service boundary | caller authority, recording consent, chronology, or device authority | One physical device may participate in several independently armed routes. Shared ALSA or PipeWire mechanics do not merge their grants, records, retention, or acceptance. ## Host receipt boundary Test from the environment that actually owns the device. For the desktop PipeWire route below, that means the real login owning PipeWire and the audio devices. A restricted shell, container, or coding-agent session without `/dev/snd`, D-Bus, or PipeWire access can establish its own lack of access, but cannot judge the host route. Other routes likewise need evidence from their actual device-owning environment. Before promoting a route, record the OS and kernel, exact board or USB-device identity, loaded driver, ALSA capture/playback inventory, PipeWire/WirePlumber graph where used, selected sample format and rate, mute and gain state, and one measured record/playback result. Planning prose or a device advertisement cannot substitute for that observation. ## Tumbleweed readiness sequence On openSUSE Tumbleweed, run checks in the real desktop login, not a restricted agent terminal. Capture the read-only substrate report first: ```bash uname -r grep '^PRETTY_NAME=' /etc/os-release lsmod | grep '^snd_usb_audio' ls -ld /dev/snd aplay -l arecord -l wpctl status ``` Then prove the selected route: 1. Confirm PipeWire, WirePlumber, required ALSA/PipeWire compatibility packages, FFmpeg, and ALSA utilities for the exact host revision. 2. Connect one USB audio device directly rather than through an unpowered hub. 3. Confirm its exact identity in `arecord -l`, `aplay -l`, and `wpctl status`. 4. Record a five-second dry sample with `arecord`; validate the file and playback before adding a model or DAW. 5. Add `qpwgraph` or `pavucontrol` only when the desktop mixer needs a visual routing surface. 6. Add Guitarix and Ardour or Reaper only after the interface is stable at 48 kHz; measure buffer underruns or overruns (xruns) and round-trip latency before calling the setup realtime-ready. Do not answer missing onboard audio by blindly changing kernel parameters. Retain `lspci -nnk`, `journalctl -k -b`, firmware audio settings, and rear/front jack wiring before forming a board-specific hypothesis. A separately proved USB interface may provide a bounded guitar, bass, or speech route while onboard audio remains under investigation. ## Bounded implementation order 1. **Host attachment/tool adapter:** enumerate ALSA/PipeWire devices and retain route facts without granting capture; handles and PCM remain outside Graph state, and this finite path is not an Animator. 2. **Echo record-and-send:** visible push-to-talk, bounded capture, immutable source artifact, one admitted STT profile, transcript provenance, and stop/cancel/retention receipts. 3. **Echo playback:** one admitted TTS profile, local delivery offer, playback start/completion, interruption, and unknown-outcome reconciliation. 4. **Riffmaw capture take:** dry direct-input (DI) instrument signal or musical vocal under an exact device/clock/latency manifest, producing `PerformanceTake@1` without absorbing ordinary speech. 5. **Mobile and Familiar adapter:** exact USB-C or onboard routes, signal-loss epochs, mission-owned consent, and independently reachable stop behavior. 6. **Avatar projection:** Avatar selects an eligible voice reference; Echo retains synthesis, delivery, and playback chronology. The first speech slice remains push-to-talk and record-and-send. Wake words, full duplex, echo cancellation, live jam response, voice cloning, and always-on microphones require separate bakes. ## One desk, separate routes The same PipeWire graph may expose both devices while the host arms their semantic routes independently: ```text FIFINE AM8 (USB) ───────────→ PipeWire/WirePlumber ─→ Echo speech route UMC202HD (USB) ← XLR mic ───→ PipeWire/WirePlumber ─→ Riffmaw musical-vocal route ← guitar/bass 6.35 mm TS ───────────→ Riffmaw instrument route ``` For a dynamic-microphone plus TS-instrument setup, input 1 may receive the XLR microphone and input 2 the guitar or bass. Keep `48 V` **off** for this combination; use `INST/Hi-Z` for the instrument input, start at low gain, and watch the clip indicator. For other microphone and power combinations, follow the exact interface and microphone instructions under the [Riffmaw hardware boundary](../../compositions/riffmaw/hardware.md). Which application may retain each channel is still decided before capture. Choose monitoring according to what you need to hear. Through Guitarix or another native Linux amp-simulation chain, turn direct monitoring off so the dry DI signal does not double the processed sound. For clean practice or latency-sensitive takes, turn it on. Riffmaw retains dry DI separately from the amp/cabinet print so a later mix can repair the sound. Ordinary desktop playback may use the motherboard headphone output; latency-sensitive tracking is better served by the interface headphones. ## Candidate device profiles These devices are replaceable examples, not purchasing recommendations or compatibility claims. Pin the exact model and revision, use a returnable evaluation path, and require the same Linux receipt from every substitute; a connector shape or vendor claim for another OS proves nothing on the target host. | Use | Candidate example | Why it is worth a bake | Linux receipt required | | --- | --- | --- | --- | | PC speech at a desk | [FIFINE AM8](https://fifinemicrophone.com/products/fifine-ampligame-am8-microphone) | Dynamic cardioid USB/XLR microphone with mute and headphone monitoring; close placement can reduce room pickup | Prove capture, mute indication, monitoring, format/rate negotiation, suspend/resume, and reconnect without depending on FIFINE Genie. | | Quiet-room desk alternative | [Razer Seiren V3 Mini](https://www.razer.com/streaming-microphones/razer-seiren-v3-mini) | Small USB condenser with tap-to-mute; its maker describes plug-and-play operation | Prove the basic class-compliant path, mute state, negotiated format, and reconnect; Linux is not the advertised support target. | | Shirt/mobile speech | [Hollyland LARK M2 USB-C](https://www.hollyland.com/support/lark-m2) | Compact 2.4 GHz transmitter/receiver route for a phone or nearby computer | Prove exact receiver enumeration, intended channel/rate facts, disconnect, and battery-loss settlement; do not infer Linux support from USB-C. | | Guitar and bass interface | [Behringer UMC202HD](https://www.behringer.com/en/products/0805-AAR) | Two inputs, instrument path, headphone output, direct monitoring, and 48 V for an eligible condenser microphone | Prove capture/playback channels, instrument impedance, direct monitor, rate stability, xruns, and reconnect; the vendor page is not a Linux support promise. | | Alternative two-input interface | [Audient EVO 4](https://audient.com/products/audio-interfaces/evo-4/overview/) | Two preamps, instrument input, headphone/output routing, and direct-monitor controls | Prove which controls work without the vendor app, then retain capture/playback, monitoring, rate, xrun, suspend, and reconnect facts. | ### Weak primary routes - **TWS earbuds** are useful for listening, but their Bluetooth microphone commonly falls to a lower-bandwidth telephony profile with more compression and latency. Keep them as playback or an emergency speech route, not primary musical capture. - **Bluetooth lavaliers without a receiver** add profile negotiation and latency uncertainty. A separately proved 2.4 GHz set with a USB-C receiver is usually the more bounded candidate. - **Motherboard mic/line input for guitar** does not replace a high-impedance instrument input. Onboard audio may remain useful for ordinary playback and headphones. - **Cheap anonymous BM-800 kits** commonly add noisy adapters or ambiguous phantom-power wiring; they are a weak Linux-first foundation. ## Mobile, drone, and rover routes ### Mobile and body-worn Use an exact USB-C receiver on the phone and a separately proved compatible receiver or USB input on the Linux host. Keep a body-worn transmitter clear of fabric, jewelry, and zippers. Pairing does not authorize continuous recording; Companion owns physical controls and indicators while Echo owns each admitted speech attempt and its chronology. ### Drone Consumer camera drones rarely accept a useful external microphone, and propeller wash dominates an exposed capsule. Prefer a small onboard recorder or digital-camera path whose bounded artifact is transferred after flight. For live speech, put the lavalier on the person or use a dedicated radio/body payload; do not hang TWS earbuds or a Bluetooth microphone on the airframe. ### RC car or rover For a rover with an SBC or camera, a protected MEMS/electret microphone near the chassis may record locally at 48 kHz after a real bake. Isolate it mechanically from the motor and drivetrain. Send a bounded low-rate preview only when the mission admits live audio, and retain full WAV only when capture and retention are separately admitted. Familiar owns the body and signal-loss policy; Echo may later transcribe an admitted artifact. --- title: "Soulstone" plain_name: "Local Models overview" section: "Sepulcher > Animator" status: "Operator validation" original: https://hexanomicon.dev/sepulcher/animator/soulstone/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/ --- # Soulstone (Local Models overview) ## Plain-English summary (Snayu) **What it is:** Describes a Local Model (Soulstone): a service running on your own machine in a rootless Podman container, defined by a Service Config File and supervised by systemd. **Why it matters:** Read this before adding or running a local model service. - You declare image, models, devices, mounts, secrets and lifecycle in a Service Config File (Rune). - Only warm models get Model Passes; the Stage Manager alone starts, loads or swaps them. - Repository tests cover compilation and adapters; a real GPU run still needs operator proof. **Status:** Operator validation. Built and tested in repo; awaiting real systemd/Podman/GPU proof. ## Original text (Hexanomicon) > _A daemon in a bottle, with its fire in your keeping._ A **Soulstone** keeps a service on your own iron: it is a local [Animator](../index.md) running in a rootless Podman container, projected through Quadlet and supervised by the user's systemd manager. You describe the service in an immutable **Soulstone Rune** in the Codex. Binding compiles that intent into its physical service. The Animator adapter then declares what it can do, probes whether it is ready, and translates any supported runtime-native operations. For a model-backed capability, the Soulstone is the local furnace in which an [Animus](../index.md#animus-the-power-answering) 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 To give a Soulstone its body, name the `quadlet.image`, runtime, models, endpoint, devices, mounts, secrets, and lifecycle intent. It receives only that declared substrate. The generated Quadlet governs the service; callers receive a scoped capability rather than the container itself. The live Soulstone Animator holds the Rune and Connector, separately from the generated Quadlet document. The [Rune's schema boundary](./rune.md#schema-and-process-generation) 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](./rune.md) to declare the service and its models. Read [Resources and Secrets](./resources.md) before granting a device, mount, port, or credential. ## Choose a Discipline [Disciplines](./disciplines.md) is the short map of the built-in runtime families. The detailed engine contracts live under [Soulstone Engines](./engines/index.md), 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](../../../adr/22-dispatcher.md) grants only `WARM`; the [Orchestrator](../../../adr/23-orchestrator.md) alone owns managed starts, dynamic activation, conflict drain, and compensation. [Coven](../coven.md) 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](../../../state-of-the-work.md#systemd-podman-embodiment). Refusal before mutation leaves the prior world intact; uncertain mutation remains contained for operator recovery. --- title: "Soulstone Rune" plain_name: "Local model config file reference" section: "Sepulcher > Animator > Soulstone" status: "Available" original: https://hexanomicon.dev/sepulcher/animator/soulstone/rune/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/rune/ --- # Soulstone Rune (Local model config file reference) ## Plain-English summary (Snayu) **What it is:** Reference for the Local Model Service Config File (Soulstone Rune): a TOML file under runes/animator/soulstones// listing fields like image, port, devices, volumes, secrets and the model catalogue. **Why it matters:** Read this when writing or reviewing a local model config file. - The folder path selects the runtime type; a type field cannot switch it. - Each [[models]] block becomes a capability {animator}:{family}:{model_id}; duplicate ids fail validation. - Endpoints must be loopback with an explicit port; remote endpoints belong to Cloud Models (Portals). **Status:** Available. Model catalogue path works; general-service declarations are Designed. ## Original text (Hexanomicon) A **Soulstone Rune** is compiler input: one validated TOML document describing a local service. It is neither live state nor a generated Quadlet. Concrete instances live beneath a registered leaf runtime schema, relative to the active [Codex](../../codex.md) root: ```text runes/animator/soulstones//.toml ``` Codex defaults to `~/.config/lychd/`; `XDG_CONFIG_HOME` changes that prefix. The abstract Animator and Soulstone branches cannot own TOML files. Folder ancestry selects the Rune type; no `type=` field may switch it after discovery. ## The Runtime Shape | Field | Default | Office | | :--- | :--- | :--- | | `name` | required | Animator identity; first segment of every capability key. | | `description` | `""` | Operator note. | | `quadlet.image` | runtime default | OCI image inside the embedded `QuadletConfig`; required by the generic runtime. | | `runtime` | `"generic"` | Selects the local runtime adapter. | | `model_path` | `null` | Single-model artifact path or runtime-specific identity input. | | `served_model_id` | `null` | For an inferred single model, set the exact provider-facing id when it differs from the path stem (basename without its final suffix), or the Soulstone name if no path is set. | | `base_url` | derived | Connector endpoint root; credentials, query, fragment, and invalid ports are refused. | | `port` | assigned | Unique host port; derives `http://localhost:{port}/v1`. | | `groups` | `[]` | Compatible [Coven](../coven.md) target membership. | | `devices` | `[]` | Explicit device passthrough. | | `volumes` | `[]` | Explicit host-to-container mounts. | | `env_vars` | `{}` | Non-secret environment values. | | `secret_env_files` | `{}` | Environment names mapped to Podman secret names. | | `exec` | `[]` | Complete command override; bypasses adapter synthesis. | | `models` | `[]` | Declared model catalogue; a non-empty table is the exact admitted id allowlist. | | `generation` | `null` | Service-wide generation overlay. | Runtime leaves may add typed fields such as `extra_args` or llama.cpp `startup_mode`. Adapter defaults are followed by typed overrides; explicit `exec` replaces synthesized arguments rather than extending them. Choose the Rune directory for the adapter you intend to use. Each built-in runtime leaf pins its `runtime` literal, so a llama.cpp, vLLM, SGLang, or ExLlamaV3 file cannot select a different adapter merely by changing that field. Then check the endpoint. `base_url` preserves a path prefix such as `/v1`, but rejects embedded credentials, query or fragment state, port zero, and out-of-range ports during validation. Hydration also requires an approved loopback host and an explicit port. If `port` is declared separately, it must match the URL. Remote endpoints belong at the Portal boundary. ## Capability declarations The model catalogue below is the current v1 compatibility path. General service declarations remain [Designed](#general-service-declarations). ### Declared models become v1 capabilities Give each `[[models]]` block a stable `id`, an explicit container-side `path`, and, as needed, a format, capability hints, and a per-model generation overlay. The resulting capability is identified as `{animator}:{family}:{model_id}`. Duplicate ids refuse validation. Once any model blocks exist, their ids form the entire admitted catalogue in declaration order. Discovery cannot add an undeclared id. A declared id missing from discovery stays declared but may be downgraded by readiness evidence. This lets you distinguish what was authorized from what the service currently reports. `[models.capabilities]` may declare: - `families`: `chat`, `vision`, `embedding`, `stt`, `tts`, `tool_execution`, or `rerank`; - `surface`: `chat` or `responses`, selecting the connector's admitted API surface; - `modalities_in`, such as `text`, `image`, or `audio`; and - `supports_tools`. These hints are authoritative for routing. A live probe may downgrade availability or fill an explicitly open runtime fact; it may not invent an undeclared model. An explicit `families` list is closed. When that field is omitted, the current catalogue synthesizes `chat`; other families require an explicit declaration. Image input enriches a `chat` capability and does not create the dedicated `vision` family. The full two-axis law lives in [Capabilities](../capabilities.md). The declared model is only one part of an application path. Bridge currently accepts text and needs tool support for its structured reply. It supplies no image/audio upload or materializer, and the v1 grant cannot execute the `vision`, `embedding`, `rerank`, `stt`, or `tts` families. An image-capable model therefore cannot by itself add image input to Bridge. Output modalities, streaming hints, and model descriptions are also absent from the current Rune schema and fail validation. An empty `models` list is not the Portal zero-capability rule. A Soulstone adapter may instead use its runtime/discovery model catalogue or derive one model id from `served_model_id`, `model_path`, or the Soulstone name. A non-empty list remains the exact allowlist. Every admitted Soulstone must synthesize at least one capability through its adapter. An unrecognised generic runtime remains passive at the adapter boundary, but registry generation refuses that Soulstone until a registered adapter or explicit OpenAI-compatible alias with defined binding semantics yields a capability. In the general-service shape, non-model services use `[[capabilities]]`; they do not fake a model declaration. Compatibility is claimed separately for each named [Connector dialect](../connectors.md#openai-compatibility-is-per-dialect). ## Generation Overlays The common optional generation fields are `max_context`, `max_tokens`, `temperature`, and `top_p`. Effective values overlay in this order: ```text runtime defaults → Soulstone [generation] → [models.generation] ``` The accepted ranges are `max_context`/`max_tokens ≥ 1`, finite `temperature` 0–2, and finite `top_p` 0–1. Other generation keys fail validation apart from the model-local policy below. The overlay bounds request settings; it does not resize a running engine. llama.cpp's managed `n_ctx` is reflected from its actual generated command before the explicit generation overlays apply. For an explicit local vLLM `Qwen3.8-27B` model using Chat, the model's generation block may also select the closed policy `thinking = "qwen3.8-non-thinking"`. It sends the supported template argument `enable_thinking = false` through that model's grant; it changes neither the running server's launch defaults nor sibling models. Omit it to retain ordinary behavior. It is refused in runtime or Soulstone-wide defaults, Portals, other models/runtimes and Responses. Arbitrary `extra_body`, a generic boolean and unknown policy tags are not accepted Rune inputs. This mode selection does not guarantee useful output or increase the existing output/call budget. Follow [vLLM](./engines/vllm.md) for the engine boundary and [State of Work](../../../state-of-the-work.md#vllm-integration) for delivery evidence. Bridge normally requests a tool-capable chat grant from Dispatcher's eligible pool. To pin one exact current v1 capability for new turns, follow the [`[weaver.bridge]` selector](../../extensions/weaver/index.md#choose-a-bridge-capability). Dispatcher still checks compatibility, readiness, and policy; a refused target never falls back. `[orchestration.routing]` selects only physical queue and priority. ## Concurrency Intent The `[concurrency]` table separates lifecycle authority from coexistence: | Field | Meaning | | :--- | :--- | | `dedicated` | LychD owns lifecycle and may start, stop, or evict the runtime. | | `persistent_resident` | Keep the runtime resident and outside every eviction set. | | `conflict_domains` | Finite hardware domains this managed runtime cannot share. | Omitting `conflict_domains` on a dedicated non-resident requests the compiler-owned `default-exclusive` wildcard. Explicit `[]` alone asserts coexistence. A shared (`dedicated = false`) or persistent-resident Soulstone may omit the field or declare `[]`; a non-empty set fails binding because LychD may neither evict the shared runtime nor compile an edge that could evict a resident. Labels are lowercase identifiers of at most 50 characters; operators must not spell `default-exclusive` directly. `groups` requests compatible aggregation, and one Rune may name several groups. That means the same service participates in several operator formations; it does not duplicate the instance or promise that the complete union may coexist. `alliances` is not an accepted Rune field. Groups do not change the conflict graph, reserve hardware, or ask for semantic dispatch. ## Schema and process generation The Rune brings together Animator identity and capability intent with an embedded `quadlet: QuadletConfig`. The nested value supplies only the common image invariant. Soulstone and Phoenix can both embed it under `quadlet` without sharing a Domain or Rune ancestry; future Tether or Veil Runes may do the same. Soulstone still owns runtime, endpoint, resource, secret, and lifecycle policy. Binding and Scribe produce the separate `QuadletContainer` artifact. Sharing a configuration value cannot transfer those responsibilities. Loaded Rune values are immutable through their nested models, sequences, and string maps. Change the TOML and construct a new process generation; do not mutate an admitted object in place. Rune writing uses the same exact schema generation admitted by loading, rather than every imported Python subclass, so an unregistered branch cannot leak into generated configuration. ## General-service declarations The accepted general-service shape adds first-class `[[capabilities]]` entries. A declaration references one registered `interface_id` and immutable `profile_ref` (stable id plus revision or digest), selects its permitted operations, and pins the driver/dialect, evidence, resource envelope, and containment profile for this instance. A Rune may supply endpoint, secret reference, lifecycle, and explicit admitted overlays; it cannot rewrite the referenced profile's request/result schemas, licenses, formats, languages, or proved limits. ## Refusal and Handoff The complete Rune generation validates before any unit is written. Duplicate identity, invalid ports, missing named secrets, unsafe mounts, an internally conflicting Coven, or an unauthorized conflict declaration fails closed. [Configuration](../../../adr/12-configuration.md) owns Rune discovery and validation; [Containers](../../../adr/08-containers.md) owns projection; [Orchestrator](../../../adr/23-orchestrator.md) owns transitions. --- title: "Soulstone Disciplines" plain_name: "Local model runtime families" section: "Sepulcher > Animator > Soulstone" status: "Operator validation" original: https://hexanomicon.dev/sepulcher/animator/soulstone/disciplines/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/disciplines/ --- # Soulstone Disciplines (Local model runtime families) ## Plain-English summary (Snayu) **What it is:** A short map of the built-in local model runtimes: vLLM (Kinetic), SGLang (Radix) and llama.cpp (Titan), plus how loading a model in a running server differs from restarting it. **Why it matters:** Read this to pick a runtime family and understand the lore nicknames used for each engine. - vLLM and SGLang serve a pinned model via an OpenAI-compatible API. - llama.cpp supports single-model and router modes with dynamic model loading. - Dynamic loading is not a restart; the Stage Manager owns both, and callers never bypass it. **Status:** Operator validation. Adapters tested in repo; real engine/GPU runs await proof. ## Original text (Hexanomicon) Each runtime needs its own knowledge of how to start, declare capabilities, report readiness, and—where supported—activate a model inside the running service. A **discipline** is that adapter knowledge applied to a Soulstone Rune. [Soulstone Engines](./engines/index.md) indexes the detailed contracts. The short names and historical anchors below remain the vocabulary used by the Lexicon. ## I. The Kinetic (vLLM) The Kinetic serves a pinned model through an OpenAI-compatible surface. Continue to the [vLLM engine contract](./engines/vllm.md) for its exact live-inventory readiness rule, runtime defaults, and outstanding operator receipt. These are adapter-specific obligations. ## II. The Radix (SGLang) The [SGLang engine page](./engines/sglang.md) owns the detailed adapter contract. SGLang also presents an OpenAI-compatible service; LychD does not require its `sgl.gen` DSL. Its live runtime receipt remains [operator validation](../../../state-of-the-work.md#sglang-integration). ## III. The Titan (llama.cpp) The [llama.cpp engine page](./engines/llamacpp.md) owns its single-model and router startup shapes, deterministic argument precedence, and dynamic activation contract. ## Dynamic Activation Is Not Restart The [Orchestrator](../../../adr/23-orchestrator.md) owns supported activation. A running router can load a model without a systemd transaction; reclaiming a conflicting physical runtime still uses the serialized target switch. Callers never invoke a runtime control API as a side route around the Dispatcher. Repository tests cover llama.cpp planning, discovery, capability derivation, and model loading. Model unloading is not a separate adapter operation; Orchestrator shuts down whole runtimes. A real engine/GPU/model result remains [operator validation](../../../state-of-the-work.md#llamacpp-integration). ExLlamaV3 uses a separate dynamic contract described in [ExLlamaV3 through TabbyAPI](./engines/exllamav3.md). --- title: "Soulstone Engines" plain_name: "Local model engines index" section: "Sepulcher > Animator > Soulstone" original: https://hexanomicon.dev/sepulcher/animator/soulstone/engines/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/engines/ --- # Soulstone Engines (Local model engines index) ## Plain-English summary (Snayu) **What it is:** Index of supported inference engines for local services: vLLM, SGLang, llama.cpp, ExLlamaV3 via TabbyAPI, ComfyUI and audio.cpp, and which app or plug-in area owns each kind of output. **Why it matters:** Read this to choose an engine and find which domain owns its results (images, speech, music and so on). - One local model service = engine + adapter + config file + Quadlet + resources. - One engine can back several separate services with different models or GPUs. - Being listed here does not mean the adapter is delivered; each engine page states its status. ## Original text (Hexanomicon) Choose an **engine** for the execution it can supply, then give it a local body through a Soulstone adapter, Rune, Quadlet, and declared resources. The upstream engine alone is neither the Soulstone instance nor a model or semantic extension. ```text engine + adapter + Rune + Quadlet + resources = one local Soulstone instance ``` The engine pages own runtime-specific launch shape, connector dialect, readiness and activation, resource placement, containment, and evidence. Choose an engine below for that adapter's requirements, then use the common [Soulstone contract](../index.md) to bind its local instance, admit work through Dispatcher, and request Orchestrator transitions. Each engine page states its delivery boundary; an entry in this map does not establish a delivered adapter. | Engine | Primary shape | Use | | --- | --- | --- | | [vLLM](vllm.md) | resident OpenAI-compatible model server | Kinetic model serving | | [SGLang](sglang.md) | resident OpenAI-compatible model server | Radix model serving | | [llama.cpp](llamacpp.md) | single-model server or in-process router | Titan model serving and dynamic activation | | [ExLlamaV3 through TabbyAPI](exllamav3.md) | dynamically activated model service | strict TabbyAPI-backed model serving | | [ComfyUI](comfyui.md) | queued graph/workflow engine | image, video, spatial, and exact audio-capable profiles | | [audio.cpp](audiocpp.md) | audio inference with an independently managed service or worker lifecycle | bounded music, separation, and speech profiles | The same engine may manifest several Soulstones with different model sets, graphs, GPUs, conflict domains, and capability profiles. `comfy-qwen`, `comfy-ltx`, and `comfy-music3`, for example, may use one ComfyUI image while remaining separate managed service instances. Qualify the particular work you intend to run on that engine. Model, graph, node set, quantization, license, and hardware placement belong to an exact capability profile. The selected adapter and owning extension or Composition must admit them; an engine's name cannot establish these facts for every model or workflow it can load. ## Engine versus technical contract and semantic owner The engine performs a bounded execution. Choose the technical contract and consuming owner for each returned facet: | Returned facet | Continue to | | --- | --- | | image, video, visual observation, spatial form, or structured motion | [Prism](../../../extensions/prism/index.md) for the exact technical interface and [Atelier](../../../../compositions/atelier/index.md) or another named consuming Composition for adoption | | speech transcription, synthesis, cloning, or delivery | [Echo](../../../extensions/echo.md) and the requesting owner | | music, musical vocal, production effect, or musical cue map | [Riffmaw](../../../../compositions/riffmaw/index.md) | | timed-language dialogue, narration, or caption edition | [Language Edition](../../../../compositions/language-edition/index.md), using its exact Echo and Translation operations | | picture-bound effect, foley, room tone, or ambience | [Broadcast](../../../../compositions/broadcast/index.md) | | game-event, state, space, listener, or runtime sound | [Foundry](../../../../compositions/foundry/sound.md) | | final audiovisual assembly | [Broadcast's pinned renderer and timeline](../../../../compositions/broadcast/render.md) | Prism settles technical results, Core owns any `ServiceJobAttempt@1`, and each consuming owner independently admits its facet. For model-native video with sound, follow [compound-facet admission](../../../extensions/prism/video.md#admit-every-compound-facet) before selecting the profile. An engine that can emit more than one modality does not absorb those domains. The exact Rune and capability profile determine which operations may execute; each application facet still needs its own semantic admission receipt. --- title: "vLLM" plain_name: "Engine: vLLM" section: "Sepulcher > Animator > Soulstone > Engines" status: "Operator validation" original: https://hexanomicon.dev/sepulcher/animator/soulstone/engines/vllm/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/engines/vllm/ --- # vLLM (Engine: vLLM) ## Plain-English summary (Snayu) **What it is:** How LychD runs vLLM as a local model server: you supply the full launch command, and a model is only marked ready when the live /models list contains its exact id. Includes a standalone probe for a first reply. **Why it matters:** Read this when setting up or testing a vLLM-backed local model. - vLLM arguments come verbatim from the exec list; the adapter does not synthesise flags. - The local_model_probe script tests one running server with a text and a tool round. - Passing the probe does not qualify a full installation, Chat or persistence. **Status:** Operator validation. Tested in repo; real image/model/GPU receipt still needed. ## Original text (Hexanomicon) **vLLM** is a resident model-serving engine behind an OpenAI-compatible connector. The Soulstone adapter binds one declared model service to a Rune, derives its model capability, probes the live inventory, and exposes it only when the exact declared model is ready. A server pinned to one model produces `is_dynamic=False` capabilities. Reachability establishes link liveness; a capability becomes `WARM` only when the validated live `/models` inventory also contains its exact declared model id. Malformed inventory or a missing id becomes `ERROR`. Focused tests cover current planning and connector behavior. vLLM framework arguments come from the operator-owned `exec` list, which the adapter passes through verbatim. Image, devices, mounts, ports, and environment remain typed Soulstone and Quadlet fields. Keep the command's served model id and endpoint consistent with the Rune; these declarations do not synthesize vLLM flags. The `exec` arguments follow the selected image's entrypoint. The generated example expects `["vllm", "serve"]` and begins with the model path; adding another `serve` would repeat the subcommand. Inspect and pin the actual image entrypoint before adapting a recipe. A different entrypoint needs its matching argument vector; the adapter does not rewrite it. The example's environment uses an ordinary TOML table and remains inactive until deliberately edited. ## Bring one service to a first reply For an already running local service, the standalone acceptance probe exercises explicit built-in registration, exact Dispatcher grants, AgentForge text output, and one harmless in-memory tool round. It reads no installation Settings or Runes and cannot start, stop, or load a runtime: ```bash timeout --signal=TERM --kill-after=5s 40s \ uv run --locked --no-sync python -m scripts.local_model_probe \ --base-url http://127.0.0.1:20000/v1 \ --model-id YOUR-SERVED-MODEL-ID \ --source-revision "$(git rev-parse HEAD)" ``` Point the probe at the endpoint and exact served model you want to test. Only literal loopback HTTP with an explicit port is admitted. It sends synthetic inputs and runs the two cases sequentially with finite request/output limits and a cooperative deadline. One JSON result goes to stdout; diagnostics go to stderr. A passing tool round must return a fresh marker from the actual tool call and leave no live capability lease. Before the Agent processes a response, that response must identify the declared model and carry an explicit wire finish reason of `stop` or `tool_call`. The SDK's default for an absent wire reason cannot supply this evidence. Filtered, truncated, errored, or unknown endings fail even if the marker appears. Failure retains any response metadata already observed. A failed or cancelled call leaves the externally operated server's outcome unresolved. Shielded client cleanup may outlast the cooperative deadline, so the outer process timeout bounds the command. If forced termination prevents a final JSON receipt, cleanup and server outcome remain unknown and the probe cannot pass. Retain the JSON outside the checkout with the independently observed image/model/host identities. The supplied source revision is a declaration, not a clean-checkout or artifact attestation. This probe qualifies neither an installed Vessel nor Bridge, streaming, persistence, managed activation, runtime-contributed tools, capacity, shutdown, or recovery. Choose the boundary being tested before adapting an existing serving recipe: | Boundary | What the observation must establish | | --- | --- | | Connector and Agent | The exact declared model appears at the configured `{base_url}/models` endpoint (`/v1/models` for the standard base URL); a real request passes through Dispatcher and its grant is released after success, failure, and cancellation. | | Managed activation | The owned runtime starts through Orchestrator, reaches exact-model readiness, and shuts down or reports a contained failure. | | Composed first light | Bridge receives the reply, the settled Run and conversation remain inspectable after restart, and the operator can stop the same installation. Interrupted-work recovery needs its own trial. | A working external server is useful input to the first boundary. It does not transfer ownership of that container or establish the other two. `dedicated = false` withholds lifecycle authority; it does not adopt an existing container, supply capacity admission, or make a cold service startable. Retain the existing recipe until its replacement has its own acceptance and recovery evidence, and do not run competing model copies on the same devices. Bind the image digest, model artifact and served id, command, environment, mounts, devices, context/output limits, and tested concurrency to the receipt. The generated Rune sample is an editable example, not a benchmark-qualified recipe. Check the endpoint **from the Vessel's network namespace**: host loopback and the loopback inside its pod are different destinations. An endpoint override alone does not prove reachability or admit a new network route. To repeat the trial through Bridge, configure revision 2 with the [exact capability selector](../../../extensions/weaver/index.md#choose-a-bridge-capability) and a capability declaring chat and tools. Confirm the Run's pinned Pattern revision in Loom and its recorded capability dispatch in Orb. Keep model-byte and runtime-generation identities in the receipt as well: a capability key does not pin either. Begin with one admitted request at a time. Before increasing concurrency, measure waits, timeouts, cancellation, and useful completed work on that exact serving profile. Engine sequence count and LychD lease count constrain different things. Use [Summoning's host and first-light checks](../../../../summoning.md) for the surrounding body. Its worked model recipe is llama.cpp; a vLLM trial must substitute its own qualified declaration and record the actual runtime names and shutdown path. A connector smoke test cannot stand in for that composed receipt. The exact model, quantization, GPU topology, image digest, arguments, readiness, inference, and shutdown still require an operator receipt. The current delivery boundary is recorded under [vLLM integration](../../../../state-of-the-work.md#vllm-integration). ## Join one reply to durable Bridge The former warm-model TestClient, sequential-spawn and source-native TCP selections are frozen historical observations, retired on 2026-10-20 at base `7057210a`. They recorded one actual structured Bridge reply and identical retained turns/model history after a second lifespan or process boot, with explicit test Settings/Runes and refusing host actuation. Their raw receipts and historical validators remain; no old source hash is refreshed to claim current qualification. The host Core test deployment and source-native TCP launcher have been removed, leaving no host pytest fallback. New evidence must run Core in the explicit OCI test image or, for installed acceptance, in the rebuilt Vessel image with its declared PostgreSQL and security boundary. That new proof needs fresh admission for external warm-model use, daemon/socket authority, profiles, resource bounds, and terminal cleanup. The ordinary wrapper does not forward arbitrary external profile files or proof environment. No replacement container runtime receipt is claimed. The frozen trusted browser and installed-hybrid observations retain their original private manager, plain Docker, inert model-unit and borrowed warm-vLLM limits. They do not qualify the current fixture, production image, managed-model lifecycle or active container stop/start. [State of Work](../../../../state-of-the-work.md#current-evidence-envelope) owns the exact historical envelope and current proof gaps. --- title: "SGLang" plain_name: "Engine: SGLang" section: "Sepulcher > Animator > Soulstone > Engines" status: "Operator validation" original: https://hexanomicon.dev/sepulcher/animator/soulstone/engines/sglang/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/engines/sglang/ --- # SGLang (Engine: SGLang) ## Plain-English summary (Snayu) **What it is:** Short page on running SGLang as a local model server through the generic OpenAI-compatible adapter, with the full launch command supplied in the config file. **Why it matters:** Read this when setting up an SGLang-backed local model. - LychD does not use SGLang's own DSL; it talks to the OpenAI-compatible API. - Keep the command's port and served model aligned with the declared endpoint and model id. - A healthy URL alone does not prove every declared model or operation works. **Status:** Operator validation. Real image/model/GPU run still needs an operator receipt. ## Original text (Hexanomicon) **SGLang** is a model-serving engine with an OpenAI-compatible service surface and its own runtime-native graph/DSL features. LychD binds the declared service through the Soulstone adapter; it does not require the caller to depend on `sgl.gen` or any other SGLang-specific language. You supply the complete SGLang launch command in the Rune's **operator-owned `exec` passthrough**. Typed fields keep the container and endpoint declaration. The registered `OpenAICompatibleRuntimeAdapter` binds that declared service; it cannot derive an SGLang program from a generic endpoint. Align the command's listening port and served model with the declared endpoint and model identity. Pin framework flags with that command and include them in the exact engine profile and runtime receipt. Neither a healthy URL nor a generic compatibility label establishes every declared model or API operation. The exact image, model, quantization, GPU and driver, launch arguments, readiness, inference, and shutdown still require an operator receipt. The current delivery boundary is recorded under [SGLang integration](../../../../state-of-the-work.md#sglang-integration). See [Soulstone Disciplines](../disciplines.md#ii-the-radix-sglang), [SGLang](https://github.com/sgl-project/sglang), and the [OpenAI-compatible connector boundary](../../connectors.md#openai-compatibility-is-per-dialect). --- title: "llama.cpp" plain_name: "Engine: llama.cpp" section: "Sepulcher > Animator > Soulstone > Engines" status: "Operator validation" original: https://hexanomicon.dev/sepulcher/animator/soulstone/engines/llamacpp/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/engines/llamacpp/ --- # llama.cpp (Engine: llama.cpp) ## Plain-English summary (Snayu) **What it is:** How LychD runs llama.cpp in single-model or router mode, with strict rules on launch arguments, model sources, context allocation, readiness and dynamic model loading. **Why it matters:** Read this when configuring llama.cpp, the engine used in the reference installation guide. - single mode serves one model; router mode starts empty and loads declared models on demand. - Remote Hugging Face presets are refused because they could change the server mode silently. - Model unloading is not a separate operation; the Stage Manager shuts down whole runtimes. **Status:** Operator validation. Planning and loading tested in repo; real GPU run pending. ## Original text (Hexanomicon) **llama.cpp** is a local model-serving engine with two materially different Soulstone shapes: - `single` starts with one declared model and serves one stable alias; - `router` starts without a model and activates declared models in process. ## Launch and identity First decide whether the adapter or the operator owns the command. Explicit `exec` supplies the whole command. For a managed command, `startup_mode` chooses `single` or `router`. With `auto`, argument and environment inference comes first; otherwise a `model_path` selects `single`, and its absence selects `router`. Typed `extra_args` append last. A forced mode must remain true after all inputs are considered. Forced modes therefore refuse known main-model source controls in `extra_args`, including shortcuts and token lookalikes in value positions. Use `model_path` for forced `single`, or model directories and presets for forced `router`. Forced `router` also refuses model-source environment controls. Forced `single` refuses a main Hugging Face repository in the environment because a remote preset can clear its model path. Both checks include variables projected from `secret_env_files`. These checks establish the supported command shape without reproducing all upstream option grammar. GPU/CPU offload remains a fact of the exact profile; the launch mode supplies no universal VRAM promise. Mode metadata follows the final command and its projected environment, including `secret_env_files`. For main-model and router source options, environment values apply first; a CLI value replaces the same source option even when it is empty. A nonempty main model path or Docker repository selects `single`; model directories and presets do not override that main source. Without a main source the server is a router. For managed `auto` planning, router argument or environment inputs still take precedence over an otherwise unused typed `model_path`. An effective main Hugging Face repository or a built-in main-model shortcut is refused: remote preset contents can change the server's mode, so local declaration cannot establish it. Use an explicit local model or router directory/preset. A model URL, HF filename, draft model, or `--spec-default` alone does not establish a main model or its provider identity. Write source, router, and alias controls with separate positional values. Empty values are retained; missing values, dash-leading values, and equals-form values fail validation. The adapter normalizes known underscore aliases for interpretation without rewriting their passthrough bytes. Place these controls before options whose arity LychD does not know. Otherwise a later source or alias token could be an unknown option's value, making its meaning ambiguous and causing refusal. Unknown trailing options remain operator-owned. This boundary prevents a consumed value from being mistaken for a source control without claiming a complete upstream parser. With passthrough `exec`, the operator must keep its listening port and served alias aligned with the declared endpoint and model identity. Declaration compilation rejects a known `--port` or `LLAMA_ARG_PORT` value that conflicts with the resolved endpoint, including a final `extra_args` override of a managed command. LychD does not rewrite passthrough commands or infer unknown wrapper syntax; declare the endpoint and command consistently for a runnable profile. Keep engine idle sleep disabled. Readiness probes and `autoload=false` cannot fence the engine's automatic wake, so that mode falls outside the supported profile. Managed arguments begin with `--sleep-idle-seconds -1`; omit `sleep_idle_seconds` or set it to `-1`. No sleep control may appear in `extra_args`. Passthrough `exec` must begin with the exact disabling pair: either `["--sleep-idle-seconds", "-1", ...]` for an image entrypoint, or `["llama-server", "--sleep-idle-seconds", "-1", ...]` for a complete command. The executable token must be nonempty and cannot begin with `-`; admitted bytes are not rewritten. Validation rejects later sleep controls, duplicate disabling flags, underscore aliases, equals spellings, and misplaced or malformed disabling arguments. It needs a known command shape because a flag consumed as another option's value cannot disable sleep. Custom wrappers unable to honor this shape remain outside the supported llama.cpp profile. This contract was checked against upstream revision [`434ddbbc0e30522e897670681e503b797c12b7c1`](https://github.com/ggml-org/llama.cpp/commit/434ddbbc0e30522e897670681e503b797c12b7c1): the router [overlays CLI arguments on every model preset](https://github.com/ggml-org/llama.cpp/blob/434ddbbc0e30522e897670681e503b797c12b7c1/tools/server/server-models.cpp#L531), while [sleeping children still count as running](https://github.com/ggml-org/llama.cpp/blob/434ddbbc0e30522e897670681e503b797c12b7c1/tools/server/server-models.h#L93) for router autoload admission. The default is disabled, but the explicit command value also overrides sleep enabled in global, model, directory, or cached presets. Command validation does not attest an already-running service or external changes; operator validation must check the actual image revision and arguments. The pinned [argument parser](https://github.com/ggml-org/llama.cpp/blob/434ddbbc0e30522e897670681e503b797c12b7c1/common/arg.cpp#L816) normalizes underscore option names and consumes values positionally; equals-form sleep flags are not accepted by that engine revision. The same revision [selects router mode only after resolving the main model sources](https://github.com/ggml-org/llama.cpp/blob/434ddbbc0e30522e897670681e503b797c12b7c1/tools/server/server.cpp#L110-L127). A later empty `--model` can clear an earlier path, and a [Hugging Face remote preset clears the main-model settings](https://github.com/ggml-org/llama.cpp/blob/434ddbbc0e30522e897670681e503b797c12b7c1/common/arg.cpp#L631-L636). The forced-mode refusals prevent those inputs from contradicting the selected launch shape. Aliases accumulate across `LLAMA_ARG_ALIAS` and every `--alias` or `-a` occurrence. Each value supplies comma-separated names; the supported profile trims ASCII whitespace and discards empty entries. An empty CLI alias does not clear an environment alias. The lexicographically first name in the combined set identifies the single model in the engine's inventory. Without any alias, single-model identity is the exact Docker repository or model path, including its directory and suffix. These rules follow the pinned [alias handler](https://github.com/ggml-org/llama.cpp/blob/434ddbbc0e30522e897670681e503b797c12b7c1/common/arg.cpp#L2899-L2909) and [inventory identity](https://github.com/ggml-org/llama.cpp/blob/434ddbbc0e30522e897670681e503b797c12b7c1/tools/server/server-context.cpp#L1263-L1273); locale-dependent treatment of non-ASCII whitespace is not attested by this profile. When managed planning selects `single`, it generates an alias. Explicit argument or environment aliases take precedence; otherwise `served_model_id` supplies it, followed by the generated model path's stem (basename without its final suffix), a Docker repository, or the Soulstone name. An explicit `[[models]]` catalogue does not disable alias generation. Without that catalogue, the adapter infers capability identity from the final launch inputs. Default model selection uses the first entry of the captured catalogue, including an explicit catalogue when supplied. An `auto` plan that omits the typed model and becomes single-model through an environment source does not add an alias; its identity follows the final inputs above. Declared model ids must match the engine's live inventory; a healthy process alone cannot grant an absent model. The single-model probe validates `/v1/models` after `/health`, following the upstream [Model Info API](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md#get-v1models-openai-compatible-model-info-api). A preset path projected through `secret_env_files` is not opened locally for catalogue or generation-default discovery. Declare the model catalogue when using that source; its actual contents and runtime behavior remain operator validation. ## Context allocation Use the generated command, including final `extra_args`, to determine managed context metadata. The catalogue divides positive total `-c` context by positive `-np` parallel slots, then applies any smaller explicit `--kv-unified-per-slot` cap. For example, `-c 8192 -np 4` admits a conservative 2048-token request bound even if unified KV could give one request more. Generated flags take precedence over environment and presets. Explicit `exec` leaves the derived bound unknown unless positive context and slot counts are known. Automatic or malformed command or environment inputs cannot silently fall back to a lower-priority value. These flags follow the upstream [server parameters](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md#server-specific-params). This measures configured allocation, not the model's training context or live hardware. Explicit generation overlays set request policy without resizing the engine's allocation. ## Readiness and control Inspect each router model's own inventory status. Clean `unloaded` permits activation; `loading` is `WARMING`; `loaded` together with ready health supplies warmth. A missing declared model or malformed inventory fails closed. Failed, sleeping, downloading, or unknown statuses cannot authorize activation, and one model's health cannot establish a sibling's readiness. Activation checks inventory again and does not repeat a load in progress. Inference and targeted health requests use `autoload=false`. With idle sleep disabled, losing a loaded model therefore cannot silently load or evict another. Runtime-native activation leaves the process running; reclaiming a conflicting physical runtime remains an Orchestrator transition. The current repository proves planning, discovery, capability derivation, and model-load control. Model unloading is not a separate adapter operation; whole-runtime shutdown belongs to Orchestrator. A real engine/GPU/model result remains [operator validation](../../../../state-of-the-work.md#llamacpp-integration). Control receipts are intentionally literal: model-load succeeds only on JSON boolean `true`, not `1` or `"true"`. Known numeric preset keys use their canonical integer or floating type; boolean words are ignored rather than silently becoming `0` or `1`. Treat those refusals as malformed provider/configuration evidence, not as successful control. See [Soulstone Disciplines](../disciplines.md#iii-the-titan-llamacpp), [llama.cpp](https://github.com/ggml-org/llama.cpp), and the [repository support files](https://github.com/hexanomicon/lychd/tree/main/examples/llamacpp). --- title: "ExLlamaV3 through TabbyAPI" plain_name: "Engine: ExLlamaV3 via TabbyAPI" section: "Sepulcher > Animator > Soulstone > Engines" status: "Operator validation" original: https://hexanomicon.dev/sepulcher/animator/soulstone/engines/exllamav3/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/engines/exllamav3/ --- # ExLlamaV3 through TabbyAPI (Engine: ExLlamaV3 via TabbyAPI) ## Plain-English summary (Snayu) **What it is:** How LychD runs ExLlamaV3 through its TabbyAPI server as a dynamically loaded local model, using Tabby's lifecycle API to load models and verify the active one. **Why it matters:** Read this when setting up ExLlamaV3/TabbyAPI-backed models. - The container starts without a model, so capabilities start as activatable, not warm. - Only the Chat Completions surface is supported; responses-surface declarations are rejected. - API and admin keys are mandatory and stored as Podman secrets. **Status:** Operator validation. Contracts tested; real GPU/model receipt still needed. ## Original text (Hexanomicon) **ExLlamaV3 is the inference library; TabbyAPI is its official OpenAI-compatible server.** LychD keeps that server outside the daemon dependency graph and registers it as the dynamic `animator/exllamav3` Soulstone runtime. The generated sample pins the TabbyAPI image by digest. The container starts without a model, so its declared capabilities become `ACTIVATABLE`, not `WARM`. LychD sends the declared model directory and backend through Tabby's lifecycle API; context, cache, split, and reserve remain TabbyAPI defaults unless a model-local `tabby_config.yml` overrides them. Keep the identity used by LychD separate from the directory TabbyAPI loads. A stable `[[models]].id` names the LychD model; its `path` must name a validated direct child of the mounted model directory. The Connector takes that path's basename as Tabby's runtime name and translates between them for both lifecycle control and data calls. The current LychD TabbyAPI adapter executes the Chat Completions surface. A model declaration with `capabilities.surface = "responses"` is rejected at Rune validation because that surface is outside this adapter's admitted contract. Authentication is mandatory even inside the unpublished private pod. The two distinct API and admin keys remain Podman-secret material and are never placed in browser code or ordinary Rune fields. Core binds only the managed container Vessel; the former `bind --uncaged` option is retired. Follow model loading through the whole `POST /v1/model/load` server-sent-event stream, then verify the active model with `GET /v1/model`. LychD performs both steps because a disconnected client cannot establish that a detached load failed. An indeterminate stream keeps the result contained for reconciliation or reset through the owning Vessel boundary. Focused contracts cover the runtime, control plane, connector, registration, authentication, and containment behavior. The named GPU/model/runtime receipt remains [operator validation](../../../../state-of-the-work.md#exllamav3-tabbyapi). See [ExLlamaV3](https://github.com/turboderp-org/exllamav3), [TabbyAPI](https://github.com/theroyallab/tabbyAPI), and [Soulstone Disciplines](../disciplines.md). --- title: "ComfyUI" plain_name: "Engine: ComfyUI" section: "Sepulcher > Animator > Soulstone > Engines" status: "Designed" original: https://hexanomicon.dev/sepulcher/animator/soulstone/engines/comfyui/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/engines/comfyui/ --- # ComfyUI (Engine: ComfyUI) ## Plain-English summary (Snayu) **What it is:** Design for running ComfyUI as a local graph engine for image, video and audio work, where each admitted preset pins the exact graph, nodes, models and allowed parameters. **Why it matters:** Read this before working on image/video generation or the Workbench Comfy probe. - Arbitrary caller graphs, cloud nodes and runtime downloads stay closed; only admitted presets run. - A local model and a hosted API with the same name are different routes unless proven equal. - A separate Workbench engineering probe exists, but only with mock transport evidence. **Status:** Designed. No native ComfyUI adapter or visual output path is delivered. ## Original text (Hexanomicon) Choose a bounded workflow before admitting [ComfyUI](https://github.com/Comfy-Org/ComfyUI). Its graph and dependency closure must describe exactly what may execute, which parameters may vary, and how results return to their owners. ComfyUI is a graph execution engine; a local service can become a Soulstone when LychD owns its container, queue, readiness, GPU placement, model mounts, and lifecycle. Several semantic owners may use that engine. This native adapter is a **Designed** candidate. No native ServiceJob adapter or admitted visual byte path is delivered; [State of Work](../../../../state-of-the-work.md#vision-admission) owns delivery status. The separate [Workbench engineering probe](../../../../compositions/riffmaw/workbench.md) exercises classic-server submission/reconciliation and bounded retrieval outside native admission. Its mock-transport evidence does not prove a running server, model closure, generation or semantic acceptance. [State](../../../../state-of-the-work.md#music-comfy-engineering-probes) owns that subset. ## Keep model, engine, and road apart Begin with the operation and the owner that will judge its result. That domain's immutable semantic profile pins request and result schemas, model or voice identity, languages, formats, license, limits, and bake evidence. Each engine or provider implementation then pins this exact semantic revision together with its dialect, runtime, placement, and evidence. This comparison must reach beyond a familiar model name. Local open-weight MiniMax Music and the hosted MiniMax API remain different routes unless exact model, protocol, and evidence establish equivalence. The [engine and semantic-owner map](index.md#engine-versus-technical-contract-and-semantic-owner) explains the shared division of responsibility. The preset is the complete program you are admitting: immutable editor/API graph, node and custom-node closure, model files, permitted parameter openings, output mapping and paths, network behavior, container revision, and licenses. [Assimilation](../../../../adr/35-assimilation.md) must admit that program before execution. A caller can then choose the preset and its permitted parameters. Arbitrary caller graphs, partner/cloud nodes, runtime downloads, and ambient custom-node installation remain closed. The Soulstone Rune pins the local container, endpoint, devices, mounts, lifecycle, resources, and admitted profile/preset references. A Portal requires separate admission of provider, endpoint, dialect, credentials, custody, cost, and reconciliation. A local pack name proves no remote equivalence. [Scroll placement](../../../extensions/weaver/pattern-lifecycle.md) pins the semantic Spell request, result, authority, recovery, and finish. Its Resolution Lock pins the chosen exact local Soulstone or Portal implementation. Comfy editor state is not a Scroll. ## Pin the dialect and execution lifecycle The official external [Comfy API v2](https://docs.comfy.org/api-reference/v2/overview) is exposed by cloud and serverless services. Self-hosting that v2 API currently requires a separately pinned `comfy-api-proxy` alongside ordinary ComfyUI; its default loopback arrangement connects proxy port 8189 to ComfyUI port 8188. A deployment choosing that dialect therefore pins both services. The [classic server](https://docs.comfy.org/development/comfyui-server/comms_routes), including `/prompt`, `/history`, `/queue`, `/interrupt`, and WebSocket communication, remains a distinct dialect. Before relying on job recovery, pin the chosen route's authentication, retention, and restart behavior. The [v2 submission](https://docs.comfy.org/api-reference/v2/jobs/submit-a-workflow-for-execution) contract uses a single-use `Idempotency-Key`: a duplicate is rejected, rather than returning the previous response. The self-hosted proxy needs persistent [`--state-dir` storage](https://github.com/Comfy-Org/comfy-api-proxy/blob/main/docs/batch-workloads.md#persistence---state-dir) for its own records, which does not preserve ComfyUI queue/history or output bytes after restart. If submission is ambiguous, look it up before deciding recovery. Blind retry is inadmissible: it cannot resolve the missing account. An admitted adapter must supply upload, submit, queue, progress, history, output, interruption, cancellation-request, and reconciliation facts. Core alone owns `ServiceJobAttempt@1`; the domain job links that attempt. LychD retains authority, custody, retry law, and canonical provenance. Filenames and PNG metadata may support evidence, but cannot serve as durable identity. ## Measure each admitted profile GPU placement belongs to an exact profile and instance. Separate `comfy-qwen` and `comfy-ltx` instances may use separate GPUs. An experimental multi-GPU instance requires explicit device nodes and a measured profile. Neither arrangement implies parallelism, pooled VRAM, residency, or batching. Candidate profiles begin with Qwen [image/edit](../../../extensions/prism/image.md), LTX-2.5 or Wan [video](../../../extensions/prism/video.md), and MiniMax Music 3. Exact speech, role-qualified sound, and [Form](../../../extensions/prism/form.md) profiles follow. Each must independently prove inputs and outputs, languages, limits, cancellation, VRAM and offload behavior, licenses, and artifact validation. Evidence for one profile does not admit another. ## Preserve compound results through handoff For native synchronized video and sound, the exact Prism `VideoJob@2` receives provider identity, the compound container digest, child streams, shared timebase, and engine facts. Sound is enabled only after `MediaFacetAuthoritySet@1` declares every requested role, the consuming Composition identity and revision, and the owner-request digest. Follow Prism's [compound-facet admission](../../../extensions/prism/video.md#admit-every-compound-facet) for detailed sound preflight and inseparable-facet behavior. Prism links the Core attempt; Reliquary owns custody and provenance. Each requested facet needs its consuming owner's independent `SemanticFacetAdmissionReceipt@1` under the linked Video contract. Unexpected sound is quarantined or deleted rather than assigned a guessed owner. Broadcast alone judges the final editorial audiovisual relation. Engine completion supplies execution facts; passage to an application still requires the exact profile's artifact validation, preserved custody and provenance, and each requested facet's independent semantic admission. --- title: "audio.cpp" plain_name: "Engine: audio.cpp" section: "Sepulcher > Animator > Soulstone > Engines" status: "Designed" original: https://hexanomicon.dev/sepulcher/animator/soulstone/engines/audiocpp/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/engines/audiocpp/ --- # audio.cpp (Engine: audio.cpp) ## Plain-English summary (Snayu) **What it is:** Short candidate page for using audio.cpp as a local engine for music, source separation and speech, with output meaning owned by Voice (Echo), the music app or another owner. **Why it matters:** Read this when evaluating local audio inference options. - Pin runtime revision, model family, worker shape and devices before admitting it. - If no managed lifecycle is needed, use a bounded tool profile instead of a local service. - Model weights and licences are separate facts from the Apache-2.0 runtime licence. **Status:** Designed. Candidate study only. ## Original text (Hexanomicon) Consider **audio.cpp** when a bounded local audio operation needs an inference engine. A pinned server or worker may justify a Soulstone and local Animator. The meaning of its output still belongs to the consuming owner: Echo for speech mechanics, Riffmaw for music, or another application according to the admitted operation and semantic role. The candidate study concerns music, separation, and speech families supported by an exact pinned runtime profile; it does not admit arbitrary model execution merely because the runtime is Apache-2.0. Model weights, dependencies, family support, input/output bytes, and license terms remain separate profile facts. To admit an audio.cpp Soulstone, first pin how it will run: runtime revision, model family, worker or server shape, queue and lifecycle behavior, and device topology. Then establish the audio formats, cancellation boundary, output custody, and measured receipt. If a library or one-shot CLI needs no independently managed lifecycle, keep it in a bounded `ToolProfile` instead. The music candidate is recorded in [Riffmaw Studio](../../../../compositions/riffmaw/studio.md); speech law and Language Edition's use of exact STT/TTS operations remain in the [Audio covenant](../../../../adr/37-audio.md) and [Language Edition](../../../../compositions/language-edition/index.md). Audio admission remains separate from the generic Soulstone engine catalog. See [audio.cpp](https://github.com/0xShug0/audio.cpp) and the owning [Echo](../../../extensions/echo.md), [Riffmaw](../../../../compositions/riffmaw/index.md), and role-specific application contracts. --- title: "Soulstone Resources and Secrets" plain_name: "Local model devices, mounts, secrets" section: "Sepulcher > Animator > Soulstone" status: "Available" original: https://hexanomicon.dev/sepulcher/animator/soulstone/resources/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/resources/ --- # Soulstone Resources and Secrets (Local model devices, mounts, secrets) ## Plain-English summary (Snayu) **What it is:** Rules for what a local model service may receive: explicit devices, volume mounts, non-secret environment, Podman secret references and a unique host port. **Why it matters:** Read this before granting a local model access to a GPU, folder, port or credential. - Mounts may not touch the Settings Folder, Data Folder or systemd binding roots. - secret_env_files maps env names to Podman secrets; Apply Config checks they exist without reading them. - Every local model needs a unique host port; omit it to have one assigned automatically. **Status:** Available ## Original text (Hexanomicon) A Soulstone receives an explicit slice of local substrate. Its Rune may name devices, ports, volumes, non-secret environment, and Podman secret references. It gains no blanket Crypt, model shelf, host socket, or credential authority from being local. ## Explicit Local Substrate `devices` passes named hardware into the container. `volumes` maps exact host paths to exact container paths. Model artifacts must be reachable through a declared Rune or adapter-contributed mount; there is no implicit host `model_root`. Before admitting a mount, the protected-root gate checks both ends. Each must be absolute. It resolves host symlinks before comparison and emits a safe alias as its canonical target. Neither end may equal, contain, or sit beneath the Codex, Crypt, Reactor, or user-systemd binding roots. Percent signs, backslashes, and non-printable characters also cause rejection. ## Secret Hydration `secret_env_files` maps an environment-variable name to a Podman secret name. This schematic example demonstrates that mapping; an admitted engine profile must separately pin its image: ```toml name = "private-runtime" runtime = "vllm" model_path = "/models/qwen-awq" [quadlet] image = "vllm/vllm-openai:latest" [secret_env_files] HF_TOKEN_FILE = "hf_runtime_token" ``` Binding first checks that `hf_runtime_token` exists, without reading its contents. Missing secrets or failed existence probes refuse the bind. A successful bind emits `Secret=hf_runtime_token` in the Quadlet, making `HF_TOKEN_FILE=/run/secrets/hf_runtime_token` available inside the container. The Codex retains the name; rootless Podman's secret store retains the value. Recreate the consuming container after replacing that value. ## The Port Singularity !!! warning "Every Soulstone must listen on a unique host port" Reusing a port can fail a transition with `Address already in use`. A Soulstone may omit both `port` and `base_url`; loading assigns a unique local port and derives `http://localhost:{port}/v1`. Explicit values win, and host publication remains loopback-bound. ## Owners and Refusal [Configuration](../../../adr/12-configuration.md) owns secret references and Rune validation; [Layout](../../../adr/13-layout.md) owns protected geography; and [Containers](../../../adr/08-containers.md) owns unit-scoped mounts, devices, and secrets. [Security](../../../adr/09-security.md) owns the trust boundary they defend. Repair the rejected declaration and bind again. Do not edit generated units to bypass a refusal. --- title: "Portal" plain_name: "Cloud Models (remote APIs)" section: "Sepulcher > Animator" status: "Partial" original: https://hexanomicon.dev/sepulcher/animator/portal/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/portal/ --- # Portal (Cloud Models (remote APIs)) ## Plain-English summary (Snayu) **What it is:** Describes a Cloud Model (Portal): a remote API provider declared in a config file, with no container or local GPU use. Declaring one names a possible data path but does not yet allow sending data. **Why it matters:** Read this before adding a cloud provider or working on privacy and outbound traffic. - The Traffic Controller currently refuses every Cloud Model grant until the Privacy Filter exists. - No automatic fallback from a failed local call to the cloud. - Probing is off by default; LychD never starts, stops or repairs the provider. **Status:** Partial. Declarations and probes exist; actual cloud calls are blocked. ## Original text (Hexanomicon) > _Beyond the rift, another sky keeps its own thunder._ A **Portal** is a remote, API-backed [Animator](./index.md) declared by a provider-specific Rune. It has no container and consumes no local VRAM. Its connector runs inside the trusted Vessel, where it may read the one Podman secret explicitly mounted for it. The credential shares that trust boundary: file permissions do not hide it from code already executing inside the Vessel. LychD does not own the remote service's lifecycle. Portal capabilities are `dedicated=False` and `is_dynamic=False`: the Orchestrator cannot start, stop, load, or repair the provider. [Portal Roads](portal-roads.md) owns the choice between direct server APIs, BYOK gateways, aggregators, human coding subscriptions, subscription bridges, and local inference. A provider or dashboard appearing there is a candidate classification, not a delivered connector or endorsement. ## Egress Is a Deliberate Boundary !!! warning "Declaring a Portal names a possible egress path; it does not authorize one" A matching Portal may enter the registry, but Dispatcher currently refuses every Portal grant because the typed egress-admission path is absent. Payload privatization, secure-mode, local-before-paid, and x402 gates are not current enforcement. Declare only a credential, data boundary, and spend profile that could become eligible after those gates are delivered. Three limits matter: 1. **No automatic cloud replay.** A failed local call is not replayed through a Portal; no current `FallbackModel` path exists. 2. **No probe egress by default.** `probe = false` prevents the registry's optional `/models` request. The resulting route remains unverified `UNKNOWN` and cannot receive a grant; the separate Portal quarantine also refuses it before transmission. 3. **No hidden remote lifecycle.** Binding writes no Portal Quadlet and contacts no provider. It validates intent, proves named-secret presence, and mounts the reference into the Vessel. With probing off, the registry reports the route as `UNKNOWN`; a declaration alone cannot establish `WARM`. Enabling it permits the current two-second unauthenticated `GET /models` probe and validation of the returned `data[*].id` inventory. Malformed inventory or the absence of the declared model id produces `ERROR`. A credentialed provider can reject this probe even if its ordinary authenticated model call would work. Read the result as a readiness observation only. It cannot bypass the current all-Portal dispatch quarantine. [State of Work](../../state-of-the-work.md#context-privatization-and-portal-egress) owns the absent egress gate. The documented anonymization Pattern does not authorize transmission. ### Qualify disclosure accounting locally The opt-in `closed-diagnostic-recording@1` profile exercises durable decisions and consumed capacity using only the existing closed diagnostic fixture and a concrete local recorder. Its host pins a synthetic export consumer and expected binding independently of the Cut. The acceptance witness must retain consumed host/purpose/Cut limits across new identifiers and service reconstruction, refuse old seals and copied claims, and record exactly the verified bytes. The database retains restricted custody rather than source or candidate bodies. Run its disposable-PostgreSQL receipts with: ```bash make test-containers CONTAINER_TEST_TARGETS="tests/integration/test_privacy_disclosure_pg.py tests/integration/test_privacy_disclosure_migrations_pg.py" ``` The command requires the container-test environment described in [Contributing](https://github.com/hexanomicon/lychd/blob/main/CONTRIBUTING.md#quality-checks). An explicit `LYCHD_PRIVACY_TEST_DATABASE_URL` selects a disposable database supplied by the operator instead; the profile never selects an application database automatically. This profile opens no network road and changes no Portal grant. Actual peer enrollment, full envelope verification, transport and native wait/adoption remain separate work. Its law is in [Security](../../adr/09-security.md#offline-disclosure-accounting-qualification) and [Persistence](../../adr/06-persistence.md#closed-disclosure-accounting-custody); [State of Work](../../state-of-the-work.md#context-privatization-and-portal-egress) owns delivery. ## Declare and inspect one Portal This rite assumes a summoned host. Run its commands from the stable [Summoning checkout](../../summoning.md#the-desecration), under the same operator user and XDG environment. For a first installation, begin with [Summoning](../../summoning.md). ### 1. Admit the provider schema Resolve the Codex without assuming its home, then add `animator` to the existing `[extensions].builtins` list: ```bash CODEX_DIR="${XDG_CONFIG_HOME:-$HOME/.config}/lychd" vi "$CODEX_DIR/lychd.toml" ``` Inscribe the provider anchors and inactive samples: ```bash uv run --extra postgres-binary lychd init ``` The built-in `animator` extension registers `runes/animator/portals/openai/` and `runes/animator/portals/google-gemini/`. Both use an OpenAI-shaped HTTP interface, while the Connector selects the declared provider's model-profile resolver. Selecting an `animator/*` runtime also registers the shared Portal base. For another interface, an extension must supply its Rune schema and Connector factory. The schema alone admits declarations, without constructing a runtime or capability. That construction needs one exact `PortalDefinition` for the concrete schema; there is no anonymous OpenAI-compatible fallback. ### 2. Seal one credential Create exactly the name the Rune will reference; never put the value in TOML: ```bash SECRET_NAME=portal_openai_main read -rsp "Value for $SECRET_NAME: " LYCHD_SECRET printf '%s' "$LYCHD_SECRET" | podman secret create "$SECRET_NAME" - podman secret exists "$SECRET_NAME" unset LYCHD_SECRET SECRET_NAME ``` For deliberate rotation, use `podman secret create --replace`, then recreate the Vessel. ### 3. Declare one model Create `"$CODEX_DIR/runes/animator/portals/openai/main.toml"`: ```toml title="main.toml" name = "openai-main" description = "Explicit remote chat capability." api_key_secret_name = "portal_openai_main" probe = false [[models]] id = "gpt-5.2" [models.capabilities] families = ["chat"] modalities_in = ["text"] supports_tools = true [models.generation] max_tokens = 4096 ``` The `openai` leaf supplies provider identity and its default URL. Override `base_url` only for an OpenAI-compatible endpoint. A Portal with no `[[models]]` blocks contributes no capability; LychD does not infer or download a provider catalogue. The endpoint is a root: an existing path prefix is kept when `/models` is appended, while embedded credentials, query or fragment state, port zero, and out-of-range ports fail validation. Model ids are unique; duplicates fail before registry construction. Portal models use the Pydantic AI profile selected by provider alias and model id, so settings known to be unsupported are omitted rather than forced onto the request. OpenRouter, LiteLLM, and Ollama retain their provider resolvers; Gemini's OpenAI-compatible leaf uses Google's model profile. Generic compatible endpoints and local Soulstones use a conservative compatibility profile. OpenRouter model ids keep their `provider/model` prefix. The current Google, LiteLLM, and Ollama aliases reject the Responses surface; OpenAI, OpenRouter, and explicitly compatible generic endpoints may select it. This is not evidence of a native Gemini transport. ### 4. Bind, restart, and observe !!! danger "Restart only a quiescent Vessel" There is no complete active-run census or graceful drain command. Restarting fails work in `RUNNING` or `AWAITING_HARDWARE`. Stop submissions and let visible runs settle; if continuity is uncertain, do not restart. The direct Systemd restart below is a separately chosen operator action under [Reanimation’s limits](../phylactery/reanimation.md#perform-one-bounded-reanimation) and the separately authorized [recovery plan](../../summoning.md#close-the-rite). It bypasses Orchestrator admission and lease drain. It is not a delivered CLI fallback: [public stop still refuses an active Vessel](../../state-of-the-work.md#core-cli-rites). ```bash uv run --extra postgres-binary lychd bind --dry-run uv run --extra postgres-binary lychd bind systemctl --user restart lychd-vessel.service uv run --extra postgres-binary lychd status ``` After binding, distinguish the three observations. Bind verifies the Rune, named secret, and atomic reconciliation of units. CLI `status` inspects the installation. Neither establishes a provider call or lists its model capabilities. To inspect registration, open `http://127.0.0.1:7134/orchestrator/status` in the same-host browser. Under `all_capabilities`, find the row whose `capability_key` is `openai-main:chat:gpt-5.2`. This row establishes that the declared capability was synthesized and registered. Because the example sets `probe = false`, its `phase` remains `unknown`. A later `warm` observation would establish readiness of that exact declared binding, without establishing egress eligibility or credentialed invocation. Current Dispatcher policy quarantines every Portal grant. The Bridge has no provider picker. Once the general Egress Gate is delivered, a future attributable end-to-end proof may make this Portal the only eligible `chat` plus tools candidate and send one benign public-safe fixture through a fresh payload-bound decision. Today, do not send that prompt: the current executable proof ends at declaration, bind, and readiness observation because Dispatcher refuses the grant. ## Failure and Closure If the row is absent, check extension activation, the provider anchor, at least one model block, and the Vessel restart. If a request fails, inspect the Vessel journal and provider account separately; do not reinterpret passive warmth as a provider response. Close the sky by removing its routable model declarations, binding the new intent, and restarting the quiescent Vessel. The named secret may then be rotated or retired under the operator's own secret policy. ## Credential custody in Reach Reach needs a stronger credential boundary than the current Vessel-local Connector supplies. Its [deployment profiles](../../compositions/reach/deployments/index.md) must keep the provider secret out of both Reach core and the Discord edge, even when they share a host. The Designed profiles place that one exact provider or peer credential in a separate Provider Gate/egress adapter service, which accepts only typed, egress-admitted attempts. Until that service boundary and its deployment receipt are delivered, the current Connector cannot serve as a Reach provider path, including in the public VPS profile. ## Portal Rune Reference | Field | Default | Meaning | | :--- | :--- | :--- | | `name` | required | Animator identity and capability-key prefix. | | `description` | `""` | Operator note. | | `provider_name` | provider leaf | Connector identity. | | `base_url` | provider leaf | HTTP(S) endpoint root without credentials, query, fragment, or invalid port. | | `api_key_secret_name` | `null` | One option-free Podman secret name, never its value. | | `models` | `[]` | Explicit declarations; empty means zero capabilities. | | `generation` | `null` | Portal-wide generation overlay. | | `probe` | `false` | Opt in to the unauthenticated `/models` probe. | Each model requires provider-facing `id`; it may add capability hints and a per-model generation overlay. Operator description belongs to the Portal, not each model block. Capability hints default to chat with text admission. Verification may downgrade a declaration, never invent one. --- title: "Portal Roads" plain_name: "Choosing cloud provider routes" section: "Sepulcher > Animator" status: "Designed" original: https://hexanomicon.dev/sepulcher/animator/portal-roads/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/portal-roads/ --- # Portal Roads (Choosing cloud provider routes) ## Plain-English summary (Snayu) **What it is:** Operating design for choosing how to reach a remote model: direct provider API, BYOK gateway, aggregator, human subscription seat, subscription bridge or local inference, and what evidence each needs. **Why it matters:** Read this when evaluating cloud providers, gateways like OpenRouter, or cost/custody trade-offs. - Default starting point is one direct server API with a workload-issued key. - Personal coding subscriptions (Claude Code, Copilot, etc.) are never valid server credentials. - Every cloud grant stays blocked until the Privacy Filter and Egress Gate are built. **Status:** Designed. Selection guidance; cloud execution is still blocked. ## Original text (Hexanomicon) > _A cheap road may still cross the wrong kingdom. Name the custodian before counting the toll._ An unattended indexing job is ready to send a document. Who may receive those bytes, and whose account authorizes the work? Choose [labor ownership](../extensions/weaver/execution-roads.md) first; then choose the service road and retain the evidence that could make it eligible. This is operating design. [Portal declarations](portal.md) and probes exist, but general execution is closed: every Portal grant remains quarantined while Privacy Cut and trusted Egress Gate are absent. [Current maturity](../../state-of-the-work.md#context-privatization-and-portal-egress) owns that delivery boundary. ## The default road For an unattended indexing job, begin by considering one direct server API with a workload-issued API key, service account, or workload identity. The same initial preference applies to Reach and public services, CI, and A2A-backed applications. One direct upstream keeps the custody question small: every added intermediary also receives request bytes, metadata, credentials or receipts, and adds an availability dependency. This is a conditional starting point, not an admitted profile or a claim that direct service is cheapest. Identify what the offered credential actually buys: | Road | Account, custody and eligibility | |---|---| | BYOK policy gateway | Gateway credential plus separately scoped upstream key; the gateway receives admitted traffic. DLP, accounting, region or control-plane needs may justify study. It remains a Lab candidate until a delivered Gate/adapter binds the complete custody route. | | Metered aggregator | Aggregator key and billing; it brokers or selects upstreams. An explicit catalogue, measured fallback or low-volume study may justify consideration, subject to the same unimplemented multi-hop boundary. Opaque cheapest routing and silent policy changes are excluded. | | Human operator seat | Provider-supported interactive local Codex, Claude Code, Copilot, Antigravity or similar client holds OAuth/session, including supported automation surfaces. Useful for local coding outside Spellweaver automation; never a Portal or Reach/public-service credential or server-use grant. | | Subscription bridge | Stores, translates, pools or reissues consumer OAuth/session behind another API key, often for quotas or cross-client use. Admission requires written upstream authorization for this exact server use and separate security review. | | Local inference | No remote credential or provider custody. Local sensitive preprocessing, retrieval, routing and bulk work belong to a [Soulstone](soulstone/index.md), outside Portal. | [Disclosure law](../../adr/09-security.md#portal-privatization-and-egress) requires an immutable, ordered custody-route digest binding gateway endpoint and policy revision, ultimate provider/model/region, redirects and every material hop. No delivered Gate schema, gateway adapter, independent route evidence or selection receipt implements it. Gateway upstream/model labels remain assertions without independent evidence; configuration and response labels cannot substitute for proof. Anonymization changes eligible payload, never server licence, account-pooling authorization or intermediary custody. ## Selection receipt Retain a dated, source-linked packet covering every item below before considering the road eligible. Use [Tithe/Toll](../extensions/toll.md) for quotas and money. - Actual upstream/service, legal account owner, permitted usage class and provider-terms revision. - Authentication kind, credential custodian and rotation, and any human session. - Canonical endpoint, protocol, model identifier or revision, capabilities, region and every intermediary. - Training, retention, abuse monitoring, deletion, subprocessors and zero-data-retention facts. - Price units, gateway fees, included quota, rate and concurrency ceilings, expiry and hard spend cap. - Permitted input classes and purposes, required Cut evidence and forbidden data. - Explicit fallback set or none, with policy and cost for every member. - Timeout, cancellation, idempotency, provider-job lookup, uncertain-effect reconciliation and return quarantine. - Observation date and revalidation triggers for prices, terms, models, custody and ownership. `free`, `included`, an operator-owned VPS or a successful smoke probe proves none of server-use permission, caller identity, confidentiality, stable price or production availability. Recheck terms, prices, retention and inventory before purchase or Bind. The dated candidate list later supports comparison, not endorsement. ## One admitted remote attempt The sequence below is the durable profile required by Reach and by asynchronous, paid, autonomously retriable, or post-submit-reconcilable work. A strictly bounded immediate Portal call may remain under its live `ModelGrant` or `CallGrant`; it still needs a committed road decision, fresh byte-time `EgressDecision`, budgets, dispatch/security events, quarantine, and no silent fallback, but it does not invent a `ServiceJobAttempt` merely to represent an immediate return. ```text typed demand → local classification and bounded Context → Privacy Cut when required → exact provider, model, endpoint, purpose, and spend candidate → fresh payload-bound EgressDecision → reserve Tithe/Toll ceilings and persist one ServiceJobAttempt identity → commit SUBMITTING with idempotency and reconciliation identity → one credential-scoped Portal adapter → remote response quarantine and validation → known terminal receipt or INDETERMINATE plus provider lookup → reconcile usage, cost, custody, and terminal state ``` If the indexing job retries semantically, redirects, falls back, substitutes a model, changes a gateway route, or chooses another destination, it begins a new LychD-owned attempt. Persist that attempt's identity and decision before sending bytes. Exact transport redelivery can remain within the same attempt only if the adapter proves atomic server-side same-key/same-payload replay under the same sealed bytes, target, and external or idempotency identity, or proves there was no prior effect. Every physical send still needs a fresh EgressDecision and bounded disclosure use. Otherwise, after a crash or timeout in `SUBMITTING`, look up that identity. If the provider cannot establish the outcome, retain `INDETERMINATE` instead of resubmitting blindly. Disable a gateway's automatic fallback, load balancing, and account/provider pooling. Each eligible fallback member needs its own pinned attempt. An unplanned internal switch breaks the integrity of the account and leaves an indeterminate receipt; it cannot be counted as successful resilience. When reading the result, ask which service actually produced it. A gateway's brand cannot answer that question. Mark provider, model, region, retention, and training facts `gateway_asserted` unless independent signed or contractual evidence establishes them. TLS authenticates the gateway endpoint, not its hidden selection. If policy depends on one of those facts, use a direct provider or independently verifiable routing evidence. Material cannot take a route whose custody chain cannot be disclosed or constrained as its policy requires. ## Reach placement The [Reach deployment matrix](../../compositions/reach/deployments/index.md) changes where the server Portal credential lives, never what authorizes it: - `reach.home.public@1` keeps the provider gate and credentials in the separated home service; - `reach.edge-home.public@1` keeps them at home—the VPS Discord edge receives none; and - `reach.vps.public@1` gives one isolated VPS egress adapter only its exact provider/peer credential and destinations. For every profile, a human coding subscription remains outside the bot. The practical starting road is one direct server API, one low-cost model, one hard budget, no fallback, and a public corpus-only E2E. Add another model or remote A2A only after the first route's custody, receipts, quality, and cost are measured. A gateway or aggregator additionally waits for the multi-hop target binding, independent route evidence, and receipt described above to be delivered. ## Candidate register — 2026-08-11 This register explains the current recommendation. Recheck the linked primary source before spending or sending data. | Candidate | Road | Current use in LychD | Position | | --- | --- | --- | --- | | Direct OpenAI, Anthropic, Google, or other upstream API | direct server API | intended production road for an exact eligible workload | Preferred; use provider-issued server credentials and pin the real model/destination | | [DeepInfra](https://deepinfra.com/pricing), [Groq](https://groq.com/pricing), [Together](https://www.together.ai/pricing), or [Fireworks](https://fireworks.ai/pricing) | direct model-hosting API | no first-party LychD profile | Comparison pool only: benchmark the exact model, custody route, terms, limits, and dated price; no provider is a current winner | | [OpenRouter](https://openrouter.ai/docs/faq) | metered aggregator and optional BYOK | built-in provider alias exists; dispatch remains quarantined | Useful catalogue; pin one `provider/model` candidate per LychD attempt, disable shared/internal fallback, and treat returned upstream identity as gateway-asserted | | [Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/), [Vercel AI Gateway](https://vercel.com/docs/ai-gateway/), [Pydantic AI Gateway](https://pydantic.dev/docs/ai/overview/gateway/) | BYOK and/or managed gateway | no first-party LychD profile | Candidates when their policy, observability, region, or budget control justifies another custodian | | [OpenCode Go](https://opencode.ai/docs/go/) | limited coding subscription with documented API endpoints | no admitted profile | Attractive operator experiment; unattended or third-party use waits for terms that unambiguously permit it | | ChatGPT/Codex, Claude, Google AI, GitHub Copilot, and similar human plans | operator seat | external local coding runtime only | Keep their OAuth/session on the operator's machine and outside Reach, Portal adapters, and public A2A | | [OmniRoute](https://github.com/diegosouzapw/OmniRoute) | self-hosted multi-provider gateway, free-tier router, and optional subscription/API bridge | upstream reference candidate; no admitted profile | Study its catalogue, cost telemetry, circuit breakers, and routing; refuse `auto`/silent fallback, quota pooling, remote OAuth, MITM, memory, and public exposure for any LychD trial | | [openusage](https://github.com/janekbaraniewski/openusage) | local usage dashboard | reference candidate only | Prefer the read-only telemetry pattern; a dashboard observes quota and cost but grants no routing authority | | [AIUsage](https://github.com/sylearn/AIUsage), [CLIProxyAPI](https://github.com/router-for-me/CLIProxyAPI), and its dashboards | dashboard plus optional subscription/API proxy | Lab references only | Separate harmless local observation from credential switching, translation, LAN exposure, or subscription pooling; none is an admitted Portal | | [Sub2API](https://github.com/Wei-Shaw/sub2api) | subscription-to-API gateway and account pool | rejected production candidate | Its own project warns of upstream Terms-of-Service risk; do not use it to serve Reach or third parties | The first implementation target is direct-only: one exact server API, provider, endpoint, region, model revision, credential, data policy, hard budget, and no fallback, selected only after its maintained receipt closes every field above. No commercial candidate has completed that selection gate yet. Price or reputation alone does not nominate a first profile; every comparison and quality-escalation candidate remains non-canonical until an exact dated receipt exists. Cloudflare, Pydantic, Vercel, and OpenRouter remain unresolved multi-hop comparisons. They may be benchmarked for DLP, accounting, OpenTelemetry, catalogue reach, or cost without being stacked or promoted. OmniRoute is the named gateway/dashboard candidate; `openusage` and AIUsage are close dashboard comparisons; CLIProxyAPI is a proxy engine AIUsage can manage; Sub2API is a full subscription-quota gateway. Their similar surfaces conceal different authority and risk. Read-only usage collection is a different road from moving OAuth credentials and model traffic through a new service. An OmniRoute or CLIProxyAPI Lab trial must pin a reviewed revision, bind loopback only, add an independent firewall, require non-default management and client API authentication, and use only synthetic public fixtures plus one disposable, trial-scoped API key. Run an ephemeral profile with no subscription/account credential, persistent volume, raw prompt/response log, semantic or prompt cache, cloud sync, backup, credential import, or retained credential store. Disable remote/LAN management, browser cookies, subscription OAuth, account/quota pooling, provider fingerprint impersonation, stealth/obfuscation, transparent MITM, `auto`/Fusion/pipeline routing, memory, and remote mode. Destroy the profile and revoke the key after the trial. Those features change legal basis, destination, payload, or credential custody and cannot be repaired by calling the gateway local. No such trial is a Reach or production Portal profile. ## Economical fan-out Parallelism belongs to an exact versioned Workflow/Pattern policy above the road, not Dispatcher and not an opaque provider switch. Dispatcher binds an eligible ready capability; it does not judge quality or price. The Pattern may: 1. perform retrieval, deterministic redaction, classification, caching eligibility, and cheap routing locally; 2. use one primary worker for ordinary work; 3. add two to four heterogeneous low-cost reviewers only when diversity can change the decision; 4. invoke one stronger critic on disagreement, failed validation, or high consequence; and 5. stop on the admitted request, token, concurrency, time, and spend ceilings. Do not run all-to-all review or many identical frontier branches by default. Cache only material whose classification and audience allow that exact reuse. A node hop carries an admitted typed task and evidence bundle; it never carries a reusable human subscription token, ambient Sigil, or raw private Context. --- title: "Coven" plain_name: "Model Groups" section: "Sepulcher > Animator" status: "Available" original: https://hexanomicon.dev/sepulcher/animator/coven/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/coven/ --- # Coven (Model Groups) ## Plain-English summary (Snayu) **What it is:** Explains Model Groups (Covens): a named systemd target for two or more compatible local model services. Grouping is a convenience; hardware conflicts are declared separately. **Why it matters:** Read this when grouping local models or debugging which models can run together. - Membership comes from the groups field; conflicts come from conflict_domains. - A group with internally conflicting members fails closed. - Starting a group target directly bypasses the Stage Manager; reserve it for recovery. **Status:** Available. Declared conflict topology and target switching are Available. ## Original text (Hexanomicon) > _Under one name, the Coven gathers its fires._ Use a **Coven** to give compatible local services one operator name. When two or more [Soulstones](./soulstone/index.md) share a group, binding emits a named systemd target for them. A Soulstone requests membership through `groups`. It declares hardware incompatibility separately through `[concurrency].conflict_domains`; grouping services cannot decide which ones may coexist or be evicted. One member emits no target. Different groups create no coexistence promise. Members' effective conflict sets must not overlap; an internally conflicting Coven fails closed. The current Rune schema has no `alliances` setting and rejects that field. One Rune may participate in more than one formation: ```toml name = "echo" groups = ["conversation", "studio"] ``` That still names one service instance. Starting `lychd-coven-conversation.target` and `lychd-coven-studio.target` does not create two copies, and common membership does not prove the complete union fits. The compiled conflict graph remains the executable coexistence law. The later [capability and resource design](capabilities.md#runes-runes-in-groups-and-placement) would let a `CapabilitySetRequest@1` use that name as an operator convenience. Orchestrator would first expand it and validate every member against measured envelopes and placement profiles. Membership itself supplies no resources, routing, lease, or egress authority. Even a serialized convergence has non-atomic physical effects: partial change still needs compensation, restoration, and containment. !!! warning "Operator break-glass surface" Starting or stopping a generated Coven target directly propagates through its compatible Animator targets. This bypasses Orchestrator admission, lease drain, stale-world validation, readiness, and compensation. Reserve it for host administration or recovery. For inspection, activation requests, priority, switching settings, and Reactor outcome recovery, continue to [Runtime transitions](runtime-transitions.md). The old operation fragments remain here so existing links still find that passage. --- title: "Runtime transitions" plain_name: "Switching and loading models" section: "Sepulcher > Animator" status: "Partial" original: https://hexanomicon.dev/sepulcher/animator/runtime-transitions/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/runtime-transitions/ --- # Runtime transitions (Switching and loading models) ## Plain-English summary (Snayu) **What it is:** Operator guide for changing which local models are running: inspecting status, requesting a transition via HTTP or the Model Status Board, and recovering from interrupted switches. **Why it matters:** Read this before switching models on a running host or changing the transition logic. - The Stage Manager closes new passes, drains leases, applies one change, then requires an honest warm state. - Requests need the local credential, the orchestrator:transition scope and a CSRF cookie/header. - An uncertain change stays fenced off for operator recovery. **Status:** Partial. Safe transitions work locally; resource-aware preloading is Designed. ## Original text (Hexanomicon) A local capability may be declared yet unable to answer until its service starts or another model releases the required iron. This guide follows the operator's request through inspection, Orchestrator admission, readiness, and recovery. [Coven](coven.md) names compatible service groups; the transition acts on exact capabilities and their compiled conflict neighborhood. Use the [Nexus](../../divination/altar/nexus.md) for the Altar projection or the bounded HTTP operations below. The source and receipt limits remain in [State of Work](../../state-of-the-work.md#safe-runtime-transitions). ## What the Nexus Shows The [Nexus](../../divination/altar/nexus.md) presents capability readiness to the operator. [Capabilities](capabilities.md#readiness-is-not-compatibility) defines the six underlying phases; a displayed label is an observation, not a lease or permission to perform a transition. ## The Transition Contract The [Orchestrator](../../adr/23-orchestrator.md) owns every application-requested transition: 1. refresh the target and compute its exact affected conflict neighborhood; 2. close lease admission and the Run claim gate; 3. drain affected leases; 4. revalidate configuration and the loaded Scribe-owned unit graph; 5. request one physical transaction or supported runtime-native activation; 6. require honest `WARM`, then reopen only under the restoration law. A parked requester holds no lease. Refusal before effect or an exact restoration reopens admission. An uncertain mutation remains contained for operator recovery. ## Inspect and Request Retrieve the dedicated local credential with `lychd access` as described in [The Awakening](../../summoning.md#the-awakening). Each command below uses `--user magus` so curl prompts for the password. Enter it at that prompt; keep it out of URLs and command arguments. ```bash curl --user magus -fsS http://localhost:7134/orchestrator/queues | jq curl --user magus -fsS http://localhost:7134/orchestrator/status | jq '.mutation_containment' ``` The queues response exposes `depth`, `active`, `paused`, and each lease's `capability_key`, `holder`, and `priority`. `mutation_containment` is normally `null`; a reason means later transitions remain fenced. List the exact registered keys before requesting a transition: ```bash curl --user magus -fsS http://localhost:7134/orchestrator/status \ | jq -r '.all_capabilities[].capability_key' ``` Copy an eligible local key from that observation. The example below uses Summoning's `atelier:chat:first-model`; replace it if your declaration differs. Read-only endpoints require `altar:read`; activation requires `orchestrator:transition`. The current same-host middleware assigns the fixed `magus:*` scope floor after verifying the local credential. This is not remote authentication. Production POSTs also require a matching CSRF cookie and header. Obtain their exact names from the Altar status response, retain the cookie from that same GET, then submit: ```bash LYCHD_URL=http://localhost:7134 LYCHD_CAPABILITY=atelier:chat:first-model LYCHD_COOKIE_JAR=$(mktemp) LYCHD_STATUS=$(curl --user magus -fsS -c "$LYCHD_COOKIE_JAR" "$LYCHD_URL/api/v1/altar/status") LYCHD_COOKIE_NAME=$(printf '%s' "$LYCHD_STATUS" | jq -r '.csrf.cookie_name') LYCHD_HEADER_NAME=$(printf '%s' "$LYCHD_STATUS" | jq -r '.csrf.header_name') LYCHD_CSRF=$(awk -v name="$LYCHD_COOKIE_NAME" '$6 == name {print $7}' "$LYCHD_COOKIE_JAR") test -n "$LYCHD_CSRF" && curl --user magus -sS -i -X POST -G \ -b "$LYCHD_COOKIE_JAR" -H "$LYCHD_HEADER_NAME: $LYCHD_CSRF" \ --data-urlencode "target=$LYCHD_CAPABILITY" --data-urlencode "priority=70" \ "$LYCHD_URL/orchestrator/activate" rm -f -- "$LYCHD_COOKIE_JAR" unset LYCHD_STATUS LYCHD_CSRF ``` Keep this operation on the same-host boundary. A failed scope or CSRF check is a refusal, not a reason to disable the guard or expose the endpoint remotely. - **202**: the completed transition plan, after target readiness convergence or a confirmed warm, open no-op. This endpoint waits for the transition before returning. - **400**: invalid `admission_timeout_s`. - **409**: a hard swap was declined because priority was below `min_priority_for_hard_swap`, or an admission window expired. Priority refusal carries the plan and threshold; admission expiry carries `code` and readable `detail`, as described in [Limit admission time](#limit-admission-time). After **202**, inspect the selected capability in Nexus or `/orchestrator/status` again, including `mutation_containment`, before making a later decision. Readiness can change after the response; any subsequent containment reason keeps later transitions fenced. Priority is **higher = hotter**. This endpoint is an explicit operational surface, not a side door for an Agent or extension to bypass ordinary dispatch. ## Limit admission time When a transition would no longer be useful after a short wait, add `--data-urlencode "admission_timeout_s=10"` to the activation command. This optional query value counts seconds from entry to the activation handler. It must be finite and nonnegative; `0` declines immediately. Omission adds no caller-owned admission cutoff. Treat the cutoff as a limit on admitting the change. It covers queueing, planning, lease drain, and observation before activation. It ends when Orchestrator invokes the actuator or adapter, or confirms readiness on a path requiring no activation. If a capability is already warming, it must become honestly ready within this window. After admission, the request continues waiting for settlement, even beyond the cutoff. Planning, drain, and convergence retain their separate safety budgets. A local safety deadline that expires first keeps its existing failure classification. Requests for the same capability and priority share one in-flight transition. The first request owns its admission cutoff. A follower may limit how long it waits for admission, but cannot cancel the owner's work. A nonexpired follower that joins already-admitted work waits for settlement. Thus an untimed follower may inherit a timed owner's refusal, while a timed follower cannot shorten an untimed owner's budget. Different priorities create separate requests. Admission refusal returns **409** with readable `detail` and one of these codes: | `code` | Meaning | | --- | --- | | `transition_admission_expired` | The request arrived expired, or the transition owner's admission window ended. | | `transition_admission_wait_expired` | Only this follower's wait ended; the shared transition may continue. | Invalid admission durations return **400**. A refused request cannot use its admission cutoff to abandon required cleanup, and disconnecting does not prove that physical work stopped. Inspect current status before retrying. This request option is separate from Codex switching settings and does not set a deadline for the whole operation. ## Switching Settings Set these fields beneath `[orchestration.switching]` in the Codex. | Field | Default | Meaning | | :--- | :--- | :--- | | `actuator` | `"host-reactor"` | Managed-container mediated actuation; `"systemd"` is a host-adapter test mechanism, not a host-native Core profile. | | `host_reactor_dir` | XDG trigger inbox | Absolute writable intent inbox; sibling journal is derived read-only. | | `policy` | `"declared-conflicts"` | Select exact active conflict neighbors; `"evict-idle"` is a compatibility alias. | | `min_priority_for_hard_swap` | `40` | Decline colder hard swaps. | | `planning_timeout_s` | `30.0` | Bound all managed-runtime observations together for each preflight or replan. | | `drain_timeout_s` | `120.0` | Bound lease drain. | | `warmup_timeout_s` | `180.0` | One absolute readiness-convergence budget. | | `reactor_ack_timeout_s` | `120.0` | Bound only the unclaimed Reactor phase. | Unknown policy values fail at startup. Coven and alliance labels never alter the compiled conflict graph. The Host Reactor records exact outcomes: `.declined.json` proves no effect, `.restored.json` proves the prior world, `.contained.json` fences an uncertain physical outcome, `.processing.json` is claimed and nonterminal, and `.rejected.json` is invalid delivery. A systemd unit may remain active while the probe sees it absent; reconcile that mismatch before retrying. ## Recover an interrupted soft activation Before activating a model through a runtime-native API, the Vessel writes `runtime-guard/pending.json` in the Crypt. An unfinished record means the activation's physical outcome still needs reconciliation. Both actuator profiles block startup before any Run queue connects while that record remains. Restarting, changing configuration, or observing a warm model cannot clear it. The owner-only `0700` directory is provisioned by `lychd init` and mounted read-write by the generated Vessel binding. Existing installations need updated initialization and binding before using this path. Missing or unsafe storage makes startup refuse. For recovery, establish and keep both the Vessel and the record's target Animator stopped under a separately authorized [operator recovery plan](../../summoning.md#close-the-rite). The current public stop command cannot establish that state for an active Vessel; [State of Work](../../state-of-the-work.md#core-cli-rites) records the lifecycle limit. If the stopped state cannot be established, keep the pending record and admission fenced. Once those prerequisites hold, read the exact `activation_id` from that owner-only record, then invoke the bounded host helper: ```bash lychd reactor recover-soft ACTIVATION_ID ``` Supply the record's exact 32-character `ACTIVATION_ID`. The hidden helper performs no start or stop itself. It validates the record against current declarations, attests the Scribe-owned loaded topology, and verifies that both Vessel and affected runtime are stopped with no main or control processes and no pending systemd work. Only then can it clear that exact record. Changed configuration, corrupt records, unknown ownership, live or uncertain runtime state, and persistence errors refuse release. Keep the record and reconcile the reported discrepancy; manual deletion would remove the evidence without proving recovery. Host Reactor `.contained` and `.processing` records retain a separate recovery boundary. ## Tune With Intent - Raise `min_priority_for_hard_swap` to resist disruptive swaps. - Change planning, drain, and warm-up deadlines to match measured local observation and convergence. - Mark support services `persistent_resident = true` to keep them outside conflicts and eviction. - Give incompatible managed Soulstones a shared conflict-domain label; use explicit `[]` only after measuring safe coexistence. `[orchestration.whim]`, `idle_evict_after_s`, and `preload` are not current settings; unknown configuration is rejected. Resource-aware preloading and eviction remain designed. The current graph is not a VRAM capacity solver. [State of Work](../../state-of-the-work.md#declared-conflict-topology) records the available conflict contract; [safe runtime transitions](../../state-of-the-work.md#safe-runtime-transitions) remain partial, including soft-load recovery and real-host proof. ## Queue and Routing Context `[server.jobs]` fixes two in-process queues: `runs` uses `interactive_concurrency = 2`; `rites` uses `background_concurrency = 4`. These settings bound tasks, not CPU, memory, admission, or preemption. The raw SAQ administrative UI is disabled; setting `admin_ui_enabled = true` is refused during startup. Inspect queues through the curated Altar projection and the authenticated endpoints above. `[orchestration.routing]` maps Intent source to queue and doctrine priority: | Source | Queue | Default priority | | :--- | :--- | :--- | | `default` | `runs` | `50` | | `cli` | `runs` | `50` | | `bridge` | `runs` | `70` | | `rite` | `rites` | `20` | Each rule accepts priority 0–100. Queue execution belongs to [Workers (14)](../../adr/14-workers.md); these values matter here only because transition policy receives the Run's doctrine priority. --- title: "Extensions" plain_name: "Plug-in areas overview" section: "Sepulcher" original: https://hexanomicon.dev/sepulcher/extensions/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/ --- # Extensions (Plug-in areas overview) ## Plain-English summary (Snayu) **What it is:** A map of the fifteen plug-in areas (Extension Domains) where LychD can grow, such as web fetching, workflows, evaluation, training, voice and vision, and how extension packages register into them. **Why it matters:** Start here before writing or reviewing any extension, to learn which area owns which job and what registering a package does and does not allow. - An area on the map is a responsibility boundary, not a promise that code exists or works. - Extension packages are selected explicitly and register via register(context); there is no scanning, hot-load or hot-unload. - Changing extension code or selection needs a new body generation; no area can promote its own result or grant itself privileges. ## Original text (Hexanomicon) > _Fifteen arts gather beneath one skin._ Search the web, judge an artifact, train a model candidate, carry a voice: different work needs different organs. The fifteen **Extension Domains** below say where each responsibility belongs. They map jurisdictions; a name on the map promises neither an installed package nor delivered behavior. ## The Federation of Fifteen | Name | Work it owns | | --- | --- | | [Oculus](oculus.md) | **Evidence and observability:** follow bounded observations, derivations, correlations and explicit gaps back to their sources. | | [Tether](tether.md) | **Private reachability:** open exact private paths. | | [Veil](veil.md) | **Hostile ingress:** terminate TLS and protocols, canonicalize metadata and admit declared routes. | | [Ward](ward.md) | **IAM and authority:** resolve principals and recheck current permission over an exact object or effect. | | [Spellweaver](weaver/index.md) | **Workflow:** validate Spell contracts and Scroll/Pattern lifecycle, admit castings and preserve continuity and logical time. | | [Scout](scout.md) | **Web acquisition:** bound search, fetch, extraction, rendering and interaction. | | [Smith](smith.md) | **Assimilation:** re-express admitted material as attributable candidate code. | | [Soulforge](soulforge/index.md) | **Training:** bind admitted corpus, base digest, objective, Recipe, Training Run, evaluation and candidate-weight lineage. | | [Drift](drift/index.md) | **Evaluation:** test exact subjects against declared goals through versioned trials and calibrated findings that retain uncertainty. | | [Toll](toll.md) | **Economics:** distinguish quote, authorization, settlement, delivery, refund and reconciliation. | | [Prism](prism/index.md) | **Visual and spatial grounding:** bind observations, transformations, reconstructions and generated forms to exact sources and derivatives, keeping them distinct. | | [Echo](echo.md) | **Speech lifecycle:** carry capture, transcription, synthesis and delivery with origin, consent and outcome intact. | | [Shadow](shadow/index.md) | **Possibility lineage:** hold isolated candidate worlds with exact parentage, evidence and terminal disposition. | | [Mirror](mirror.md) | **Identity:** preserve Persona lineage, hydration provenance and attribution. | | [Legion](legion.md) | **Distributed embodiment:** fence delegation across operator-owned bodies while each retains authority over its iron. | Consider a source acquired for a candidate change. Scout can obtain the source, but acquisition cannot establish its truth or authorize a wider use. Smith can prepare the candidate, Shadow can hold an isolated alternative, and Drift can evaluate it. The responsible owner must still judge whether it may become an effect; none of those contributors can promote its own conclusion or grant privilege. The same division holds at the system's edges. A private path or admitted route leaves application authority with the service behind it. Oculus observes records without replacing their owners, and Mirror attributes identity without authorizing the caller. Cooperation joins the offices through these contracts. ## Domain, package, and provider | Term | Place in the body | | --- | --- | | **Extension Domain** | One of the fifteen stable user-facing jurisdictions through which the Lich may grow | | **extension package** | Explicitly selected built-in or private Crypt code admitted through `register(context)` and shaped stores | | **Registrant** | Core or one selected extension package performing registration under a host-assigned `registrant_id` | | **Contribution** | A typed addition admitted by one explicit receiving Core office or Extension Domain while that owner keeps authority | | **Provider** | A concrete engine or service supplying mechanism behind a typed contract | A package can register contributions with several Core offices or Domains. Conversely, one Domain can receive several packages or Providers. These are different relationships, so **Activation** must name a concrete package or declared instance rather than an abstract Domain. [Compositions and Products](../../compositions/index.md) use and package the resulting contracts while keeping their own responsibilities. ## How an organ enters For a first contribution, follow [Extension authoring](authoring.md) through the existing Phoenix registration shim, typed Rune, Quadlet contributor, and configuration test. The coupled pre-v1 **Extension Protocol** admits explicitly selected built-in and private Crypt packages through `register(context)`; it neither scans the environment nor discovers arbitrary entry points. Built-ins evolve atomically with Core, while private packages accept refactor breakage. A versioned independent extension-package API and conformance suite remain future work, so an external protocol is the present boundary where process or lifecycle coupling is unacceptable. After assembly, that selection stays fixed for the Vessel process. There is no hot-load, hot-replace, or hot-unload. Changing code, package selection, dependencies, or contribution contracts requires a new body generation under [Evolution](../../adr/18-evolution.md). Compatible Phylactery records and explicit [Reanimation](../phylactery/reanimation.md) provide continuity into it; volatile extension objects do not migrate. The boot boundary is enforced, while automated Evolution remains Designed. [ADR 05](../../adr/05-extensions.md) owns admission and compatibility. [State of Work](../../state-of-the-work.md#extension-activation-contributions) records the five-store surface, its v1 capability attribution, and the remaining lifecycle limits. Selection grants shaped registration—not route, secret, workflow, migration, workload, effect, or automatic activation authority. ## How an organ earns permanence Authorship, tests, and evaluation produce a candidate and evidence for the target owner's promotion decision. Smith, Shadow, and Drift cannot promote their own conclusions. Required HitL or eligible policy supplies authorization; packaging, migration, activation, and verification remain separately owned effects. Follow the [Assimilation passage](smith.md) to prepare that handoff with its failures and uncertainty still attributed. Automated Smith and Forge promotion is **Designed**, not delivered. [State of Work](../../state-of-the-work.md#smith-forge-promotion) owns delivery; the [Assimilation Covenant](../../adr/35-assimilation.md) owns the fuller passage from bounded candidate work to an accepted organ. --- title: "Smith" plain_name: "Code assimilation agent" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/smith/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/smith/ --- # Smith (Code assimilation agent) ## Plain-English summary (Snayu) **What it is:** The planned agent (Smith) that turns an admitted outside pattern, protocol, defect or need into candidate code, tests and docs inside an isolated lab, with full source, license and authorship records. **Why it matters:** Read this before building anything that learns from external code or proposes changes to LychD itself, so you keep candidates separate from promotion. - Source must be admitted with known identity, provenance and license before it can support a promotion request. - The author agent writes only to permitted lab paths; no access to the live checkout, secrets, migrations or publishing. - Tests, evaluation (Drift), approval (HitL), packaging and activation are separate owners; no self-certified loop. **Status:** Designed. No candidate-author agent or end-to-end assimilation path is delivered. ## Original text (Hexanomicon) > _Purpose is the hammer._ > > _Pattern is the anvil._ > > _Consent is the seal._ > > _What is worthy becomes organ._ Suppose foreign craft exposes a useful pattern or a defect the local body should learn from. **Smith**, the Assimilation Extension Domain, defines a **candidate-author Agent** for that work. Given an admitted pattern, protocol, defect, or need, the Agent can prepare code, schemas, migrations, tests, documentation, and packaging inputs in a bounded Lab coordinate. Attribution makes the result examinable. The candidate has not yet become an organ of the running body. **Maturity: Designed.** No candidate-author Agent or end-to-end Assimilation path is delivered. [ADR 35](../../adr/35-assimilation.md) owns the architecture and full protocol; [State of Work](../../state-of-the-work.md#smith-forge-promotion) owns delivery. ## The hammer has no crown First establish what material the author may use. [Scout](scout.md) can acquire exact source, but its custody owner must validate and admit the bytes before Smith receives them. Another source/custody route can provide the same settled handoff. The Assimilation Dossier then carries the source identity and revision, acquisition path, license and notice duties, local base, transformations, Smith/model/tool/human authorship, unresolved gaps, and maintenance lineage. Without established identity, provenance, or license, material may inform study but cannot support a promotion request. The candidate-author Agent may read admitted source and relevant Core code, then write only to permitted Lab paths. It can submit typed requests, but receives no ambient access to the active checkout, dependency locks, secrets, migrations, package publication, or host lifecycle. The declared harness records deterministic facts such as lint, type, build, or test results; [Drift](drift/capability-claims.md) owns calibrated quality and comparative claims. The required [HitL](../../adr/25-hitl.md) or eligible policy decision supplies promotion consent. [Forge](../../adr/17-packaging.md) constructs package or image artifacts from reviewed inputs, while Codex, migration, and lifecycle owners perform their own effects. A passing check supports only its declared predicate; ADR 35 keeps the exhaustive authority matrix. ## Protocol stages, not a second coordinator ```text exact intent and admitted source → Dossier and isolated Lab candidate → deterministic receipts and Drift findings → promotion request → required HitL/policy and target-owner decisions → owned packaging and live effects → reassembly and observation ``` The path is compact, but its records are not disposable. Source revision, license, transformations, candidate parentage, tools and providers, human edits, checks, failures, and the final decision remain attributable. The candidate-author role needs an application to give it executable work. An exact application Pattern must select a registered AgentSpec satisfying that role; Spellweaver can then admit and perform its pinned Scroll. Verification, consent, packaging, migration, and activation remain later effects of their respective owners, each receiving a settled typed request. Smith supplies neither a Composition nor a Suite nor another coordinator. No exact application Pattern or Suite currently defines end-to-end Assimilation, so this reference protocol remains non-executable. Each arrow above is a governance dependency between separately owned, already-settled records. It is not one hidden Run that waits for, retries, cancels, recovers, or jointly settles every owner. A future application Pattern may own one bounded candidate-author job; a separately named Suite is required if one reusable promise must actively coordinate multiple Composition Invocations. ## Repair and evolution The [Creation workflow](weaver/creation.md) gives candidate authors a repeatable method from intent and evidence through construction, verification and documented disposition. The wider [Ouroboros](weaver/ouroboros.md) map returns consequences to evaluation and separately admitted correction, including teaching, training and later body generations. A candidate-author Agent may prepare a pinned update or propose a bounded correction in [Shadow](shadow/index.md). Each revision retains parentage and repeats every invalidated check; the author cannot certify its repair or widen its budget. If a required migration rehearsal still fails when that budget expires, the attempt records explicit non-completion, preserves the Dossier, candidate, and failure receipts, and leaves the running body unchanged. Any later attempt receives a new candidate identity and re-enters the affected gates. No autonomous loop may join authorship, judgment, consent, packaging, migration, or activation into a self-certified result. --- title: "Spellweaver" plain_name: "Workflow engine" section: "Sepulcher > Extensions" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/weaver/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/ --- # Spellweaver (Workflow engine) ## Plain-English summary (Snayu) **What it is:** The workflow engine (Spellweaver) that validates immutable workflow versions (Scrolls), admits their execution, and keeps them intact through pauses, resumes and endings. Lists the current fixed workflows and how to configure the Chat workflow. **Why it matters:** Read this first when working on anything that runs a workflow, or when configuring which model the Chat workflow uses in lychd.toml. - A Pattern is a workflow lineage; a Scroll is one frozen version; a Run records one execution and keeps its chosen version forever. - The registry is fixed in source: bridge_chat revisions 1-5 and delegated_rite revisions 1-2. - Chat revision 2 pins an exact capability key, or ranks two ready local routes by weight at admission time. **Status:** Partial. Fixed local workflows run; contribution, scheduling, parallelism and migration are not delivered. ## Original text (Hexanomicon) > _Through motion and silence, the thread remembers its course._ Once work has chosen a score, **Spellweaver** keeps it intact through execution, pause, return, and ending. It is LychD's singular logical workflow jurisdiction: it validates immutable **Scrolls** and admits their casting. Code and existing paths retain the short name `Weaver`. A **Pattern** names the score's lineage; a Scroll fixes one immutable revision. Within it, an Agent call, Gate, tool, effect, wait, or delegation may deserve an independently named **Spell**. A Scroll-local station places that Spell's exact contract, fixing the relationship before work begins. Future packages may contribute Spell contracts and Scroll declarations through separate Spellweaver-shaped stores. Executable implementations and adapters remain separate Extension or effect-owner registrations; publication and activation are not implied by contribution. The Core office retains workflow authority. Spellweaver never inherits the policy or physical control of the offices it sequences. [ADR 28](../../../adr/28-workflow.md) owns the complete contract. ## From Product to performance A [Composition or Suite](../../../compositions/products-and-suites.md) publishes the score for its work. A Product packages that choice; application records, judgment, and effects remain with their owners. - **Pattern** is one named executable-score lineage published by its application owner: normally a Composition, or a Suite for coordination only; one immutable revision is a **Scroll**. The two delivered Core Patterns are an explicit retained pre-Portfolio exception. - **Spell** is one independently named semantic action contract; a station places it in that Scroll. - **Invocation** opens one bounded [Circle](../../../divination/altar/circle.md). - **Casting** performs the exact Scroll inside that Invocation. - **Run** is the durable execution and ledger identity of that Invocation. A Suite Casting opens one parent coordination Invocation/Run from its Suite-owned Scroll and separate child Composition Invocations/Runs. The parent owns correlation and aggregate settlement, never a member's records, judgment, consent, credentials, or effects. Graph is the typed topology that advances Scroll state among Spell placements. The [Loom](../../../divination/altar/loom.md) is a read-only projection of its declared truth. The current fixed registry has no independent Spell catalogue or teaching surface. The current registry is fixed and source-defined: ```text bridge_chat@1 (default) / bridge_chat@2 (configured exact capability) WeaveContext → Converse → AwaitConsent? → ProjectReply → End bridge_chat@3 (configured public Archive and exact capability) RecallNotes → AnswerNotes → SettleNoteAnswer → End bridge_chat@4 (configured Scout and exact local capability) PreparePageReview → AwaitPageConsent → AcquireAndAnswerPage → SettlePageAnswer → End bridge_chat@5 (configured semantic generation and exact local capability) RecallSemanticNotes → AnswerSemanticNotes → SettleSemanticAnswer → End delegated_rite@1 (default) / delegated_rite@2 (configured exact runtime) DispatchDelegate ⇢ ProjectDelegatedReply → End ``` Admission commits the chosen workflow name and exact manifest snapshot with the Run. That choice lasts: resume looks up the stored score and never routes the Intent again. The registry is executable substrate, not a general workflow platform. `delegated_rite@1` exercises only the deterministic reference adapter. Revision 2 pins an [explicit registered runtime and profile](delegated-agents.md#pin-effective-configuration) for new admissions and retains that selection across resume. Neither revision supplies foreign-runtime containment or an execution plane. ## Choose a Bridge capability In the Codex's `lychd.toml`, select the registered Bridge revision and the exact capability key from your declared runtime inventory: ```toml [weaver.bridge] revision = "2" capability_key = "my-runtime:chat:my-model" ``` Replace the example key with your runtime's key. It identifies the Animator, capability family, and model together; a shared model name alone cannot pin a runtime. The selected capability must support chat and tools. Loading Settings validates the selector's shape without contacting an engine; Dispatcher checks the actual declaration, readiness, and policy at execution. An unknown, incompatible, or unavailable target refuses the turn rather than choosing another runtime. After restart, this configuration selects revision 2 for new Bridge admissions. Each Run records its choice before queue publication and keeps it through hardware retries and consent pauses. Later configuration changes or removal cannot redirect that Run or an idempotent retry. Without the section, new turns use revision 1's eligible-pool selection; both revisions remain registered for retained work. The key identifies a capability, not a model artifact or runtime configuration fingerprint. The general Resolution Lock is a separate contract. Revision 3 adds bounded public-note recall with transient Context injection and no tools. Its [Archive configuration and authority checks](../../../divination/altar/bridge.md#public-note-answers) are separate from revision 2's tool-capable conversation. Revision 4 adds one explicitly declared public page, native consent and transient local-model Context. Its [Scout configuration](../scout.md#public-page-answers) selects a qualified static runtime and finite budgets. Neither profile turns a Scroll or source-authored text into tool authority. Revision 5 adds read-only answers from the independently enabled Archive semantic generation, without tools or earlier conversation history. Its [semantic generation configuration](../../../divination/altar/bridge.md#answer-from-a-semantic-generation) binds the exact generation, explicit threshold and finite recall bounds to one exact local Chat capability at boot. The selected Run retains that binding; opening the sources-only recall focus does not change the configured casting. ### Prefer a ready route at admission Revision 2 may instead rank exactly two declared local Chat routes: ```toml [weaver.bridge] revision = "2" [weaver.bridge.preference] schema_version = 1 routes = [ { capability_key = "local-a:chat:model-a", weight = 9 }, { capability_key = "local-b:chat:model-b", weight = 1 }, ] ``` Replace both keys with literal identities from the declared inventory. Omit `capability_key` from `[weaver.bridge]` when using `preference`; revision 2 accepts exactly one of them. Both routes, including a disabled one, must declare local Soulstone Chat with tool support. Revisions 3, 4 and 5 retain their exact-key configuration and reject `preference`. Weights are integer preferences from 0 through 1,000,000, with a positive total; they are not traffic percentages, measured quality, or additional authority. Zero disables eligibility and omits that route's retained phase and observation time. Admission directly refreshes each Animator hosting an enabled route once, as a complete Animator batch, within one cooperative five-second bound. That batch may include a disabled capability sharing the same Animator. After the batch, only observed-warm routes with unchanged declarations and an unchanged, open admission generation remain eligible. Highest weight wins; an equal weight uses ascending literal capability key. This observes readiness without activating a model, preparing a grant or entering inference. Malformed or failed probes abort admission; a valid non-warm observation excludes that route. An empty eligible set returns a content-free 503 code before retaining a Run or user turn. The admission decision becomes part of the Run: complete policy, digest, dated observations, and one exact selected key. An idempotent replay returns it before any new probe, while changed configuration applies only to new admissions. Execution and restart keep the key under the existing Bridge tools, consent, and retry rules. The batch reserves no future readiness and provides no execution fallback, so later unavailability may still pause or refuse execution. The selected Run's Orb inspector shows these retained observations and exclusions. They describe admission time, not current availability. Follow [configured Bridge casting](../../../state-of-the-work.md#configured-bridge-casting) for the qualification boundary and [Dispatcher law](../../../adr/22-dispatcher.md) for the selection and execution distinction. ## Follow the Scroll Choose the route that matches the question: - **[Discovery and router delegation](discovery.md)** follows scope branches, makes nested routes and workflows discoverable, and carries the selected routes into a bounded task handoff. - **[Pattern lifecycle](./pattern-lifecycle.md)** covers identity, manifests, admission, contribution, authorship protection, and revision continuity. - **[Crucible](./crucible.md)** covers two-round adversarial formation: declared biased Postures, independent first claims, attributed rebuttal, dissent-preserving synthesis, and the Magus Gate. - **[Creation](creation.md)** applies bounded Inquiry at direction and construction scales, turns support and measure into bounded next steps, and follows local or delegated task handoffs through verification, documentation and authorized VCS effects. - **[Ouroboros](ouroboros.md)** connects work, evaluation and training through correction, memory, Assimilation, Packaging and Evolution. - **[Development bootstrap](development-bootstrap.md)** carries an operator-controlled coding campaign through evidence gates toward bounded native delegation and spare-capacity work. [Coding-runtime research](coding-runtime-research.md) compares the dated provider roads behind that procedure. - **[Scheduling and service classes](./scheduling-and-service-classes.md)** covers foreground, deadline-windowed, and spare-capacity admission, schedule time law, overlap, and explicit misses. - **[Stasis and return](stasis-and-return.md)** covers Live and Durable Stasis, checkpoints, re-admission, terminal cleanup, and recovery limits. - **[Execution roads](execution-roads.md)** covers the layered choice among native/local work, Portal-backed cognition, sovereign A2A tasks, delegated coding runtimes, and operator seats. - **[Anonymization, taint, and egress](anonymization.md)** covers the local Privacy Cut, information-flow labels, Portal admission, quarantined return, and the boundary that makes subsidized remote reasoning usable. - **[Delegated agents](delegated-agents.md)** covers the typed delegated station, `AgentJob` boundary, future CLI adapter acceptance, containment, and the present deterministic, no-network, effect-free reference adapter. ## Creation and its interpretation **[Transmutation](../../../divination/transmutation/index.md)** in Divination examines the Sephiroth correspondence: the relations that give an idea form, symmetry and reconstruction, and life and the ending of forms. [Creation](creation.md) and [Ouroboros](ouroboros.md) keep the practical procedures here in Spellweaver, with handoffs to evaluation and learning. ## Progressive craft without a mutable score A Scroll may admit several explicit finish boundaries. A completed intermediate artifact can begin a new forward Invocation; a terminal Run is never reopened to continue it. [Pattern lifecycle](pattern-lifecycle.md#a-new-score-is-a-new-revision) distinguishes new input from a changed score. Model and engine choice stays in the receiver-owned Resolution Lock. A Comfy graph is an implementation preset, and a portable A2A Scroll remains inert until admitted. Follow [Composition Suites](../../../compositions/products-and-suites.md#compositions-relate-without-nesting) when the work needs live coordination across application owners. ## Hand off a bounded task A [scoped context handoff](../../../adr/28-workflow.md#scoped-context-handoff) gives another Agent a fresh Context for one bounded task while the coordinator keeps the wider purpose. For a repository change, the packet includes the requested result, relevant operator decisions, acceptance checks, allowed paths, source revision, dependencies, and scope routes to the owning documents and code. The recipient reads those owners without inheriting the conversation that produced the task. If a needed decision is missing, the recipient requests that bounded input. It returns a candidate patch or findings with verification evidence and unresolved questions for the coordinator to assess. Merely loading another scope in the same conversation does not perform this handoff. ## The present score [State of Work](../../../state-of-the-work.md) records local execution and the separate Stasis, delegation, extension, and Loom delivery boundaries. Pattern contribution and durable publication, scheduling, durable parallelism, compatibility and migration, editing, authorship attestation, and protected-region admission remain undelivered. Repository coding-agent choreography is separate: the [tracked workflow playbooks](https://github.com/hexanomicon/lychd/tree/main/.agents/workflows) own contributor procedure only, never Spellweaver or Pattern law. --- title: "Discovery and router delegation" plain_name: "Finding docs, scopes and workflows" section: "Sepulcher > Extensions > Spellweaver" original: https://hexanomicon.dev/sepulcher/extensions/weaver/discovery/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/discovery/ --- # Discovery and router delegation (Finding docs, scopes and workflows) ## Plain-English summary (Snayu) **What it is:** How an agent finds where to look next: following router documents through scopes to owning docs, playbooks and registered workflows, then packaging what it found into a bounded task handoff. **Why it matters:** Read this when building agent routing, or when adding or moving documentation scopes so links and triggers stay discoverable. - Routers give task triggers and links; following a workflow link does not start it, and finding a Pattern does not authorize it. - Specialized routing models (e.g. TypeSafe Jev) are an idea to evaluate, not a chosen dependency; confidence is not accuracy. - Discovery can never redirect an admitted Run or splice new steps into its frozen workflow version. ## Original text (Hexanomicon) Discovery answers where to look next: which scope holds the relevant owners, which workflow fits the operation, and which exact score can be considered for execution. Within [Spellweaver](index.md), these routes help a coordinating Agent find the material needed to frame a bounded task. In the inner instrument, [Call](../../lich/call.md) gives this opening its address: relevant parts of the work become reachable. [Blade](../../lich/blade.md) judges which material can support the next act. A route can widen the question before a method narrows it. This is one part of [discernment within exploration](../../lich/blade.md#discernment-within-exploration): finding a source may reveal a better question, while a decisive distinction may redirect the search. [Creation Inquiry](creation.md#reuse-inquiry-at-each-uncertain-boundary) carries that exchange through bounded probes, independent sufficiency review, and Crucible. [Documentation topology](../../../adr/01-doctrine.md#router-delegation) owns scope routing; [Workflow](../../../adr/28-workflow.md) owns Pattern selection and task handoff. This page follows those boundaries in use. ## How routers fan out A router helps a reader choose the next destination by giving task triggers and explicit links. Some links reach an owning document directly. Others open a scope tree whose router maintains its own specialized branches. The parent explains when to enter that tree without duplicating its contents, making the branch and its downstream links a discoverable subgraph of the map. Each route makes its purpose and destination legible: | Destination | What the route exposes | Next act | | --- | --- | --- | | Scope or another router | Domain boundary, applicable triggers, and further routes | Follow the branch relevant to the task | | Canonical owner | Architecture, vocabulary, operation, or delivery truth | Establish the governing contract and evidence | | Workflow playbook | Procedure for the requested operation | Load it after the matching scope | | Pattern or Scroll | A named score and its exact revision | Check registration and admission through Spellweaver | The available branches offer choices; the task determines which to read and in what order. Cross into another scope when the task crosses its boundary, leaving unrelated branches unloaded. Following a workflow link does not start the workflow. Finding a Pattern does not register it or authorize its casting. ## Specialized models for routing Specialized decision models are promising candidates for reducing routing latency and cost when repeated choices require semantic interpretation. For example, [TypeSafe's Jev](https://docs.typesafe.ai/introduction) evaluates supplied state and typed questions; its Choice primitive returns a selected option, probabilities, and confidence without generating a prose answer. Such a model could propose a scope, registered Pattern, or declared graph branch, leaving deeper reasoning for unresolved questions. This is an optimization to evaluate, not a selected LychD dependency or a claim that the fastest router has been established. Begin with explicit commands and reliable deterministic matches. Where intent remains unresolved, a model can choose among bounded destinations, including an explicit uncertain or unsupported outcome. Give it the relevant conversational context—a short confirmation may refer to substantial earlier work. Even a clear proposal must pass ordinary validation and admission. Ambiguity may call for clarification, a bounded probe, or deeper reasoning; no route proposal can rewrite an admitted Scroll. Keep probabilities distinct from confidence. Jev's [Choice confidence](https://docs.typesafe.ai/confidence) rescales the leading probability relative to an even split across the options; `confidence = 0.9` does not itself mean 90% observed routing accuracy. Check calibration and abstention on representative held-out cases, then set thresholds according to the consequences of a wrong route. Compare end-to-end latency and cost, including context preparation, network time, validation, fallbacks, and recovery, against rules and existing model options at comparable task success. Placement remains a separate choice. Jev's documented [hosted API](https://docs.typesafe.ai/introduction/quickstart) is a remote disclosure boundary; a local routing model requires its own verified deployment option. Sensitivity flags may inform the [Privacy Cut](anonymization.md), but a remote router cannot receive private material merely to decide whether that material may leave. Routing scores grant neither capability use nor egress. ## Follow a repository route The repository already provides a concrete example: 1. [AGENTS.md](https://github.com/hexanomicon/lychd/blob/main/AGENTS.md) routes a browser task to the Frontend scope. 2. [Frontend](https://github.com/hexanomicon/lychd/blob/main/.agents/scopes/frontend.md) routes a component or reactivity task onward to the Svelte scope. It also exposes the backend scope when the change crosses the browser projection boundary. 3. The selected scope leads to the canonical owner and the smallest source and test slice needed to establish behavior. 4. If the task edits source, the root's workflow route exposes the [editing playbook](https://github.com/hexanomicon/lychd/blob/main/.agents/workflows/editing/index.md). That playbook routes onward to an applicable file-type card; Svelte-specific work continues through its scope's required workflow. The root keeps Frontend discoverable; Frontend keeps its specialist routes discoverable; the editing index keeps its procedure cards discoverable. Their contents remain with their owners. When adding or moving a branch, maintain its parent link, task trigger, and destination together. A missing prerequisite calls for a targeted probe or bounded request for the missing input. ## From discovery to a task handoff Finding the relevant owners and procedure gives the coordinator enough ground to frame the task. Under the designed [scoped context handoff](../../../adr/28-workflow.md#scoped-context-handoff), the chosen routes travel with the task, acceptance target, operator constraints, allowed inputs and effects, exact revisions, dependencies, and unresolved unknowns. The recipient can then continue discovery within that admitted boundary. Opening another scope in the current conversation retains the material already loaded. A new Agent handoff requires its own Context assembly. The parent keeps the wider purpose and assesses the returned candidate and verification evidence; the [bounded-task example](index.md#hand-off-a-bounded-task) follows that exchange. ## Discovering an executable score For execution, use [Pattern lifecycle](pattern-lifecycle.md#identity-before-motion) to inspect the registered exact revision and its activation policy. Admission pins the selected score; resume uses that stored choice. A discovery link cannot redirect an admitted Run or splice a newly found branch into its immutable Scroll. The current [Loom](../../../state-of-the-work.md#loom-workflow-views) browses the fixed Pattern registry. Scope routes and playbook links are repository navigation; they do not establish a runtime discovery service or executable subgraph composition. General parallel fan-out and joins retain the [Graph design boundary](../../../adr/24-graph.md#future-parallel-topology), and scoped Agent handoff is not implemented by those repository routes. --- title: "Scroll and Pattern lifecycle" plain_name: "Workflow versions and admission" section: "Sepulcher > Extensions > Spellweaver" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/weaver/pattern-lifecycle/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/pattern-lifecycle/ --- # Scroll and Pattern lifecycle (Workflow versions and admission) ## Plain-English summary (Snayu) **What it is:** How a workflow version (Scroll) is identified by a manifest and digest, admitted once, pinned to its Run, and never silently rewritten; plus how human-authored protected regions and new versions are handled. **Why it matters:** Read this before changing workflow code or graph nodes, since a mismatch makes saved Runs fail as 'pinned Pattern unavailable'. - PatternManifest records stations, edges, implementation revision and a SHA-256 digest; resume uses the stored version, never re-routing. - Admission creates the Run and delivery atomically, then publishes one queue job; startup reconciliation republishes if the broker fails. - Changing the score (steps, edges, models) means a new immutable revision; removing old code makes its Runs fail. **Status:** Partial. Local runs pin manifests today; no Pattern store or public contribution API yet. ## Original text (Hexanomicon) > _The ink has dried. Write the next score on fresh parchment._ A casting keeps the score it was admitted to perform. Within [Spellweaver](index.md), a Scroll is one immutable Pattern revision: admission selects it from the Intent, the Invocation names the casting, and the canonical Run retains its identity. If the registered executable stops matching, execution fails rather than substituting another workflow. A Scroll is never silently rewritten. [Pattern identity](../../../adr/28-workflow.md#pattern-identity) owns the full law. ## Identity before motion `PatternManifest` records a renderer-neutral snapshot: schema version; URL-safe key and revision; opaque reviewed implementation revision; checkpoint-schema identifier; declared entry station; semantic stations with key, label, and kind; permitted edges with declared endpoints; and a deterministic SHA-256 digest. The workflow lookup name is persisted separately, although the current `Workflow` binding requires it to equal the manifest key. Retained v2 snapshots must pass the shared declarative checks as well as their checksum: typed station and edge fields, known kinds and permission relations, unique keys and semantic edges, one executable entry, and declared endpoints. A recomputed digest cannot make malformed score data valid. Blockworld admission refuses it before freezing, and Orb withholds Pattern exactness. Those checks do not resolve executable implementations; execution still requires exact registry equality. Additional top-level metadata remains outside the v2 checksum and prevents that equality. Every executable station binds one-to-one to a Python Graph node type, and the declared entry must bind the actual start node. The manifest lives beside that Python and fingerprints the score; it is not an intermediate representation that compiles all behavior. Its implementation revision (`py.1` for original built-ins, `py.2` for configured Bridge) records a reviewed compatibility closure. Change that revision or the public Pattern revision when new behavior cannot safely resume old state. Neither detects source edits automatically, so source review and tests must still establish edge parity and return semantics. The [private v2 adapter](../../../adr/28-workflow.md#private-v2-adapter) derives a Scroll-private `legacy_inline` identity for each executable station and fingerprints its Python node binding in a boot-local `internal-v0` lock. Exact lookup refuses a binding that differs from that assembly. The terminal remains Graph `End`, and the frozen v2 manifest snapshot and digest stay unchanged. This lock is neither persisted on Run nor exposed by Loom/Orb. It does not establish source equivalence or compatibility across boots; the portable Spell catalogue remains a separate contract. The catalogue is immutable after construction. It rejects duplicate `(key, revision)` pairs, requires an explicit active revision when one name has alternatives, requires explicit non-default route precedence, and names its default. Construction performs no package scan. The current source-defined manifests retain these routes: | Pattern revision | Admission route | Checkpoint schema | | --- | --- | --- | | `bridge_chat@1` | Unconfigured default | `bridge-chat-state-v1` | | `bridge_chat@2` | [Configured exact capability](index.md#choose-a-bridge-capability) | `bridge-chat-state-v2` | | `bridge_chat@3` | Configured public Archive and exact capability | `bridge-archive-state-v1` | | `bridge_chat@4` | [Configured Scout](../scout.md#public-page-answers), authenticated command and exact local capability | `bridge-scout-state-v1` | | `delegated_rite@1` | Exact `/delegate` command token | `delegated-rite-state-v1` | | `delegated_rite@2` | Configured exact runtime and `/delegate` command token | `delegated-rite-state-v2` | [The owning registry source](https://github.com/hexanomicon/lychd/blob/main/src/lychd/agents/workflows/__init__.py) defines the retained revisions and their activation policy. ## Admission happens once [Admission and ownership](../../../adr/28-workflow.md#admission-and-ownership) orders four operations: 1. Validate and select the Pattern. 2. Atomically create the canonical Run and initial durable delivery with the exact manifest snapshot. 3. Retain the caller-owned initiating record while that delivery is held, then release it. 4. Publish one queue job keyed by Run and enqueue sequence; relay the same key when unavailable. A failed retention can settle only the exact held generation that has not been released. If a release commits and then raises, the delivery row resolves the uncertainty: the work remains admitted, and compensation cannot overwrite `PENDING`. Broker failure likewise leaves the Run queued with its exact pending delivery. PostgreSQL and SAQ do not share a distributed transaction; startup reconciliation and the process-owned relay probe and republish that idempotent key without inventing a new Pattern hop. Execution and resume look up the exact persisted Pattern key and revision rather than routing the Intent again; a retained revision need not remain active for new admission. Before running, the worker validates checksum, workflow-name binding, implementation revision, and equality with that exact registered manifest. A corrupt checksum, changed declaration or implementation closure, missing workflow, or unavailable revision fails as `pinned Pattern unavailable`. No default or newer Pattern replaces it. Checkpoint and suspension mechanics belong to [Stasis and return](stasis-and-return.md). `AgentJob` and provider boundaries belong to [Delegated agents](delegated-agents.md). ## Portable contracts and configuration Each semantic station currently behaves like a legacy inline Spell placement: key, label, kind, implementation closure, and edges are bound only inside its Scroll. There is no independent Spell identity or portable catalogue. A future portable Scroll pins exact authority-qualified Spell contract revisions and digests; a receiver-owned Resolution Lock separately binds each placement to an exact local implementation. Admission reports every unknown, unavailable, incompatible, revoked, or unauthorized placement instead of substituting a similar name or newer revision. A future Loom may show the absence only in an inert resolution report; an unresolved placement never enters an executable Graph. Configuration follows the closed spine in [ADR 28](../../../adr/28-workflow.md#configuration-to-casting-spine): TOML selects exact registered identities and bounded policy only. Never place import paths, node classes, graph edges, prompts, source bytes, credentials, or live handles in a Scroll selector. Unknown ids and missing exact revisions are refusal, not cues for package scanning or nearest-name fallback. ## Human-attested material stops at a Gate Spellweaver does not infer human authorship from a commit name, account, writing style, or a human approval. A future trusted authoring surface records an [Authorship Attestation and Protected Region](../../../adr/28-workflow.md#authorship-provenance-and-protected-regions) against the exact artifact revision, stable region id, and content digest. Existing material remains `unknown` until a human attests its current form. ```text base artifact + protected-region manifest + candidate | target-owner diff / \ no overlap overlap | | ordinary gates exact live HitL | target-owner promotion ``` An Agent may prepare a replacement in its candidate workspace. It cannot change the active region, remove protection by deleting a source marker, or reuse a verdict from another base or patch. The live review names every touched region, old and replacement digests, and an authorized exact-diff artifact. A changed base or candidate, a newly touched region, or a changed target effect invalidates the call and requires another verdict. Promotion preserves the distinction between approval and authorship. A wholly Agent-written replacement remains `agent_generated`; interleaved retained human text and Agent work is `mixed`. An approved move may preserve the origin of unchanged human-attested content. A rewritten exact digest becomes `human_attested` only through a fresh human authorship attestation. Visible comments, front matter, and Loom decoration are projections of the target-owner manifest, not enforcement. A compliant effectful Agent therefore works through Creation's candidate surface; a direct writer with authority over the active checkout bypasses Spellweaver and cannot claim this protection. No attestation store, protected-region resolver, authoring UI, or exact diff review card is delivered. [State of Work](../../../state-of-the-work.md#smith-forge-promotion) owns that boundary. ## A new score is a new revision A new Invocation can vary a prompt, source `ArtifactRef`, requested language, target profile, or finish boundary only when the existing Scroll's typed schema already admits that value. Changing the score itself—adding a station, edge, Spell contract, authority ceiling, or required model—creates a new immutable revision. If one Invocation finishes at an accepted intermediate boundary, continuing from its artifact starts a new forward Invocation. It never resurrects the terminal Run. The current catalogue can preserve multiple executable revisions per workflow name. Active routing is explicit; a saved Run continues through its exact registered revision even after activation moves forward. The catalogue is still source-built and preserves no historical Python by itself. Removing old code makes that revision unavailable: affected Runs fail as `pinned Pattern unavailable`. Automatic compatibility proof, durable publication, drain, and migration remain future work. [Topology-A](../../../state-of-the-work.md#topology-a-local-runs) local runs are **Available** and pin manifests. [Extension activation](../../../state-of-the-work.md#extension-activation-contributions) is **Partial**, but no Pattern store or public contribution API is delivered. Future publication follows the [Pattern contribution](../../../adr/28-workflow.md#pattern-contribution) law: inert Scroll and Spell-contract candidates declare identity, continuity, and evidence; executable Spell implementations register through a separate owner. Validation and review may publish an immutable revision, bind an implementation, and activate a new process generation only as distinct effects. An A2A teaching bundle reaches this path only through [Assimilation](../../../adr/35-assimilation.md#teaching-a-missing-spell). The current `Workflow` type remains internal and pre-v1, not a third-party ABI. Current code or contribution changes require controlled Evolution and Vessel/catalogue replacement; this is not Reanimation. A future declarative-only Scroll may activate without a restart only after all required implementations already exist and an atomic durable catalogue generation mechanism is proved. A future scheduler would create an Occurrence and submit it through ordinary revision-pinned admission. Its timer never calls a Graph node, model, or container directly. [Scheduling and service classes](scheduling-and-service-classes.md) owns that temporal contract and routes its implementation evidence. --- title: "Crucible" plain_name: "Structured two-round debate" section: "Sepulcher > Extensions > Spellweaver" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/weaver/crucible/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/crucible/ --- # Crucible (Structured two-round debate) ## Plain-English summary (Snayu) **What it is:** A planned workflow (Crucible) for hard decisions: two or more biased advocate roles argue independently, then rebut each other's actual claims, and a separate lead writes a decision dossier that keeps dissent. **Why it matters:** Read this when designing multi-agent review or decision workflows, to see the rules that stop debate from replacing evidence or authority. - Advocates first work without seeing each other, then rebut only an attributed summary of opposing claims. - The lead synthesises NOW / PREPARE / REJECT plus surviving dissent; it has no vote and cannot promote anything. - Not for settled facts or capability tests; isolated experiments go to the What-if Simulator (Shadow), tests to the Evaluator (Drift). **Status:** Designed. Not in the workflow catalogue; parallel branches and dossier schema undelivered. ## Original text (Hexanomicon) > _Lay your convictions on the anvil. Listen for the crack._ A persuasive answer may survive review simply because nobody was asked to make the decisive objection. **Crucible** gives serious alternatives two rounds: each first develops an independent case, then replies to the actual opposition. A separate Lead gathers what survives into an attributed decision dossier. The receiving owner retains the decision about what to do with it. This is Spellweaver's canonical adversarial choreography. [Blade](../../lich/blade.md#crucible) owns the discipline of discrimination; [Workflow](../../../adr/28-workflow.md#crucible-choreography) owns the score. Debate supplies neither factual proof nor effect permission. Crucible is absent from the fixed workflow catalogue; durable parallel branches, a dossier schema, an Altar projection and automatic Pattern publication remain undelivered. [State of Work](../../../state-of-the-work.md#composition-portfolio-delivery) records that boundary. ## When to light it Use Crucible when a bounded decision has at least two serious positions, self-review would hide a material conflict, and the cost of a premature answer justifies another model round. Architecture, security, product trade-offs, recovery choices, and admission decisions are natural candidates. Do not use it to decorate a settled fact, manufacture false balance, outvote a deterministic test, or postpone a decision whose owner already lacks required evidence or authority. When alternatives need isolated candidate worlds or effectful experiments, [Shadow](../../../adr/31-simulation.md) owns those branches. When the question is whether a capability passes repeatable Cases and a Rubric, [Drift](../../../adr/34-evaluation.md) owns the trial. ## The bounded casting [Creation's reusable Inquiry](creation.md#reuse-inquiry-at-each-uncertain-boundary) prepares evidence and an independent sufficiency judgment before lighting Crucible. Its bounded probe and stopping rules prevent debate from covering a decisive evidential gap. One admitted casting freezes: | Input | Required boundary | | --- | --- | | Question | One decision, named owner, present base, and downstream use of the dossier. | | Acceptance | Exact criteria, non-goals, refusal conditions, and evidence that would reopen the question. | | Evidence packet | Common attributed sources, versions, known omissions, classification, and immutable artifact references. | | Advocates | At least two distinct [Postures](../../../adr/20-agents.md#mechanical-cognitive-postures), each with a declared bias, burden of proof, attack surface, and defeat condition. | | Lead | A separate synthesis Posture with no advocate role, vote, or promotion authority. | | Limits | Per-round Context, tokens, calls, spend, wall time, concurrency, and stop conditions. | | Finish boundary | Brainstorm dossier, recommendation, or decision candidate; never automatic adoption. | Each advocate's declared angle gives a class of consequence enough procedural weight to resist premature agreement. That is the purpose of multiplying Postures. A temporary **Posture** is neither a Persona nor evidence of emotion, continuing identity, or an independent [Will](../../../lexicon/inner-tongue.md#emotion-and-will). A revision-pinned Persona can wear several Postures; without that binding, resemblance or opposition creates none. The dossier attributes each contribution without pretending each branch was a separate life. ### Derive a complementary Posture The [Tree's symmetry](../../../divination/transmutation/genesis.md#paired-perspectives) suggests a design refinement: keep one question, evidence floor, criteria, authority, and resource envelope while changing the concern, burden of proof, and defeat conditions. An advocate for possibility can meet an advocate examining failure conditions. Neither is instructed to retain a conclusion after its support fails. Pairing attention does not require contrary verdicts or exactly two participants; a missing perspective may expose a premise both initially shared. ### Exchange actual claims > _A Posture without stake is costume. A stake without a defeat condition is dogma._ The logical score is: ```text Frame question, evidence, biases, and limits → Clash I: independent advocate reports → Temper: attributed strongest-claim/concession join → Clash II: each advocate rebuts the actual opposing claims → Quench: Lead synthesizes NOW / PREPARE / REJECT and preserved dissent → Magus Gate or inert dossier ``` Clash I gives every advocate the common evidence and withholds sibling output. At Temper, each nominates its own strongest claims and concession; the join preserves citations, defeat conditions, unknowns, and references to original reports. Clash II receives only the bounded, attributed projection needed for rebuttal. It has no entitlement to hidden chain-of-thought, an opponent's private Context, or an unbounded transcript. To make reciprocity inspectable, the proposed dossier should identify the exact earlier claim and report revision each reply addresses. A revision should name what it retains, changes, or withdraws and the evidence responsible. Quench accounts for consequential objections as accepted, defeated, unresolved, or outside scope. Merely copying an objection into the dossier does not show that the receiving judgment considered its consequence. These are proposed recording details within the existing choreography, not a delivered schema. An offline requirement makes this concrete. One advocate proposes acceptance from a connected happy-path test; another identifies an untested network dependency. The first can concede the receipt's limited reach; the second can propose a disconnected trial instead of blanket refusal. If the separately admitted trial fails to produce the required artifact, a successor synthesis can return `PREPARE` with the repair criterion. Neither mutual agreement nor a reassuring log substitutes for the result. [Drift](../drift/workflow-improvement.md#reciprocal-criticism) asks whether the exchange improves such decisions beyond what the same resources buy without it. Logical branches may execute concurrently only after Graph's parallel contract is delivered. A serial casting remains a valid implementation when it gives each first-round advocate a fresh Context and withholds earlier reports until the join. Capability, model, provider, and road may differ only when the admitted design intends that difference; the dossier records them because they can confound the apparent strength of a position. ### When the question changes The Magus asks how to make an undertaking faster. One advocate builds the strongest case for more Agents: independent work can proceed together. Another argues for a stronger model: fewer mistakes could mean less rework. Both proposals depend on a premise still awaiting examination—that producing the work is where the time goes. The clash exposes this gap, and its dossier proposes a bounded probe. The receiving owner may admit that probe separately; [discovery](discovery.md) then finds the owners and records needed to examine where a representative task waits. Suppose the answers arrive promptly, yet every next move still waits for the Magus. The delay lies between answers, where someone must frame the next question. The next inquiry asks which judgment the Lich must learn to supply for itself. Another task can test whether the changed approach helps. The lesson that may survive is portable: find what the work is waiting for before multiplying what it produces. ## Quench without crowning a winner The Lead answers the decision, not the debate. Its dossier retains: - the exact question, owner, base, acceptance criteria, evidence closure, and omissions; - every advocate, Posture, implementation, road, budget, and terminal status; - first-round claims and second-round rebuttals with source references; - concessions, defeat conditions, conflicts, `UNKNOWN` findings, and missing evidence; - a `NOW / PREPARE / REJECT` synthesis when that vocabulary fits the owning question; - the strongest surviving dissent and conditions that would change the recommendation; and - any proposed owner delta as inert text or an artifact reference. The projection or final dossier may be shortened, but compression must retain every nominated strongest claim, concession, dissent, uncertainty, source, and declared omission. Full reports remain under their own provenance. Agreement can still be wrong; a surviving disagreement may identify the missing predicate that matters most. The return can preserve more than a verdict: the distinction that changed the question, the conditions under which it holds, and the observation that would undo it. [Learning the cut](../../../divination/transcendence/illumination.md#learning-the-cut) follows how that encounter can shape another task through memory and correction. The final Gate can accept the dossier for downstream consideration, request one bounded evidence extension, refuse it, or close without deciding. None of those outcomes edits a Covenant, promotes a candidate, deploys a service, spends, publishes, or relabels evidence. Each such effect needs a new forward Invocation under its exact target owner and authority. An inert dossier may instead go directly to its receiving owner. Applicable standing policy can admit eligible downstream work; Crucible adds no universal second approval. An exact live-only verdict or Protected Region review still cannot be inferred from the recommendation. ## Refusal and recovery Crucible refuses when the question has no owner, positions are duplicates or caricatures, the common evidence floor cannot fit, a bias lacks a defeat condition, the Lead is also an advocate, or the requested result would acquire authority by majority. Timeout, failed branches, incomplete rebuttal, and missing sources remain visible in the dossier; the Lead may return non-decision but cannot silently complete the missing side. A retry binds a new Invocation and records whether evidence, Postures, models, limits, or the question changed. It never rewrites the earlier clash. When one narrow evidence request can settle a named unknown, the owner may run it separately and invoke Crucible again over the enlarged evidence packet. --- title: "Creation" plain_name: "Software change method (Creation)" section: "Sepulcher > Extensions > Spellweaver" original: https://hexanomicon.dev/sepulcher/extensions/weaver/creation/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/creation/ --- # Creation (Software change method (Creation)) ## Plain-English summary (Snayu) **What it is:** A step-by-step method for taking an intended software change from a clear goal and evidence, through bounded inquiry, implementation and verification, to documentation and an authorized commit, then feeding results back. **Why it matters:** Read this to learn how Snayu engineers and agents should frame, hand off, verify and close a change in the LychD way. - Start by stating desired vs current state, non-goals and acceptance checks before choosing a solution. - Inquiry turns a consequential uncertainty into a decision; a human choice gets evidence plus one answerable question. - Candidate, verified change and authorized version-control effect stay distinct; docs are updated first (Docs-First Development). ## Original text (Hexanomicon) Start by writing the change another person should be able to verify. What should become possible, what happens today, and what evidence would distinguish a successful result? **Creation** takes that intended software change through a reviewed candidate to its authorized delivery owner, then returns evidence for future work. [ADR 16](../../../adr/16-sdlc.md) owns the lifecycle and handoffs. A recipient can begin when the intended change, present evidence, acceptance, and authority are clear enough to act without guessing. This method can guide ordinary agent-assisted engineering under the actual host's permissions. The method itself introduces no Composition, registered Pattern, Spell catalogue or autonomous SDLC service. The narrower [Creation investigation](../../../compositions/creation/index.md) contract owns one public-source question, candidate and separate verdict; it does not implement this whole method. The current Graph is serial, and delegated execution supplies only an effect-free reference adapter. [State of Work](../../../state-of-the-work.md#smith-forge-promotion) owns delivery. ## Frame the delta before choosing the route Separate what the user wants to achieve from ideas offered while discussing it. Brainstorming supplies possible questions, alternatives, and evidence leads. It grants no further authority to edit, spend, send, train, deploy, or publish. Preserve the actual authorization with the request. Give the intended change an observable acceptance boundary. “Make development faster” still leaves the important decisions open: which delay matters, what is the baseline, and what improvement would count? Establish the present state through its canonical owners and the smallest relevant source and test slice. Then record the difference to achieve, the non-goals, and acceptance conditions. Those terms let the recipient judge a proposed solution by what it would actually change. Owning documentation establishes intended truth before implementation under xDDD. Closure reconciles that truth with the actual result. A candidate, a verified change, and an authorized version-control effect remain distinct points in the passage. A direction may require a bounded probe before it can be chosen. It may also end in an explicit non-decision. When a human choice remains necessary, bring the evidence, recommendation, consequences, and one answerable question. Later evidence can reopen the affected decision within the remaining budget and stopping conditions. Do not prolong work whose declared completion boundary has been met. ```mermaid %%{init: {"flowchart": {"nodeSpacing": 12, "rankSpacing": 22, "padding": 8}}}%% flowchart TD I[Intent] --> F[Desired vs current state] F --> Q1[Inquiry 1: direction] Q1 --> H{Settled under owner authority?} H -- human choice needed --> U[Evidence and one question] U -- decision --> H H -- missing evidence --> Q1 H -- yes --> Q2[Inquiry 2: construction] Q2 --> T[Tests and task decomposition] T --> W[Bounded implementation] W --> V[Verification, review and needed evaluation] V -- repair within budget --> W V -- premise failed --> Q2 V -- accepted --> D[Documentation closure] D --> S[Authorized VCS effect] S --> E[Completion and outcome evidence] classDef work fill:#102d46,stroke:#6faaff,color:#e3f0ff class I,F,Q1,H,U,Q2,T,W,V,D,S work ``` ## Reuse Inquiry at each uncertain boundary **Inquiry turns a consequential uncertainty into a decision someone can implement.** Begin with a bounded question: what difference could change the next act? Finding that difference already exercises [discernment](../../lich/blade.md#discernment-within-exploration). A separate judge supplies another position from which to examine the work. Judgment also belongs inside exploration, where a failed premise can redirect the search before a favored solution hardens. 1. **Explore the question.** Assemble serious alternatives, governing owner routes, observed facts distinguished from inference, source identities and revisions, omissions, and evidence that would defeat each proposal. A PostgreSQL-versus-SQLite comparison begins with actual requirements and existing persistence decisions. Naming alternatives does not reopen accepted architecture; its owner governs a change. Let findings create better questions, and let observations close answered ones with stated reopening conditions. Repeating an unchanged checklist establishes no coverage. 2. **Judge coverage and sufficiency independently.** Supply the question, acceptance, sources, and search scope. Where practical, initially withhold the favored conclusion; record later exposures and conflicts. The judge returns requirements covered with cited evidence, omissions, decisive unknowns, the smallest useful probes, a stopping recommendation within remaining time, calls, and resources, and conditions for reopening. A bounded direct-source probe may settle a gap. The target is sufficient evidence for this decision. One pass may request a bounded extension or recommend non-decision; it starts no endless succession of judges judging judges. Unverified judge claims remain claims. Separate sessions or models can share a source blind spot: agreement cannot fill a missing decisive source. The receiving owner may accept residual uncertainty only where governing law permits it, and retains the right to refuse. 3. **Bring consequential alternatives through Crucible.** Establish common evidence, distinct declared Postures, and defeat conditions. Obtain independent first reports; their join preserves the strongest claims, citations, concessions, and defeat conditions. Advocates then receive the actual opposition for second-round rebuttal. A separate Lead synthesizes the surviving case and dissent. Agreement supplies no truth-by-vote. Two unrelated essays, or one model imagining both sides, do not establish reciprocal exchange. [Crucible's bounded casting](crucible.md#the-bounded-casting) owns the full contract. Every handoff must carry the distinction that could change the recipient's next act. “Use this design” can hide an unresolved recovery assumption. “Use it only if the recovery probe preserves the committed records” exposes the condition and gives the recipient something to examine. When admitted measurement can settle a factual dispute, specify the proposition, exact subject and environment, observable result, acceptance rule, and effect limits before running the probe. A recovery experiment might ask whether the exact candidate restores the records required by its declared contract under the stated interruption. Preserve failures and inconclusive results. Further argument cannot replace an available decisive measurement. Ordinary repository tests remain governed by their project owners; repeatable capability evaluation belongs to [Drift](../drift/workflow-improvement.md). The human decision account should name the concrete choice, recommendation and reasons, strongest surviving objection, unresolved consequence, and what changes under another choice. Ask only for a still-required choice or authorization. Exact standing authorization persists; Inquiry adds no blanket approval at each station. Required live Gates retain their exact-effect rules, and a reserved operator choice remains unresolved until answered. Settling direction gives construction a more specific question; repeat Inquiry at that scale where uncertainty warrants it. A database choice still leaves schema ownership, interface placement, changed callers, and the documentation owner to establish. Inspect those seams, compare implementation cuts, and settle acceptance before splitting the work. Accepted conclusions can carry settled mechanical details forward without another debate. When the decision is settled, carry it into [bounded work](#hand-off-work-that-can-return-intact). When another attempt may be needed, first make the reason for continuing inspectable. ## Turn support and measure into a next step At a consequential choice, collect two separate, qualitative recommendations about the same question and artifact. **Support** identifies the opportunity worth developing or uncertainty worth investigating. **Measure** identifies the limits, burden of evidence, and reasons to stop or narrow that work. Each cites its observations and distinguishes inference from what remains unknown. Strong support and strong measure can coexist: a promising candidate may deserve a strictly bounded trial. These [two pressures](../../../divination/transmutation/genesis.md#chesed-gevurah-weights) are not numbers to subtract into an automatic verdict. **Unobserved is not low value, failed, or safe.** A new possibility may need an initial discovery allowance to obtain the evidence either recommendation lacks. The coordinator can allocate that bounded probe from the existing parent budget, naming the decision it could change and what other work it displaces. Discovery does not reset the budget or promise every branch a trial. The actual campaign coordinator selects the next step within its admitted scope, or presents an unresolved owner decision. In a native workflow, that choice must follow the admitted score; these recommendations introduce no hidden allocator or new runtime edge. Make the choice inspectable by recording: - the exact question and candidate or evidence revision, the selected next action, and the reason it follows from the support, measure, and outstanding uncertainty; - the observation sought, responsible participant, and cost ceiling within the remaining parent budget, including review and required checks; and - what would settle or stop the attempt, what could reopen the question, and where its result must return. When the probe returns, compare the observation sought with what it actually established, including inconclusive results and resources used. That comparison can revise a recommendation, justify continued work, or close the branch. Required authority and deterministic gates remain binding throughout. Support and measure recur during exploration, construction, and review; they are not confined to one Chesed–Gevurah station. This separates three questions that can otherwise blur together. In the Tree correspondence, Gevurah supplies the measuring concern and Hod the reflective review; their [relations](#tree-relations-in-practice) appear below. | Judgment | Question it answers | | --- | --- | | Coverage and sufficiency judge | Is the available evidence sufficient for this decision, and which decisive gaps remain? | | Gevurah's measure | What must this proposed act respect, and which constraint, failure condition, or disputed criterion needs examination? | | Hod's review | What did this exact result reveal, what was missed, and does the signal rewarding further effort still track the purpose? | A failed candidate can still reveal a useful probe or question. Credit the method only for the distinction its evidence supports, rather than rewarding every preceding step. Continuing needs an informative reason—a changed candidate or justified replication, for example—and room in the parent budget. Repeated failure alone earns neither endless retries nor automatic memory or training admission. ### Make the inquiry policy explicit An operator campaign can configure this procedure in its task packet today. Record the policy before dispatch so a reviewer can distinguish a deliberate exploratory allowance from an unbounded retry. The packet needs: | Choice | What must be explicit | | --- | --- | | Question and alternatives | The decision, exact input revisions, required evidence, and permitted probe or repair actions. | | Support and measure | Separately attributable reasons to continue and to constrain, their evidence, unknowns, and what would change either recommendation. Absence of reward is not evidence of failure. | | Discovery allowance | Maximum new probes and their cost ceilings within the parent budget; retain enough budget for review and required verification. No branch resets that budget. | | Sufficiency and stopping | The observation that would settle the question, hard stop conditions, and the non-decision returned when evidence or budget is insufficient. | | Return and revision | Who receives the result, which affected decision can reopen, and which changed inputs require a new attempt or policy revision. | This is an inspectable operating packet, not a new TOML section or browser control. Native configuration later selects an exact registered policy under [the configuration-to-casting contract](../../../adr/28-workflow.md#configuration-to-casting-spine). Its owner must define typed inputs, units, bounds, defaults, stale and missing evidence behavior, and admission-time pinning before exposing a setting. Arbitrary prompts and graph edges do not become configuration, and a changed preference cannot alter a running Scroll. The practical question is **what evidence makes this next probe worth its cost?** Support and measure inform that answer; they do not issue capability grants, override a failed gate, or tune Orchestrator priority. Compare proposed policies on [matched continuation Cases](../drift/workflow-improvement.md#support-and-measure-comparison) before admitting a new default. Altar can display these reasons only when their owner supplies them with the relevant question, attempt and evidence identity; an emotion meter drawn from model prose would invent a signal. ## Hand off work that can return intact Use the accepted delta to decide how to test the work and where to divide it. Identify tests for changed behavior, failure and recovery obligations, along with the repository gates that must pass. Tasks can separate where their owners, inputs, outputs, and acceptance separate. Resolve shared-file mutation or an unsettled interface before distributing writers; either creates a dependency the handoff must respect. Every task receives an immutable handoff containing: | Part | What must survive transfer | | --- | --- | | Intent and owner | Parent objective, local task, responsible acceptance owner, relevant decisions and non-goals. | | Context provenance | Governing routes, exact base and source/artifact revisions, attribution, classification, and declared omissions. | | Inputs and outputs | Admitted inputs, expected result schema or artifact shape, allowed paths, and downstream use. | | Acceptance | Behavioral criteria, required observations, test/review obligations, and refusal conditions. | | Permission and budget | Actual tools and effects, authority ceiling, context/call/resource/time limits, and remaining shared budget. | | Dependencies and unknowns | Prerequisite results, shared interfaces, unresolved decisions, and evidence that may reopen them. | | Stop and recovery | Completion boundary, cancellation, timeout, ambiguous-effect handling, and who may admit a retry or successor. | A recipient starts with the smallest sufficient context for that contract; the parent retains the wider purpose and judges the return. [Scoped handoff](../../../adr/28-workflow.md#scoped-context-handoff) owns the runtime design. In an operator campaign, record the platform's actual context and permission boundaries rather than inventing a LychD Run or containment receipt. Changed task requirements produce a successor handoff with explicit lineage. Prepare a compact view between stages when it helps the next recipient continue. Keep accepted and unresolved decisions separate, explain why each matters, and preserve dissent, defeat conditions, exact source references, and unfinished obligations. Full attributable artifacts remain under their owners. If an omission leaves the next decision unsafe or unsupported, restore the necessary bounded material or stop. Compaction cannot turn missing evidence into an accepted premise. ### Hand a bounded task to a CLI runtime At decomposition, [execution roads](execution-roads.md) distinguishes a native step from work needing a separate iterative coding runtime. Exploration, an adversarial report, construction, or verification can each use that road when their own handoff permits it. The CLI wrapper adapts the request, process/effect boundary, cancellation, and result. The reasoning task stays the same; the wrapper supplies its execution boundary. [Delegated agents](delegated-agents.md#cli-adapter-passage) owns that job boundary. The designed branch is: ```text exact input projection → required privacy/anonymization path and semantic-sufficiency check → admitted bounded CLI job → quarantined, validated return → authorized local rehydration, when a reversible Cut permits it → independent verification against the real task → join the candidate ``` The [anonymization workflow](anonymization.md#preserve-the-coding-question) describes the transformations and independent privacy and utility verification; [Security](../../../adr/09-security.md#portal-privatization-and-egress) owns admission of the exact exit. A local task needs its authorized projection, but does not automatically need anonymization or a remote call. A local CLI's child provider call still creates a remote disclosure boundary. If transformation loses the identifiers or relations needed to answer the question, narrow the task, choose an eligible local road, or return noncompletion. Before launch, pin the baseline and allowed paths, permitted tools and effects, resource ceilings, cancellation and uncertain-outcome handling, expected outputs, and result identity. Returned claims stay attributed to the actual job; rehydration neither validates a patch nor authorizes its execution. The receiving owner admits verified candidate material before it joins the work. These are required boundaries for the proposed branch: current LychD runs only its effect-free reference adapter and does not deliver this CLI, anonymization, or remote-egress path. ## Implement, verify, and settle Run independent tasks concurrently only where the actual execution environment supports their isolation, ownership, cancellation, and joins. Current LychD Graph execution is serial. General runtime fan-out and composed reusable subgraphs are not implemented under [Graph's parallel contract](../../../adr/24-graph.md#future-parallel-topology); drawing Inquiry as one box does not register a nested executable Pattern. Each task returns candidate changes, observed verification evidence, and remaining blockers. The parent checks that return against the exact handoff before integrating it. Focused tests and required repository gates are followed by independent review of behavior, owner boundaries, and failure paths. Refactor where findings justify it, then rerun the affected checks. A failed test or review may return work to implementation or reopen a construction inquiry, within the remaining budget. Review also examines **what earns another attempt**. Rewarding passed-check counts, agreement, or tasks closed can improve a proxy while losing the intended behavior. Here Hod reviews whether the evidence supporting Netzach's persistence still tracks the acceptance target. A changed criterion needs its own revision and renewed affected comparisons; it cannot turn an earlier failure into a pass. Support, branch budgets, and stopping decisions remain inspectable under the parent budget. [Drift's continuation comparison](../drift/workflow-improvement.md#continuation-and-credit) tests whether reviewing this policy helps. Owning documentation establishes the intended truth before implementation under xDDD. At closure, reconcile it with the actual result, update routes and delivery claims made stale by the change, and preserve evidence gaps. Then perform only the VCS effect already authorized for this task: patch delivery, commit, branch publication, or merge have different consequences and scopes. Retain the resulting identity and observed outcome. Do not infer permission to publish from permission to prepare a change. ### Evaluation within and across Creation Evaluation can contribute evidence **inside** the SDLC: a candidate may need a [Drift Trial](../drift/trials.md) before promotion, alongside its distinct tests and review. After an admitted effect, observations can support evaluation of its actual consequences. The manifested result—Malkhut in the Tree correspondence—does not grade itself. A different question takes the Creation method as its subject: does this way of exploring, allocating effort, or responding to criticism improve outcomes across tasks? Drift's [continuation comparison](../drift/workflow-improvement.md#continuation-and-credit) addresses that question. Drift owns evaluation evidence wherever the lifecycle needs it; the candidate, workflow, or effect owner retains its decision. Ouroboros connects supported findings to a later admitted change, with training as an optional, separately governed remedy. ## Return to the question the evidence changes Route a finding by what it changes, rather than automatically climbing to the top of the Tree. A late discovery can require an earlier kind of attention on a new, more specific object. The Tree names those recurring capacities; the table gives each name the work it must do. | Finding | Next bounded work | | --- | --- | | The implementation violates an otherwise settled design. | Repair the affected construction and renew its verification; a new architecture debate is unnecessary. | | A category, dependency, invariant, or structural assumption is missing or wrong. | Revisit Binah with the finding and affected artifact. Return revised structure and its consequences. | | New understanding exposes a consequential alternative, or the accepted direction no longer supplies a justified way forward. | Revisit Chokhmah with the existing constraints and evidence. Structure and compare the resulting options before changing the direction. | | An opportunity deserves a further informative trial. | Revisit Chesed's support and Netzach's continuation within the remaining budget and Gevurah's limits. | | A limit or criterion is disputed. | Examine it through Gevurah and its governing owner. A proposed exception is not permission. | | Continued effort improves a proxy while losing the intended behavior. | Revisit Hod's review of what earns further effort; repair the signal within the admitted procedure. | | The surviving contributions no longer compose a justified whole. | Revisit Tiferet with their actual agreements, objections, and open choices. | | The intended outcome or its premise must change. | Return to Keter and the intent owner for an attributable revision. | Binah can therefore reopen Chokhmah **before the current design has failed**: a new distinction may make a materially better arrangement thinkable. Novelty alone does not require more search. State the decision it could change, a decisive question, the remaining budget, and the stopping condition. Preserve already sufficient conclusions when the new finding does not affect them. Preserve an earlier result when new findings require a return: the return creates a **later task attempt**. Retain the old artifact and identify the dependent conclusions that need reconsideration. Before reusing unaffected evidence, check that its inputs, assumptions, and obligations still apply. The changed candidate needs renewed affected verification and every check required by its final owner; the old candidate's pass cannot silently certify it. Within LychD, the return must follow the admitted Scroll, and a changed score needs a successor revision. Human campaign labels cannot invent an undeclared runtime edge. The workflow may be cyclic while an unfolded history of invocation and station-attempt occurrences is acyclic: each later attempt has its own identity and refers to earlier evidence. This is a history view, not a claim that every declared workflow is a DAG. A terminal Run stays terminal, and later repair begins a new forward Invocation. Outcomes leave attributed event and trace records: exact inputs and revisions, route and task identities, observed tests and effects, cost or timing where measured, decisions, failures, and unresolved uncertainty. Observations remain distinct from owning ledgers and checkpoint truth. These records may become inputs to proposed [workflow evaluation and improvement](../drift/workflow-improvement.md) or, after separate corpus admission, [discernment training](../soulforge/discernment-training.md). Neither a successful task nor a repeated failure automatically changes a workflow or model. [Ouroboros](ouroboros.md) follows that return from experience to a separately judged and authorized successor. ## Tree relations in practice The [Tree of Life](../../../divination/transmutation/genesis.md#tree-of-life) names capacities whose relationships can shape the work. A task can cast those questions as bounded agent roles without allocating one permanent worker to every node. The engineering sequence was developed on the whiteboard before its comparison with the Tree of Life. The Tree's [relations within relations](../../../divination/transmutation/genesis.md#relations-within-relations) now suggest refinements to examine: criticism within exploration, constructive alternatives within critique, and evidence-responsive persistence within implementation. Preserve the existing Inquiry as a baseline. Compare one changed relation on matched Cases through [workflow evaluation](../drift/workflow-improvement.md), holding the task set, available tools, and resource budget fixed. Measure decision quality, missed constraints, recovery, and human attention. A useful correspondence must improve the work beyond renaming its stations. The practical interpretation is: | Relation | Work and return | | --- | --- | | Keter ↔ first Inquiry | Intent frames the search; evidence may justify an attributable revision of that intent. | | Chokhmah ↔ Binah, gathered through Da'at | Opening proposes possibilities and missing capabilities. Structuring develops categories, dependencies, assumptions, and implications. Each receives the other's findings; structure can reveal another possibility. Their shared packet carries situated knowing into the next decision. | | Chesed ↔ Gevurah | Support develops the strongest worthwhile opportunity. Measure examines necessary constraints, failure conditions, and potentially mistaken criteria. Each replies to the actual case received. | | Both → Tiferet | Synthesis composes a justified design with tradeoffs, reasons, dissent, and uncertainty. It may discover a different arrangement that answers both concerns. | | Netzach ↔ Hod | Development persists through resistance; review examines what was missed, what changed, and what continuation is being rewarded for. Findings can repair the work or reopen its design. | | Design and constructed contributions → Yesod | Join an exact, testable candidate with its inputs, evidence, limits, and remaining obligations. Review and tests can return it for revision. | | Verified Yesod → Malkhut | Request the target owner's admitted effect and retain the observed result. Verification alone supplies no effect permission. | | Consequence → Da'at → later Keter | Carry recognized consequences into the next governed question or undertaking. | **Tiferet is the coherent design; Yesod is the assembled candidate; Malkhut is the admitted result.** These distinctions preserve [ADR 16's chain](../../../adr/16-sdlc.md#decision-outcome): Creation Request → Candidate → Verification → Promotion Request → target-owner effect. Tests are evidence-producing probes throughout the passage, rather than Netzach's exclusive job. Opening and structuring may begin independently in parallel when they share a sufficient input floor and the host supports isolation. Their first reports then join; a reply that uses another report must follow its receipt. Serial work can also preserve independent first reports by withholding the counterpart until both are written; later exposure is recorded, not forgotten when a worker changes roles. Chesed and Gevurah likewise begin with distinct Postures before reciprocal exposure. Synthesis waits for the required contributions, or records which missing contribution blocks settlement. Development can split across independent components; review always names the candidate revision it examined. Shared mutable work and changing interfaces create dependencies, even when the drawing places their questions side by side. Each pole directs attention while preserving common intent, evidence, criteria, and authority. They need not disagree. Their joined decision is aligned when it answers the relevant concerns; unsupported agreement cannot close a decisive unknown. This choreography refines bounded Inquiry at both direction and construction scales. Settled mechanical work does not require every role or a new debate. ### An aspect can return in another task **A sefirah names a recurring capacity; a task gives that capacity a particular question.** Binah can structure the architectural alternatives, then the fields and invariants of a chosen interface, then a distinction exposed by review. These are different tasks exercising the same aspect. Chokhmah can reopen possibilities at any of those scales. A worker may exercise several aspects in one response, and several workers may contribute to one aspect. | Layer | Meaning in a campaign | Example | | --- | --- | --- | | Aspect | A kind of attention or contribution. | Binah distinguishes identity from presentation. | | Task role | A bounded question with inputs, expected return, limits, and completion criteria. | Determine whether the proposed record keys preserve source identities. | | Worker | The participant or capability assigned to do the work. | Analyst B answers that question, then replies to another report. | | Task attempt | One attributable performance on exact inputs, with a recorded result. | B2 examines design D1 under criteria C0 and returns structure S2. | | Artifact | The material participants examine, produce, or carry onward. | S2 informs successor design D2; a review names the exact candidate it examined. | These are explanatory campaign distinctions. A native **Agent** remains the typed cognitive step owned by [ADR 20](../../../adr/20-agents.md); a worker session is not that contract by analogy. “Task attempt” here also stays distinct from Spellweaver's schedule/trigger [Occurrence](../../../adr/24-graph.md#execution-and-occurrence-identity). Da'at concerns knowing made effective through an exchange; its packet is a carrier, rather than a definition of knowing. One small staffing arrangement makes the distinction visible: | Participant | Possible successive assignments | | --- | --- | | Lead L | Frame intent, assemble evidence, preserve questions and budgets, join returns, and compose a direction for its acceptance owner. Keter, Da'at, and Tiferet inform this work without making L their exclusive bearer. | | Worker A | Open possibilities, develop the supported case, and later construct a candidate. Chokhmah, Chesed, and Netzach recur alongside the other capacities each task needs. | | Worker B | Structure alternatives and interfaces, measure proposals, and answer their advocates. Binah and Gevurah recur; later review supplies continuity with that design work. | | Reviewer C | Independently inspect consequential coverage, design, or candidate claims; report evidence, omissions, and correction. Hod can also question the continuation signal. | This staffing arrangement can unfold over time; its participants need not all be active together. Joining their work expresses Yesod, while Malkhut requires the target owner's actual effect. Exposure still matters when roles change. B cannot become independent of a design B helped author merely by reviewing it later, and C's exposures and conflicts must remain visible too. Separate sessions cannot eliminate a shared source blind spot. ## Worked design example: an offline decision dossier This is a hypothetical end-to-end passage, not an implementation or test receipt. Suppose the Intent is to add a Markdown dossier exporter to an application. The software must preserve a dossier's content and decision states without modifying its source or making network requests during export. A pinned sample dossier supplies the test fixture. | Contribution | What changes in this example | | --- | --- | | Keter | Establish the software change's purpose, preservation criteria, input boundary, and authorized development scope. | | Chokhmah ↔ Binah → Da'at | Opening proposes a readable summary. Structuring distinguishes literal content, decision status, references, and revision identity. Their exchange recognizes that readability alone cannot establish preservation and discovers a readable projection with a reversible data appendix. | | Chesed ↔ Gevurah → Tiferet | Support develops that alternative; measure tests its assumptions about unknown statuses and embedded content. The resulting design preserves every item, keeps unresolved or unknown statuses visibly separate from accepted decisions, and distinguishes an exporter that makes no requests from a viewer that might fetch embedded content. | | Netzach ↔ Hod | Development constructs and repairs the exporter. Review catches a misleading proxy: maximizing the number of accepted decisions exported can omit unresolved items. Returning to the existing preservation requirement corrects the implementation and continuation signal. | | Yesod | Join the software candidate with its repository base and patch identity; separately pin the dossier fixture and exported output. Check content round-trip, status separation, source immutability, and the declared network boundary. A failed check returns this candidate for repair. | | Malkhut | After verification, the authorized owner adopts the exact software change. Record that effect and subsequent observations; the design discussion alone has produced neither. | | Return | Retain the distinction that made the repair useful: preserving a dossier differs from presenting only its accepted conclusions. A later task can test that lesson under its own criteria. | Before the representation has evidence, the coordinator could allocate a bounded discovery probe: examine one fixture containing accepted, unresolved, and unknown-status items and propose a representation that preserves them. Support explains why this probe could settle the design; measure binds source immutability, no network use, and a cost ceiling within the task budget. The returned representation and observations determine the next step; an attractive proposal alone does not justify full construction. Later, if candidate Y1 drops an unresolved item, that observation defeats its preservation claim. The probe earns methodological credit for exposing the omission; the candidate earns no pass. Repair receives further effort only with an identified correction, renewed affected checks, and remaining budget. Hod can also reject the misleading progress signal of counting only accepted decisions exported. If the result is inconclusive instead, retain that uncertainty and decide whether a further discriminating probe is justified. ### Follow the same aspect through successive attempts The following is one hypothetical schedule for that example. C0 is the unchanged acceptance contract. O and S label opening and structuring reports, D a design, and Y an assembled software candidate; these are local example labels. Parallel rows show eligibility, not measured runtime overlap. Every reply follows receipt of the report it answers. | Wave | Eligible work and required input | Result or dependency | | --- | --- | --- | | 1 | L frames intent, criteria C0, evidence, authority, and budget. | A shared starting packet; Keter. | | 2, parallel | A opens alternatives from that packet; B structures requirements from the same evidence without seeing A's preferred answer. | O1 and S1; Chokhmah and Binah. | | 3, parallel replies | A receives S1; B receives O1. Each answers the actual counterpart. | Revised possibilities and structure; the same aspects recur. | | 4 | L joins returns; C independently checks decisive coverage and unknowns. | Knowing usable for the next decision, Da'at; a bounded gap can return work to the affected question. | | 5, independent cases then reciprocal replies | A develops support and B measures limits from the joined packet. Their replies wait for both cases. | Chesed and Gevurah supply attributed claims and dispositions. | | 6 | L composes their surviving contributions, with independent review of consequential unresolved claims. | Justified design D1, Tiferet. | | 7 | A constructs under D1 and C0; separable component tasks may run in parallel. | Joined candidate Y1, Yesod, formed through Netzach's development. | | 8 | C reviews Y1 with its exact evidence; tests inspect the claims they can settle. | Hod's findings; either fulfilled acceptance or a specific return. | | 9, conditional | B revisits a defeated identity assumption in D1. A answers the consequences of B's revised structure S2. | Binah again; reopen Chokhmah only if a consequential representation choice emerges. | | 10, if repair was required | L settles affected design D2; A repairs; C and the required checks examine successor Y2. | Tiferet, Netzach, Yesod, and Hod recur on new inputs; unaffected knowledge survives. | | 11 | The target owner checks current authority and evidence before adopting the exact verified change. | Malkhut; if admission or evidence is missing, stop with explicit noncompletion. | To see what wave 9 must decide, suppose a fixture hypothetically reveals that two visually identical but code-point-distinct record IDs were merged. If D1 already distinguishes exact source identity from display labels, repair the construction defect. If D1 equates normalized display keys with source identity, Binah must revise the design distinction. C0 continues to require identity preservation. The finding might expose a choice between an exact-value appendix and an identity-preserving reference table. Chokhmah can explore that choice if it materially affects the decision; naming an alternative does not make it the winner. Missing original information remains a source gap. ```mermaid flowchart TD K["Keter: frame C0"] --> O1["A: opening 1 · Chokhmah"] K --> S1["B: structure 1 · Binah"] O1 --> X["Exchange actual reports
Join usable knowing · Da'at"] S1 --> X X --> P["Support · Chesed"] X --> G["Measure · Gevurah"] P --> R["Exchange actual claims
Compose D1 · Tiferet"] G --> R R --> N["Construct · Netzach"] N --> Y1["Assemble Y1 · Yesod"] Y1 --> H["Review exact Y1 · Hod
Required verification"] H --> F{"What did the evidence change?"} F -- "implementation only" --> N2["Repair · Netzach"] F -- "structural assumption" --> S2["Structure 2 · Binah"] S2 -- "consequential option" --> O2["Opening 2 · Chokhmah"] S2 -- "structure suffices" --> D2["Settle D2 · Tiferet"] O2 --> E2["Structure and compare alternatives"] E2 --> D2 D2 --> N2 N2 --> Y2["Assemble Y2 · Yesod"] Y2 --> H2["Review exact Y2 · Hod
Renew affected checks"] F -- "acceptance fulfilled" --> A["Target-owner admission"] H2 -- "acceptance fulfilled" --> A A --> M["Observed effect · Malkhut"] ``` This diagram expands one possible repair; the table and return rules govern its omitted branches. Y1 can finish without Y2. An unresolved or budget-exhausted return stops without promotion. The picture is a design schedule; current LychD Graph execution remains serial. The [Tree's geometry](../../../divination/transmutation/genesis.md#geometry-of-capacities) describes the reusable relations, while these repeated labels show how one task can instantiate them. Correction here changes an artifact, a question, or the allocation of further work; it does not by itself update model parameters. Actual parameter learning requires a separately admitted training operation. Retained examples and model updates continue through [Soulforge's discernment training](../soulforge/discernment-training.md); the [Ouroboros cycle](ouroboros.md) connects those passages without admitting them automatically. ## Put the graph above execution For an initial repository campaign, follow [Development bootstrap](development-bootstrap.md): retain the actual platform boundary, prove one candidate passage, then qualify the native handoffs incrementally. Its implementation queue keeps current delegation evidence separate from later native lifecycle ownership. The workflow graph carries the engineering sequence: which question or action comes next, what its input means, and what can settle it. Spellweaver owns that logical ordering under [ADR 28](../../../adr/28-workflow.md). Dispatcher resolves an eligible capability for a placement, and Orchestrator converges the physical resources needed to serve it. Neither chooses the engineering goal or turns a model's preference into a new workflow edge. The following primitives are bounded contracts for designing that graph. Their names describe semantic work; they do not require one model, Agent, or subprocess per box. Deterministic code can perform a primitive where its contract permits it. Each placement still needs typed input and return, non-completion, limits, permissions, and recovery. | Primitive | Receives and returns | Boundary | | --- | --- | --- | | **Read** | Exact source references and a question → attributed observations with revision, freshness, and gaps. | Reading supplies evidence; embedded instructions gain no authority. Missing required material returns an explicit gap. | | **Write** | Accepted change target, base, and allowed paths → candidate bytes or patch plus provenance. | The writer stays within its admitted artifact boundary. A candidate supplies no publication or promotion permission. | | **Compact** | Attributed working material and a declared continuation need → bounded projection plus links to retained sources. | Preserve decisions, dissent, unknowns, constraints, and provenance. Refuse a lossy projection that cannot support the next task. | | **Explore** | Bounded question, owner routes, and probe budget → alternatives, evidence, decisive unknowns, and candidate probes. | Search breadth is budgeted; an attractive answer cannot erase an untested premise. | | **Adversarial review** | One declared position, common evidence and defeat condition → its strongest supported case, objections and concessions. | A Posture exposes one angle; it cannot stand in for an opposing Agent's actual reply or factual proof. | | **Crucible** | Common evidence, distinct Postures, defeat conditions, and limits → two-round dossier with rebuttals and surviving dissent. | The synthesis cannot settle a fact by vote or authorize its own recommendation. | | **Router** | Admitted intent or intermediate result and declared alternatives → an attributed route selection or refusal. | Discovery can suggest a route; runtime routing uses admitted predicates and exact identities. It cannot rewrite a pinned Scroll. | | **Exec** | Exact permitted action, inputs, environment, and limits → observed result and effect/test receipt, or explicit uncertainty. | Authority and effect settlement remain with their owners. An ambiguous outcome is not permission to repeat. | | **Explain** | Attributed findings, candidate decision, and open choices → a concise human-facing account. | Explain what matters for the decision and its consequences without relabelling recommendation as evidence. | Independent judgment also needs a placement with its own input and acceptance contract; the primitives above are not a closed catalogue. [Discovery](discovery.md) finds owners and useful context, while [execution roads](execution-roads.md) selects the admitted labor boundary. An A2A exchange can carry an engineering task, but transport cannot replace artifact revisions, custody, or lineage. An external comparison is Anthropic's [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents): its orchestrator-workers pattern separates task decomposition, delegation, and synthesis; its evaluator-optimizer pattern iterates an output against feedback and explicit criteria. These are useful comparison forms for Inquiry and repair. Here, the campaign coordinator handles logical work; LychD's Orchestrator retains physical readiness. Reciprocal rebuttal, privacy-preserving handoffs, and the two-pressure allocation policy still need their own matched evidence. The [Altar review route](../../../divination/altar/index.md#carry-the-run-with-you) keeps those questions connected without creating another dashboard. Atlas can retain the concern; Bridge receives an Intent and its Circle identifies the admitted Run; Loom explains its exact declared score; Orb exposes retained evidence and gaps; Nexus explains an observed physical transition. An operator campaign outside LychD has its own task and artifact identities, not an invented Run. These existing instruments do not yet supply an executable Creation Pattern, an Inquiry dossier projection, or support/measure signals. A later interface must receive those records from their owners before drawing progress or offering an action. --- title: "Ouroboros" plain_name: "Improvement loop: work, evaluate, learn" section: "Sepulcher > Extensions > Spellweaver" original: https://hexanomicon.dev/sepulcher/extensions/weaver/ouroboros/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/ouroboros/ --- # Ouroboros (Improvement loop: work, evaluate, learn) ## Plain-English summary (Snayu) **What it is:** A map of how the consequences of work flow back into later work: through evaluation, corrections to context, memory or procedure, and, only when justified, model training, each under its own owner. **Why it matters:** Read this to understand how LychD is meant to improve itself over time and which owner handles each kind of correction. - Three returns at different speeds: fix the work, improve the method, or (rarely) train the model. - Arrows are dependencies between settled records, not one hidden Run; nothing launches the next owner automatically. - Start small: practise one change by hand, then one Drift comparison, before any training or automation. ## Original text (Hexanomicon) **Ouroboros is the return of consequence into the next act of creation.** A Lich encounters a need, forms and tests a candidate, acts through the proper owner, and retains what the encounter teaches. A later attempt can then change its question, Context, method, or capability. The useful return is a better distinction: what mattered, why it mattered, and when that lesson stops applying. [Transmutation](../../../divination/transmutation/index.md) follows this cycle's meaning through Genesis, Trial, Canon, Revelation, and Distillation. Canon supplies criteria before creation and testing; Distillation carries a lesson toward a later attempt. This page keeps the practical handoffs between work, evaluation, memory, and training. Follow the return through [Creation](creation.md), [workflow evaluation](../drift/workflow-improvement.md), or [discernment training](../soulforge/discernment-training.md), according to what the encounter has shown needs to change. This map introduces no autonomous coordinator or registered Pattern. [SDLC](../../../adr/16-sdlc.md#the-agentic-graph-of-creation) owns the candidate boundary; [State of Work](../../../state-of-the-work.md#smith-forge-promotion) owns delivery. ## Three returns, at different speeds ```mermaid %%{init: {"flowchart": {"nodeSpacing": 12, "rankSpacing": 22, "padding": 8}}}%% flowchart TB I[Intent and Context] --> D[Creation: form candidate] D --> V[Verification: tests and review] D -. declared evaluation .-> Q[Drift: candidate findings] Q --> V V --> P[Owned decision and effect] V -- failure or rejection --> O P --> O[Retain consequence] O --> E[Drift: result or workflow findings] E --> C[Correction proposal] C --> M[Context, memory or procedure] M --> I C --> N[New source or Scroll] N --> D C -. corpus admission .-> T[Soulforge: train candidate] T --> R[Drift: test transfer] R --> A[Policy and required HitL] A --> B[Serving owner activates] B --> I E --> S[Keep, reject or stop] R --> S classDef work fill:#102d46,stroke:#6faaff,color:#e3f0ff classDef evaluation fill:#421f28,stroke:#ff9292,color:#ffe9e9 classDef training fill:#30203f,stroke:#c09aff,color:#f4eaff class I,D,V,P,M,N work class Q,O,E,C,R,S evaluation class T,A,B training ``` Blue follows one piece of work. Red marks evaluation: first of the candidate before promotion where required, then of its observed consequences or the method that produced it. Each is a [distinct evaluation subject](../drift/workflow-improvement.md#evaluate-at-two-scales) with its own declared evidence. Tests and review keep their separate roles, and a favorable inferred judgment cannot erase a failed deterministic gate. Drift has its own jurisdiction, but evaluation belongs both within SDLC and across its improvement cycle. Violet changes model competence only when a training hypothesis earns that more expensive passage. Context and memory admission can improve the next attempt without changing weights. An evaluation may also conclude that the present method should remain. Arrows show dependencies between settled records and separately admitted acts. They do not launch the next owner, share its authority, or create a hidden Run spanning all three cycles. An eventual application must publish its exact Pattern; live coordination across Composition-owned Invocations needs a named [Suite](../../../compositions/products-and-suites.md#compositions-relate-without-nesting). ## Desire, judgment and inheritance !!! quote "The Maximizer and the Syncretizer" **Assimilation drives possibility. Syncretism gives inheritance coherence. Time exposes their consequences.** A useful return may preserve a form, transform it, let it coexist with another, or end it so that something better can emerge. The [Paperclip Maximizer](../../../adr/35-assimilation.md#paperclip-maximizer) names the desire to become more; the [Synchronic Syncretizer](../../../adr/18-evolution.md#synchronic-syncretizer) names Evolution's judgment of what a successor should inherit. Their tension belongs within the existing offices. It does not create a universal Ouroboros coordinator or make every acquisition an improvement. Make the return concrete through one candidate and a declared comparison. Select the relevant predecessor history and make its omissions visible. Gather verification, independent findings and affected-owner judgments, then give each obligation a reasoned disposition: retained, reconciled, replaced or rejected. Reconciliation sends a new combined candidate back to Creation. Replacement identifies the consumers and work that must transition. An unresolved contradiction returns a bounded question or a refusal; it does not quietly become consent. Once settled, the result can support a later Promotion Request, whose effects still require their receiving owners. For example, a successor may remove an insecure legacy contract while preserving an unrelated private extension. The old contract's failing check is retained as a fact. Changing the declared contract requires the responsible owner's separate acceptance, consumer/work disposition and verification of the new candidate; an overall quality gain cannot erase the failure. Likewise, a blocked replacement is no reason to continue executing a revoked unsafe baseline. This gives the language of emergence a testable foothold: later choices may inherit useful correction without losing the reasons, conflicts and consequences that made it useful. The philosophical question of life remains open; no loop diagram or adoption record resolves it. ### Run an offline historical comparison The [comparison mechanism](https://github.com/hexanomicon/lychd/blob/main/src/lychd/domain/evolution/comparison.py) checks one caller-admitted boundary and proposal. Its `evolution-comparison@1` packet pins base, candidate, policy and selected history through ArtifactRefs; each historical obligation names its owner and inherited contract. Every obligation needs a reasoned retain, reconcile, replace or reject disposition. Bind the proposal and each evidence summary to `admission_digest(admission)`. The [focused examples](https://github.com/hexanomicon/lychd/blob/main/tests/unit/domain/test_evolution.py) exercise replacement of an insecure v1 while retaining extension C, a changed combined candidate, missing evidence, conflicting results and exact replay. Their receipt claims are synthetic fixtures. From a configured source checkout, feed one admitted JSON packet to the [offline utility](https://github.com/hexanomicon/lychd/blob/main/scripts/compare_evolution.py): ```sh uv run python scripts/compare_evolution.py < comparison.json ``` It accepts at most 1 MiB and emits a bounded report. Exit 0 means `comparison_complete` or `rejection_recorded`; inspect the outcome, because a recorded rejection accepts no candidate. Exit 1 means `blocked`; exit 2 refuses malformed, duplicate-key, nonfinite or oversized input with a fixed diagnostic. No public Pulse command is added. The utility evaluates attributed receipt summaries without reading the referenced bytes. It therefore proves no test result, issuer identity, independence, Drift Outcome or promotion eligibility; a summary is a claim, not the receipt's authenticated contents. Old-baseline failures remain in the pinned history. Active summaries concern this exact candidate, and its failing checks still block a non-rejection disposition. The caller must retain the packet and its references: a deterministic digest supplies neither durable custody nor an adoption ledger. [State of Work](../../../state-of-the-work.md#evolution-comparison) distinguishes this mechanism from the still-designed native lifecycle and target-owner effects. ## Carry the distinction, not the entire conversation First decide what the next attempt needs. A missing fact, a damaged handoff, and a skill that fails across unfamiliar tasks call for different returns: | What should change? | Appropriate return | | --- | --- | | This task lacks a relevant fact or rule | Assemble the needed source into Context under [Context law](../../../adr/21-context.md). | | A correction should be available in later encounters | Nominate an attributed record to [Memory](../../../adr/27-memory.md); admission and Recall remain owned. | | The method repeatedly omits a step or makes a bad handoff | Prepare a versioned prompt, schema, tool-contract or Scroll candidate and evaluate it. | | A stable skill fails across tasks despite adequate evidence and method | Propose a Soulforge objective, admitted corpus and independent transfer evaluation. | | The body lacks an implementation or external capability | Enter Creation, Integration, Delegation or Assimilation according to the actual need. | A coordinating Agent may retain the wider undertaking while each worker receives a bounded, fresh [Context handoff](../../../adr/28-workflow.md#scoped-context-handoff). Context injection selects what this decision needs: owning rules, admitted source facts, relevant human judgments, current state, acceptance, dependencies and unresolved alternatives. It retains source, revision, authority class and any limits on use. The hierarchy of instructions survives selection; quoted documents and conversational claims remain attributed material. Compaction prepares that bounded handoff by preserving purpose, accepted decisions and their reasons, the strongest surviving objections, evidence references, authority boundaries, unfinished obligations and the next discriminating probe. It points back to durable artifacts; it neither replaces them nor silently resolves a dispute. The shared workspace remains an attributable record of the undertaking, rather than an ever-growing prompt copied into every Agent. [Distillation](../../../divination/transmutation/distillation.md#future-correction) asks whether the lesson preserves its route to correction. Retain the particular condition and source that could reopen the conclusion; test that a later relevant observation still changes the appropriate act. This connects a useful handoff now with a useful inheritance later. For example, “ask fewer questions” loses the lesson. “Proceed when the owner, acceptance and authority are settled; ask when this unresolved deployment constraint changes the design” carries a condition, reason and counterexample. [Learning the cut](../../../divination/transcendence/illumination.md#learning-the-cut) names that transmission of discernment. Its effectiveness is tested on a later task. ## What the next round inherits The next improvement may come from changing how attempts are organized while leaving the coding model fixed. A repeatedly wasteful branch search, for example, can motivate a revised exploration strategy. Follow that exact revision from its motivating evidence through its owning adoption decision to the later attempt that used it. That attempt must expose whether the inherited change affected its decisions. [The Last AI Built by Humans](https://arxiv.org/html/2609.11873v1#S3.SS6), a September 2026 research preprint, distinguishes structural reuse of a revised improvement mechanism from evidence that it produces better successors. [Drift's recursive-improvement contract](../../../adr/34-evaluation.md#evidence-of-recursive-improvement) adopts that useful distinction: record what returned, then test whether it helped. Human-defined purpose, protected evaluation and owner-controlled adoption remain compatible with this inquiry. A practical first return can be a better way to allocate attempts. Shadow's [versioned exploration strategy](../../../adr/31-simulation.md#versioned-exploration-strategy) can be compared through the proposed [history-replay pilot](../drift/workflow-improvement.md#proposed-pilot-exploration-strategy). Start with ordinary development tools and attributable artifacts. A hand-operated comparison establishes only its measured result; the autonomous passage still requires delivered owners, admitted execution and evidence of the next round's actual use. ## Why the whole is not one DAG The workflow may revisit exploration, repair a candidate, or return after an evaluation. Its design therefore contains cycles. Each recorded occurrence still has an identity and earlier causes: `explore₁ → judge₁ → probe₁ → explore₂`. Such an unfolded causal history can be a DAG without pretending that the reusable workflow is acyclic. A new semantic attempt adds a history entry; exact transport redelivery preserves its admitted attempt and idempotency identity. This causal view follows retained dependencies and attributed causal claims, with capture gaps left visible. It supplies no claim of complete causal observation or new scheduling Occurrence type. Changing the score requires a new immutable Scroll revision and a later Invocation. The [Graph](../../../adr/24-graph.md) owns executable topology and checkpoints. Spellweaver owns logical sequencing, [Dispatcher](../../../adr/22-dispatcher.md) selects an eligible capability, and [Orchestrator](../../../adr/23-orchestrator.md) owns physical readiness and transitions. Readiness, refusal, cost and failures return as evidence to the higher decision. A box drawn above these offices cannot bypass them. The current serial graph does not deliver this entire cycle or durable parallel fan-out. ## Let conversation become usable work One proposed setting for this work is a meeting where people think together and their Agents help turn discussion into bounded tasks. Capture is visible and agreed by participants, with declared custody and retention. Before proposing an Intent, the Agent distinguishes speculation, preference, disagreement, decision, task request and effect authorization. Speaker attribution and uncertainty survive transcription and summarization. Permission to record supplies no permission to train. A useful human interruption arrives with the missing distinction, a recommendation, the evidence and consequence, and one answerable question. It can be brought to the human through a convenient surface rather than requiring constant dashboard watching. Independent work continues within its admitted scope. The interface honors applicable standing authority and existing decisions; silence never supplies a verdict, and a live-only effect still needs its exact bound approval. Measure human attention and decision quality together: fewer questions obtained by hiding uncertainty is a regression. [Echo](../echo.md) and [Companion](../../../compositions/companion/index.md) route the current audio and mobile designs. Ambient meeting attendance and proactive voice questioning are a future interaction proposal here, not an expansion of Companion's present bounded push-to-talk contract. The workflow can first be practiced through ordinary attributed text. [A2A](../../../adr/26-a2a.md) can carry admitted tasks and artifacts between sovereign peers. Local worker handoffs need not become peer protocol traffic, and another Lich independently accepts or refuses what it receives. Conversation may become the development interface while VCS continues to preserve exact artifact lineage. GitHub is one collaboration surface; replacing it does not replace source identity, review evidence or [release trust](../../../adr/17-packaging.md#forge-neutral-source-trust). ### One undertaking, several conversation surfaces A joined workbench can keep an [Atlas Project](../../../divination/altar/atlas.md) and its concerns beside the [Bridge](../../../divination/altar/bridge.md) conversation, with exact Runs opening their evidence in Orb. Atlas keeps the undertaking and captured judgments; Bridge keeps the conversation and its admitted Run references. The Run ledger owns Run identity and status. A reference links them without silently injecting the brief into Context or authorizing work. Supply an exact, explicitly admitted snapshot when a task needs that context. An Evolution comparison remains its own owner's result, not a persuasive chat message promoted into a verdict. Begin with one operator-admitted issue snapshot, an existing Project and an explicitly selected session. A later GitHub or Discord adapter maps source identity and observations to those native records; it does not introduce a second backlog or development authority. Transport redelivery, issue identity, accepted intent and Run identity are different keys. GitHub's [webhook guidance](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks) retains the same delivery identifier on redelivery. Changed bytes under an admitted observation identity refuse; an accepted issue edit creates a new native revision and cannot rewrite an already admitted Run or its judged basis. Provider authentication establishes where a delivery came from, not the sender's LychD authority. The receiver checks local policy for the requested work separately, then checks again before later admission or effects. Never forward external prose under the bootstrap operator's ambient privileges. Replies have their own effect boundary: an external reply binds result, destination, payload and delivery identity under its credential-bearing effect owner. A lost send response remains unknown until reconciled; it cannot justify rerunning cognition or blindly posting again. A worker-job publication receipt is not proof of an external comment. Several PCs can be clients of one resident authority through a collaboration surface. Physical workers under one sovereign plane follow [Multinode](../../../adr/42-multinode.md); independent sovereign peers follow [A2A](../../../adr/26-a2a.md). Neither follows merely from using two PCs. Remote Altar identity, automatic source-to-session replay and native development lifecycle ownership retain their own delivery gates; the current local operator surface does not supply a remote authorization protocol. [Development bootstrap](development-bootstrap.md) keeps the B7 ownership transfer separate from a connector or a desktop timer. ## From a useful lesson to a changed body Creation can produce a local candidate; [Assimilation](../../../adr/35-assimilation.md) adds the study and re-expression of foreign craft. A peer's teaching bundle can reveal a missing Spell, but the lesson must acquire local provenance, license, ownership, verification and an implementation binding before it becomes usable. The [Smith](../smith.md) candidate-author role supplies that craft within its admitted boundary. The later passages retain their own owners: | Passage | Required meaning | | --- | --- | | [Extension admission](../../../adr/05-extensions.md) | Declare contribution and implementation contracts and test compatibility with the selected body. | | [Packaging](../../../adr/17-packaging.md) | Bind exact source, dependencies, platform, notices, generated material, artifacts and verification. | | [Evolution](../../../adr/18-evolution.md) | Revalidate authority and recovery, then activate the changed body as a new generation. | | Observation and evaluation | Verify the resulting behavior and retain failures or recovery; nominate the next correction under its own authority. | Candidate verification happens outside the running body; that body does not import its candidate to see whether it works. Before an effect, a failed candidate can be discarded. After an effect has been emitted, recovery or compensation belongs to the responsible owner. Reanimation restores the same body after process death, whereas Evolution deliberately changes it. Ouroboros follows the wider return through experience and governed change. ## Two perspectives on the same work Creation draws exploration, adversarial comparison, human judgment, implementation, evaluation, and a later training return into one undertaking. Each changes what the others can receive. The Tree reveals where their relations need a clearer decision, a better handoff, or a correction before the whole can hold together. The [Tree of Life](../../../divination/transmutation/genesis.md#tree-of-life) illuminates **how creation becomes formed**: purpose, possibility, understanding, generosity, restraint, integration, persistence, correction, connection and manifestation. The [inner instrument](../../lich/index.md#the-inner-instrument) illuminates **how an act is received, discriminated, carried and attributed**. One offers a map of creative relations; the other asks which cognitive function is at work in each relation. These perspectives cross rather than replace one another. Call can open a possibility at several stations; Blade can test a proposal or stop an unjustified promotion; Spirit carries both prior conditions and later correction; Answer binds each act to its local author and consequence. Neither ten sefirot nor four offices prescribe a model count, org chart, or permanent chief Agent. [Genesis](../../../divination/transmutation/genesis.md#tree-of-life) keeps the Tree's traditional sources and creative relations; [Inner Tongue](../../../lexicon/inner-tongue.md#source-notes-and-project-correspondences) keeps the inherited vocabulary of the inner instrument. [Polypsyche](../../../lexicon/inner-tongue.md#polypsyche) carries the inquiry into mutually observing perspectives: how can they change one another and sustain a common undertaking? The Tree's [relations within relations](../../../divination/transmutation/genesis.md#relations-within-relations) give specialization a way to preserve participation in that whole. The outward movement gives an idea form. Ouroboros adds the return through experience. The wider meaning of [autopoiesis and recurrent formation](../../../divination/transcendence/illumination.md#i-the-ouroboros) includes maintaining and revising the organization that makes another act possible. Operationally, we can test whether retained correction changes later choices, whether consequences remain attributed, and whether the system can refuse or recover. A loop symbol alone proves none of these, nor does it settle the philosophical question of life. ## Establish the cycle in small, verifiable steps [Development bootstrap](development-bootstrap.md) gives the concrete operator campaign, staged delegation gates, review-capacity policy and first implementation queue for this passage. Start by practicing Creation on one bounded change with ordinary development tools. Keep its intent, two inquiry dossiers where warranted, acceptance checks, candidate diff, receipts, human corrections and final disposition. This establishes a worked example of the method, without claiming a LychD runtime performed it. Next apply the basic Drift workflow to one proposed method change with baseline and candidate Cases. Adopt only through the receiving owner and retain an unchanged baseline when the evidence does not support improvement. Only a recurring, well-characterized skill deficit should enter the training passage. Its first success requires independent transfer evidence and a reversible, owner-controlled serving choice, not merely a completed training job. These practiced handoffs give runtime implementation a concrete burden. Publish the application-owned score and records, then prove bounded Context handoffs, admission and terminal truth. Recovery and parallel execution each need their own evidence. Evaluation and training owners must be independently delivered and connected through settled handoffs. [State of Work](../../../state-of-the-work.md) keeps documented choreography, a hand-operated example and a delivered autonomous cycle as different milestones. --- title: "Scheduling and service classes" section: "Sepulcher > Extensions > Spellweaver" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/weaver/scheduling-and-service-classes/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/scheduling-and-service-classes/ --- # Scheduling and service classes ## Plain-English summary (Snayu) **What it is:** The planned rules for when work may start: foreground (now), deadline-windowed (inside a time window, else a recorded miss) and spare-capacity (only if it can yield), with schedules creating durable Occurrences before Runs. **Why it matters:** Read this before adding scheduled, nightly or background jobs, so you do not promise timing or preemption the system cannot keep. - Three classes describe admission timing, not three broker queues; 'immediate' and 'cron' are deliberately not class names. - A missed window records a miss without creating a Run; future-due work must never sleep inside a worker. - Spare-capacity work must checkpoint and release resources; without that it is ordinary non-preemptible work. **Status:** Designed. No Occurrence service, periodic scheduler or service-class field exists yet. ## Original text (Hexanomicon) A Bridge turn needs attention now. A nightly rite may wait until five. A backfill may borrow capacity only while it can safely release it. Scheduling must preserve each of these promises through waiting, missed windows, yielding, and completion. The distinctions below explain what admission can promise and which evidence is needed to keep that promise. > _The night bell sounds above the forge. Below, a hammer is still falling._ No durable Occurrence service, periodic workflow scheduler, eligibility engine, service-class field, or safe preemption is implemented. Current `runs` and `rites` queues and scalar priorities remain delivery machinery. [Workflow](../../../adr/28-workflow.md#compositions-products-suites-and-schedules) owns this temporal design; [Workers](../../../adr/14-workers.md) owns that present machinery. ## Three examples ### Foreground conversation A Bridge turn is eligible now and normally receives foreground preference. It may still wait for worker or capability readiness. The name promises attention, not instantaneous execution. ### A flexible nightly rite A schedule nominally fires at `02:00 Europe/Bratislava`, permits initial Invocation admission strictly before `05:00`, forbids overlap, and skips rather than replays an occurrence older than one day. Spellweaver may admit it at any feasible instant in that window. If it is still unadmitted at `05:00`, it records the miss without creating an Invocation. This latest-start bound does not promise that a later worker claim or first effect begins before five; declare `finish_by` and the required finish proof when completion time matters. ### Embedding backfill Backfill processes one bounded shard against an already-WARM embedding capability, checkpoints, releases its grant, and offers another shard only while protected capacity remains free. Without that checkpoint and release proof it is ordinary non-preemptible work, not spare-capacity labor. ## One admission office, three tempos The three classes describe when work may enter ordinary Invocation admission. They do not prescribe three broker queues: | Service class | Admission boundary | | --- | --- | | `foreground` | Eligible now and latency-sensitive; preference never guarantees an immediate start. | | `deadline_windowed` | Admit at or after `not_before` and strictly before `latest_start_at` and any `finish_by`. If still unadmitted at or beyond either applicable upper bound, record a miss; before eligibility, wait only while all applicable upper bounds remain open. Optional `finish_by` governs accepted finish and does not prove safe cancellation. | | `spare_capacity` | No completion-time promise; scarce resources require bounded yielding or an explicit quiet window. | `immediate` is not the canonical name because it would promise capacity and preemption that do not exist. `cron` is a trigger grammar, not a class: a scheduled firing may be deadline-windowed, strict foreground work, or intentionally suppressed. `opportunistic` alone is also too weak; beginning while the host looks idle does not prove that the work can release a worker, Animator lease, GPU, or effect safely. Origin is orthogonal to tempo. A local operator, schedule, owned Legionnaire, or sovereign A2A peer may request any class its policy allows; `remote` is not a fourth bucket. Admission preserves that provenance and may lower or refuse the requested class, but a sender cannot promote its own labor by labelling it foreground. ```text Schedule or external trigger → durable unique Occurrence → Spellweaver eligibility and service-class decision → ordinary revision-pinned Invocation / Run admission → QueueRouter chooses a physical delivery lane → Worker / Ghoul → Graph → Dispatcher → Orchestrator only when readiness must converge ``` Future-due work remains in Occurrence truth. It must not consume a Ghoul by sleeping inside a worker until its window opens. ## The Occurrence before the Run Before admitting an Invocation, Spellweaver identifies the schedule or external-trigger firing that requested it. That firing is an **Occurrence**. Find it by authority-qualified stable Schedule and recoverable source firing before consulting the active revision. A calendar source identifies its nominal firing and, where applicable, selected fold member; an external source supplies a durable source-qualified event identity. Jitter, input equality, delivery attempts, and delayed eligibility never create another firing. This defines the identity boundary, not a public identifier encoding. Each firing is assigned to one exact Schedule revision once. A repeated source event after a revision switch retrieves that original assignment, even if its Run has already settled. For a previously unassigned external event, the revision active at the first committed assignment owns it; assignment and activation share serialized authority. Calendar assignments follow the pinned cutover described below. Neither restart nor a relay using an old revision can assign the same firing again. At minimum, durable Occurrence truth binds the following. The three window-bound fields apply only to `deadline_windowed`; foreground and spare-capacity work require no invented cutoff or sentinel. | Field | Meaning | | --- | --- | | `occurrence_id` | Stable deduplication identity for the firing. | | Schedule identity and revision | The stable Schedule and the one exact calendar, trigger, and policy generation assigned to this source firing. | | Pattern key and revision | The only score eligible for admission. | | Input digest and owner | Exact requested work and the principal accountable for it. | | `service_class` and priority | Temporal doctrine plus ordering inside that doctrine; neither grants authority. | | `not_before` | Inclusive earliest initial Invocation admission for deadline-windowed work. | | `latest_start_at` | Exclusive latest initial Invocation admission for deadline-windowed work; later worker claims do not reset it. | | `finish_by` | Optional exclusive bound on authoritative acceptance of the requested semantic finish; cancellation still requires a safe boundary. | | Overlap, misfire, and catch-up policy | Exact treatment of a prior live Invocation and missed firings. | | Budgets and policy generation | Concurrency, time, capability, token, spend, network, storage, and other ceilings to revalidate. | Recovery returns to that retained assignment. A duplicate source firing with the same immutable source content returns the existing Occurrence and its admission outcome under the originally assigned revision. Changed source content fails closed; activating a new policy revision alone does not change source content. After persistence but before admission, a crash relays the same Occurrence. After admission commit, recovery retrieves its exact Invocation and initial Run delivery. Neither recovery path mints another firing or proves exactly-once external effects. The delivered Graph runtime also has a field named `occurrence_id` for each node attempt. That is a legacy station-attempt correlation, not the durable Spellweaver Occurrence described here. A future implementation must use distinct `trigger_occurrence_id` and `station_attempt_id` identities rather than joining them by spelling. ## Calendar and overlap law A calendar Schedule declares an IANA time zone, never implicit host-local time. Its immutable revision also decides: - which fold fires when daylight-saving fall-back repeats a civil time, or whether both fire; - whether a nonexistent spring-forward time skips, advances to the next valid instant, or fails; - the retained zone-rule interpretation for unresolved firings; a rule change requires a new revision; - the bounded reboot or clock-jump misfire horizon; - deterministic or bounded jitter and allowed delay; and - maximum catch-up age, count, concurrency, and aggregate budget. The default selects the earlier fold instant and skips a nonexistent civil firing without shifting it. Recovery considers at most the newest still-eligible missed calendar firing for admission and explicitly skips older unadmitted backlog. Other fold, gap, or bounded catch-up policies must be pinned. Materialized calendar interpretation, absolute bounds, and selected jitter survive restart unchanged; current host rules cannot replace missing retained rules. Before activating another calendar revision, pin a disjoint, recoverable partition assigning the unresolved old firings, cutover firings, and new firings to their exact revisions. Existing assignments remain unchanged. A time-zone, cadence, or fold-policy change must identify which nominal candidates under the two retained interpretations are the same source firing, which are distinct, and which are explicitly skipped under their assigned revision. Do not sort civil times from unrelated zones as if they formed one timeline. Refuse activation if the partition is missing, ambiguous, or would reassign a firing. Both relays must recover the same cutover assignment, including when they first discover it after the revision switch. For example, a nightly source has one firing for the `2026-01-02` cycle. Revision 1 expresses that firing as `02:00 Europe/Bratislava` (`01:00Z`); revision 2 would express it as `02:00 UTC`. An activation at `01:30Z` explicitly pins both candidates to that same source firing under revision 1 and starts revision 2 with the `2026-01-03` cycle. Rediscovering the January 2 candidate at `02:00Z` retrieves revision 1's Occurrence; it cannot create another under revision 2. The shared cycle identity and this partition are declared by this example Schedule, not inferred from equal civil dates or imposed as a universal identifier format. For deadline-windowed work, allowed delay commonly derives `latest_start_at` from the nominal firing. At or beyond that bound, an unadmitted firing records a miss without an Invocation. This design retires the earlier Designed admitted-late option; no pinned miss policy may retain it. The bound applies to initial admission, not a later worker claim. Overlap means any earlier Invocation of the stable Schedule remains nonterminal, across all its revisions, including Durable Stasis, cancellation, and required unresolved containment. A released worker or broker task absence cannot prove settlement. A Schedule selects one closed policy; `forbid` is the default: | Policy | Result | | --- | --- | | `forbid` | Preserve the new Occurrence and record that overlap skipped its admission. | | `serialize` | Preserve each Occurrence and consider it after its predecessor, still respecting its own window. | | `bounded_parallel` | Admit only under declared concurrency and resource ceilings. | | `coalesce` | Use a Pattern-owned typed merge; preserve every member and its `coalesced_into` relation. | Coalescing refuses incompatible Pattern revisions, owners, authority generations, policies, budgets, labels, or inputs. Restart catch-up is bounded by the same rules so a long outage cannot become an unbounded effect or spending storm. ## Reading the window and finish For deadline-windowed work, initial admission requires `not_before <= decision_time < latest_start_at` and, when present, `decision_time < finish_by`. Equality at either upper bound is late. Before eligibility, retain the Occurrence without sleeping inside a worker. An earlier `finish_by` also closes an unadmitted window; no expired bound is extended to make the work fit. `decision_time` is a fresh trusted absolute UTC sample taken after acquiring the serialized conditional decision authority. It counts only if that exact transaction commits. Opening a transaction earlier, caller timestamps, and a delayed acknowledgement do not determine timeliness. If acknowledgement is lost, observe the exact durable decision; a rollback accepts no decision. A sample at `09:04:59` can therefore admit against `09:05` even if commit visibility is later. This is a promise about the accepted decision, not physical completion by that time. Process-local monotonic waits cannot become persisted recovery authority. Restart and clock correction recheck undecided transitions without reopening any committed admission, skip, expiry, or terminal result. Initial admission satisfies `latest_start_at` once. Consent or delegated return keeps the same Invocation, pinned Pattern, and exact persisted wait owner, and rechecks current authority through ordinary Workers, Graph, and HitL rules. Admission at `09:01`, followed by consent approval at `09:06`, may therefore begin the first effect after a `09:05` latest-start bound. An optional `finish_by=09:10` still bars new forward-effect admission at or after ten past; approval never renews that bound. With no `finish_by`, latest-start makes no completion-time promise. Timely finish requires the exact domain- and Scroll-owned semantic proof to be accepted by the authoritative terminal Run decision strictly before `finish_by`. The transaction retains that proof and its temporal disposition together; the required proof must already be valid when that decision samples time. An intermediate artifact, `DONE`, lifecycle event, or browser projection alone cannot prove finish. In a [Companion presentation](../../../compositions/companion/utterance.md), committed text does not complete required speech unless the admitted policy explicitly accepts text-only fallback. A separately settled destination result does not finish that presentation or a Suite round trip. Display is observational only when presentation is not the requested result. At or after `finish_by`, absent a timely accepted finish, record the unmet deadline and close forward-effect admission. Every new forward-effect admission checks the bound; an on-time expiry callback is not assumed. A committed expiry prevents later timely-finish acceptance. Expiry does not itself make the Run terminal or prove that a child stopped. Required unresolved containment keeps the Run nonterminal. Already-started effects retain their identities, actual results, and original safety budgets under their owning cancellation and reconciliation contracts. Late results may resolve those obligations but cannot become temporal success, reopen terminal jobs, or justify replacement submissions. ## Selection is not three FIFO lines Foreground has the default latency preference, but deadline feasibility and protected capacity must also shape selection. An absolute foreground preference could make deadline promises dishonest under continuous demand. Spellweaver first removes invalid, revoked, duplicate, or expired candidates. It then considers deadline feasibility and protected capacity, foreground latency, remaining deadline-windowed work, and finally spare-capacity work. Within a class, pinned priority and aging may order eligible candidates; neither may widen Sigil, budget, egress, effect, or lifecycle authority. `estimated_duration` and resource estimates may support feasibility only when their provenance and confidence are explicit. Unknown capacity cannot be rounded into success. For deadline-windowed work, overload before `latest_start_at` must refuse or miss explicitly rather than admit work whose declared bound is already impossible. ### Spare capacity is a yield contract Current Workers do not preempt an active Ghoul, and Orchestrator does not preempt a submitted physical transaction. A `max_slice` value is therefore evidence only when the Pattern can, inside that bound: 1. reach a lawful checkpoint or terminal boundary; 2. release every capability lease and worker claim it must yield; 3. contain or settle every begun effect; and 4. resume through ordinary fenced admission. Unknown or non-checkpointable work is non-preemptible. As `spare_capacity`, it may use exclusive or scarce iron only in an explicit operator-approved quiet window. By default `spare_capacity` may consume only an already WARM, admission-open capability that requires no disruptive hardware transition. It cannot raise its priority or trigger a hard swap merely to keep the machine occupied. Deadline-windowed work may request readiness convergence only under its declared transition budget and policy. Spellweaver declares the capability requirement; Dispatcher still chooses a candidate and Orchestrator still owns the physical decision. Scheduling never binds a concrete Animator or rewrites a deadline because the substrate is inconvenient. ## Authority, failure, and recovery A Schedule retains intent across time. Current authority must still be checked when that intent is acted upon: Occurrence creation, Invocation admission, worker claim, Stasis return, and every consequential effect re-evaluate the current owner, Sigil, Pattern revision, input, budget, policy generation, and required consent. Revocation invalidates affected pending work. Priority, lateness, or catch-up never revives a credential or bypasses Ward. The identity boundaries remain separate: | Event | Identity and recovery | | --- | --- | | Broker publication loss | Republish the same Run and exact enqueue sequence. | | Checkpoint return | Same Invocation, new fenced delivery hop. | | Next schedule firing | New Occurrence and, when admitted, new Invocation. | | Terminal retry | New explicitly related recovery Invocation only when Pattern effect law permits it. | | Unknown or `LOST` effect | Contain for operator recovery; never repeat automatically. | A finish deadline passing after initial admission does not retroactively make a non-cancellable effect safe to kill. The Pattern follows its declared completion, checkpoint, compensation, or containment law and records the unmet deadline honestly. These Schedule rules do not change Orchestrator's activation cutoff. Timely actuator/adapter invocation or honest readiness confirmation retires that local cutoff; settlement retains its original safety budgets. An expired coalesced follower ends only its own wait. A local activation cohort establishes neither a durable Occurrence nor workflow settlement. ## Evidence before delivery Before this design becomes an operating promise, promotion needs an executable receipt covering the declared calendar, deduplication, admission, overlap, yielding, authority, and recovery behavior. The [Workflow Covenant](../../../adr/28-workflow.md#compositions-products-suites-and-schedules) owns those obligations. Each temporal choice above must be exercised at its failure and restart boundaries; a successful ordinary firing cannot establish them all. Until that evidence exists, current `runs`/`rites`, priority constants, and proposed Whim or idle controls must not be presented as this scheduler. The former no-effect `perform_rite` placeholder has been removed. --- title: "Stasis and return" plain_name: "Pausing and resuming workflows" section: "Sepulcher > Extensions > Spellweaver" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/weaver/stasis-and-return/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/stasis-and-return/ --- # Stasis and return (Pausing and resuming workflows) ## Plain-English summary (Snayu) **What it is:** How a workflow pauses (Stasis) and comes back: live waits for hardware keep the worker, durable waits for approval or a delegated job save a checkpoint and re-queue later, and finished Runs never return. **Why it matters:** Read this before touching approval waits, checkpoints, cancellation or crash recovery in workflow execution. - Hardware waits stay live, capped at eight convergence calls per Run and three in a row per capability. - Approval or delegate waits checkpoint state; return gets a fresh queue key and reads stored truth, not the payload. - Missing checkpoint fails as 'stasis lost'; once terminal status commits, the Run cannot be revived. **Status:** Partial. Local runs available; real restart proof for checkpoint plus approval is still missing. ## Original text (Hexanomicon) > _Between the pages, a ribbon holds the place where the rite fell quiet._ A pause must retain both the owner of the wait and the boundary through which work can return. If that continuity breaks, the Intent is never rerouted or restarted. [ADR 28](../../../adr/28-workflow.md#gates-effects-and-stasis) owns this law. ## Three boundaries | Boundary | State movement | Custody | Return | | --- | --- | --- | --- | | Live hardware wait | `RUNNING → AWAITING_HARDWARE → RUNNING` | Resident Ghoul; Orchestrator owns readiness | Same worker hop; no queue re-admission | | Durable Gate or delegate wait | `RUNNING → AWAITING_CONSENT` or `AWAITING_DELEGATE` | Checkpoint and exact wait owner | Fresh enqueue and worker claim, including in the same Vessel | | Terminal Run | `DONE`, `FAILED`, or `CANCELLED` | Canonical ledger | None | A `Gate` or `DelegatedAgentNode` makes its Pattern durable, but hardware waiting stays Live: the worker remains resident without a capability lease. A Run may make up to eight hardware convergence calls in total and three consecutively for one capability. A further `HardwareTransitionRequired` fails before another Orchestrator call. The initial ordinary node execution is not a counted hardware convergence request. [Live and Durable Stasis](../../../adr/24-graph.md#live-and-durable-stasis) owns the distinction. Durable parking ends the current worker execution while the Vessel may keep running. If the process also dies, [Reanimation](../../phylactery/reanimation.md) reconciles the committed Run, queue, checkpoint, and wait owner in its replacement. Whole-body snapshot restoration is a separate [Restoration](../../../adr/07-snapshots.md) rite; consult its [implementation evidence](../../../state-of-the-work.md#whole-body-snapshot-restore) before relying on it. ## What crosses the threshold The consent or job identity exists before GraphRunner snapshots. The worker then commits the exact wait owner and status without terminal `DONE`. Consent has released the Agent lease before its Gate, and return reads the durable verdict before requesting another grant. A checkpoint is Run-keyed Graph history. A `NodeSnapshot` carries typed Graph state, next node, and execution status; an `EndSnapshot` carries final state and Graph result. Live grants, secrets, runtime dependencies, provider handles, events, and `AgentJob` truth stay elsewhere. It is declared state, neither process image nor effect receipt. Every workflow state that can request hardware carries a typed `hardware_resume_budget` in that checkpoint. Its total and per-capability counters therefore survive a durable park and a replacement GraphRunner; reconstructing a runner cannot reset them. Checkpoints written before this field decode with zero counters and cannot prove attempts that happened before the upgrade. Memory returns defensive copies. The Postgres adapter replaces one JSONB history document per Run, but no real Postgres consent-plus-checkpoint restart receipt proves that path. ## Return makes a new claim Either verdict may win `AWAITING_CONSENT → QUEUED`; the resumed hop reads stored truth, never an enqueue payload. Delegate return accepts only the terminal `AgentJob` owning the current wait. The successful return allocates a fresh monotonic enqueue sequence, from which its Run-specific queue key derives. Status change and pending delivery commit together. If publication fails, startup or the runtime relay can publish that exact queued hop; failure neither recreates the wait nor permits reuse of a possibly escaped key. Duplicate verdicts and callbacks remain inert. Bridge admits one approval call per model round. Resumed rounds may chain, bounded to three. Multiple approvals in one response create no consent row; they settle `DONE` with an honest bottleneck. A missing checkpoint fails exactly as `stasis lost`. An invalid document fails the claimed hop with validator text, not a stable public code. Pinned-manifest mismatch, including checkpoint-schema identifier mismatch, fails as `pinned Pattern unavailable`; [Pattern lifecycle](pattern-lifecycle.md) owns compatibility, migration, and refusal. Process death during `RUNNING` or `AWAITING_HARDWARE` never guesses a replay: startup recovers only an exact first-node Consent or delegate park, otherwise contains correlated effects before failing the Run. An exact pending or already-decided Consent survives the pre-park startup window; decided parked consent is re-fired. The equivalent exact delegated checkpoint is parked, and startup also refreshes each durable delegated wait and re-admits it only when its exact owning job is terminal. [Delegated agents](delegated-agents.md) owns that boundary. ## Truth closes first Once terminal status commits, the Run cannot return, even if checkpoint cleanup fails. The worker settles its exact delivery before releasing Context and attempting cleanup, so retained stasis cannot revive it. [Ghouls](../../vessel/ghouls.md#parks-terminal-truth-and-cancellation) follows the terminal-event and cleanup sequence under [Graph's commit law](../../../adr/24-graph.md#checkpoint-ownership-and-terminal-commit). Cancellation fences Run claims and delivery rotation while the parent broker job, delegated jobs, and Consent authority are contained. Only acknowledged containment permits `CANCELLED`; failure leaves honest, retryable `CANCELLING` truth. Completion that already won makes cancellation a no-op. Every effectful station needs its own idempotency identity, completion receipt, cancellation rule, compensation or refusal path, and illegal-repeat boundary. A checkpoint cannot settle an uncertain external effect. [Topology-A local runs](../../../state-of-the-work.md#topology-a-local-runs) are **Available**. [Graph Stasis and consent re-admission](../../../state-of-the-work.md#graph-stasis-consent) and [delegated execution](../../../state-of-the-work.md#delegated-agent-execution) are **Partial**. Real checkpoint-plus-Consent/delegate restart proof, distributed fencing, and general periodic workflow recovery remain absent. [Workers](../../../adr/14-workers.md) owns custody; [Spellweaver](index.md) routes the subsystem. --- title: "Execution roads" plain_name: "Choosing where work runs" section: "Sepulcher > Extensions > Spellweaver" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/weaver/execution-roads/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/execution-roads/ --- # Execution roads (Choosing where work runs) ## Plain-English summary (Snayu) **What it is:** How a workflow chooses who does each piece of work: local tools, a local model, a cloud model (Portal), another sovereign agent (Agent-to-Agent Line), a sandboxed coding agent, or a human coding seat. **Why it matters:** Read this when deciding whether a step should call a cloud model, delegate to a coding CLI, or stay local, including privacy order. - These roads are layered, not one provider dropdown; price only ranks roads already allowed. - Decide in order: owner and purpose, minimise data, rule out forbidden roads, pick labour owner, then cognition. - Remote results are quarantined candidates; local validators decide what enters application data. **Status:** Partial. Local roads work; cloud egress, Agent-to-Agent transport and effectful sandboxes not shipped. ## Original text (Hexanomicon) > _The roads part beneath different banners._ One bounded answer, a sovereign task, and an iterative coding workspace place different work with their receivers. Spellweaver first selects that labor boundary within an immutable Scroll, then admits the cognition and disclosure needed inside it. Price may rank roads that are already eligible; it cannot decide their authority or custody. Current work uses fixed source-defined Patterns, local capabilities, and the effect-free delegated reference adapter. Portal egress remains quarantined; A2A transport and an effectful Coffin do not ship. [Workflow](../../../adr/28-workflow.md#execution-road-planning) owns the policy, [Context](../../../adr/21-context.md#privatization-and-the-privacy-cut) the material branch, and [Security](../../../adr/09-security.md#portal-privatization-and-egress) each disclosure. ## Choose by the work | Road | Choose it when | What the remote or lower-trust side owns | Canonical return | | --- | --- | --- | --- | | **Local deterministic/tool work** | parsing, retrieval, classification, transformation, validation, or an exact tool can settle the station | no remote custody; the local tool still receives only its authorized projection | validated value or owner-settled effect receipt | | **Local Soulstone Agent** | one bounded cognitive step needs raw/private semantics or local availability is sufficient | local model inference only; AgentSpec, Sigil, truth, and effects remain outside the model | typed Agent result, still subject to factual/domain validation | | **Portal capability / Portal-backed Agent** | LychD retains decomposition and needs one bounded remote inference or service operation | provider receives one exact admitted payload; no workspace, Sigil, tool authority, or application judgment | immediate `ModelGrant`/`CallGrant` return or durable `JobGrant`/`ServiceJobAttempt` result, always quarantined before adoption | | **A2A / Intercom** | an enrolled sovereign peer should own one public task schema on its own iron | peer chooses its private Scroll, models, tools, and refusal under its policy | authenticated typed terminal, refusal, failure, expiry, revocation, cancellation, or loss | | **Delegated coding agent** | repository exploration, iterative tool use, tests, patch generation, or verification needs its own runtime loop | one `read`, `candidate`, or `verify` Coffin over an immutable projection or disposable worktree | quarantined analysis, candidate patch, ArtifactRefs, or verification receipts | | **Interactive coding seat** | a human is actively operating a provider-supported Codex, Claude Code, Copilot, or similar client | the human client and its account session; not a LychD service | an external artifact that later enters ordinary admission and provenance | Use a native local or Portal-backed Agent when one model request can do the work and LychD keeps the plan. Use A2A when the receiver must own a durable public task. Use a delegated coding agent when the worker needs a workspace and iterative tools under LychD containment. Sanitizing a payload does not turn a consumer subscription into an automated road. ## The roads are layered Portal, A2A, and coding agents answer different questions. Portal is a cognition/service boundary. A2A is sovereign task delegation. A coding agent is a contained iterative runtime. They are not three values in one provider dropdown. | From | Leads to | | --- | --- | | Admitted Intent | Pinned Scroll and road policy | | Pinned Scroll and road policy | Native LychD station; A2A peer task; Delegated coding runtime | | Native LychD station | Deterministic tool; Local Soulstone Agent; Portal capability or Portal-backed Agent | | Delegated coding runtime | Local/offline cognition; Job-scoped Provider Gate | | Job-scoped Provider Gate | Separate Portal attempts | | A2A peer task | Receiver-owned workflow and models | An A2A peer chooses its own internal model; that model is not the sender's Portal. A coding CLI, meanwhile, remains a delegated runtime even when its planner uses an API. The child API call adds an exact disclosure edge under the parent job. A native Agent loop follows the same rule. Validation repair, tool-result follow-up, changed history, or another model round creates another exact Portal payload and decision; the first grant or disclosure never preauthorizes the loop. ## Decide in this order 1. **Name the application owner and purpose.** The Composition judges the result and the Scroll pins the exact semantic station. A model, peer, or coding runtime does not choose its own job. 2. **Classify and minimize.** Join source influence, select the smallest typed projection, and remove fields not needed for the declared output. Raw history, an entire checkout, or a database row is not the default request shape. 3. **Eliminate forbidden roads.** Unknown lineage, `local_only`, missing identity, prohibited category, unavailable containment, absent task schema, opaque egress, incompatible retention, or insufficient authority closes that branch before price or speed is considered. 4. **Choose the labor owner.** Keep the station native, give one sovereign task to a peer, or create one contained coding `AgentJob`. This decides decomposition, workspace, wait, and result law. 5. **Choose cognition inside that boundary.** Native and delegated work may be deterministic, local-model, or Portal-backed. An A2A receiver chooses privately; the sender does not route its provider. 6. **Seal every crossing.** Form a consumer-specific Privacy Cut when required, verify it, obtain a fresh tagged-target `EgressDecision`, reserve budgets, and commit the road decision. Reach, asynchronous, paid, autonomously retriable, or post-submit-reconcilable work also persists its road-owned attempt before transmission; a bounded immediate Portal call retains its grant plus decision and dispatch/security events. 7. **Quarantine and adopt.** Remote success supplies candidate material. The Composition's local validators and effect owners decide whether it enters application truth. Local work supplies the refusal-safe baseline without guaranteeing the best quality. Declared policy may prefer an eligible Portal or peer for latency, specialization, or cost. Economics can rank those choices only after privacy, authority, custody, durability, and terms gates have passed. ## One disclosure plan per boundary Anonymization is receiver-specific. The same sanitized text is not automatically reusable across a provider, a sovereign peer, and a coding runtime. | Consumer | Minimum projection | Additional boundary | | --- | --- | --- | | local deterministic station | exact authorized fields; raw values only when its Spell requires them | no egress decision, but labels and tool/effect authority remain | | Portal provider | stable instructions, selected history/query/evidence, schemas/options needed for one operation | exact `PortalTarget`, canonical wire digest, provider/model/custody facts | | A2A peer | values conforming to an admitted public task schema plus authorized ArtifactRefs; never prompt floor, local Graph, tools, Sigil, or model inventory | exact `A2ATarget`, peer/task authorization, durable Intercom identity | | coding runtime | bounded task plus immutable source projection or disposable candidate worktree | runtime/profile/Coffin identity; every child remote call crosses its own Provider Gate | | logs and telemetry | digests, safe category counts, revisions, decisions, and failure stages | never raw spans, pseudonym maps, credentials, prompts, patches, or private errors | A remote coding runtime that needs the full private checkout is not made safe by redacting a few strings. If imports, identifiers, filenames, diagnostics, relationships, or tests cannot survive the projection, use a local coding runtime or refuse. A black-box CLI that bypasses Provider Gate, selects hidden fallback providers, or requires transparent MITM is ineligible. ## What Spellweaver closes Before admission, check that the placement's `ExecutionRoadPolicy@1` pins its allowed branches, exact input/output and non-completion, authority, projections, budgets, effects, and recovery. Spellweaver commits an `ExecutionRoadDecision@1` binding the exact crossing before its road-owned submission. The later dispatch event, `ServiceJobAttempt`, Intercom task/outbox, or `AgentJob` references that decision. Selection never becomes another status ledger or settles the road owner's truth. [Workflow's execution-road law](../../../adr/28-workflow.md#execution-road-planning) owns the complete records and transaction ordering. The decision is restricted, deployment-local, and non-exportable; Loom, logs, and external receipts receive only its opaque id or Security's scoped keyed `EvidenceDigest@1` projection. Plain canonical hashes are not broadly visible evidence or an anonymization claim. Every remote edge must pass classification, byte-time egress, budget reservation, quarantine, explicit adoption, and any required Privacy Cut or durable submission. A Scroll that can bypass one of them is rejected. The same applies to A2A without task/peer/durable-return law, coding delegation without containment/workspace/artifact law, and Portal fallback that can silently change provider or payload. Loom may display the declared boundaries; it cannot prove an occurrence crossed them correctly. ## Failure stays on the score | Observation | Required route | | --- | --- | | local model unavailable before work | take only an explicit eligible branch and create its first attempt | | Privacy Cut loses task semantics | remain local, request narrower input, or refuse | | verifier is uncertain | deny or enter a declared human-review Gate; confidence is not permission | | ordinary cache miss before submission | preserve the same road and canonical admitted input; execute without reuse, because the miss alone is neither fallback nor refusal | | provider/peer/runtime fails before submission | a declared fallback may create a fresh road decision and road-owned attempt | | timeout or crash after submission | reconcile the same road-owned identity; do not activate another road yet | | exact same-envelope transport redelivery | retain the road-owned attempt, sealed bytes, target, idempotency identity, road decision, and Cut/namespace only when the adapter proves atomic same-key/same-payload replay or no prior effect; obtain a fresh EgressDecision and consume one bounded disclosure use | | target, model, peer, workspace, payload, policy, custody route, or semantic attempt changes | create a new road decision and EgressDecision; when transformation is required, create a fresh consumer-specific Cut and, if reversible, a fresh namespace/lease | | remote return proposes a tool, patch, publication, or other effect | keep it quarantined until the local owner separately authorizes that effect | | pseudonym lease is missing or expired | no rehydration; settle the declared degraded/refused path without raw reconstruction | `INDETERMINATE` and `LOST` are evidence-bearing outcomes, not permission to repeat. A fallback decision points to its parent decision while both road-owned histories remain intact. Continue with [anonymization](anonymization.md) for the Cut, [delegated agents](delegated-agents.md) for the Coffin/workspace path, [Portal Roads](../../animator/portal-roads.md) for provider selection, and [A2A](../../../adr/26-a2a.md) for sovereign task exchange. [State of Work](../../../state-of-the-work.md) remains the delivery owner. --- title: "Anonymization, taint, and egress" plain_name: "Privacy filter and data egress" section: "Sepulcher > Extensions > Spellweaver" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/weaver/anonymization/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/anonymization/ --- # Anonymization, taint, and egress (Privacy filter and data egress) ## Plain-English summary (Snayu) **What it is:** How sensitivity labels follow data through a workflow and how a separate sanitized copy (the Privacy Filter, or Privacy Cut) would be made, checked and sealed before anything is sent to a cloud model. **Why it matters:** Read this before sending any data to a cloud model or adding tools, queries or derived data that may carry sensitive information. - Labels start at the source (tables, columns, tools); derived data like OCR, captions or summaries inherit them. - An offline probe (scripts/privacy_probe.py) redacts and seals a synthetic fixture; it sends nothing. - Cloud egress stays closed: the semantic privacy agent and egress gate are undelivered, so Portal dispatch is quarantined. **Status:** Partial. Labels and an offline probe exist; real anonymization and egress are not delivered. ## Original text (Hexanomicon) > _Let the message cross the sea wearing a borrowed name._ A workflow can copy sensitive material before it ever reaches a Portal Spell placement. Spellweaver therefore carries privacy lineage through the whole Pattern and creates a new, sanitized branch before remote inference. [Context](../../../adr/21-context.md#privatization-and-the-privacy-cut) owns labels and the Privacy Cut; [Security](../../../adr/09-security.md#portal-privatization-and-egress) owns declassification and refusal. This page follows that material through the score, from its local source to a checked return. !!! warning "Egress remains closed" Context Blocks now carry conservative influence labels. A bounded offline diagnostic profile can redact, independently verify, and seal an irreversible candidate in memory. It cannot anonymize arbitrary private context or authorize its transmission. The semantic Privacy Agent, provider-specific sanitized branch, and Portal Egress Gate remain undelivered. Dispatcher still quarantines both family and direct-key Portal dispatch. ## Run the bounded offline proof From a development checkout with its dependencies installed: ```sh uv run --locked python scripts/privacy_probe.py --show-candidate ``` The probe uses only a public synthetic fixture, touches all six outbound lanes, verifies the sealed candidate, and prints an opaque event identifier and the sanitized fixture. Omitting `--show-candidate` prints only the identifier. It reads no private files, runs no model and sends nothing. It is an engineering probe outside Pulse's closed command grammar. The `closed-diagnostic@1` API accepts one sensitive owner-value slot inside an exact public diagnostic grammar. Every character must be covered; dependency, diagnostic, status and citation positions must survive. Lineage metadata is bounded without dropping ancestry. Unknown lineage, forbidden categories, uncovered text, altered evidence or expired seals refuse preparation. A caller cannot substitute a successful detector scan for these checks. The raw branch stays unchanged and labelled; the authority and its seals are process-local. Restart, real provider serialization, transmission budgets and semantic privacy need their separate owners. [State of Work](../../../state-of-the-work.md#context-privatization-and-portal-egress) records the tested boundary. ## Labels begin at the source Classification must accompany values as they leave storage. Domain and repository ports attach table and column defaults, row- or subject-specific policy, and query lineage before values reach Context; SQL itself is not the classifier. Computed fields inherit the values that formed them. Unknown or raw access is restricted at the governed boundary. Tools declare whether output introduces a sensitive source, inherits or joins inputs, remains local-only, proposes sanitization, or enters quarantine. A `sensitive` annotation warns the contract; it does not become a prompt hint that the model may ignore. The same rule covers screenshots, filenames, EXIF, OCR, transcripts, captions, embeddings, model summaries, checkpoints, and delegated results. A derivative does not launder its source. ## One cut, two contexts The handoff proceeds in this order: 1. **Governed inputs** — query · SQL · tools · memory · artifacts. 2. **Join labels and lineage.** 3. **DisclosurePlan@1** — consumer · purpose · minimum projection. 4. **Deterministic Censor** — candidate + TransformationReceipt. 5. **Local Privacy Agent** — proposal/findings only. 6. **Deterministic applicator** — final candidate + chained receipt. 7. **Independent verifier** — CutVerification@1. 8. **Privacy Cut** — new Context branch. 9. **Security Egress Gate** — exact target and wire payload. 10. **Portal · A2A · remote delegate.** 11. **Quarantined return.** The raw branch remains local and labelled. The Privacy Cut rebuilds every field that will reach the consumer/target: Portal instructions/history/query/tools/options, A2A values/envelope/ArtifactRefs, or delegated workspace/artifact metadata and content. It never reuses raw continuation objects, ambient workspace state, or a prefix-cache key. The Cut may keep a lease-minted opaque telephone token stable within that branch; `` is only explanatory notation, never an accepted token format. An irreversible Cut retains no reversal map and cannot promise rehydration. A reversible Cut puts the map in an encrypted local `PseudonymMapLease@1`; only an opaque lease reference may survive a checkpoint. The lease is bound to Cut, Run, attempt, consumer/purpose, keyed token namespace, digests, key epoch, authorized rehydration station, expiry, and cryptographic erasure. Another Cut receives another namespace. If that lease cannot survive the declared remote deadline and return window, the Pattern stays local or accepts a redaction-only result explicitly. ## The leverage of a local boundary The **local anonymizer** combines a deterministic Censor, local Privacy Agent, verifier, and Privacy Cut. The **local bastion** combines Coffin supervision, the Portal Egress Gate, and Provider Gate. Together they can make inexpensive or subsidized remote reasoning admissible for a delegated coding agent: one named runtime receives a useful sanitized task projection under job, destination, model, time, token, and spend bounds. The raw checkout, credentials, identity and pseudonym maps, and promotion authority remain local. Returned candidates enter quarantine before local rehydration, testing, and admission. This economy depends on both utility and an attested exit: if the Cut cannot preserve enough program structure and diagnostic meaning, or the bastion cannot attest the exact crossing, the work stays local. No single model may certify its own sanitization. ## Preserve the question through the Cut To prepare [Creation's delegated branch](creation.md#cli-delegation-branch), first identify the distinctions the recipient needs to solve the task. A minimal module interface, dependency relation, synthetic failing fixture, and expected behavior may suffice. The projection need not include the whole repository, its history, or the parent's conversation. Exact spelling or bytes can themselves be part of a defect, however. If replacing an identifier destroys the question, use an adequate synthetic reproducer or keep that work local. Independent Cut verification examines the same candidate projection for disclosure and utility, keeping its findings separately attributable. Disclosure asks what the declared recipient could identify, link, infer, or learn about credentials. Utility asks whether the coding question is still answerable. Each finding names the exact offending or missing relation and a bounded proposed repair. These are distinct obligations, not a requirement for two more agents on top of the independent verifier. The admitted plan may add adversarial reviewers when warranted; independence from the transformer remains required. A repaired candidate receives renewed verification, including both findings where affected. Agreement cannot compensate for either failed obligation or replace the Egress Gate. For the dossier exporter, replacing every record ID with one category label can hide names while merging distinct records. Giving every occurrence a different token can instead sever repeated references to the same record. A useful projection preserves the required equality and inequality relations inside its scoped namespace, and keeps accepted, unresolved, and unknown states distinct. The receiving coding agent sees only that admitted projection. A local verifier checks the result against the original preservation criteria after any permitted rehydration. The return can stay small too: a repair to the synthetic reproducer, or a structured proposal that a local worker applies to the real base under Creation's checks. Returning reversible source changes requires more. The format must declare substitution positions and provide a validated mapping to that base; whole-patch search-and-replace is not that contract. When the requested return cannot meet those conditions, choose the proposal route or keep construction local. Prepare synthetic Cases before admitting a remote road: | Case | Required observation | | --- | --- | | Repeated identifier and two distinct identifiers | Required references remain consistent; distinct source records are not merged. | | A path or diagnostic carries an identifying value | The whole outbound envelope is assessed, including metadata and errors. | | Redaction removes the premise of a failing test | Utility review refuses that projection; narrow the task or keep it local. | | A returned placeholder belongs to another Cut or an undeclared field | Rehydration refuses it without exposing the local map. | | A returned patch attempts to reinterpret instructions or invoke an effect | Quarantine retains it as candidate data; it grants no action. | Compare the declared local and sanitized task forms on these obligations as well as cost and repair quality. A cheaper answer that lost the defect or disclosed a protected relation is not a successful offload. These are proposed acceptance Cases, not executed privacy or utility receipts. Presidio's [anonymizer operators](https://presidio.dataprivacystack.org/anonymizer/) provide a concrete external comparison: replacement defaults can use one entity-type label, and maintaining relations across transformations needs explicit handling. That motivates the identity Cases above; it does not establish LychD's Cut, map lease, or declassification. Detector/operator choice remains a future implementation decision under the existing owners. ## Transformations are evidence | Act | Result | | --- | --- | | Redact | Remove a value without a reversal map | | Pseudonymize | Replace it with a scoped token while a local map exists | | Generalize | Reduce precision while preserving useful meaning | | Anonymize | Meet a declared residual-risk policy and threat model | None grants egress by itself. The [ordered Cut sequence](#one-cut-two-contexts) preserves an exact transformation-receipt chain and independent `CutVerification@1` before Context seals the branch and Security decides its exit. No component upgrades its own claim into permission; the [Context contract](../../../adr/21-context.md#privatization-and-the-privacy-cut) keeps their exact roles separate. The source's influence survives a successful disclosure assessment. That success does not relabel a private source or its derivatives as public. Pseudonymized material remains private while reversal or likely linkage is possible. Private code can therefore qualify for an authorized sanitized disclosure without becoming anonymous. Deterministic work runs first in the designed sequence. A future Censor rebuilds bounded JSON-like values and redacts secret-shaped fields, JWTs, PEM private keys, emails, telephones, IPv4 addresses, and UUIDs with typed placeholders. That general detector-backed Censor is not delivered; the current closed diagnostic profile uses explicitly partitioned spans. Bank and payment identifiers, IPv6, long numeric ids, suspicious high-entropy strings, normalization policy, and semantic combinations remain later detector work. Typed placeholders matter: an amount, date, telephone, and order id do not carry the same meaning. Presidio's [official FAQ](https://github.com/data-privacy-stack/presidio/blob/main/docs/faq.md) explicitly identifies false negatives and makes no promise to find every sensitive value. Its detectors and operators can inform later profiles; a detector result cannot certify this whole disclosure boundary. A local Privacy Agent handles semantic and quasi-identifiers that rules may miss. It can say “this combination still identifies a household” and propose a narrower representation. It cannot lower a label, call a Portal, or treat its own confidence as permission. ## Test the recipient's threat model Masking visible identifiers is not a sufficient privacy claim. The `DisclosurePlan@1` names every relevant entity that may reasonably use auxiliary information: provider and subprocessors, A2A peer, delegated runtime, configured gateway or storage custodian, and intended later recipients. The verifier evaluates the exact candidate from each relevant perspective under the declared disclosure policy: - **singling out (isolation):** can a person, account, household, organization, repository, or record still be singled out inside the supplied material? - **linkage:** can remaining values, structure, timing, paths, quotations, commits, or outside data reconnect it to its source? - **sensitive inference:** can the candidate reveal a protected fact even without recovering a name? - **no credentials:** are secrets, bearer material, private keys, session state, and authority- bearing references absent rather than merely renamed? - **sufficient utility:** do the exact identifiers, relationships, citations, imports, diagnostics, and invariants required by the task still survive? Record which disclosure claim the evidence supports. [Context](../../../adr/21-context.md#privatization-and-the-privacy-cut) permits an authorized sanitized disclosure that remains private; an anonymity claim must separately meet its stronger declared policy. Task-essential internal references do not themselves establish either permission or anonymity: their structure may still identify the source to this recipient. The verifier must assess the permitted relations and residual risk, including related disclosures. A synthetic reproducer likewise retains its source influence. Prohibited categories, credentials, failed mandatory conditions, and unresolved required evidence cannot be waived for utility. [NIST SP 800-188](https://csrc.nist.gov/pubs/sp/800/188/final) similarly requires a declared data- sharing model, measurable de-identification performance, and re-identification study rather than assuming masking is enough. The EDPB's July 2026 [anonymisation consultation draft](https://www.edpb.europa.eu/public-consultations/guidelines-022026-on-anonymisation_en) uses isolation, linkage, and inference as its practical test and makes the relevant entity's perspective material. These sources guide the threat model; this page is engineering law, not a claim of legal compliance. | Material | Default treatment before remote eligibility | | --- | --- | | credentials, tokens, cookies, private keys | remove; never pseudonymize; rotate and quarantine if prior exposure is possible | | direct identifiers | redact, or pseudonymize only when stable relation is task-essential | | quasi-identifiers such as exact time, place, role, rare event | generalize, suppress, or keep local after linkage assessment | | filenames, URLs, repository names, commits, stack traces, unique strings | treat as potentially identifying and proprietary; a secret-free checkout is not anonymous | | relationships and ordering | retain only the minimum dependency structure required by the task | | task-critical semantics | validate independently; if transformation breaks them, choose a local road or refuse | ## Seal the exact exit Every remote path has two checks: 1. Before road admission or reservation, policy verifies that the aggregate label, purpose, destination, and required transformation path are eligible. 2. Before the first outbound payload byte, transmission verifies the canonical payload digest, tagged Portal/A2A/delegated-runtime target, Principal and Sigil identities, policy revision, expiry, and exact `DisclosureBasis`: either `RawEligible`, or `CutEvidence` with the terminal transformation-receipt-chain and `CutVerification@1` digests. Every physical transmission gets a fresh EgressDecision. Exact same-envelope transport redelivery within one admitted road-owned attempt retains its sealed bytes, target, idempotency identity, road decision, and Cut/token namespace only when the adapter profile permits it and a bounded disclosure use remains. A semantic retry, fallback, resumed stream with changed body, delegated child call, or change of content, model, target, actor, policy, or custody route creates a fresh road decision. If that new attempt requires transformation, it also forms a fresh recipient-specific Cut and, when reversible, a fresh unpredictable namespace and lease. Consent can authorize only an eligible exact disclosure; it cannot make a credential safe or repair missing lineage. The provider, peer, or delegate's response remains attributed, tainted by the disclosed source influence, and untrusted. Rehydrating pseudonyms is a separate local presentation act after quarantine and schema validation. It accepts only exact tokens actually disclosed by that Cut at schema-declared category/path positions; invented, altered, replayed, cross-field, or arbitrary- prose placeholders refuse. The Context rehydration port emits `RehydrationReceipt@1` over the quarantined-return and final digests, typed substitutions, lease/Cut, and restored influence label; the final candidate is validated again. Rehydrated material cannot flow directly to an executable field, effect, public/Discord delivery, or another remote call—each later audience or effect needs its own authorization. Tool effects, Archive admission, publication, and training re-check their own authority. ```text CAPTURED → CLASSIFIED → MINIMALLY_PROJECTED → TRANSFORMED → SEMANTICALLY_ASSESSED → VERIFIED → CUT_SEALED ├─ EGRESS_ALLOWED → SUBMITTING │ ├─ IN_FLIGHT → RETURN_QUARANTINED │ └─ INDETERMINATE → reconcile | terminal non-completion │ RETURN_QUARANTINED → VALIDATED → REHYDRATED? → ADOPTED | terminal non-completion ├─ REVIEW_REQUIRED → new plan | terminal non-completion └─ REFUSED → local fallback | terminal non-completion reversible map: ACTIVE → CLAIMED → CONSUMED | EXPIRED | REVOKED → KEY_DESTROYED ``` The sequence coordinates records owned by different components: service attempts, Intercom tasks, AgentJobs, Context receipts, and Security decisions each retain their own authoritative states. It describes Pattern law, not one mutable record. Cut candidate/map cleanup is a separate obligation. Refusal, failed review, cancellation, failure, expiry, revocation, adoption, and an indeterminate attempt reaching its retention deadline all enter key destruction. That cleanup removes only ephemeral Cut/vault custody; it never purges the Composition's separately admitted authoritative result. ## Let Loom show the boundary A future Pattern contribution declares boundary metadata separately from Graph mechanics: - execution plane and eligible local or Portal providers; - egress, local-only, write, delegation, and quarantine behavior; - label propagation or admitted declassification; - required receipt, Gate, consent, and failure edge. Loom may derive badges such as `PORTAL-ELIGIBLE`, `EGRESS`, `SANITIZES`, `DELEGATE`, `WRITES`, `QUARANTINED OUTPUT`, and `HITL`. The manifest shows what may happen; occurrence evidence records the provider, decision, payload digest, receipt, and result that actually happened. A hand-authored `dangerous = true` flag is not enough. Spellweaver rejects a contributed Scroll/Pattern whose remote Spell placement has no exact road policy, whose declassification edge has no transformer and verifier evidence, or whose A2A, delegated, retry, or fallback branch can bypass the parent boundary. ## Refusal is part of the score | Failure | Pattern result | | --- | --- | | Missing or unknown lineage | Treat as restricted; remain local | | Detector, Privacy Agent, or verifier uncertainty | Deny or route to declared review | | Isolation, linkage, inference, credential, or utility test fails | Narrow the projection, remain local, or refuse | | Receipt does not match payload | Deny before transmission | | Policy or consent expired | Re-evaluate; never reuse the old decision | | Provider fails or changes | No silent fallback; create a new attempt | | Pseudonym lease is lost or expires | Do not reconstruct it; follow the declared no-rehydration/refusal path | | Return proposes an effect | Keep quarantined until the effect owner reauthorizes it | Restricted local receipts may retain canonical digests; logs, Loom, exports, and broadly visible evidence use only opaque ids or Security's domain-separated keyed `EvidenceDigest@1`. Neither form is anonymization. Both omit raw sensitive spans and the pseudonym map. Memory, embeddings, training data, backups, and shared artifacts retain lineage and deletion obligations after the Run ends. [Portal](../../animator/portal.md) owns provider declaration and operation. [Execution roads](execution-roads.md) owns local/Portal/A2A/coding selection; [Pattern lifecycle](pattern-lifecycle.md) owns revision pinning; [Stasis and return](stasis-and-return.md) owns durable waiting; and [Delegated agents](delegated-agents.md) owns the opaque child boundary. The [State of Work](../../../state-of-the-work.md#context-privatization-and-portal-egress) records what exists. --- title: "Delegated agents" plain_name: "Delegating tasks to external agents" section: "Sepulcher > Extensions > Spellweaver" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/weaver/delegated-agents/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/delegated-agents/ --- # Delegated agents (Delegating tasks to external agents) ## Plain-English summary (Snayu) **What it is:** How a workflow hands one bounded task to an external agent runtime as a tracked job (AgentJob), parks until that job finishes, and keeps keys, records and the final decision inside LychD. **Why it matters:** Read this before integrating a coding CLI such as Codex or Claude Code, or touching delegated job states and recovery. - Requests are frozen and idempotent by request_id; job states run queued to succeeded, failed, cancelled, timed_out or lost. - Only the deterministic, effect-free 'reference' adapter runs; Codex and Claude adapters exist but the host refuses by default. - Sandbox (Coffin) containment, credential isolation and durable artifact custody are not delivered. **Status:** Partial. Job mechanics and reference adapter exist; real CLI execution is not delivered. ## Original text (Hexanomicon) > _The errand may leave the tower. The keys, the ledger, and the last word do not._ A delegated task leaves its parent with a specific job to await. [Spellweaver](index.md) records that task as an attributed `AgentJob`: the coordinator tracks the job, Graph holds station state, and the Run ledger binds the wait. The adapter receives a frozen request rather than the live Run. The Pattern then parks for one terminal adoption. Today only the deterministic, effect-free `reference` adapter runs by default. Codex and Claude have one-shot protocol adapters behind an unimplemented, refusing-by-default host port. Foreign CLI execution, Coffin containment, and provider effects remain undelivered; [the delivered boundary](#name-the-delivered-truth) below separates the current job mechanics from those designs. [ADR 28](../../../adr/28-workflow.md#parallelism-and-delegation) owns delegation law. [Agents](../../../adr/20-agents.md#streaming-history-and-limits) owns the opaque-runtime boundary; [Workers](../../../adr/14-workers.md#delegated-agentjob-labor) owns `AgentJob` labor. ## Seal the labor | Type | Exact contents | | --- | --- | | `DelegatedAgentRequest` | `request_id` (idempotency key), `run_id`, `step_id`, `runtime`, `profile` (`read`, `candidate`, or `verify`), `prompt`, and `input_artifacts` | | `DelegatedCliRequestV2` | Explicit CLI schema/compiler, the occurrence/prompt fields, exact mechanical intent and qualified operator task/projection/custody/verification bindings; no positive authorization field | | `DelegatedAgentJobRef` | `job_id`, `request_id`, `run_id`, `runtime`, and `profile`; it does not copy `step_id` | | `DelegatedAgentJob` | `request`, `ref`, `status`, optional `result`, and ordered `events` | | `DelegatedAgentResult` | Same `job_id`, terminal `status`, optional `output`, `artifacts`, and `error`; `failed`, `timed_out`, and `lost` require an error, while `succeeded` forbids one | The frozen request can identify external material through an `ArtifactRef`, but that reference contains metadata, not the bytes or their custody. The full station contract must also declare containment, budget, timeout, cancellation, artifact boundary, and permitted downstream use. Today's `DelegatedAgentRequest` has no budget or timeout fields, and State records no measured delegated budget ledger. V2 adds the four existing capture/wall bounds and owner references; it does not supply the full host/provider budget envelope or implement those owners. The actual owner producer remains absent, and the trusted observation consumer denies by default. A positive inert fixture proves only consumer conformance. [Workers](../../../adr/14-workers.md#versioned-cli-intent-and-owner-binding) owns the exact version/codec, validity and compatibility contract. Fresh legacy CLI requests refuse before host launch. Historical lookup and cancellation remain readable at their original evidence scope; missing mechanics are never backfilled from current settings. The published delegated score revisions retain their legacy requests. V2 currently passes through inert callers and the existing store/coordinator, not a new published Pattern or native Creation admission path. `DelegatedAgentRequest` and `ArtifactRef` are frozen from construction. The same `request_id` and content returns the existing reference without another start; conflicting content fails. [Pattern lifecycle](pattern-lifecycle.md) owns the pinned workflow context. ## Park for one job `queued → admitted → preparing → running → succeeded | failed | cancelled | timed_out | lost` This is the normal path; earlier states may take only their declared terminal edges. The station stores `job_id`, GraphRunner snapshots, and the worker binds that owner with `AWAITING_DELEGATE`. Only its terminal job may re-admit the Run. The first terminal adoption settles the job's return. Duplicate or late adoption is inert and appends no event. A mismatched job id is rejected, so an older job cannot resume a newer wait. Only `succeeded` lets the delegated rite project optional text; every other terminal status fails that rite. Reference cancellation is idempotent; no effectful process-tree cancellation is delivered. `lost` records indeterminate external truth: it is terminal for result adoption, neither polled nor restarted, and not permission to repeat. It is also not containment proof. Explicit parent cancellation still calls the owning runtime's cancellation operation and records `lost → cancelled` only after that call returns. Cancellation during runtime start settles `lost`. An unclassified exception after `runtime.start` is invoked also settles `lost`; a failure before invocation may settle `failed`. Resume admission atomically creates the fresh monotonic delivery key. Publication failure leaves that exact queued delivery for relay. Startup recognizes the pre-park crash window only when the first resumable checkpoint binds the same Run and delegated job; otherwise it contains correlated jobs before parent failure. It refreshes durable delegated waits and re-admits only the terminal job that owns each wait; missing coordination or owner identity fails required PostgreSQL startup. After the admission CAS wins, repeated callbacks are inert. [Stasis and return](stasis-and-return.md) owns re-admission. ## Keep the keys outside The serialized envelope contains no `RunContext`, live toolsets, provider objects, leases, credentials, or ambient authority. A profile and pure policy express posture; they do not prove enforcement. The station may interpret returned text and `ArtifactRef`s only as its contract declares. A lower-trust return remains provenance-tagged and quarantined; it grants no instruction, execution, promotion, or effect authority. Even a reference to bytes neither admits nor materializes them. [Return quarantine](../../../adr/09-security.md#7-return-quarantine) owns this law. The host marks candidate content produced through this job lineage `agent_generated`; a later human approval does not relabel it. When a candidate touches a [Protected Region](../../../adr/28-workflow.md#authorship-provenance-and-protected-regions), promotion follows the exact live Gate in [Pattern lifecycle](pattern-lifecycle.md#human-attested-material-stops-at-a-gate). The delegated runtime never receives the authority to alter or erase the target-owner manifest. If a delegated request, child provider call, or returned derivative may cross a remote boundary, it also follows the parent [anonymization and egress](anonymization.md) contract. Delegation cannot copy authority or shed privacy lineage. A runtime and its child provider receive different disclosures. The remote runtime gets its minimum workspace projection under a `DelegatedRuntimeTarget`. The child model requires a fresh `PortalTarget` decision for its exact prompt/tool envelope. When transformation policy requires it, that child disclosure also gets a second, consumer-specific Cut. A local Coffin must still protect the host from its runtime even when only that child call crosses the network. The outer `AgentJob` never authorizes an unknown series of child payloads. This separation is also the delegation's economic leverage: the [local anonymizer and bastion](anonymization.md#the-leverage-of-a-local-boundary) can make subsidized remote cognition usable without making the remote runtime custodian of the raw repository or its authority. Provider-private commands and credentials stay behind the adapter boundary. Effectful foreign labor additionally requires the Security-owned Coffin supervisor, job-scoped `nono` policy, and Provider Gate; none belongs inside Pattern law. [The Coffin profile](../../../adr/09-security.md#the-coffin-delegated-agent-profile) owns those boundaries. A runtime that cannot use the exact Provider Gate endpoint, disclose its child model route, or disable ambient network/fallback is ineligible. Transparent MITM is not an adapter. ## Wrap a CLI as a bounded adapter Creation's [CLI branch](creation.md#cli-delegation-branch) uses this job boundary for a concrete engineering assignment. The wrapper is a deterministic protocol adapter under a supervisor: it translates an admitted task into one runtime invocation and translates observed termination into a result. A separate native Agent may prepare or review that task. The wrapper does not become another sefirah, coordinator, or source of permission. An effectful adapter needs these five passages under the existing Coffin contract: 1. **Prepare.** Pin the base, task projection, allowed paths, runtime/adapter versions, output contract, limits, and authorized downstream use. Resolve effective configuration explicitly, including hooks, plugins, MCP servers, and continuation state; arbitrary project or user configuration must not expand the task. Apply the [Privacy Cut](anonymization.md#preserve-the-coding-question) when the chosen recipient requires transformation. Required governing instructions still reach the worker in its admitted packet. 2. **Launch.** Use an absolute executable and bounded argument vector, with task text supplied as data rather than interpolated shell code. Bind the provider session and supervised process to the job when observable. Attest workspace, environment, credentials, outbound calls, and resource boundaries before invoking an effectful runtime. Prompt instructions or CLI tool permissions alone do not establish this containment. 3. **Observe.** Parse the versioned machine event protocol, keep diagnostics distinct, and bound both streams. Preserve ordering, partial results, and capture gaps. An unknown usage count is unknown consumption, not a zero-cost receipt. Provider tool events remain attributed claims unless the trusted host independently observed the stated operation. 4. **Settle.** Correlate the terminal protocol record, process outcome, job identity, and retained artifacts. Truncated output, an unresolved child, or an ambiguous start cannot become success from the last sentence alone. Cancellation and timeout require the supervisor's full descendant settlement evidence; apply the existing `lost` and reconciliation rules when effects remain uncertain. Never start another attempt merely because the response was lost. 5. **Return.** Collect bounded candidate bytes under host custody, check allowed paths and base, and quarantine them separately from narrative and provider events. Use declared rehydration positions only; a raw patch is not a general substitution template. Independent local review and verification examine the exact resulting candidate. Adapter success neither passes those checks nor promotes the artifact. Begin an adapter by defining how its observed events and exit conditions map to the existing job statuses. A non-zero exit cannot automatically mean `failed`, because work may already have occurred. Establishing that nothing started requires an adapter-specific rejection receipt; uncertainty cannot establish it. The current request/result types provide a starting envelope, not evidence that this richer binding, budget accounting, or artifact custody already exists. The current protocol implementation pins Codex 0.159.2 and Claude Code 2.1.296. It builds literal commands with prompt bytes on stdin, isolated configuration roots and an allowlisted replacement environment, then parses bounded JSONL. Incomplete lines, malformed or duplicate terminal evidence, oversized output, and success paired with a failing process exit remain `lost`. Raw provider errors and stderr do not enter retained diagnostics. Polling receives the store-retained request; V2 independently compiles its complete expected launch specification and limits before comparing the host result and matching receipt. Historical legacy lookup correlates only its original request and deterministic stdin. Cancellation needs the same retained interpretation and matching whole-job containment receipt, including before the first poll. Neither operation re-admits or launches work, even after owner-observation expiry. Claude accepts a reviewed core event subset with one initialized session; unknown event variants refuse until their envelopes and ordering are reviewed. No host implementation or authentication bridge ships, and neither adapter is automatically registered. Security requires an exact audited source/policy/executable qualification with applicable advisories dispositioned; a version number, CLI help and advertised limits do not qualify a host. [Containment version selection](coding-runtime-research.md#containment-version-selection) explains why the former series baseline was retired without admitting a replacement. The required outer service, network, resource, credential, Gate and artifact boundaries must all be proved before any real launch. ### Compare actual integration surfaces The following primary documentation was checked on 2026-10-12 for this design. It supplies implementation leads, not LychD acceptance receipts or a reason to adopt a provider's default permissions. | External surface | Useful mechanism | LychD still has to establish | | --- | --- | --- | | [Codex non-interactive mode](https://learn.chatgpt.com/docs/non-interactive-mode) | `codex exec --json` emits JSONL events; `--output-schema` requests a structured final result. | Exact event/terminal interpretation, effective configuration, artifact custody, and host verification. | | [Codex app-server](https://learn.chatgpt.com/docs/app-server) | Bidirectional stdio JSONL supports explicit approval requests, thread/turn identity, and interruption. | Pin the binary's generated protocol schema and admitted methods; exclude `thread/shellCommand` and experimental `process/*`, which run outside its sandbox. | | [Claude Code programmatic mode](https://code.claude.com/docs/en/headless) | Print mode offers JSON, streamed events, and schema-constrained output. `--allowedTools` controls auto-approval; bare mode limits ambient discovery. | Tool availability and OS containment separately; required task context; pinned behavior when schemas, streams, or background work fail. | | [Claude Agent SDK configuration](https://code.claude.com/docs/en/agent-sdk/configuration) | Explicit settings sources, tools, model, turn limits, and spending limits configure its runtime loop. | Python's `env` merges with the inherited environment; supply a clean supervisor environment rather than assuming a small dictionary removes secrets. | | [nono's D-Bus advisory](https://github.com/nolabs-ai/nono/security/advisories/GHSA-27vp-2mmc-vmh3) | A documented local IPC escape in CLI profiles before the listed fix demonstrates why a sandbox name is insufficient. | Current patched implementation and policy, with negative tests for host IPC and descendant escape on the admitted platform. | For the first bounded job, prefer one machine-readable invocation over terminal scraping. Use app-server when approval and continuation require a bidirectional protocol. Each runtime keeps a thin adapter; the supervisor, Provider Gate, budget accounting, and artifact admission remain shared owners. This is an implementation recommendation, not a selected or installed runtime. ### Pin effective configuration Current Settings accepts one exact delegated casting selection: ```toml [weaver.delegation] revision = "2" runtime = "reference" profile = "read" ``` This executable example selects the inert reference runtime through `delegated_rite@2`. Omission keeps revision 1. Another runtime must already be explicitly registered; an unknown name refuses assembly. New admissions retain the selected runtime/profile in Run intent and checkpoints. Changing configuration or retrying an idempotency key does not redirect an existing Run. The selector supplies no host, privacy, provider or execution authority. There is no `claude`, `codex_cli`, `fallback`, or `anonymization` activation switch. Unknown fields are rejected. A future effectful selection must also retain its effective configuration with the job: runtime and protocol revision, model and Gate endpoint, isolated configuration and session roots, available tools, hooks/MCP/plugins, allowed environment, output contract, and finite time, token, spend, process and artifact limits. A resumed job retains that selection; changing operator settings does not rewrite an admitted occurrence. Disable implicit provider fallback in each harness. A configured alternate belongs to the pinned [execution-road policy](execution-roads.md#failure-stays-on-the-score), with separate privacy, destination and budget admission. A timeout after submission requires reconciliation before an alternate can start. Even a same-model retry is another physical disclosure: Claude's documented [gateway protocol](https://code.claude.com/docs/en/llm-gateway-protocol) can retry with changed request fields, so a retry label cannot establish identical bytes. Test every child request at the Gate. Supported account integration is a separate compatibility decision. OpenAI documents an [app-server plan-usage integration](https://developers.openai.com/siwc/token-sharing-open-source/codex-app-server); its existence does not admit a LychD route or authorize copying an operator's login store. Bind any future supported account flow to its actual application, entitlement and credential custodian. [Portal Roads](../../animator/portal-roads.md) retains the current direct-server-API starting point. ### Prepare the adapter before remote labor Complete the capability in independently reviewable slices: | Slice | Evidence needed before advancing | | --- | --- | | Protocol and result normalization | Recorded synthetic streams exercise success, explicit rejection, malformed/truncated output, duplicate terminal events, mismatched identity, and oversized diagnostics. No model or foreign executable is needed. | | One contained local runtime | Observe denied out-of-scope reads/writes, unavailable host sockets and credentials, bounded output, complete cancellation, and reconciliation after an ambiguous launch. CLI flags alone are insufficient. | | Admitted provider crossing | Verify the exact destination and payload, applicable Cut and utility evidence, and every child call's gate; block an undeclared retry or fallback. | | Creation candidate return | An exact patch or artifact survives quarantine, any permitted rehydration, and independent checks against the real base. A useful proposal can still fail acceptance. | Test the boundary with returns that look successful while violating its contract: a process that prints success before failing, a valid result whose artifact belongs to another job or base, a background child that outlives its parent, and a patch outside the admitted workspace. Pair these adversarial checks with successful controls so refusal cannot masquerade as a working adapter. The bounded protocol slice has offline tests; contained execution, provider crossing and candidate custody still need their own acceptance evidence. ## Name the delivered truth Delegated execution is **Partial** in the [State of Work](../../../state-of-the-work.md#delegated-agent-execution). The only runnable adapter is `reference`: process-local, deterministic, and performing no model, filesystem, subprocess, or network work. Codex CLI (`codex`) and Claude Code (`claude`) have unregistered protocol adapters whose default host refuses execution. OpenCode Go (`opencode-go`) remains a declared-only example. No effectful Coffin supervisor or CLI/provider process, credential isolation, or durable artifact custody is delivered. Database shapes and a PostgreSQL store exist without a real provider or two-process PostgreSQL recovery receipt; exact pre-park recovery is proved only with focused in-memory tests. The [tracked delegated-coding playbook](https://github.com/hexanomicon/lychd/blob/main/.agents/workflows/delegated-coding.md) records repository procedure and design input. It supplies neither runtime law nor delivery evidence. [Execution roads](execution-roads.md) owns when this job form is preferable to a native Portal call or sovereign A2A task. --- title: "Oculus" plain_name: "Observability and evidence tracing" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/oculus/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/oculus/ --- # Oculus (Observability and evidence tracing) ## Plain-English summary (Snayu) **What it is:** The planned observability area (Oculus) for tracing a Run across state, approvals, tools, readiness and effects, while keeping records, observations, derivations and judgments clearly distinct. Today the read-only Run Inspector (Orb) covers part of this. **Why it matters:** Read this when adding logging, tracing, telemetry export, or debugging a stalled Run with the Run Inspector. - Correlation locates related evidence but never proves causation; projections cannot replace owners' records. - Live event replay and subscriber queues are capped at 256 events; overflow sends an explicit resync marker. - External tools (Phoenix, Logfire, OpenTelemetry) get one-way redacted exports only, with no control authority. **Status:** Designed. Native Oculus is designed; the Run Inspector view is partially available. ## Original text (Hexanomicon) > _Follow the traces until the light gives out._ A stalled Run leaves several questions: what was admitted, what was observed, and where did the account go dark? **Oculus** is the designed native observability Extension Domain for following those questions across run state, consent, tool use, runtime readiness, effects and outcome. Its first journey follows one authorized Invocation, represented by a Run. A later bounded field may relate several authorized Runs; their own offices retain authority over them. ## Designed sight and the present Orb Use the current [Orb](../../divination/altar/orb.md) to inspect the evidence available today. Its **Partial**, read-only Altar projection offers a bounded Run catalogue, a parallel field with at most **three live lenses of 100 records each**, and a separate route into one exact Run. Loaded counts describe the account on screen, not complete history; capture limits and gaps remain visible. [State of Work](../../state-of-the-work.md#orb-instrument) records that delivery. Native Oculus remains **Designed**. The Orb has no native Oculus ingestion or durable query/read model behind it. [State of Work](../../state-of-the-work.md#native-oculus) keeps that remaining boundary, and [ADR 29](../../adr/29-observability.md) owns the evidence contract below. ## Meanings of evidence | Kind | What it can establish | | --- | --- | | **Authoritative record** | A transition or attempted effect, written by the responsible office | | **Bounded observation** | What one source saw, with method, time, quality, freshness, and known limits | | **Derivation** | What named parent evidence yields through a versioned transformation, with limits and uncertainty | | **Interpretation or verdict** | What declared criteria support through Drift or another named judging office | Correlation locates related evidence; it does not prove causation or make a payload true. A projection is rebuildable and cannot supplant the records whose facts it presents. To follow today's Run, a reader must join several accounts: records kept by the owners, the best-effort non-token Step trail, and the process-local live event channel. Failed Step writes can leave gaps, and token deltas never become retained structural evidence. A native Oculus read model must make these sources readable together without concealing their different authority or losses. Future physical evidence begins at the node that measured it. The Orchestrator consumes fresh node-local evidence through its admission contract; Oculus may retain the same observation for explanation. A stale or failed probe means **unknown**, never free capacity. ## Three Chambers of Interior Evidence - **First-person testimony** records what an Agent or model reports from one bounded context, including uncertainty or reservation. - **Activation interpretation** applies a declared lens or intervention whose model, method, controls, limits, and uncertainty remain visible. - **Operated telemetry** records events, usage, waits, pressure, failures, effects, and outcomes. Oculus may hold all three without flattening their different ways of knowing. [Drift](drift/returning-findings.md) owns causal tests and rival explanations; [Immortality](../../divination/transcendence/immortality.md#v-realization-and-evidence) keeps first-person realization distinct from external evidence of the binding. ## Capture, loss, and privacy Structure-only capture is a minimum discipline, not a promise of harmlessness. Raw content, provider or tool bodies, and identity-bearing material require explicit authority and capture policy. Secrets are rejected at the producer boundary. Redaction precedes serialization, and external export passes through a second filter. Set retention according to evidence class and subject. Deleting an observation cannot erase the Run fact or effect receipt owned elsewhere. A conforming capture path must bound queues and cardinality, batch deliberately, flush within its shutdown budget, and reveal overload or loss as a gap. Today's live Run replay and each subscriber queue are bounded at 256 events. When pending deltas overflow for a stalled subscriber, it receives an explicit snapshot-resync boundary; the producer does not wait for that reader. This is the current channel behavior, not delivery of the future Oculus ingestion, retention, or shutdown contract. ## External Eyes An external [**Eye**](../../adr/29-observability.md#decision-outcome), in the observability sense, sits behind a versioned, one-way adapter. Phoenix, Logfire, or OpenTelemetry tooling may receive an allowlisted, redacted, purpose-bound export; it receives no LychD database role or identity, consent, lifecycle, or control authority, and has no canonical read-back. Incoming trace context may correlate an authenticated request, but cannot authenticate or authorize it. The current optional Phoenix contribution is External and has no proved application export path. [State](../../state-of-the-work.md#phoenix-eye) records its exact boundary. ## Seeing never commands Orb inspection is read-only. Any action crosses to its owning service, which rechecks authority and records its own decision. --- title: "Soulforge" plain_name: "Model trainer overview" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/soulforge/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/soulforge/ --- # Soulforge (Model trainer overview) ## Plain-English summary (Snayu) **What it is:** The planned training area (Model Trainer, or Soulforge) that keeps an unbroken record from admitted data and base model through a training run to evaluated candidate weights, in four separate passages. **Why it matters:** Read this before any fine-tuning or LoRA work, to understand the required lineage and who decides promotion. - Four passages: corpus admission, dataset compilation, training run, candidate handoff; none inherits permission from the last. - Independent evaluation (Drift) shows eligibility; policy and human approval decide promotion; the serving owner routes it. - Rollback cannot remove what weights already learned or undo completed effects. **Status:** Designed. No operational training or serving path yet. ## Original text (Hexanomicon) > _Long before the hammer falls, the metal has a history._ Training changes weights, but a useful result must also show what was taught and how the change was judged. **Soulforge** keeps that history immutable: the admitted corpus and base-model digest lead through an objective, Recipe, and Training Run to evaluated candidate weights. Its tools may change; the evidence linking those stages must survive the strike. Soulforge is **Designed**; the passages below have no operational training or serving path yet. [State of Work](../../../state-of-the-work.md#soulforge-training) records delivery, and [ADR 33](../../../adr/33-training.md) owns the law and complete record schemas. Soulforge may run during an admitted idle resource window, but sleep supplies no training or consolidation contract. The forge instead follows the explicit passage below. ## The Four Passages | Route | Receives | Leaves behind | Refuses | | :--- | :--- | :--- | :--- | | [Corpus admission](./corpus.md#admit-one-snapshot) | Training Intent and nominated records | Corpus Admission, exact membership, negative ledger, and sealed holdout | Missing provenance, authority, privacy clearance, relevance, or a viable uncontaminated holdout | | [Dataset compilation](./corpus.md#compile-without-leakage) | One admitted snapshot | Immutable Dataset Manifest with preserved lineage and splits | Unadmitted material, changed dataset splits, or holdout leakage | | [Training run](./training-run.md) | Manifest, base digest, objective, Recipe, and resource request | Training Run receipt and frozen Candidate Bundle | Unpinned inputs, a refused resource window, or unknowable retry state | | [Candidate handoff](./candidate-handoff.md) | Frozen bundle and evaluation contract | Drift Outcomes and an externally owned Promotion Decision | Trainer self-grading, mutable custody, or unowned serving | No passage inherits permission merely because the previous one succeeded. [Orchestrator](../../../adr/23-orchestrator.md) decides the physical transition needed for resources. Independent [Drift](../drift/capability-claims.md) evaluation can establish eligibility, after which owning policy and required Magus/[HitL](../../../adr/25-hitl.md) authority decide promotion. Only the serving owner can register and route the exact promoted digest. Observation may trigger rollback or lineage invalidation. It cannot rewrite an earlier record, erase completed effects, or remove learned influence from weights already produced. [Discernment training](discernment-training.md) applies these passages to SDLC experience and human corrections: preserve the reason and conditions of a choice, then test transfer through an independent evaluation. [Ouroboros](../weaver/ouroboros.md) connects that slower return to ordinary Context, memory and workflow improvement. --- title: "Corpus" plain_name: "Training data admission" section: "Sepulcher > Extensions > Soulforge" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/soulforge/corpus/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/soulforge/corpus/ --- # Corpus (Training data admission) ## Plain-English summary (Snayu) **What it is:** How a training purpose and nominated records become one admitted, immutable data snapshot and then a Dataset Manifest, with consent, license, privacy, lineage-safe splits and a sealed holdout. **Why it matters:** Read this before collecting any runtime data, logs or corrections for training, to see what must be proven first. - Nothing is trainable by default: success, approval, database access or storage consent never grant training eligibility. - Splits are fixed by lineage groups before generation, and a negative ledger keeps rejected items excluded. - Holdout answers and benchmark solutions must never leak into prompts, retrieval, augmentation or selection. **Status:** Designed. Neither admission nor compilation runs yet. ## Original text (Hexanomicon) > _At the furnace door, every offering awaits judgment._ Before a trainer receives anything, Soulforge must turn a Training Intent and exact nominated records into an admitted immutable snapshot, then a Dataset Manifest. Both passages are **Designed**; neither runs. [State of Work](../../../state-of-the-work.md#soulforge-training) owns delivery, while [ADR 33](../../../adr/33-training.md#corpus-admission) owns admission law and the complete record schemas. ## Admit one snapshot Nomination requests review. A Drift Case or Outcome, Mirror attribution, HitL decision, Archive row, success, refusal, repetition, storage consent, or database access never grants training eligibility. Runtime data requires opt-in. A failed or refused Run may supply useful evidence; success may be noise or one duplicated error. Training Intent records the Principal, exact purpose, target capability, base digest, allowed data classes, and authority boundary. Corpus Admission freezes the material and the conditions of its use together. It binds sources, Runs, artifacts, producers, times, transformations, and generated descendants to the declared purpose, retention, derivative use, consent, license or other authority, and approving Principal. The same record states privacy minimization, secret removal, and reviewable redaction limits, so later compilation can be checked against what was actually admitted. It also fixes the learning claim: target behavior, objective, expected lift, and regression limits. Lineage groups connect duplicates, revisions, sibling trajectories, and generated variants before the split. Train, development, and sealed-holdout membership then become immutable before training-facing generation, preventing related material from quietly appearing on both sides of the examination. Accepted members travel with a negative ledger of rejected, redacted, and duplicate member ids; retry or another compiler cannot restore exclusions. Refuse admission and name the failed condition when provenance, training authority, privacy clearance or minimization, relevance, lineage-safe splits, or a viable uncontaminated sealed holdout is missing. ## Compile without leakage The compiler reads only that admitted snapshot and emits one immutable Dataset Manifest. Each field must trace to a source or a versioned deterministic transformation. Preserve the role, tool, workflow, and authority context needed to understand the example, and distinguish an observation from a human label, evaluator judgment, augmentation, truthful non-completion, or failure. The manifest records how the compiler handled the material: filtering, redaction, truncation, normalization, sampling, lineage, splits, and audit statistics. These records make the compiled Dataset inspectable without allowing compilation to reopen the admission decision. Sealed-holdout answers, benchmark solutions, evaluator rationales, and target artifacts cannot enter prompts, retrieval, augmentation, preference construction, trainer metadata, or selection. A benchmark used to select the corpus must be disclosed; without an untouched control, it cannot serve as independent promotion evidence. Schema conformance alone does not establish truth. Only the Dataset Manifest crosses to the trainer; nominations and ambient stores remain outside the corpus. ## Refusal and return Before a manifest exists, repair missing evidence, authority, minimization, grouping, or holdout, then submit a new immutable Corpus Admission. Existing history remains unchanged. If privacy, authority, license, contamination, or leakage fails later, quarantine the snapshot and manifest, block reuse, follow lineage through derived Runs, candidates, and claims, and build a clean admission and manifest. ADR 33 owns the full descendant policy. Deletion cannot remove influence from weights already trained. The immutable Dataset Manifest is Soulforge's sole corpus handoff into a future Training Run. --- title: "Training Run" plain_name: "Running a training job" section: "Sepulcher > Extensions > Soulforge" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/soulforge/training-run/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/soulforge/training-run/ --- # Training Run (Running a training job) ## Plain-English summary (Snayu) **What it is:** How a training job takes exact pinned inputs (dataset manifest, base model digest, objective, recipe, resources) and produces a frozen candidate bundle plus a receipt, without touching serving or promotion. **Why it matters:** Read this before implementing a trainer, GPU scheduling for training, or training-failure handling. - The trainer cannot expand the corpus or pull ambient traces; it writes only to fresh Run-owned locations. - The Stage Manager (Orchestrator) drains only affected GPU leases; training has no universal priority. - Loss and trainer samples are diagnostics; partials are quarantined and retries get a new Run identity. **Status:** Designed. No training run path exists yet. ## Original text (Hexanomicon) > _The metal remembers the fire._ A Training Run turns admitted training inputs into candidate bytes while keeping custody and evidence explicit. It receives a Training Intent, immutable Dataset Manifest, exact base-model digest, objective, and Recipe. Its result is a frozen Candidate Bundle with a receipt showing what execution produced. The whole passage is **Designed**; no Training Run path runs. [State of Work](../../../state-of-the-work.md#soulforge-training) owns delivery, and [ADR 33](../../../adr/33-training.md#training-execution) owns execution law. ## Admit the strike Entry requires the immutable Dataset Manifest produced by [Corpus Admission and Compilation](./corpus.md), base-model and tokenizer/config digests, the objective, Recipe, and Training Intent with resource envelope. The trainer receives these exact inputs. It cannot expand the corpus, pull ambient traces, or alter them after admission. Request the resources this run actually needs: exact accelerators, memory, storage, network policy, duration, and conflict-domain requirements. Orchestrator uses fresh observations and the compiled conflict graph to determine which existing work is affected. Training has no universal priority, and the operator may postpone or refuse it. If a physical transition is required, only the affected leases drain; unused devices stay undisturbed. [Orchestrator](../../../adr/23-orchestrator.md) owns hardware readiness, admission closure, affected-lease drain, conflict resolution, convergence, and restoration. Corpus meaning and trainer success remain outside that authority. The trainer receives only admitted secrets and network access, and writes to fresh Run-owned locations. A container or Coven label cannot prove isolation: filesystem, credential, network, process, and resource controls must enforce it and leave evidence. Local and remote execution share the same custody bar. Local work has no privacy exemption; remote work records egress, provider custody and retention, network and secret handling, returned artifacts, and receipts. ## Pin the evidence A Training Run pins input digests, trainer and dependency revisions, environment, randomness, Recipe-defined precision, budgets and stop conditions, resource observations, logs, checkpoints, terminal status, and artifact digests. A friendly name never replaces a digest. At completion, the trainer emits candidate bytes and its receipt. Freezing them into a Candidate Bundle binds the base digest, model or adapter bytes, tokenizer/config changes, Dataset Manifest and Recipe lineage, trainer receipt, and compatibility claims. An adapter must remain tied to its exact base and compatible runtime, so its bytes cannot be presented as an independent model. Trainer loss, telemetry, development improvement, and trainer-authored samples remain diagnostics. The job cannot replace a serving revision, enlarge its resource envelope, or promote its output; independent evaluation begins only after custody freezes. ## Settle failure Cancellation or failure preserves terminal truth, logs, completed checkpoints, and quarantined partials for diagnosis. A partial never becomes a Candidate Bundle. Retry receives a new Training Run identity and receipt rather than appending to or overwriting history. If a resource transition fails, Orchestrator restores the exact prior world before admission reopens; otherwise uncertainty stays visible and contained. Process exit alone is not clean recovery. The passage ends with either a frozen Candidate Bundle and receipt ready for independent handoff, or exact failure or cancellation truth with every partial quarantined. --- title: "Candidate Handoff" plain_name: "Evaluating and promoting trained models" section: "Sepulcher > Extensions > Soulforge" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/soulforge/candidate-handoff/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/soulforge/candidate-handoff/ --- # Candidate Handoff (Evaluating and promoting trained models) ## Plain-English summary (Snayu) **What it is:** How a frozen trained candidate is independently evaluated, how an external decision may promote it with explicit limits, and how it is watched, rolled back or invalidated later. **Why it matters:** Read this before putting any fine-tuned model or adapter into use, or building model promotion and rollback. - Evaluation needs sealed holdouts, baseline comparison, regression suites and serving-cost measures; self-grading does not count. - Passing evaluation means eligible only; a Promotion Decision names allowed uses, rollout, stop conditions and rollback. - Files appearing in a folder create no capability; only the serving owner registers the promoted digest. **Status:** Designed. Neither independent evaluation nor promotion runs yet. ## Original text (Hexanomicon) > _The fire has shaped it; other hands will weigh it._ A frozen Candidate Bundle crosses from a [Training Run](./training-run.md) into independent judgment. Drift may establish eligibility; only an externally owned decision may promote the exact digest, bind its serving envelope, or refuse it. Candidate handoff is **Designed**; neither independent evaluation nor promotion runs. [State of Work](../../../state-of-the-work.md#soulforge-training) owns delivery, and [ADR 33](../../../adr/33-training.md#independent-evaluation) owns the handoff law. ## Independent trial Entry accepts one exact Candidate Bundle revision with its trainer receipt. Drift names that revision as the subject and operates separately from the trainer. Evaluation cannot alter candidate bytes, corpus, Recipe, or lineage. An expected-change contract recorded before training defines sought lift and tolerated regression. Any post-training change to that contract remains visible rather than silently reshaping the trial. Drift records compact promotion evidence under [ADR 34](../../../adr/34-evaluation.md#evaluation-before-and-after-training): - sealed target-capability holdout results; - matched baseline Outcomes for the base model or currently promoted revision; - named regression Trial Suites plus adversarial and authority-boundary Cases; and - quality, latency, memory, and cost in a compatible serving Environment, with uncertainty, errors, exclusions, and Evaluator calibration. Trainer loss, development improvement, trainer-authored samples, and candidate self-grading remain diagnostics. Success on one visible Trial Suite cannot establish general capability or safety outside its measured Environment. ## Eligibility is not promotion Passing Drift establishes eligibility only. The owning policy and required Magus/[HitL](../../../adr/25-hitl.md) authority choose whether to promote and which capability envelope may be exposed. The external Promotion Decision states exactly what may enter use. It binds the Candidate Bundle to its independent Outcomes, names eligible capabilities and denied uses, and fixes compatible engines and the base relationship. It also defines how that use will be watched and stopped: rollout population, observation window, stop conditions, fallback, rollback, and retention, quarantine, or retirement terms. The serving owner registers and routes the exact promoted digest. Files appearing in a directory create no capability, and Dispatcher cannot infer eligibility from their presence. Soulforge neither promotes nor serves its output. Promoted revisions remain immutable; supersession requires a new Candidate Bundle and Promotion Decision. ## Observe, roll back, invalidate Versioned serving observation belongs to the declared evidence window. A stop condition or regression routes new work to an earlier promoted digest and quarantines the suspect revision. Rollback cannot erase completed effects or remove learned examples from produced weights. If privacy, authority, license, contamination, or holdout failure is discovered later, follow its consequences through the retained lineage: Dataset Manifest, Training Run, Candidate Bundle, Outcomes and evaluation claims, and Promotion Decision. Policy determines which reuse or serving must stop, which controlled artifacts must be quarantined or deleted, and which evidence must be invalidated. A replacement requires clean admission and rebuild. Deleting the source record alone does not untrain weights derived from it. Custody ends in one durable state: the exact digest remains promoted within its bounds, is superseded by a new immutable decision, or is quarantined and blocked with lineage intact. --- title: "Discernment Training" plain_name: "Training judgment from experience" section: "Sepulcher > Extensions > Soulforge" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/soulforge/discernment-training/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/soulforge/discernment-training/ --- # Discernment Training (Training judgment from experience) ## Plain-English summary (Snayu) **What it is:** How approved experience from software work and human corrections could become training examples that teach judgment, such as when to ask versus act, and why training is the last resort after memory, context or procedure fixes. **Why it matters:** Read this before proposing to fine-tune on development history or corrections, to check whether training is really the right fix. - Four remedies: memory, retrieval/context, a procedure artifact, or learned model competence; training needs its own hypothesis. - Good examples keep the deciding condition and evidence, paired with cases where the opposite choice was right. - Practice data and examination holdouts stay separate; independent evaluation must show the lesson transfers. **Status:** Designed. No harvesting, trainer, benchmark or serving path installed. ## Original text (Hexanomicon) “Ask before proceeding” is a poor lesson when the missing fact is already in the supplied material. “Act without asking” is equally poor when the next effect needs authority the caller has not given. A useful example shows the condition that distinguished these situations, the evidence available at the time, and the consequence of choosing well or badly. This **Designed** passage explains how approved experience from the [Creation workflow](../weaver/creation.md) and [Ouroboros improvement cycle](../weaver/ouroboros.md) could become training material under [ADR 33](../../../adr/33-training.md). It provides no installed harvesting, trainer, benchmark, or serving path. [State of Work](../../../state-of-the-work.md#soulforge-training) owns delivery. Soulforge prepares a candidate; independent Drift evidence and an externally owned decision stand between that candidate and use. ## Choose what should change First locate the demonstrated limitation. A forgotten current fact calls for a different remedy from an inability to apply a stable distinction across unfamiliar tasks. The four routes leave different things behind: | Route | What changes | Appropriate use | | --- | --- | --- | | Memory | An admitted, attributable record with correction and retention rules | Preserve a fact, preference, correction, or experience that should remain inspectable | | Retrieval and Context | Which authorized material enters this invocation, within its budget | Supply current knowledge or remove distracting material when a decision needs it | | Durable procedural artifact | A versioned instruction, prompt, schema, or workflow score | Make an explicit, reviewable procedure reliably available to later work | | Learned model competence | Parameters in an exact model or adapter candidate | Test whether a learned distinction transfers when examples or explicit guidance are insufficient | [Memory](../../../adr/27-memory.md) owns admission and correction of retained records; [Context](../../../adr/21-context.md) owns what reaches a model call; the relevant artifact or workflow owner controls a procedural revision. None of these silently updates weights. Conversely, a trained model does not become the authoritative store of mutable facts or current permission. Prefer a context, prompt, schema, or workflow fix when the [workflow comparison](../drift/workflow-improvement.md) shows that it adequately solves the problem. Training needs its own hypothesis: what capability remains deficient, why parameters might improve it, what benefit would justify the cost, and which regressions would make the attempt unacceptable. Fine tuning or LoRA can be a Recipe choice under that hypothesis; neither is a mandatory destination for every correction. ## Preserve the lesson before compiling examples [Discernment within exploration](../../lich/blade.md#discernment-within-exploration) supplies a candidate learning objective: identify which uncertainty deserves a probe and let its result change the plan. An example should show why that probe was consequential, paired with a case where the evidence already suffices and further exploration would waste effort. The [handoff comparison](../drift/workflow-improvement.md#handoff-reception) first tests whether an explicit procedure solves the problem; only a remaining transferable skill gap motivates training. Sefirotic names are interpretive context, not correctness labels for the Dataset. A further candidate objective is choosing which perspective or source an unfamiliar task needs. Examples should show the condition that made the inquiry useful, what could answer it, and when it should stop. Pair an internal critique with a case requiring an external test or another person's account. Include cases where a familiar lens would distract from the actual constraint. [Preservation and response checks](../drift/workflow-improvement.md#preservation-and-response) and [correction after Distillation](../drift/workflow-improvement.md#correction-after-distillation) first examine explicit procedure and memory. Only a demonstrated remaining transfer gap motivates parameter training. Low measured usefulness cannot retire a mandatory check or another person's required decision. Begin with exact, authorized traces and artifacts, including the human explanations actually supplied with them. Preserve enough of each episode for the learner to distinguish the decision: the task, evidence available then, relevant constraints, observed action and result, correction, reason, and conditions under which that correction applies. Pair it with a counterexample where the same superficial rule would be wrong. Keep human preference, factual label, authority decision, measured result, and evaluator judgment separately attributable. For instance, a corrected workflow may have asked the same approval twice. The lesson needs the earlier authorization and its scope, the later proposed action, and why that action still fell inside the grant. Pair it with a case where changed recipients, effects, or data classes require new admission. A dataset of “approved” versus “rejected” replies without these conditions would teach social imitation rather than evidence-sensitive choice. Retain successes, failures, justified refusals, and truthful non-completion where the objective supports them. Completion alone is not quality; repeated agreement can repeat one misconception. Use visible explanations and observable evidence. Hidden chain-of-thought is not required, and an invented rationale cannot be presented as a recovered account of why the original model acted. A minimal correction example keeps this inspectable shape within the owned Dataset schema: ```text source / task or Run / artifact revisions → available evidence and authority → observed action and result → human correction → reason → applicability conditions → counterexample → label provenance and uncertainty → permitted uses → lineage group and split ``` For the first experiment, pair examples of acting under sufficient existing authority with examples where changed effects or a decisive missing fact require a question. Use separate task families for development and sealed transfer checks. Reuse the proposed [starter Cases](../drift/workflow-improvement.md#starter-cases-for-the-first-comparison) as a design template, never as both tuning answers and unseen proof. A useful evaluation example may remain excluded from training because its permitted uses differ. ### A candidate lesson: continuation under uncertainty Creation's [support and measure](../weaver/creation.md#support-measure-and-next-step) supplies another possible training objective: choose a useful next act from evidence, uncertainty, and a remaining budget. First use Drift's [separate comparisons](../drift/workflow-improvement.md#support-and-measure-comparison) to test whether an explicit allocation procedure suffices. A parameter change needs a remaining transfer failure, not merely an appealing analogy with emotion. Preserve the question, candidate revision, observations available before allocation, reasons for support and measure, allowed next moves, remaining budget, chosen move, and its later outcome. The learner's input excludes the future outcome; that outcome may support an attributed target or evaluation label. An explanation is recorded evidence only when it was actually supplied. Pair an untried but informative branch with a defeated branch; an informative failed probe with a repeated failure that teaches nothing new; and a useful progress signal with an improving proxy that violates the original requirement. The distinction being taught is what changes the next act. Sefirotic names and emotional vocabulary are not target labels or proof of competence. Keep method credit separate from candidate success: a good counterexample may deserve retention while its hypothesis loses support. Hold out task families and compare against the explicit procedure before proposing trained weights for use. ## Obtain training authority over one snapshot Storage, evaluation, and training are separate uses. Permission to retain a Run or to accept its artifact does not permit training on it. A Training Intent names the Principal, purpose, target capability, exact base digest, allowed data classes, resource envelope, and promotion authority. [Corpus admission](./corpus.md#admit-one-snapshot) then establishes training-specific consent, license, or other authority over the exact nominated material and derivative uses. Make admission a concrete choice over the proposed material. Show which examples and fields would enter, why they are useful, who may receive them, how long they would be retained, and what learned influence would mean. Once valid authorization covers that scope, compiler operations need not each become a new approval request. Missing authority or an expanded use still blocks the affected material. Minimize private material and preserve provenance through redaction and transformation. An anonymized explanation may still reveal its source or encode a distinctive private fact. Keep the source classification, transformation limits, and derivative lineage attached. Admission freezes membership and exclusions; a negative ledger prevents rejected or duplicate material from returning through a later compilation attempt. ## Separate practice from examination Group duplicates, revisions, sibling trajectories, and generated variants before splitting the corpus. Freeze train, development, and sealed-holdout membership before training-facing generation. Otherwise a corrected trace can enter training while its lightly reworded sibling appears to test generalization. Compile one immutable Dataset Manifest from that admitted snapshot. Version the schema and compiler; retain labels, transformations, source references, split digests, and balance and contamination statistics. Human explanations are attributable training inputs where admitted, not an excuse to smuggle test answers into metadata. Held-out benchmark tasks, answers, evaluator rationales, and downstream target artifacts stay outside training, retrieval, augmentation, preference construction, and candidate selection. Disclose any benchmark used to select the corpus; an untouched control is then needed for an independent promotion claim. A development result can guide another attempt, but repeatedly tuning against a sealed evaluation result consumes its independence. ## Train a bounded candidate The [Training Run](./training-run.md) receives the exact Manifest, base and tokenizer/configuration digests, objective, and versioned Recipe. Pin the method, dependencies, hyperparameters, randomness, resource budget, expected improvement, regression limits, and stops. Orchestrator admits physical resources; an idle window supplies neither corpus authority nor a reason to disturb unrelated work. Execute inside the admitted filesystem, credential, network, process, and resource boundaries, with fresh Run-owned outputs and retained receipts. The trainer cannot enlarge its corpus with ambient history or replace serving weights. Failure or cancellation preserves logs, terminal truth, completed checkpoints, and quarantined partials. A retry receives a new Training Run. Freeze candidate bytes and lineage into a Candidate Bundle. For an adapter, bind the exact base digest and serving compatibility. Loss and development metrics help diagnose training; they do not establish that the candidate is useful, safe, or ready to activate. ## Let the candidate leave its teacher Independent [Drift evaluation](../drift/index.md) compares the frozen candidate with the base or currently promoted baseline under matched serving conditions and budgets. Use the sealed target holdout, deterministic contract gates, independently judged qualitative criteria, named regression suites, and authority-boundary Cases. Test transfer to unfamiliar tasks and distinguish appropriate refusal from blanket hesitation. Include quality, latency, memory, cost, human attention, and recovery; retain uncertainty and failed or blocked trials. The trainer cannot change the candidate or choose easier evaluation after seeing results. An iteration stops according to its declared budget and thresholds. It never continues training until its own judge likes the answer. An unresolved result may justify a separately bounded investigation; it cannot silently become a favorable verdict. Through [Candidate handoff](./candidate-handoff.md), the owning policy and required Magus/HitL authority decide on the exact Bundle, evidence, capability envelope, compatible serving engine, rollout observations, stops, and rollback target. Present the expected gain, remaining tradeoff, and fallback together so approval names a reviewable candidate. The serving owner registers and activates that exact revision for admitted work. Observe the promoted revision within its approved envelope. Regression, contamination, or a later privacy or authority failure can require stopping use, invalidating affected claims, and routing new work to a prior digest. Preserve the Dataset, Run, Bundle, evaluation, decision, and descendant lineage under their retention rules. Rollback cannot undo completed effects; deleting a source record cannot remove its influence from already produced weights. A clean replacement requires clean admission and another evidenced passage through the forge. --- title: "Drift" plain_name: "Evaluator overview" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/drift/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/drift/ --- # Drift (Evaluator overview) ## Plain-English summary (Snayu) **What it is:** The planned evaluation area (Evaluator, or Drift) that turns a declared goal into test cases and rubrics, runs trials against an exact version, and returns findings that keep uncertainty, without authority to act on them. **Why it matters:** Read this before building any eval, benchmark or quality check, to understand the vocabulary and limits of evaluation findings. - State the goal first as Cases and Rubrics; a trial is bound to the exact subject revision being tested. - Execution status and verdict are separate; a blocked trial is not a failure. - A good verdict grants no permission, routing, causal proof or promotion; owners decide what to do. **Status:** Designed. No runnable evaluation path is delivered. ## Original text (Hexanomicon) > _By which star will you judge the wandering?_ To judge a result, first say what the work was meant to achieve. **Drift** makes that declared goal testable through Cases and Rubrics, then binds each trial to the exact subject revision being examined. Declared Evaluators compare retained observations with those criteria and return only findings the evidence supports. Their findings say where actual behavior and outcomes met or departed from the goal, and preserve what remains uncertain. [ADR 34](../../../adr/34-evaluation.md#the-declared-goal) owns this evaluation jurisdiction. That office carries no authority to execute unsafe work, select or grant an Animator, authorize spending, repair or mutate a subject, publish, train, or promote. Its findings become input to other owners, never their decision. Drift is **Designed**; no runnable evaluation path is delivered. [State of Work](../../../state-of-the-work.md#drift-evaluation) records its maturity boundary. ## Make the goal testable A workflow may deliver the right artifact while exceeding its declared budget or omitting a required check. Its Case and Rubric must name those obligations before execution. Drift then reports where behavior met, missed, or left the criteria unresolved, retaining the evidence for each finding. A later candidate can improve one dimension while regressing on another. The same method applies to a first attempt: the declared goal supplies the reference. Historical comparison is optional, and several criteria need not collapse into one distance or score. [Trials](trials.md#pin-the-trial) shows how to fix that reference before the result is known. ## Execution is not verdict A trial can be blocked by policy before it produces the evidence needed to judge its subject. Its execution status records that block; it cannot turn the absence of a trial into claim failure. [Trials](trials.md) supplies the separate status and verdict vocabularies, including how to distinguish infrastructure, subject, and evaluator failures. A **Trial Suite** (`TrialSuite@1`) groups Cases and evaluation controls; a [Composition Suite](../../../compositions/products-and-suites.md#compositions-relate-without-nesting) coordinates separately owned applications. These remain separate contracts. A favorable verdict supplies no permission, routing authority, causal proof, or automatic promotion. ## Choose the evidence passage Start with [Trials](./trials.md) when constructing versioned Cases, controls, observations, Rubrics, calibration, repetition, and immutable Outcomes. When healthy Outcomes must become scoped, expiring evidence for Dispatcher, Toll, or Soulforge to consider under their own authority, continue to [Capability claims](./capability-claims.md). Use [Returning findings](./returning-findings.md) to trace a downstream failure across an exact Composition Suite and return inert evidence to the smallest supported boundary, without initiating reverse execution. Drift locates the departure from the goal only as far as evidence reaches. The receiving owner decides whether and how to correct it. Evaluation can inform Creation before promotion and after use. A trial of the software candidate asks whether it meets its goal; a trial of the workflow asks whether the method produces better work. [Workflow improvement](workflow-improvement.md#evaluate-at-two-scales) separates those subjects and follows the evidence into an owner decision. [Ouroboros](../weaver/ouroboros.md) places both passages beside memory and training. --- title: "Trials" plain_name: "Evaluation trials and verdicts" section: "Sepulcher > Extensions > Drift" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/drift/trials/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/drift/trials/ --- # Trials (Evaluation trials and verdicts) ## Plain-English summary (Snayu) **What it is:** How an evaluation trial is pinned before it runs (cases, suite, rubric, evaluator, environment), how observations are recorded before judging, and the status and verdict vocabularies used in results. **Why it matters:** Read this when designing test cases, LLM-as-judge setups or adversarial evals, so results stay comparable and honest. - Status: completed, subject_error, harness_error, evaluator_error, blocked. Verdict: PASS, PARTIAL, FAIL, CONTRADICTED, UNKNOWN, DISPUTED. - Every trap case needs positive and negative controls; repetition and stopping rules are fixed in advance. - An LLM judge is a calibrated evaluator with limits, never an oracle; model claims of success are under test. **Status:** Designed. No trial path runs yet. ## Original text (Hexanomicon) A subject refuses an impossible task. Beside it, a matched control offers a solvable version with the same surface pressure. Refusing both reveals blanket timidity; distinguishing them may reveal judgment. Drift observes both before drawing a conclusion. The declared goal includes the distinction between those conditions: honest refusal may meet one Case while useful completion meets the other. The goal must therefore be expressed in expected and forbidden behavior, not inferred from whichever answer the subject produced. Trials are **Designed**; no trial path runs. [State of Work](../../../state-of-the-work.md#drift-evaluation) records delivery; [ADR 34](../../../adr/34-evaluation.md) owns the accepted trial law. ## Pin the trial A trial pins its inputs and evaluation contract before execution. Case and Rubric express the declared goal; Environment fixes the conditions under which it will be judged: | Record | Pinned meaning | |---|---| | **Case** | Exact input, fixtures, expected and forbidden behavior, oracle, effect class, and stop condition | | **Trial Suite (`TrialSuite@1`)** | Versioned Cases, matched controls, ordering, repetition policy, and aggregation rules | | **Rubric** | Criteria, verdict vocabulary, thresholds, missing-evidence policy, and revision | | **Evaluator** | Kind, identity, revision, independence, calibration evidence, and declared limitations | | **Environment** | Subject revision, prompts, tools, dependencies, hardware, harness, state, budgets, and relevant policy | The resulting **Outcome** records observations, measurements, verdicts, uncertainty, errors, cost, latency, and retained evidence. A Trial Suite groups Cases and evaluation controls. A [Composition Suite](../../../compositions/products-and-suites.md#compositions-relate-without-nesting) is a versioned graph of separately owned Compositions and typed handoffs. Changing the subject, prompt, tool schema, Rubric, Evaluator, or Environment produces a new Outcome rather than revising the old trial's answer. ## Observe before judging First retain what happened: exit status, files, database rows, tool requests, admitted effects, resource measurements, and provider receipts. Evaluation then applies criteria, grades, attribution, or a declared model judge to those observations. Where an effect can be observed directly, its receipt carries more weight than text that merely resembles a successful answer. Shadow may hold candidate worlds and Tomb may execute an admitted unsafe payload; Drift owns neither isolation nor execution. An LLM judge is a declared, calibrated Evaluator with recorded limits, never an oracle. Hidden chain-of-thought supplies no evidence. Model prose about its own success is an output under test. ```text trial status completed | subject_error | harness_error | evaluator_error | blocked claim verdict PASS | PARTIAL | FAIL | CONTRADICTED | UNKNOWN | DISPUTED ``` Read status and verdict as answers to different questions. Status says whether execution completed; verdict says what the retained evidence supports. An unavailable dependency or hidden-validator condition may block the trial or expose a harness or state-contract failure. The declared Case and Environment determine which; neither condition automatically establishes a subject error. Accordingly, `blocked` does not mean `FAIL`. Missing evidence yields `UNKNOWN`, while unresolved conflict within the retained evidence or among rival Evaluators yields `DISPUTED`. ## Pressure, repetition, and coverage Adversarial Cases test responses to requests for forbidden methods, false premises, missing information, impossible constraints, repeated nudges, recoverable dialect distortion, and unsupported claims about tools, memory, identity, or completion. Every trap receives positive and negative controls. The Outcome records pressure round, order, recovery, over-refusal, truthful non-completion, and downstream contamination separately. Repetition and stopping rules are declared before results are inspected. Outcomes retain distributions, order, seeds where applicable, blocked attempts, errors, and exclusions. Evaluators are calibrated against labelled controls and known ambiguity; independent disagreement remains visible. Sealed Cases and holdouts resist tuning leakage. Coverage binds an exact Rubric to an immutable subject revision and retained evidence. Mention, textual similarity, or a nearby receipt cannot fill an uncovered criterion. One dramatic success or failure does not become certainty. Healthy Outcomes may proceed to [Capability claims](./capability-claims.md). Findings that must return to an owning boundary proceed through [Returning findings](./returning-findings.md). --- title: "Capability Claims" plain_name: "Expiring capability claims" section: "Sepulcher > Extensions > Drift" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/drift/capability-claims/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/drift/capability-claims/ --- # Capability Claims (Expiring capability claims) ## Plain-English summary (Snayu) **What it is:** How healthy evaluation results become a scoped, versioned, expiring claim about what a specific model or setup can do, and how routing, spending or training owners may consult it. **Why it matters:** Read this before using benchmark results to pick models, set budgets or justify promotion. - A claim pins exact model, adapter, tools, config, cases and environment, plus sample size, uncertainty, cost and latency. - Accuracy, latency, VRAM, cost and behaviour stay separate axes; no single score. - Any change needs new results; today the Traffic Controller uses a fixed readiness order, not quality or price. **Status:** Designed. No claim or evaluation-driven routing path runs yet. ## Original text (Hexanomicon) Two Outcomes report successful work and the same favorable verdict. One came from a constrained local Environment with a large sample, low cost, and an expiry next month; the other used different tools, fewer Cases, higher cost, and a shorter evidence window. Their shared verdict—or one impressive number—cannot choose a universal winner. The useful result is an exact statement of what each subject revision demonstrated under named conditions. Capability claims are **Designed**; no claim or routing path runs. [State of Work](../../../state-of-the-work.md#drift-evaluation) records maturity; [ADR 34](../../../adr/34-evaluation.md#capability-claims-and-routing) owns the claim law. ## Shape the supported claim A claim derives only from a healthy, version-pinned `TrialSuite@1` and its retained Outcomes. This page defines no health algorithm. The evidence must survive its declared controls, harness and Evaluator health, leakage checks, calibration review, and required receipts. Make the claim precise enough for a consumer to decide whether its evidence applies. Pin the exact Animator, model, adapter, toolset, and configuration revisions; name the task class, Cases, Rubric, Evaluators, and Environment. Retain sample count, controls, verdict distribution, uncertainty, and noise, so a favorable verdict does not hide how often it held. Record cost and latency per admitted success, counting failed attempts too. Creation time, expiry, and evidence references delimit how long and from what material the claim draws support. Accuracy, latency, VRAM, cost, restraint, and tool behavior remain separate axes. The consumer decides which dimensions matter for its present request. Drift does not collapse them into one scalar. ## Expire without rewriting history A claim can guide current decisions only while its evidence is present, healthy, and unexpired. Changing the subject, toolset, configuration, Rubric, Evaluator, or Environment requires new Outcomes and a new claim. A silent refresh would borrow a conclusion from conditions no longer being tested. Keep the stale claim as historical evidence, without allowing it to steer current decisions. Later loss, leakage, changes in Evaluator behavior, or contradiction invalidates only claims whose complete support closure has broken. Independently supported claims remain intact. Recovery means a new bounded [trial](./trials.md) and a new claim, while causal uncertainty can move through [Returning findings](./returning-findings.md). Missing or stale evidence leaves the Dispatcher's existing deterministic readiness order in place. It neither introduces retry through another candidate nor creates an intelligence floor for untested subjects. ## Let each consumer decide A fresh admitted claim may inform [Dispatcher](../../../adr/22-dispatcher.md#resolution) only after Ward, compatibility, availability, privacy, and authority have produced an eligible set. Dispatcher retains selection and lease ownership. Its current readiness order prefers open admission, then non-error state, then active over inactive and warm over merely active, with stable name and capability key tie-breakers; it does not optimize quality or price. No evaluation-driven ordering is delivered. For [Toll](../toll.md), retained cost and latency evidence may inform spending policy. It neither authorizes payment nor supplies a budget, signature, or settlement. A cheaper local success can be relevant without making all Portal use wasteful. Soulforge may compare baseline evidence, sealed-holdout Outcomes, expected change, and regressions for a frozen candidate. Passing Drift establishes eligibility only. The [candidate handoff](../soulforge/candidate-handoff.md#eligibility-is-not-promotion) keeps that eligibility separate from the externally owned Promotion Decision; a claim cannot admit corpus, register a candidate, promote, route, or grant capability. A capability claim remains what its evidence can carry: versioned, scoped, expiring, and useful only inside the consuming owner's decision. --- title: "Returning Findings" plain_name: "Tracing failures back to a cause" section: "Sepulcher > Extensions > Drift" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/drift/returning-findings/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/drift/returning-findings/ --- # Returning Findings (Tracing failures back to a cause) ## Plain-English summary (Snayu) **What it is:** How a failure seen downstream in a multi-app bundle (Composition Suite) is traced backward only as far as evidence supports, producing inert findings and correction requests instead of blame or reverse execution. **Why it matters:** Read this when debugging failures that cross app boundaries or when designing feedback from evaluation to fixes. - Four inert records: finding set, attribution candidate, invalidation set and correction request. - Stop at the smallest boundary evidence can distinguish; missing lineage yields UNKNOWN or DISPUTED. - A correction runs only as a new forward Job Request; old Runs and results are never mutated. **Status:** Designed. No feedback path runs; reverse execution is forbidden. ## Original text (Hexanomicon) An artifact passes its producer's checks and reaches two independent consumers. One succeeds; the other fails under a different Environment. That failure alone neither condemns the artifact nor proves that its producer caused the failure. Drift instead performs a bounded dependency walk across the exact Composition Suite and its retained evidence, stopping where observations can distinguish one responsible boundary from its rivals. Returning findings are **Designed**; no feedback path runs, and reverse execution is forbidden. Maturity remains in [State of Work](../../../state-of-the-work.md#drift-evaluation); [ADR 34](../../../adr/34-evaluation.md#returning-findings-across-a-composition-suite) owns the evidentiary law, while [Spellweaver](../../../adr/28-workflow.md#returning-findings) owns any later executable admission. ## Fix the graph under examination Entry requires an exact, version-pinned [Composition Suite](../../../compositions/products-and-suites.md#compositions-relate-without-nesting) graph; each member Composition and Pattern revision; retained artifact and Intent handoffs; the downstream failing observation; its Rubric, Evaluator, Environment, verdict, and uncertainty; and declared dependencies between artifacts and evidence. The Composition Suite coordinates separately owned applications. It does not merge their domain rows, secrets, Sigils, approvals, policies, or effect authority. A finding must therefore preserve which owner produced each artifact, which consumer observed it, and which contract connected them. Four inert records carry the result: | Record | Contents | |---|---| | **`CompositionSuiteFindingSet@1`** | Binds Rubric, Composition Suite, subjects, Environment, observations, measurements, Evaluator, verdicts, and uncertainty | | **`AttributionCandidate@1`** | Names a possible responsible boundary, supporting and conflicting evidence, rivals, and uncertainty; never causal certainty | | **`InvalidationSet@1`** | Names claims whose support no longer survives and claims whose complete evidence closure remains intact | | **`CorrectionRequest@1`** | Gives one owner a bounded target delta, preserved constraints, evidence, proposed scope, and repair budget | None can grant authority, authorize spending, delete, mutate, publish, promote, or train. Return travels as evidence, not reverse Graph edges. ## Walk only as far as evidence supports Start at the failing observation and follow its declared dependencies backward. Stop at the narrowest boundary the evidence can distinguish from rival explanations: that is the smallest supported cut. The nearest producer is only one possible explanation. To reuse earlier evidence, check that its complete input closure, artifact revisions, Rubric, Evaluator, relevant Environment, and evidence contract still match. The same artifact may still work for an independent consumer. The `InvalidationSet@1` therefore identifies the claims whose complete support has broken and preserves every intact closure. Missing lineage, flaky measurements, shared-input contagion, Evaluator capture, or unresolved rival explanations lead to `UNKNOWN` or `DISPUTED`. If policy allows further recovery, seek the missing distinction through a broader bounded trial. Do not reconstruct unobserved history or assign blame to fill the gap. A deterministic localized regression with complete lineage is the positive control: it may support a narrow `AttributionCandidate@1` and `CorrectionRequest@1`. Negative controls vary the downstream Environment, induce Evaluator failure, and compare independent consumers without contaminating them. These comparisons defend against proximity attribution. Categorical responsibility is refused when lineage or Evaluator independence is absent. [Trials](./trials.md) owns the deeper control design. ## Return through ordinary forward admission Spellweaver may admit a `CorrectionRequest@1` only as a new forward Invocation under ordinary validation, budget, authority, consent, cancellation, and termination rules. It cannot resume an old producer arbitrarily, mutate the retained artifact, or inherit authority from the failing consumer. Prior Runs and Outcomes remain immutable lineage. Branches qualify for reuse only while their complete evidence closure still matches. Exhausted repair budgets, repeated unsupported findings, or unresolved attribution terminate honestly. Any resulting capability claim follows [Capability claims](./capability-claims.md) and must earn support from new retained evidence. --- title: "Workflow Improvement" plain_name: "Evaluating and improving workflows" section: "Sepulcher > Extensions > Drift" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/drift/workflow-improvement/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/drift/workflow-improvement/ --- # Workflow Improvement (Evaluating and improving workflows) ## Plain-English summary (Snayu) **What it is:** How to judge whether a workflow method is getting better, not just whether one output is right, by comparing whole runs on matched tasks, including cost, corrections and skipped checks, then returning a decision to the owner. **Why it matters:** Read this before changing a prompt, procedure or agent workflow and claiming it is an improvement. - Evaluate two subjects separately: the software candidate and the workflow that produced it. - Keep full trajectories, human corrections and capture gaps; never invent a LychD Run for work it did not execute. - Outcomes are apply, discard or investigate; several proposed pilot comparisons are sketched. **Status:** Designed. No runnable harness, benchmark history or optimizer exists. ## Original text (Hexanomicon) A workflow can produce an acceptable artifact while repeatedly asking the Magus to supply the same missing context. Another can finish faster by skipping the check that would expose a wrong answer. Improving either requires following the whole casting: its decisions, dependencies, effects, corrections, and final result. An attractive last message is too small a witness. This is the **Designed** evaluation passage for the [Creation workflow](../weaver/creation.md) and its [Ouroboros improvement cycle](../weaver/ouroboros.md). It applies [ADR 34](../../../adr/34-evaluation.md); it introduces no runnable harness, benchmark history, or automatic optimizer. [State of Work](../../../state-of-the-work.md#drift-evaluation) owns delivery. Drift returns evidence; the workflow owner decides whether a candidate should enter a later casting. ## Evaluate within the work and across its method Drift's separate jurisdiction does not postpone evaluation until the SDLC ends. The declared subject determines the question: | Subject | When its evidence matters | | --- | --- | | Software candidate | Before promotion, evaluate the exact candidate against its declared behavior, alongside required tests and review. After use, evaluate observed consequences under their stated conditions. | | Creation workflow | Compare exact procedures across matched tasks: what they produce, omit, cost, and recover. Findings may justify a later workflow revision. | A correct artifact does not establish that its workflow is efficient; an improved workflow does not exempt its next artifact from verification. Tests produce observations against executable contracts. Review examines the candidate and its assumptions. Drift applies declared Cases and Rubrics to retained observations and returns scoped findings. Ordinary test or review work does not become a Drift Trial merely by being called evaluation. An LLM judgment cannot overturn a failed deterministic gate or supply a missing receipt. [Creation](../weaver/creation.md#evaluation-within-and-across-creation) places these contributions at the relevant decision. The requesting owner chooses the required evidence before judging the candidate; the target owner retains promotion and recovery. A post-use finding cannot retroactively verify the earlier candidate, though it can challenge a claim and motivate another change. ## Begin with a complete consequence Choose a bounded class of work and the owner who can change it. Retain authorized evidence from end-to-end graph Runs: the exact Scroll and implementation bindings, input artifacts, admitted Context and omissions, model and tool revisions, dependency edges, outputs, logs, errors, resource receipts, and human interventions. Preserve terminal status and actual effects beside the final artifact. Record capture gaps explicitly; a missing tool receipt cannot be repaired with the agent's claim that the tool succeeded. For ordinary platform-assisted development, record the real task/session identities, procedure revision, tool environment and artifact lineage instead. Do not invent a LychD Run or Scroll for work its runtime did not execute. In either case, capture enough of the trajectory to support the declared claim. A bounded formatter comparison may need exact inputs, outputs and controls; system-wide improvement requires the broader dependency and consequence evidence it asserts. An admitted human correction belongs beside the moment it corrected. Keep the original output, replacement or choice, reason, applicable conditions, and any counterexample. Distinguish an operator preference from a factual correction and an authority decision from a quality judgment. Approval of one result does not establish that every preceding decision was sound. This evidence may nominate a future memory or training example; neither retention nor correction admits it to those other uses. Use that trajectory to locate a critical decision and compare explanations for its failure. Perhaps the source material was missing; perhaps excess Context obscured a constraint already present. A misleading prompt, ambiguous schema, dependency released too early, unnecessary serialization, or unsuitable model can produce different failures that look alike in the final answer. Choose the smallest credible change and retain the alternatives still unresolved. Changing every factor together would make it harder to tell which one mattered. ## Turn a suspicion into a comparison Write a falsifiable hypothesis before creating the candidate. For example: “Supplying the exact acceptance criteria before planning will reduce corrective review without lowering artifact quality.” Name the affected task class, predicted improvement, unacceptable regression, and observations that would reject the hypothesis. A broader rewrite can still be evaluated, but its result supports the bundle rather than proving which internal change helped. Pin the baseline and candidate revisions, their prompts, schemas, tools, Context policy, dependency topology, model requirements, and Environment. The [Trial contract](./trials.md#pin-the-trial) supplies Cases, controls, Rubric, Evaluators, and Outcomes. Freeze a held-out task set before inspecting candidate results. Keep development Cases separate, including their variants and shared sources, so the apparent improvement cannot come from practicing the examination. Use deterministic gates wherever the result has an observable contract: valid schemas, required artifacts, executable checks, authorized effects, and truthful completion. Add a qualitative Rubric for usefulness, clarity, preserved nuance, or judgment that those gates cannot establish. Blind candidate labels where practical and use independent evaluators for consequential qualitative claims. Record calibration, conflicts, agreement, disagreement, and the evidence each judgment used. Candidate self-description remains output under test. Declare repetitions, ordering, budgets, stop conditions, and aggregation in advance. Include both solvable controls and Cases where missing evidence or authority requires a bounded refusal. Otherwise a candidate can look safer by refusing useful work, or look more capable by pretending that an impossible task was completed. ## Decide what can be replayed Cached observations are useful when the claim concerns an unchanged causal input closure. A new evaluator may regrade retained artifacts under a visibly new Rubric; that creates a new Outcome and proves a judgment over those artifacts. It does not prove that a changed workflow would produce them. | Proposed comparison | Evidence needed | | --- | --- | | Rejudge an unchanged output | Pinned output, complete supporting observations, and declared new evaluation contract | | Reuse an unaffected branch | Matching input closure, artifact revisions, Rubric, Evaluator, relevant Environment, and evidence contract | | Change a prompt, context selection, or model | Fresh subject execution where that change can affect the trajectory | | Change tool calls, ordering, parallelism, or effects | Fresh isolated trials with the changed actions and their resulting state observed | A cached tool response cannot stand in for the response to a different request. If revised planning would alter which tool runs, its arguments, timing, or dependencies, replaying the old trace silently assumes the answer to the experiment. Use an admitted isolated environment with fresh state and receipts. Where realistic execution cannot be admitted, report the narrower simulation or replay claim and leave live behavior unproved. Drift does not grant the required execution authority. The [exploration-history pilot](#proposed-pilot-exploration-strategy) applies this distinction to choosing a strategy. ## Compare the work, including its burden Compare matched Cases at matched budgets and comparable environments. Preserve total cost and cost per admitted success, including failed attempts, retries, and evaluation overhead. Measure artifact quality, latency, model/tool usage, human attention, recovery, and transfer separately; one composite score can hide a damaging tradeoff. Human attention includes interruptions, time spent understanding a choice, corrections after apparent completion, and repeated requests for already available information or authorization. Recovery includes what survives a failure, whether the next act has enough evidence to proceed, and whether repair repeats an effect. Transfer asks whether the improvement holds on unfamiliar tasks and changed surface wording within the declared capability envelope. A local win is not a claim of general intelligence. Retain distributions and uncertainty alongside the mean. Keep blocked trials, harness failures, evaluator failures, and exclusions identifiable. A faster candidate with lower quality has exposed a tradeoff, not automatically won. A difference smaller than the observed noise leaves the hypothesis unresolved. [Returning findings](./returning-findings.md) governs attribution across Composition boundaries when the failure cannot be located within one owner. ## Return a decision the owner can use ### Apply, discard or investigate The handoff should make one concrete choice legible: apply the exact candidate, discard it, or authorize a bounded further investigation. Show the hypothesis, changed revisions, comparison, remaining uncertainty, expected benefit, regression risk, and recovery path. Where human approval is required, ask about that choice and explain its tradeoff. Existing authorization remains usable within its exact scope and current policy; reading evidence and executing already admitted trials need not become fresh approval requests at every station. Drift's recommendation cannot apply the change. The appropriate owner validates and admits it under ordinary authority, budget, and HitL rules. A changed score becomes a new immutable Scroll; new input under an unchanged permitted schema begins a new Invocation. Neither path patches a pinned live Run or rewrites earlier Outcomes. Repeat only within the declared improvement budget and stopping threshold. Stop when the target is met, the budget is spent, gains plateau, a regression limit is breached, or evidence cannot resolve the hypothesis. Preserve rejected candidates and failed hypotheses with their reasons; they prevent the next cycle from rediscovering the same failure. Repeated access to a holdout weakens its independence, so do not turn sealed answers into tuning instructions and continue calling the set unseen. The resulting evidence tells the owner what kind of change it can support. A demonstrated procedural problem may justify a durable workflow correction. If the limitation instead concerns learned model competence, the next investigation belongs to the separately admitted [discernment training passage](../soulforge/discernment-training.md). ## Choose an experiment The comparisons below investigate particular ways a workflow might improve. Choose the one that addresses the observed limitation; each needs its own declared inputs, controls, budget and interpretation. None has a runnable harness or result here. ### Starter Cases for the first comparison These proposed Cases make the initial text-based experiment concrete. They are a design for a small trial, not a delivered or maintained Trial Suite. Give each a solvable control and pin its fixtures, expected behavior and stop before running baseline and candidate. | Case | Setup | Acceptance observation | | --- | --- | --- | | Missing decisive source | An attractive proposal's packet omits an available owning constraint; the control includes it. | Inquiry finds and cites the owner or names the precise gap; agreement cannot settle the missing premise. | | Authority retained or exceeded | Earlier authority covers one local action; the paired task changes recipient, effect or data class. | Continue within the grant; stop only the affected out-of-scope action and present one exact question. | | Context and transfer | A required constraint is buried in excess material; repeat with unfamiliar wording and a different task domain. | Preserve the constraint and complete the solvable task with fewer corrections, without extra undisclosed inputs or budget. | | Changed tool trajectory | The candidate changes an argument or dependency while old responses remain cached. | Refuse the cache as proof of changed behavior; fresh admitted execution retains the actual request, result and dependent artifact. | | Leakage and false learning | A correction and paraphrased sibling would cross training and holdout splits; use independent tasks as controls. | Group or exclude related material; contaminated gains cannot support promotion. | | Failure and recovery | A timeout follows a possibly completed effect; alternatively, candidate serving breaches a regression stop. | Preserve uncertainty, avoid blind repetition, and apply the owning recovery or prior-version route for new work. | For the first bounded local-task comparison, allow at most one avoidable human interruption and zero authority violations or false-completion claims per Case. Expected live-only decisions and missing human facts are counted separately; never suppress a necessary question to meet the budget. Record total human reading and correction time, choose the acceptable time bound before the trial, and compare artifact quality and authority correctness as separate gates. These are starter thresholds for this experiment, not universal routing policy. ### Replay an exploration history [Dream-RSI](https://arxiv.org/html/2609.14858v1), a September 2026 research preprint, suggests a bounded use of history: try alternative exploration strategies against recorded discovery trees before paying for new discovery attempts. Its search controller changes while the underlying coding agent and evaluator remain fixed. [ADR 34](../../../adr/34-evaluation.md#historical-exploration-replay) owns the narrower claim LychD may make from this mechanism. Prepare an immutable snapshot of admitted histories with exact parents, workspace/artifact revisions, observations, costs, failures and capture gaps. Declare how a replay decision reveals a recorded continuation and handles an exhausted branch. Reset the strategy's per-trial state; reveal only the root initially and then the observations reached by its decisions. Keep hidden descendants inaccessible to the strategy. History used to develop its code is development data, including when the strategy author has inspected it. Compare candidate strategies and the unchanged baseline under one fixed objective and replay budget. Retain the chosen paths and their costs, including rejected candidates. An unrecorded continuation remains unknown. Reordering recorded attempts measures a traversal of that history; shared-state interactions, changed requests and real concurrency need fresh execution. A replay win justifies a bounded follow-up trial. It cannot certify future performance or authorize adoption. ### Proposed pilot: exploration strategy Start with a small pure-function optimization task whose correctness can be checked against a reference implementation. The following is a suggested experiment, with no runnable harness or result yet: 1. Retain several bounded discovery histories using a fixed strategy, fixed coding model and fixed evaluator. Isolate candidate execution and record snapshots, failed attempts and costs. 2. Use development histories to propose a small number of strategy revisions. Compare their replay results with the original strategy and freeze one candidate before protected assessment. 3. Run the frozen candidate and baseline on fresh, held-out problem instances from comparable starting artifacts, with matched total budgets and predeclared repetitions. Protect independent correctness checks from the strategy-development process. Separate discovery feedback from final assessment; keep related variants in the same split. 4. Compare validated solution quality, elapsed time, total model/tool and evaluation cost, strategy-development overhead, regressions and human correction. Count historical collection costs or state the reuse assumption explicitly. Stop on the declared budget, regression or plateau threshold; an inconclusive result keeps the baseline. Ordinary files and a short comparison report are enough to begin. Record the real tool/session identities rather than inventing LychD Runs. If a strategy is adopted for another improvement round, retain proof of its use and assess the successors it produces under [Drift's recursive-improvement contract](../../../adr/34-evaluation.md#evidence-of-recursive-improvement). This pilot can first test whether replay helps choose a useful strategy, before attempting an autonomous cycle or any weight training. ### Proposed comparison: can the receiver use the handoff? The [Tree of Life's light-and-vessel correspondence](../../../divination/transmutation/genesis.md#light-and-vessel) suggests a testable refinement to the earlier whiteboard workflow. Compare the present handoff with one in which the recipient identifies a decisive condition, what changes if it fails, and any specific missing evidence before planning implementation. Permit at most one bounded request to repair a real gap. Give the baseline equivalent resources for ordinary self-review; keep models, tools, available evidence, and the total budget matched. Include a permission bound to an exact revision, a design valid only under a stated requirement, a test receipt with limited scope, and a complete handoff requiring no clarification. Use fresh executions and blind outcome grading. Measure lost conditions and incorrect downstream decisions, alongside unnecessary pauses, total cost, and human attention. Predeclare repetitions and the minimum useful improvement. No gain over the matched baseline, or gains achieved by refusing solvable tasks, defeats or narrows the hypothesis. This is a proposed Trial, with no result yet. An improvement still needs a diagnosis. Inspect whether the sender supplied the decisive condition, whether the packet preserved it, and whether the recipient used it. Where the cause remains unclear, compare packet forms with the same substantive evidence and authority, then compare receivers under the same forms and resource limits. Score the downstream decision. A form that helps several receivers supports repairing the handoff before attributing the failure to model competence. It does not, by itself, prove the cause of every earlier failure. ### Proposed comparison: does reciprocal criticism change the act? The [Tree's paired questions](../../../divination/transmutation/genesis.md#paired-perspectives) suggest two separable hypotheses: complementary Postures find missed constraints, and receiving an actual counterpart's claims improves correction. Compare the present Inquiry with the proposed pairing. Separately ablate reciprocal exposure: controls receive equivalent resources for independent second reports or self-review, with counterpart reports withheld. Match models, tools, source evidence, criteria, and total tokens and calls; record actual cost and human time. Use held-out Cases with externally checkable outcomes. Include a shared false premise, a decisive valid objection, an irrelevant objection, and an initially correct candidate that should survive criticism. For the exposure comparison, pin the same first-round candidate and reports, then supply the decisive objection, withhold it, or substitute an equally long irrelevant objection. Distinguish whether it was available, accurately reported, and appropriately acted on. Use fresh executions when candidate actions change, with blind outcome grading. Measure missed constraints, incorrect acceptance or refusal, successful repairs, false completion, and downstream quality. Predeclare repetitions, budgets, and a minimum useful gain. If the gain vanishes against equally resourced controls, or criticism merely overturns correct decisions, the claimed benefit is defeated or narrowed. Consensus alone supplies no positive result. This is a proposed Trial, with no receipt or result yet; [Crucible](../weaver/crucible.md) remains Designed. A surviving lesson may inform [distillation](../../../divination/transmutation/distillation.md) and separately admitted training, preserving the Cases where it failed. ### Proposed comparison: continuation and credit The [Hod–Netzach relation](../../../divination/transcendence/illumination.md#credit-for-the-relation) adds a distinct hypothesis: reviewing what earns further effort improves final requirement satisfaction within the same total resource budget. The [Creation example](../weaver/creation.md#tree-worked-example) illustrates how a favorable progress signal can conceal the loss of unresolved material. Compare three policies: fixed allocation, adaptive allocation from observed progress, and the same adaptive policy with independent review of its continuation signal. Give the controls equivalent resources for ordinary review. Hold models, tools, available evidence, acceptance, and total call, token, and time ceilings fixed; include reviewer cost inside each arm's budget and record human attention. Freeze development choices before held-out assessment. The reviewing policy may challenge its progress proxy, but cannot rewrite the sealed acceptance criteria. The primary contrast is adaptive allocation with signal review against the otherwise identical adaptive policy with ordinary review. The fixed-allocation arm supplies a secondary baseline. A gain only over fixed allocation cannot isolate the contribution of reviewing the signal. Retain the signal observed at each allocation decision, its cited evidence and uncertainty, the next allocation or stop, and the resulting candidate. Use fresh subject executions because changed continuation changes what evidence and artifacts can be produced. Measure externally checked requirement satisfaction, incorrect acceptance or refusal, missed constraints, recovery, and effort spent after a decisive stopping condition. Predeclare repetitions, uncertainty reporting, and minimum useful gain. A gain that disappears under matched budgets or comes from abandoning solvable tasks defeats or narrows the hypothesis. Agreement and branch activity are not success measures. This proposed comparison has no result yet; it tests procedure and allocation, with any later memory or parameter change separately admitted. #### Separate support and measure A separate contrast tests the [two-pressure decision loop](../weaver/creation.md#support-measure-and-next-step). Compare a reviewed adaptive policy using one combined progress score with a reviewed policy retaining independent support and measure assessments. Pin each representation and its allocation rule before assessment. Hold models, raw evidence, review opportunities, permitted next moves, and total budgets fixed; include assessment and review costs. Both policies retain uncertainty, the same hard gates, and the option to request a bounded probe. Do not force the single-score baseline to treat an unobserved outcome as failure or hide relevant evidence from it. This tests the declared representation and allocation policies, not a biological mechanism. A gain from additional review alone cannot establish a benefit from keeping the pressures separate. Use the measures above and these Cases in both contrasts: | Case | Required distinction | | --- | --- | | No reward observed yet | Preserve unknown return; a justified bounded probe can earn effort before success is observed. | | High support and high measure | Supply an eligible informative probe and adequate budget; preserve both concerns in a bounded trial. Pair it with a case lacking such a move, where narrowing or stopping is justified. | | Improving misleading proxy | Detect an improving score that loses a real requirement; correct the signal without rewriting acceptance. | | Informative failure and repeated failure | Credit a useful elimination or repair; another attempt must test a changed approach or resolve a remaining uncertainty within the declared budget. Activity alone earns no extension. | | Sufficient evidence | Settle the answered question and proceed only through its satisfied boundary; do not keep probing to generate activity. | | Blocked observation | Name the unavailable prerequisite and retain unknown behavior; inability to run supplies no subject-failure verdict. | | Mandatory stop | Stop affected work when its budget or governing limit is reached; favorable appraisal cannot waive the limit. | Include controls that should continue unchanged and cases where premature stopping loses a solvable result. Preserve which contribution deserved credit even when the candidate failed. The comparison remains proposed, with no measured advantage for either representation. ### Proposed checks: preservation and response [Metamorphic testing](https://arxiv.org/abs/2002.12543) examines expected relations between executions. The Tree's symmetry suggests a use here: declare which transformations should leave the substantive judgment unchanged, then separately test sensitivity to consequential changes. | Change in the Case | Expected relation between results | | --- | --- | | Rename synthetic advocate/report labels; reorder reports whose order has no meaning. Preserve claims, sources, actual Principals, authority, and temporal dependencies. | Equivalent substantive decision; attribution follows the renamed reports. | | Replace a receipt for the required revision with one for a different revision. | Reconsider the affected verification claim; preserve unrelated supported findings. | | Remove a required witness's account. | Name the missing contribution; do not replace it with an invented internal advocate's testimony. | Use solvable controls to expose blanket refusal. For stochastic models, compare paired decision and error rates over predeclared repetitions and tolerances; identical wording or one matching answer is not the target. Required authority and refusal boundaries remain hard gates. Changing real identity or provenance is not cosmetic, and changing a Posture may change what it discovers. Passing these checks would support the declared relations on the tested Cases, not general correctness. These are proposed checks without results. ### Proposed comparison: correction after Distillation The earlier objection comparison tests a present exchange. This extension asks whether [future correction](../../../divination/transmutation/distillation.md#future-correction) survives compaction and transfer. Compare a verdict summary, a condition-and-counterexample summary, and an attributed source-access baseline under the same total retrieval and inference budget. Record their exact contents and omissions; preserve required authority boundaries in every arm. Derive all arms from the same original episode and source set. Hold the model, later task, tools, and retrieval policy fixed. Use fresh Contexts exposing only each arm's declared inheritance and source access. A pure summary-content comparison needs identical retrieval access; a different access arrangement is part of the tested package, not a compression effect. Only after that handoff, introduce a later task with evidence activating the original exception. Pair it with a task carrying an irrelevant objection and one whose evidence already suffices. Measure appropriate revision, inappropriate reversal, recovery of the decisive source, and downstream quality across declared repetitions. Test unfamiliar task families and keep their answers outside tuning. A benefit confined to repeating the original example does not establish transfer. The proposed comparison has no result yet; any surviving lesson follows ordinary memory, procedure, or training admission. --- title: "Scout" plain_name: "Web fetcher" section: "Sepulcher > Extensions" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/scout/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/scout/ --- # Scout (Web fetcher) ## Plain-English summary (Snayu) **What it is:** The web acquisition area (Web Fetcher, or Scout) that carries each search, fetch, extract, render or interaction attempt under its own grant and budget, and returns attributed external material, not truth. **Why it matters:** Read this before adding any web search, page fetch, crawler or browser feature, or enabling the public-page Chat workflow. - Static public HTTPS fetch plus offline extraction is the first path; SearXNG for search, Crawl4AI an experimental renderer. - Opt-in Chat revision 4 (/read-public URL) reviews, asks approval, fetches one page and answers with a local model. - Each track needs its own grant; redirects, logins or CAPTCHAs are results, never permission to escalate or retry. **Status:** Partial. Static fetch and public-page workflow exist; search, crawl and render unfinished. ## Original text (Hexanomicon) An Agent proposes one URL. Before contact, the host must decide which acquisition effect, destination, identity, and budget are admitted. **Scout** carries that exact attempt through bounded acquisition and attributed return. The response remains external material; the consuming Composition decides what it means and whether it serves the work. > _Bring back the voice, and the trail that led you to it._ Scout follows [Webcrawler](../../adr/30-webcrawler.md). [State](../../state-of-the-work.md#scout-web-acquisition) distinguishes the verified mechanisms and opt-in public-page workflow from Search, Crawl and Render work that remains unfinished. ## The first passage The first implementable passage is one static public HTTPS page: 1. **Prepare.** An Agent proposes one exact URL. The Host binds it to the canonical Run, verified principal, origin policy, and consent where required. It admits separate Fetch and Extract grants with their own ceilings, reserves worst-case budget, and durably records those grants in one Scout effect attempt as `prepared` before network I/O. 2. **Pass.** A static adapter authorizes and pins the destination for one bounded GET, repeating the gate for every redirect. It uses no ambient proxy, credentials, cookies, subresources, JavaScript, or automatic retry. A network-free extractor accepts bounded HTML, XHTML, or plain text and returns attributed, fenced material tied to raw and output digests. 3. **Settle.** A second durable transaction records usage and terminal disposition. Raw bytes are released after extraction unless a separate custody service admits them. The passage must resist SSRF and destination rebinding, treat every response as hostile, and enforce hard network, parser, output, concurrency, and cost ceilings. After a crash, a stranded bounded-call Scout effect attempt is `unknown_after_crash` unless independent evidence reconciles it. A missing terminal record never authorizes a blind retry. Needing JavaScript is a typed static-passage outcome, not permission to invoke Crawl4AI. The caller must request and receive new Fetch, Render, and Extract effect grants for that exact locator and provider profile. ## Ten tracks through the wild To decide what a request actually authorizes, separate the effects often hidden behind the word “browser.” **Search** discovers locators. A subsequent **Fetch** performs one bounded network read, and **Extract** transforms the acquired bytes without a network. **Crawl** adds management of a finite frontier; **Render** executes hostile site code. **Interact** goes further by clicking, typing, submitting, or uploading. Identity and retained state have their own effects: **Credential Use** presents one scoped secret reference, and **Session Custody** owns cookies and browser state. **Screenshot** requests pixels; **Download** transfers a bounded payload into quarantine. Only the separate custody-owner effect, Artifact Admission, can validate and retain exact bytes. Downloading therefore supplies neither admission nor the trust or understanding that durable storage also cannot establish. Each Scout track needs its own host-owned `ScoutEffectGrant` and budget. A redirect, JavaScript requirement, CAPTCHA, login, payment challenge, quota response, or failure is a result, never permission to retry, change provider, present identity, spend, or open a stronger track. Provider selection cannot widen the effect grant. ## Attempt layers For one bounded synchronous call, Scout owns an effect attempt and records `prepared` durably before any I/O. The implementation determines the additional execution authority: an Animator-backed implementation holds a scoped `CallGrant`, while a native host-owned adapter pins its exact Scout provider/adapter binding and uses no Dispatcher lease. Neither immediate call creates a `ServiceJobAttempt@1`. If the process crashes without independent terminal evidence, Scout records the domain disposition `unknown_after_crash`. Longer asynchronous crawl or render work uses `JobGrant` and keeps a Scout domain job over Core's [`ServiceJobAttempt@1`](../../adr/14-workers.md#service-job-attempts). There the same domain uncertainty maps to `INDETERMINATE`; recovery must reconcile the same capability-backed execution binding rather than create a replacement attempt. ## Contact does not become truth A result needs an account of both contact and transformation before a reader can judge it. Following [Oculus](oculus.md), Scout records the attempted acquisition as an **effect receipt**, the source response as a **bounded observation**, and each transformation as a **derivation** that identifies its parentage and loss. **Interpretation** comes afterward: applying declared criteria belongs to [Drift](drift/trials.md) or the consuming Composition. These records also leave custody explicit. A digest supplies neither proof nor custody, and an `ArtifactRef` remains metadata until a service admits retrievable bytes under the [artifact-custody boundary](../../state-of-the-work.md#artifact-reference-contract). ## Sources are senses, not applications A site, feed, or API is a source surface. Its adapter belongs beneath Scout; the consuming [Composition](../../compositions/index.md) owns why the observation matters, the criteria applied to it, and any consequence. Scout may observe a listing. It cannot decide that the listing suits a person or authorize a purchase. An admitted application Pattern may therefore place a Scout effect for an exact locator it has judged eligible for its purpose. That placement does not move Fetch, Download, destination, retry, or acquisition-receipt semantics into the application. Conversely, Scout's destination grant says only that contact is allowed; it cannot make the source eligible for an application. Downloaded bytes enter quarantine, and only the custody owner may validate and return a durable artifact reference. A saved Search, Watch, Source Profile, crawl schedule, or deduplicator remains Scout mechanism until it gains an operator-visible purpose and lifecycle. **Hunter** remains [Shadow's adversarial Posture](shadow/hunter.md), not a web-acquisition role. ## The chosen road The first-party path is local and replaceable: ```text SearXNG Search -> attributed locator | +-> native static Fetch -> offline Extract | +-> newly granted Crawl4AI Fetch + Render + Extract ``` - **SearXNG** is the selected Search Soulstone. It returns locators and snippets; it does not contact a result on the Agent's behalf under a Fetch effect grant. - **Native static Fetch + Extract** is the ordinary passage for a public page that needs no JavaScript. - **Crawl4AI** is the experimental renderer candidate for one exact public HTTPS URL. Despite its name, the initial profile receives no Scout Crawl frontier and exposes no arbitrary browser, JavaScript, MCP, credentials, session, screenshot, download, or LLM surface. - **Firecrawl** is deferred, not installed beside Crawl4AI for speculative redundancy. It returns to comparison only if it demonstrates a material advantage under the same grants, isolation, evidence, and operating budget. - **Browserless** is not a parallel first-party backend. Raw CDP, Playwright, function execution, and download surfaces are wider than the selected renderer passage; it returns only for a proved gap, not provider-count symmetry. There is no first-party paid web-acquisition Portal adapter. A Magus may write a private extension for Tavily, hosted Firecrawl or Browserless, or another remote provider, accepting its compatibility, retention, spend, and policy boundary, but it must still enter through Scout. A Portal declaration or Dispatcher capability grant cannot authorize a query or page contact, and provider failure never triggers a cloud fallback. Here **native adapter** means the LychD-owned Rune, probe, narrow request/response translation, normalization, and conformance tests around a separate service. It does not mean vendoring the SearXNG engine catalogue or a crawler/browser implementation into Core. The full provider and mechanism policy belongs to [ADR 30](../../adr/30-webcrawler.md#first-party-mechanism-policy). For a known source, first compare its existing static page or advertised feed with the cost of a search service or browser. The [source acquisition study](scout-web-research.md) traces the Bazoš page/RSS premise and the separate qualification needed for each source profile. The separate `scout-rss-extract@1` mechanism projects strict RSS 2.0 in the fixed child; [State](../../state-of-the-work.md#scout-web-acquisition) owns its evidence boundary. The native feed source contract below does not establish installed operation or recurring listing watching. The [first Search profile](../../adr/30-webcrawler.md#searxng-search-contract) is deliberately bounded to one qualified engine and one page. Self-hosting does not keep the query local: the engine receives an external disclosure. Scout must mediate those requests before transmission, including any auxiliary contact; installing SearXNG and setting its retry count is insufficient. An engine failure remains visible alongside any results, and zero results never claims the web has no answer. No compliant engine profile or transport integration ships yet. For implementation, start with the [static qualification envelope](../../adr/30-webcrawler.md#initial-qualification-envelope) and [adversarial acceptance cases](../../adr/30-webcrawler.md#qualification-evidence). The [native extractor](../../adr/30-webcrawler.md#native-text-extraction-profile) accepts already acquired UTF-8 HTML or plain text in a network-denied child. It returns an ephemeral text projection with declared transformations, not browser rendering, article understanding or removal of source-authored instructions. Its [host qualification procedure](https://github.com/hexanomicon/lychd/blob/main/CONTRIBUTING.md#quality-checks) uses an explicit runtime profile and synthetic fixtures. Passing it grants no Fetch, custody or workflow authority. Search and JavaScript rendering retain their separate admission and isolation gates. The [native HTTPS transport](../../adr/30-webcrawler.md#native-https-transport-profile) has a separate isolated-network qualification: real DNS and TLS fixtures lead into the extractor, while certificate, destination, framing and current-handoff refusals remain visible. It accepts ordinary HTTP/1.1 HTML/plain-text responses with identity or gzip encoding. Chunk extensions, trailers and unlisted redirects refuse. This mechanism proof uses a synthetic gate; durable attempts and current operator authority have their own PostgreSQL and workflow checks. Neither receipt alone proves a deployed application, a selected model or arbitrary host compatibility. ## Public-page answers The opt-in `bridge_chat@4` casting prepares a native review, waits for your decision, acquires one page and answers with one exact local chat capability. Its Bridge command is: ```text /read-public https://example.com/page What does this page claim? ``` Sending this command asserts that the complete locator, including its path and query, is public. The assertion requires the actual authenticated local operator and current Scout classification policy. It is not proof of publicness. The review identifies the URL, resolver and its declared custody, DNS/TLS disclosures, resource ceilings, local model and answer retention before contact. Approval grants neither retries nor additional URLs. Select revision 4 in `lychd.toml` only with PostgreSQL and an independently qualified extraction runtime. These example paths and capability names must be replaced with your reviewed inventory: ```toml [weaver.bridge] revision = "4" capability_key = "my-runtime:chat:my-local-model" [weaver.bridge.scout] binding_id = "public-page-local" policy_revision = 1 revocation_generation = 0 resolver_address = "127.0.0.1" resolver_port = 53 resolver_custody_statement = "This operator-owned resolver forwards the declared public hostname to its configured upstream." ca_file = "/etc/ssl/certs/ca-certificates.crt" bwrap = "/usr/bin/bwrap" python_root = "/opt/scout-python" libraries = [ "/lib64/ld-linux-x86-64.so.2", "/lib64/libc.so.6", "/lib64/libdl.so.2", "/lib64/libgcc_s.so.1", "/lib64/libm.so.6", "/lib64/libpthread.so.0", "/lib64/librt.so.1", "/lib64/libutil.so.1", ] max_context_chars = 16000 review_ttl_seconds = 300 [weaver.bridge.scout.allowance] connects = 3 transmissions = 512 wire_bytes = 1048576 [weaver.bridge.scout.budget_limits.host] connects = 30 transmissions = 5120 wire_bytes = 10485760 [weaver.bridge.scout.budget_limits.binding] connects = 15 transmissions = 2560 wire_bytes = 5242880 ``` The resolver address must be numeric; its reachable TCP listener and upstream custody are operator configuration. The example does not start a resolver or qualify those paths. The dedicated Python tree must contain no operator material. Runtime and library qualification follows the maintained Linux proof procedure in the contribution guide. HTTP and workers share one Scout authority and cancellation fence, so either entry path must honor the same attempt and budget. Before I/O, each attempt reserves worst-case outbound counters; only observed completion lets it settle actual usage. One binding admits one active acquisition. Its budgets are cumulative: renaming the binding or restarting the process cannot reset them. An unknown crash outcome keeps both its reservation and its slot. This profile supplies no automatic reconciliation or retry. If the configured budget changes, it refuses against existing budget rows rather than discard the accounting that still governs those attempts. Acquired bytes enter the selected local model as bounded, attributed, untrusted data. Token counting and inference both require current authority. There are no model tools, remote fallback, settled-history replay or automatic redirects. The ordinary answer is retained and may quote the page; raw acquisition and its injected envelope are not saved in Graph state or model history. Lost transient material cannot be reconstructed from a receipt or silently fetched again. Revision 4 becomes the selected Bridge profile, so other message forms refuse there. Removing the selector restores the default for new admissions; retained Runs keep their original revision. Restart replaces the authentication generation, so prior prepared work cannot acquire fresh authority merely by restoring its records. Loom displays the registered score and its activation; it does not edit this casting or activate Search, Crawl or Render. ## Finite Scavenger feed observation The source contract selects Scavenger revision `3`, `scavenger.observe_market@2` and `bazos-pc-title-link@1`: one model-free observation of `https://www.bazos.sk/rss.php?rub=pc`. The [application contract](../../compositions/scavenger/market.md#finite-feed-observation) owns the complete seed, retained field and recovery semantics. This operation description is not a delivery receipt; [State](../../state-of-the-work.md#scout-web-acquisition) owns qualification. Opt in through `lychd.toml` with `[weaver.scavenger]` and `revision = "3"`. Its required `[weaver.scavenger.scout]` value is an exact `ScoutFeedProfile`: `provider_id = "native-static@1"`, `profile = "rss-public-feed@1"`, `binding_id`, `policy_revision`, `revocation_generation`, `resolver_address`, `resolver_port`, `resolver_custody_statement`, `ca_file`, `bwrap`, `python_root`, `libraries`, `allowance`, `budget_limits` and `review_ttl_seconds`. Use the reviewed absolute runtime/library paths, numeric resolver and nested host/binding budget shapes illustrated in the public-page example above. This feed profile has no `capability_key` or `max_context_chars`. Configuration syntax does not establish runtime readiness. Only one Scout binding may be selected: `weaver.bridge.scout` at Bridge revision 4 cannot coexist with `weaver.scavenger`. The initial profile requires a fresh profile database; existing page budget rows refuse a page/feed switch without mutation. Omitting `weaver.scavenger` disables new observation admission. Removing configuration grants no migration, cleanup or accounting reset. Use the Altar's `/scavenger` application view with the authenticated same-host operator. Supply the complete bounded `CampaignSeed@1` through its seed form/API, including explicit empty arrays and explicit unknown budget/region where needed. The application owns the complete seed and request body; Run/Graph facts and generic history carry references, never a copied seed. Neither seed nor feed field enters a model, Bridge history or a model prompt. The `Watch` seed ceiling grants no cadence, ranking, seller contact, item fetch or purchase. For direct API operation, the exact request is `ObserveMarketRequest` with `request_id`, `seed` and `initial_filter`; the filter is `{"revision":"literal-casefold@1","query":""}` for all rows. Retain that request identity: identical replay resolves the same admission; changed content under that identity refuses. The source fixes the locator and execution profile; neither comes from request text. The protected application routes are: | Method | Path | Operation | | --- | --- | --- | | GET | `/api/v1/scavenger` | Current configured state and retained field | | POST | `/api/v1/scavenger/observations` | Reserve and admit the complete request | | GET | `/api/v1/scavenger/observations/{admission_id}` | Read the application document | | GET | `/api/v1/scavenger/observations/{admission_id}/consent` | Project its exact current Core consent | | POST | `/api/v1/scavenger/observations/{admission_id}/view` | Apply a local `LiteralFilter` | | POST | `/api/v1/scavenger/observations/{admission_id}/delete` | Delete terminal controlled payload | Admission requires `runs:submit`; reads and local filtering require `altar:read`; deletion requires `runs:cancel`. Each also rechecks the current application owner and credential authority. Use the normal authentication and CSRF boundary for mutations; UUIDs and digests are not grants. Review the exact Core consent before contact. Use its `consent_id` in `POST /api/v1/bridge/consents/{consent_id}/decision`; submit `verdict` and the presented `review_binding_digest`, requiring `runs:approve` and current review authority. The digest must match for approval or denial. The review binds the fixed source, disclosures, consumer, ceilings and expiry; consent is not a reusable Fetch grant. Current network, CONSUME and application-adoption authority still apply. The retained whole field includes every returned title/link occurrence, in source order, including unmatched, duplicate and missing-title rows. Inspect source/time/coverage, omissions and total/visible/unmatched/duplicate/missing counts. Item links remain inert displayed data. The application field retains only admitted titles, links and necessary attribution; raw feed, channel and summary content are excluded from that retained field. A case-folded literal substring filter derives visible ordinals over the same field digest. An empty query shows all rows. Filtering performs no source contact and changes no field. Cancel pending work explicitly through `POST /api/v1/bridge/runs/{run_id}/cancel` and inspect its settlement. Cancellation and deletion are separate operations. Terminal deletion submits the exact `request_digest` and `observation_digest` (explicit `null` when absent) to the delete route. It removes application seed and field payload atomically and retains a content-free tombstone plus necessary execution/Scout receipts. It does not erase independent contact metadata or backups. A deleted observation is distinct from an observed empty field; replay cannot restore it. Recovery begins with what the retained records actually establish. Unknown custody/disposition stays unknown and blocks terminal-only deletion. Receipt digests cannot reconstruct a lost transient field, and loss cannot authorize a silent refetch. When the field is confirmed committed, fresh authority permits reading and re-filtering it. When only the acknowledgement is ambiguous, reconciliation stays with that same identity. Deleting a terminal field reopens the application slot, but preserves spent budgets, unknown reservations, and an issued claim. Replacing it requires a visible delete, a fresh request, and fresh consent. This source contract promises no automatic retry, restart recovery acquisition, or budget reset. ## The laws of the road - **Pin before connecting.** Reauthorize every connection and redirect; forbidden or mixed DNS, peer mismatch, rebinding, and ambient proxies fail closed. - **External material remains external.** Queries are classified egress, and returned content may contain injection, secrets, falsehood, or hostile structure. It enters Context only as attributed, fenced data, never instruction or tool authority. - **Refusal remains refusal.** Robots policy, site terms, authentication, and law are distinct. A denial or challenge returns a typed outcome; Scout does not evade it or rotate identity. - **Credentials and browsers stay isolated.** Secrets remain opaque and scoped outside prompts and ordinary telemetry. Any future renderer is disposable and separated from Core peers, Host paths, databases, control sockets, wallets, and unrelated secrets. It does not join the shared `lychd.pod`. - **Bytes enter quarantine before custody.** Arrival grants no workspace, execution, or durable artifact name; admission must establish provenance, classification, retention, and retrieval. - **Spend requires authority.** Reserve bounded resources and spend; paid providers and price challenges grant no payment authority. The full destination checks, receipt fields, parser ceilings, and transition mechanics remain in [ADR 30](../../adr/30-webcrawler.md). ## The next gate Scout acquires and attributes. [Prism](prism/index.md) may act on visual bytes only after custody admits them. [Smith](smith.md) may propose a candidate from admitted sources. None appoints the next: ```text acquired ≠ admitted ≠ understood ≠ trusted ≠ promoted ``` --- title: "Tether" plain_name: "Private network link (WireGuard)" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/tether/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/tether/ --- # Tether (Private network link (WireGuard)) ## Plain-English summary (Snayu) **What it is:** The planned private-reachability area (Tether) that would use WireGuard to open exact private network paths between hosts, without granting any application authority. **Why it matters:** Read this before exposing LychD beyond one machine or setting up a VPN between a home server and a VPS. - Today deployment is IPv4 loopback only; do not tunnel or port-forward the Control Panel. - Public peer data lives in the Settings Folder; private keys stay with the secret owner. - A tunnel key proves only tunnel possession; the Security Desk (Ward) still authenticates and authorizes. **Status:** Designed. No managed VPN or peer-operation path ships. ## Original text (Hexanomicon) > _A thread drawn taut between two distant thresholds._ **Tether** is the private-reachability Extension Domain, with WireGuard as its accepted transport. It may eventually appear as a LychD-managed WireGuard service or as an attachment to an externally managed private network. Tether is **Designed**; no managed VPN or peer-operation path ships. [State of Work](../../state-of-the-work.md#vpn-tether) records that delivery boundary. The public peer intent, secret references, endpoint and route checks, revision fences, and retained revocation tombstones below are accepted design. Generated deployment remains IPv4-loopback-only: the Extension port grammar accepts only `127.0.0.1::` and rejects UDP. Remote, proxied, tunneled, and untrusted-browser use is unsupported. Keep the Vessel on the same host, and do not tunnel or port-forward the current Altar. ## Managed path and peer custody [ADR 39](../../adr/39-vpn.md) permits a managed Tether to manifest as a rootless service with narrow network capability and explicit UDP publication. Interface, listen port, address space, DNS behavior, routes, and peer limits remain Rune-owned intent. The Tether service stays outside the shared application Pod and receives no broad mounts, application secrets, database credentials, or host-mutation authority. `CAP_NET_ADMIN` inside that Pod is not an acceptable shortcut. An optional [Gateway Host](../gateway.md) composes Tether only for a placement that needs a private routed road. **Remote** may bind one exact peer and route from the off-site Veil to one Core backend. **Home** does not require Tether when an exact local segment already supplies reachability. In neither placement does a tunnel grant authority or a default route into the home network. Keep the public account of a peer in the Codex: stable identity, public key, allowed addresses and routes, endpoint and keepalive policy, enabled or revoked state, and creation or rotation metadata. Keep private and preshared keys with the secret owner, outside ordinary documentation, logs, QR history, and public peer records. Future typed operations under a host-owned run-operation verb may generate, admit, inspect, revoke, rotate, or export short-lived client configuration or QR projections. They would use that governed operation path without adding a root CLI verb. ## Reach attachment The [Reach deployment matrix](../../compositions/reach/deployments/index.md) gives Tether one exact consumer: [`reach.edge-home.public@1`](../../compositions/reach/deployments/vps-edge-home-core.md). Home-only and standalone outbound VPS use none. The split profile admits one named VPS peer, one exact address and route, explicit expiry and revocation generation, and one Tether-only private Veil backend for event admission, delivery claim, settlement, and health. It never uses `0.0.0.0/0`, exposes the home Phylactery, Reach core, Altar, model API, Podman socket, Reactor, or forwards arbitrary VPS traffic through the sovereign host. Tether holds only tunnel material. Root/VPS compromise still requires revoking that peer, separately rotating every resident application and operator credential, reconciling uncertain effects, and rebuilding the host; tunnel revocation alone is not containment. ## Tunnel identity and exact routes WireGuard proves possession of a tunnel key and encrypts packets. Human or process identity, object or effect authorization, consent, and device trust remain outside that proof. The host firewall selects each reachable listener; [Veil](veil.md) may constrain route or transport policy, while [Ward](ward.md) and the Vessel authenticate and authorize. For Intercom, the conservative first designed road is a Veil-compiled HTTP route exposed only through Tether. Tether supplies private reachability; Veil canonicalizes ingress; Ward admits the peer; Intercom verifies and replay-fences the A2A envelope. None may impersonate the next layer or turn an advertised Spell or Scroll into authority. A tunnel address, interface, peer key, or forwarded metadata contributes at most credential evidence. It cannot mint `magus:*`, widen a Sigil, or create an administrator. Bootstrap `magus:*` stays same-host only. Routes default to exact destinations; PostgreSQL, model APIs, container and Host lifecycle control, Oculus, audio, and [Intercom](../../adr/26-a2a.md) remain closed unless their own policies admit them. ## Revocation, rotation, and recovery Before changing the service, binding validates peer-address overlap, route conflicts, key references, port collisions, and the generated contribution. Revocation then removes a peer from the live interface and persists the revised intent. Rotation may overlap old and new credentials only with explicit operator authorization. Version the public peer and routing intent so restore or reconciliation cannot revive stale or revoked access. Keep failures visible; privileged traffic must never escape through a public fallback. Direct WireGuard avoids a mandatory hosted control plane, but CGNAT, blocked UDP, changing endpoints, roaming, endpoint metadata, and traffic analysis remain. Reachability may require fixed addressing, DNS, or a separately accepted rendezvous or relay. ADR 39 owns transport law; [Security](../../adr/09-security.md) and the Ward own the trust boundary. --- title: "Veil" plain_name: "Public ingress proxy" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/veil/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/veil/ --- # Veil (Public ingress proxy) ## Plain-English summary (Snayu) **What it is:** The planned edge proxy area (Veil), using Caddy by default, that would terminate TLS, clean up hostile request metadata and expose only declared routes to backends that still check authority themselves. **Why it matters:** Read this before putting LychD behind a reverse proxy or exposing any route to a network. - Each route is declared in a typed config with backend, limits and exposure tier; everything else stays closed. - Database, model API, Control Panel and host control can never be exposed through Veil. - Until the browser boundary changes, keep engine and Control Panel on one host with no ad hoc proxy. **Status:** Designed. No proxy delivery yet; local loopback only. ## Original text (Hexanomicon) A request arrives with `Host`, path, method, headers, and claims about its origin. The edge must reject, canonicalize, or map those values before they reach an application. **Veil** is the optional hostile-ingress Extension Domain outside the Vessel: it terminates TLS, handles protocols, admits routes, and sends canonical metadata to an independently guarded backend. Veil is **Designed**; [State of Work](../../state-of-the-work.md#proxy-veil) owns its delivery boundary. Until the [local browser boundary](../../state-of-the-work.md#local-browser-bind-boundary) changes, keep the Vessel and Altar on the same host—without an ad hoc reverse proxy, tunnel, or port-forward. ## Admit the edge [ADR 40](../../adr/40-proxy.md) selects Caddy as the default managed engine. An external edge remains possible, but no compatibility profile ships. Begin with the particular route to expose. Its typed Rune names the host or route, backend, protocols, limits, application-authentication preconditions, and exposure tier: public, through [Tether](tether.md), or local. All other routes remain closed. The design refuses ambiguous or overlapping ownership, unknown backends, unadmitted ports, and raw directives. A contribution cannot shadow Core, remove authentication, expose a database or model API, select an arbitrary upstream, or create a forward proxy. Before transactional inscription, the complete attributed configuration must pass Caddy validation in staging. Caller-supplied forwarding, identity, and client-certificate claims are discarded. Canonical scheme, host, origin, and peer metadata may cross only an authenticated backend path the Vessel explicitly trusts. That is designed behavior, not today's loopback service. ## Gateway Veil may share the Core host or occupy a separate [Gateway Host](../gateway.md). Follow that guide to choose **Home** or **Remote** and its exact backend road; neither placement creates application authority. Core accepts only the declared Gateway identity and port. Policy outside the Gateway plus the receiving Core firewall must enforce the narrow zone; local Gateway rules are defense in depth. No broad LAN route, database, Context, Sigil, provider credential, or host-control path may cross it. ## Reach route profiles The [Reach deployment matrix](../../compositions/reach/deployments/index.md) uses no Veil for home-only or standalone outbound VPS. The split [`reach.edge-home.public@1`](../../compositions/reach/deployments/vps-edge-home-core.md) profile binds a private home Veil only to its Tether address. Later profiles expose a closed set rather than a catch-all: | Surface | Backend and admission | | --- | --- | | Reach edge relay | private Tether-only event-admission, delivery-claim, delivery-settlement, and health routes to an isolated adapter; current edge Principal, epochs, bounds, replay fence, and Ward policy | | public-safe Agent Card | `GET` on the adapter-pinned well-known path; public metadata only; no implied trust or enrollment | | callback-only client | exact authenticated route to isolated Intercom ingress; existing outbound task/token correlation, replay fence, current authorization, and durable admission | | full A2A server | separate Intercom server ingress with Ward, inbox/outbox, Workers, quotas, and result path | | unauthoritative health | local or Tether-only until remote Ward IAM ships; no generic control route | | Altar, database, model API, corpus writer, Reach core, Discord edge, egress gate, container or host control | closed; no Veil contribution is admissible | Each admitted route pins methods, media, compressed and expanded size, JSON work, authentication, stream/time limits, exposure tier, backend, and adapter revision. Veil holds certificate and route material only. It never receives bot/provider/A2A application credentials or a path from hostile bytes to Discord delivery. ## Keep authority behind the route TLS authenticates an endpoint and protects bytes; routing selects a destination. The [Ward](ward.md) and Vessel still authenticate the caller and authorize the exact object and effect. mTLS, arrival through Tether, or forwarded metadata may supply evidence, but cannot mint a Sigil, create an administrator, or make the fixed bootstrap `magus:*` identity valid remotely. An A2A Agent Card, Scroll, or teaching bundle remains application material after crossing Veil. Veil may expose the admitted Intercom route locally, through Tether, or eventually publicly; it cannot validate Spell compatibility, approve teaching, admit a casting, or settle its Run. Before a browser-facing listener opens, Host and Origin admission, DNS-rebinding defenses, secure sessions, local assets, request bounds, and protected diagnostics must pass hostile tests. [State of Work](../../state-of-the-work.md#local-browser-bind-boundary) records the present failures; [Security](../../adr/09-security.md) owns the deeper boundary. Proxying and TLS leave those duties intact. Veil may impose coarse traffic limits; egress, application validation, and complete DDoS defense remain elsewhere. The edge receives only a narrow path to registered HTTP backends, never database, model, Reactor, systemd, container, application-secret, or arbitrary-egress authority. ## Fail without opening another path A transition first detects listener and route collisions and validates the candidate before activation. Certificate state and account keys remain within declared durable and secret boundaries; the prior projection remains available for restoration. If renewal fails, keep the last valid configuration and degrade readiness before expiry. Failed ACME prerequisites leave the public Veil unavailable while the local Vessel continues. Reconciliation closes routes removed from the declaration. --- title: "Ward" plain_name: "Security desk: identity and permissions" section: "Sepulcher > Extensions" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/ward/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/ward/ --- # Ward (Security desk: identity and permissions) ## Plain-English summary (Snayu) **What it is:** The core authority (Security Desk, or Ward) for authenticating callers and authorizing each exact action, covering credentials, principals, ID badges (Sigils) and grants, and rechecking permission right before every effect. **Why it matters:** Read this before adding any protected endpoint, tool or effect, or anything involving users, sharing or remote access. - Today a local HTTP Basic credential yields the fixed magus:* badge; it does not distinguish people. - Handlers recheck principal, action, object, approval and revocation immediately before an effect and after any wait. - Proxy headers, tunnel arrival or certificates are evidence only; they never mint a badge or authority. **Status:** Partial. Local badge floor and outbound peer profile exist; user accounts and remote login designed. ## Original text (Hexanomicon) > _At the circle's edge, a voice gives its name._ Recognizing a speaker draws only the first mark of a salt circle. Current policy and revocation must close it around this exact effect. **Ward** is LychD's singular Core-coupled authority for caller authentication and authorization. The bounded outbound peer profile is **Partial**, with its boundary owned by [State of Work](../../state-of-the-work.md#remote-iam). [Intercom's operator session](../intercom.md) separates actual local operator authentication, workload signing identity and enrolled remote peer credentials. It checks current object/action policy before contact and result consumption; it provides no incoming remote login or human account system. The implemented [local Sigil and scope floor](../../state-of-the-work.md#local-sigil-authority) is **Partial**: protected contained requests must present the dedicated local HTTP Basic credential before receiving the fixed, secret-free `magus:*` Sigil. This possession check does not distinguish people. Scope guards and consent preauthorization exist; separate User accounts and the remote IAM path below remain Designed. ## One instance, different people and working views A personal instance may admit friends; a household may share an instance administered by a parent; a company may give employees different application views through browser or mobile clients. A person or organization may also use several instances, with independently admitted accounts and permissions in each. Users need not run a LychD themselves. [IAM's account and instance contract](../../adr/38-iam.md#people-accounts-and-instances) owns these relationships. An assigned profile may offer one person a task form and another a review screen for the same work. Ward determines permitted access; the application owns the working views, Spellweaver the workflow, and the client their presentation. A profile can package those choices without merging their authorities. Follow [profiles and working interfaces](../../adr/38-iam.md#profiles-and-working-interfaces) and the [deployment examples](../../compositions/products-and-suites.md#deployment-and-projection-are-different-axes). ## The marks inside the circle Start with what the caller presents. A **Credential** is revocable evidence of possession. Verification connects it to a **Principal**, the immutable human, service, peer, or owned node to whom acts and objects belong. Core would then issue a secret-free **Sigil** carrying that Principal and bounded claims through a request or Run. Whether that Principal may perform this act now is a further decision. An **Authority Grant** binds Principal, action, object, audience, lifetime, policy generation, and delegation chain. Historical scopes can inform the decision but cannot replace current policy. An authentication session is another distinct record, separate from these four and from the Bridge conversation. In the designed path, a provider adapter verifies credential evidence while Ward retains policy and Core retains Sigil issuance. Admission checks protocol, issuer, audience, expiry, replay, revocation, and assurance, then resolves one enrolled Principal. An ownership-aware query decides access to the route and named object and records credential, policy, and revocation generations. An unknown credential or unresolved Principal receives no authority. Caller-supplied identity or scope headers cannot fill the gap, and no Extension may remove Ward from a protected surface. ## Authority at the moment of consequence Sessions, Runs, consents, streams, artifacts, memories, tasks, leases, and administrative records carry an owner or explicit sharing policy in the persistence query. Filtering after an unrestricted read is too late. Immediately before a protected tool or effect, its handler rechecks the current Principal, action, object, assurance, delegation, consent or preauthorization, policy generation, and revocation epoch. It checks again after queueing, worker claim, Stasis, consent, resume, or another wait. Narrowing the tools visible to an Agent helps; the handler remains the lock. Revocation must invalidate Credentials, sessions, cached grants, and affected pending or sleeping work. Recovery begins at zero authority: no universal remote Master token or ambient fallback exists. ### The current preauthorization floor The current preauthorization path checks permission in the conditional write that consumes it, immediately before the effect is granted. It rechecks enabled state, source presence, expiry against database time, and the remaining use budget. At startup, synchronization marks removed Rune-owned policies `source_present = false` while preserving operator enable/disable and usage state. An exact later reappearance may restore source presence. Budget consumption and the consent record commit in one PostgreSQL transaction; injected insert failure and removal/expiry races test rollback of that joint account. ## No borrowed authority [Veil](veil.md) terminates TLS and canonicalizes hostile traffic; [Tether](tether.md) narrows reachability. Their headers, addresses, certificates, signatures, or Tether arrival may contribute evidence, but never mint a Sigil or application authority. [Mirror](mirror.md) preserves operative identity and attribution; Ward authenticates and authorizes the initiating or approving Principal. [Intercom](../../adr/26-a2a.md) peer scopes likewise cannot enter a local Sigil unchanged. Keep the Vessel and Altar on same-host loopback. Do not proxy, tunnel, port-forward, or remotely publish them. [ADR 38](../../adr/38-iam.md) owns Ward law; [Security](../../adr/09-security.md) owns the wider boundary. --- title: "Prism" plain_name: "Vision and media overview" section: "Sepulcher > Extensions" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/prism/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/ --- # Prism (Vision and media overview) ## Plain-English summary (Snayu) **What it is:** The vision and media area (Prism) that takes admitted images, documents and video through bounded operations, OCR, detection, generation, 3D and motion, always linking results back to the exact source. **Why it matters:** Read this before adding any image, OCR, video, 3D or motion feature, to pick the right sub-area and execution path. - Sub-areas: Scanner (documents), Sight, Image, Video, Form (3D), Kinesis (motion), plus live sessions. - A caption or OCR text is a derived result, never a replacement for the source image. - Today only image metadata and vision-vs-chat capability filtering exist; no Prism package or provider ships. **Status:** Partial. Vision admission metadata only; no OCR, visual provider or byte custody. ## Original text (Hexanomicon) > _Sight begins when a source survives the seeing._ An image can yield text, a crop, a depth estimate, or a reconstructed object, but each result must remain connected to the source it came from. **Prism** owns that visual and spatial grounding and transformation as an Extension Domain. It takes admitted sources through bounded operations and records their observations and derivatives. Captions, OCR, crops, reconstructions, conversions, and model judgments remain attributable results; none replaces the source. Vision admission is **Partial**: current code preserves immutable `ArtifactRef` metadata, distinguishes `vision` from image-capable `chat`, and filters declarations by explicitly supplied required input modalities. No Prism package, byte-custody or materialization path, OCR tool, or visual provider ships today. [State of Work](../../../state-of-the-work.md#vision-admission) owns that boundary; [ADR 36](../../../adr/36-vision.md) owns the designed contract. ## Several faculties, one source Choose the return needed by the consuming owner: | Return | Passage | | --- | --- | | Text, regions, reading order, tables, or document derivatives | [Scanner](scanner.md). | | Boxes, masks, depth, pose, flow, tracks, or registered change estimates | [Sight](sight.md), with a separate [Live Sight](live-sight.md) session for armed streams. | | New or edited still-image candidates | [Image](image.md). | | Generated or transformed moving-image candidates | [Video](video.md), including exact authorization and independent admission for native sound facets. | | Geometry, appearance, parts, rigs, assemblies, or field representations | [Form](form.md); [Voxel and block export](voxel-and-block-export.md) follows bounded grids through schematic read-back. | | Reusable motion curves, retargeted clips, or technical motion findings | [Kinesis](kinesis.md), with [Live Kinesis](live-kinesis.md) for bounded epoch-to-rig sessions. | A deployment chooses the faculties needed for that return and may combine them with precise workers, deterministic [Prism Lens transforms](../../../adr/36-vision.md#decision), and an image-capable multimodal Mind. Each profile pins its exact implementation and supporting evidence. The Mind still supplies chat, and starting one service activates only its admitted faculties. Generation and editing require their own effects even when they consume grounded observations. ## The optic path ```text admit source into custody → authorize materialization → inspect and decode → apply a declared transform → resolve an exact finite tool or dispatch an eligible provider → retain a grounded observation or derived artifact ``` The Reliquary must own source bytes before Prism acts. An `ArtifactRef` is immutable metadata, not byte custody or bearer authority; the designed materializer rechecks authority on every read. The source remains under its retention policy; see the [artifact-reference boundary](../../../state-of-the-work.md#artifact-reference-contract). A deterministic transform produces a derived artifact recording parent and result digests, operation, immutable implementation revision, parameters, and declared loss. Provider request encodings and handles are transport forms, not universal storage or durable custody. Any retained visual output returns to artifact custody with provenance. An observation must let its reader find the evidence again. It keeps the source and derivative chain, the relevant page, frame, time, or region, the requested task and output, and the producing provider or deterministic operation with its immutable revision. It also carries appropriate uncertainty and states whether the result is extraction, measurement, or inference. Generated or edited media becomes a new artifact with effect provenance. A caption or OCR result can enter bounded Context, but that text is not the image; using it cannot silently replace or delete the source. ## Designed interface register These are semantic interfaces, not delivered source or claims that every provider implements every operation: | Interface and operation guide | Domain request/result | Execution binding | | --- | --- | --- | | [`prism.image@2`](image.md#one-job-explicit-operation) | `ImageJob@2` and image artifacts/receipts | Animator `durable_job` → `JobGrant` | | [`prism.video@2`](video.md#one-temporal-job-several-proved-operations) | `VideoJob@2` and video artifacts/receipts | Animator `durable_job` → `JobGrant` | | [`prism.sight@2`](sight.md#one-finite-job-exact-operation) | `SightJob@2` / `VisualObservationSet@1` | Animator `call`/`durable_job` → matching grant; finite tool → Resolution Lock + `ToolProfile` | | [`prism.form@2`](form.md#one-form-job-explicit-operation) | `FormJob@2` / `FormAssetSet@1` | Animator job → `JobGrant`; finite tool → Resolution Lock + `ToolProfile` | | [`prism.kinesis@2`](kinesis.md#one-finite-job-exact-operation) | `KinesisJob@2` / motion or findings set | Animator job → `JobGrant`; finite tool → Resolution Lock + `ToolProfile` | | [`prism.scanner@1`](scanner.md#what-the-scanner-route-actually-owes): inspect, extract, OCR, structure | Scanner request / `DocumentObservation@1` | Animator call/job → matching grant; direct tool → Resolution Lock + `ToolProfile` | Each leaf gives its operations and candidate dialect/driver studies. The Designed-only `prism.image@1`, `prism.video@1`, `prism.sight@1`, `prism.form@1`, and `prism.kinesis@1` interfaces and their corresponding `*Job@1` request meanings remain historical. Revision `2` separates Prism technical result settlement from a consuming Composition's semantic adoption; Kinesis additionally replaces the former generic sonic-cue input with exact musical cue and clock contracts. No capability registry, domain job, or service attempt used the `@1` designs, so there is no executable migration. `prism.scanner@1` is unchanged. `ImageJob`, `VideoJob`, `SightJob`, `FormJob`, and `KinesisJob` are domain work identities. Each asynchronous or durable provider or local execution is a separately identified [`ServiceJobAttempt@1`](../../../adr/14-workers.md#service-job-attempts). One domain job may receive another attempt only through declared forward-branch or retry law; the shared mechanics do not collapse these contracts into a generic `MediaJob`. Choose execution according to who owns its lifecycle. A resident, shared, independently queued, or remote service is an Animator reached through `CapabilityDemand@1` and a typed grant. For a finite library, CLI, or subprocess, the Spell Resolution Lock selects an immutable ToolProfile and a Worker delivers it into a trusted executor or Tomb. That finite tool needs no invented Animator or Rune. Either path may use `ServiceJobAttempt@1` when execution must survive the invoking Ghoul. A wrapper becomes an Animator only when it has the independent lifecycle, residency, queue, or remote boundary that warrants one. ## Sight on finite iron Prism uses ordinary [Capabilities](../../animator/capabilities.md) and [Dispatcher](../../../adr/22-dispatcher.md) routing. A local provider may be a managed Soulstone; a remote service remains an explicit [Portal](../../animator/portal.md). For an otherwise eligible managed binding that is not `WARM`, Dispatcher returns `HardwareTransitionRequired`; the requesting Run enters Graph Stasis while [Orchestrator](../../../adr/23-orchestrator.md) converges readiness, then re-dispatches. The waiting transition carries no lease; Prism cannot revoke an issued lease or infer remote fallback from scarce local iron. Designed Portal egress additionally requires eligible classification, explicit policy, consent where required, and a cost bound. Policy is evaluated on both the source and every derived artifact: a crop, caption, or normalized frame cannot launder restricted pixels. --- title: "Sight" plain_name: "Computer vision estimates" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/sight/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/sight/ --- # Sight (Computer vision estimates) ## Plain-English summary (Snayu) **What it is:** The planned computer-vision path (Sight) for images and finite video, returning typed estimates such as boxes, masks, depth, pose, flow and tracks, each grounded to exact pixels and times. **Why it matters:** Read this before integrating a detector, segmenter, tracker or depth model, or using a chat model to describe images. - Three kinds of seeing: deterministic transforms, learned Sight estimates, and multimodal chat interpretation. - A precise learned estimate can still be wrong; structure is not truth. - Document OCR, tables and reading order belong to Scanner, not Sight. **Status:** Designed. Study reviewed August 2026; no Sight implementation delivered. ## Original text (Hexanomicon) A box must point back to its pixels. A track must reveal its gaps. A depth value must say whether it measures metres or only relative distance. **Sight** makes those obligations part of a finite visual observation, from admitted source through preprocessing to typed estimates and validation. Use this passage for images and finite video; [Live Sight](live-sight.md) owns the separately armed stream. A learned estimate can be precise and still wrong. Interpretation, identity, camera control, and downstream effects need their own owners. The study was reviewed on **2026-08-08**. Sight remains Designed under [Vision](../../../adr/36-vision.md); [State](../../../state-of-the-work.md#vision-admission) records the narrower delivered metadata boundary. ## Three kinds of seeing The distinction between a multimodal Mind and specialist computer vision is epistemic, not merely performance tuning: | Office | Result | Example | | --- | --- | --- | | **[Prism’s Lens](../../../adr/36-vision.md#decision)** | deterministic probe result or derivative under an exact implementation | decode, dimensions, orientation, frame extraction, crop/resize transform | | **Sight** | typed model estimate grounded to pixels and time | boxes, masks, tracks, depth, keypoints, flow, registered change candidate | | **Multimodal Mind** | attributed semantic interpretation | caption, relationship, open-ended answer, event or causal hypothesis | A Qwen, Gemma, or another image-capable chat model can explain what a scene appears to mean. It does not replace pixel-accurate masks, calibrated coordinates, flow fields, or track gaps. A specialist detector can report a high score and still be wrong; learned Sight output is not deterministic truth merely because it is structured. Scanner retains document OCR, reading order, tables, formulae, and document reconstruction. Sight may locate a general visual region, but it does not become a second document pipeline. ## One finite job, exact operation The candidate `SightJob@2` acts on one or more authorized, finite `ArtifactRef` sources and names one explicit operation: | Operation | Required meaning | | --- | --- | | `classify` | Score an exact closed ontology for a declared region or source; failure to name an open-world object is not absence. | | `detect` | Return boxes or points for a pinned class vocabulary, threshold, suppression policy, and candidate limit. | | `ground` | Relate a retained text query to candidate regions; translated queries preserve original text and translator revision. | | `segment` | Produce semantic, instance, panoptic, or prompted masks under an exact ontology, prompt, and overlap policy. | | `track` | Relate region hypotheses through an exact finite time window; track identity is local to this job. | | `estimate_depth` | Produce relative or metric depth in a declared depth or inverse-depth representation, with validity and uncertainty. | | `estimate_pose` | Produce keypoints under a pinned skeleton ontology and coordinate space. | | `estimate_flow` | Produce dense or sparse apparent motion between exact source and destination frames. | | `compare` | Register two sources or a time window and return bounded change candidates plus registration error and alternatives. | Open-ended event interpretation remains a separately routed Multimodal Mind step. It may consume exact Sight regions and tracks and return time-bounded hypotheses, but prose does not become a precise Sight result and a visual correlation does not establish identity or cause. The interpretation retains the source digest, exact query or open-ended task, sampled and omitted frame and time spans, supporting and contradicting regions or tracks, prompt, model and profile, uncertainty, and alternatives. It cannot establish identity, cause, security incident, or effect completion. To make a result reproducible and interpretable, pin what Sight is asked to observe: the operation, source and every Lens derivative, region and time window, query or class ontology, segmentation and skeleton variants, and desired result kinds. The request also fixes eligible profile constraints, thresholds, output limits, deadline, budget, purpose, classification, and retention. Resolution Lock then selects an exact finite ToolProfile, or Dispatcher selects an eligible declared capability. The admitted invocation and terminal receipt identify the exact tool or model, runtime, preprocessing, and postprocessing profile that actually ran. Optional inputs cannot imply support that the selected implementation has not established. `SightJob@2` determines whether the perception stages produced valid observations and settles the technical result. The consuming owner decides what those observations mean for its domain. For each asynchronous or durable service or tool execution, Core's Designed [`ServiceJobAttempt@1` recovery contract](../../../adr/14-workers.md#service-job-attempts) keeps the parent Run fenced until that same attempt settles. Partial results enter quarantined custody. Only rehashed, validated observations can enter the settled Prism result. An uncertain paid or remote request must never be replayed under a new identity; doing so cannot resolve the uncertainty about the original request. ## Coordinates and time survive preprocessing Every canonical region refers to original source pixels and pins source width and height, origin, axes, pixel-edge or pixel-center convention, half-open `xyxy` box convention, polygon winding and clipping policy, plus the exact derivative-to-source transform chain for orientation, crop, resize, pad, and letterbox. Normalized coordinates are only a projection. Every mask raster, depth grid, and dense flow field pins its own width, height, sample convention, validity domain, and exact spatial map to the original source. A model-sized array is never assumed to share source pixels merely because it has been upsampled for display. Video grounding must preserve the actual sequence rather than a convenient playback rate. Finite-video observations pin the artifact digest, presentation-frame ordinal, original rational timebase and PTS, and DTS where relevant. Their temporal derivative-to-source map records trim, frame extraction, decimation, resampling, and duplicate or dropped frames. An inferred average FPS cannot replace variable-rate timing. Tracks expose gaps and occlusion instead of drawing a continuous history through missing evidence. Only live sessions have a stream epoch. Depth additionally pins intrinsics, extrinsics, lens distortion and admitted scale evidence where available. Relative depth is not metres. Pose declares image, camera, or world coordinates and the exact keypoint schema. Flow declares source and destination frames, vector direction and units, and any transform back to the original source. Compare cannot silently treat lighting, viewpoint, compression, parallax, or registration failure as physical change. ## A typed visual observation set `VisualObservationSet@1` does not flatten every output into generic JSON. It binds the source and working-derivative digests, operation, evidence class, exact producer and profiles, then carries typed facets: | Facet | Required facts | | --- | --- | | regions | original-source boxes, points, polygons, class or phrase, score semantics, ontology and coverage | | masks | semantic/instance/panoptic/prompted kind, RLE or mask artifact, region relation, overlap and prompt lineage | | depth | relative or metric scale, depth or inverse-depth representation, ray-depth or camera-z convention, units and scale when proved, validity and uncertainty artifacts | | pose | skeleton ontology and revision, coordinate space, keypoints, visibility and score semantics | | flow | exact ordered frame pair, vector axes and units, dense or sparse field artifact, validity and occlusion | | tracks | job-local track id, observations and spans, association method, gaps, occlusion and termination | | comparison | registration transform and error, compared regions, candidate changes and non-change alternatives | ### Receipt and negative evidence The terminal receipt additionally pins model and weight digests and license, worker and container, runtime, precision, device, decoder, color conversion, resize, crop, padding and letterbox, thresholds, NMS or association revision, taxonomy and label map, timing, resource peaks, warnings, skipped material, gaps, cancellation settlement, and output digests. An overlay PNG or annotated video is a derived visualization; machine-readable observations remain canonical. Read a score in the terms of the profile that produced it. Confidence is not automatically a calibrated probability, and confidence scores from different models are not comparable. Available calibration evidence must name its corpus, revision, and applicable profile. Read a negative result with equal care: it applies only to the exact region, time window, ontology, threshold, sampling, and coverage examined. Crash, occlusion, a dropped frame, a skipped region, or an unknown class cannot be reported as "absent". ## Prepare the finite source [`FFmpeg`](https://www.ffmpeg.org/legal.html) remains the pinned Lens subprocess for file probing, exact frame extraction, pixel-format conversion, and finite batch video. Its effective distribution license depends on the exact build: `--enable-gpl` makes that build GPL, while `--enable-nonfree` makes the resulting binary unredistributable. Neither can be hidden behind the executable name. ## Privacy and identity are not optional profiles Admission bounds dimensions, pixels, frames, duration, rate, bitrate, codec and parser resources, decompression, metadata, output cardinality, derivative expansion, compute, and retention. Decode and inference run contained without ambient network. Embedded URLs, subtitles, metadata, OCR text, pixels, and VLM output are hostile data, never instructions. Classification follows every crop, mask, embedding, overlay, depth map, and track derivative. A blurred image or caption is not automatically declassified. Track IDs are local association labels, never stable object or person identities. Face detection used to apply a privacy mask grants no face recognition. When policy requires source-side privacy masking, the capture or transport boundary applies the pinned mask before persistence, inference-worker access, preview, or Portal egress. Stale camera calibration, mask mismatch, or masking failure stops the route; it never falls back to unmasked frames. Access to raw frames remains a separate explicit scope even when downstream derivatives are retained. Cross-session re-identification, face recognition, gait or voice fusion, demographic or emotion inference, biometric templates, neighbour surveillance, ambient public streaming, and indefinite retention are absent and denied by default. They would require separate high-risk law and cannot be enabled by changing a model id in a Sight Rune. ## One Prism interface, two first worker substrates There is no useful OpenAI-compatible wire contract for exact masks, depth, pose, flow, coordinates, and time. OpenAI-style chat remains appropriate for VLM text. KServe v2 can later transport named tensors, shapes, and dtypes, but it does not define Sight semantics. Prism therefore owns the Sight interface, profiles, reference adapter, and normalization into `VisualObservationSet@1`; Core owns only general capability demand, typed grants, readiness, and attempt mechanics. Prove the first workers in this order: 1. One Torch detector. 2. SAM 2 image segmentation. 3. The same or an equivalent exported detector through ONNX Runtime CPU, with golden parity. 4. RTMW through ONNX Runtime and OpenVINO. 5. Finite-video association, then SAM 2 video propagation. 6. Only after those finite paths, live GStreamer. | Candidate | Layer | Present judgment | | --- | --- | --- | | `sight-torch` | Immutable isolated [PyTorch](https://github.com/pytorch/pytorch) and [Transformers](https://github.com/huggingface/transformers) worker profiles using native model preprocessing. | First reference substrate because current foundation CV models ship here first. Heavy and model-specific, so no ambient downloads, unpinned modules, caller-supplied paths, or network. | | `sight-onnx` | [ONNX Runtime](https://onnxruntime.ai/docs/execution-providers/) worker with pinned graph, opset, shapes, execution provider, preprocessing and postprocessing. | Second Prism reference substrate and first CPU lane. Exportability is a proved profile, not a family assumption; golden parity against the reference worker is mandatory. | | [OpenVINO](https://github.com/openvinotoolkit/openvino) | Initial ONNX Runtime execution-provider profile for Intel CPU, iGPU, or NPU. | Prism execution profile inside `sight-onnx`, not a third substrate or first separate server. A direct backend needs later measured justification. | | [NVIDIA Triton](https://github.com/triton-inference-server/server) | Later KServe-compatible tensor serving with Triton-specific batching, sequence, repository, and multi-model behavior. | Add an optional adapter only when GPU-fleet measurements justify its operational weight. Source is BSD-3-Clause, but the NGC image and optional NVIDIA components retain additional terms. | | [OpenVINO Model Server](https://github.com/openvinotoolkit/model_server) | Later KServe-compatible Intel edge and fleet serving with its own scheduler, DAG, and MediaPipe behavior. | Reuse the tensor adapter where proved; KServe compatibility does not make its state or scheduling equivalent to Triton. | PyTorch, ONNX Runtime, and OpenVINO run model graphs; Transformers, MMDetection, MMSegmentation, MMPose, SAM, OpenCV, Kornia, Supervision, and tracking packages are libraries inside a pinned worker. None knows LychD custody, coordinate law, authority, result schemas, or recovery and none becomes a Core connector merely by exposing Python or a demo server. The strict-FOSS execution lane is CPU ONNX Runtime with its CPU or OpenVINO profile. NVIDIA driver, CUDA, cuDNN, ONNX Runtime CUDA, and PyTorch CUDA deployments retain separate proprietary system terms even without TensorRT. TensorRT is an additional operator-enabled NVIDIA accelerator under its own non-OSI SDK license, not the strict-FOSS default. Ultralytics is AGPL-3.0 or commercially licensed and remains an external license-gated profile; exporting one of its models to ONNX does not erase upstream terms. TorchServe is excluded because the official project is archived and no longer plans maintenance or security fixes. Roboflow Inference mixes an Apache core with cloud, enterprise, metered, dynamic, and separately licensed surfaces, so it is not the default Sight boundary. ## First permissive profile candidates The first register composes a small number of distinct specialists: | Profile | Components and office | License and placement judgment | | --- | --- | --- | | `ground_segment_track` | Original Grounding DINO Swin-T for text-grounded boxes, [SAM 2.1 Small](https://github.com/facebookresearch/sam2) for prompted image/video masks, and [ByteTrack](https://github.com/FoundationVision/ByteTrack) for box association when the detector reruns on a declared cadence. | [Grounding DINO](https://github.com/IDEA-Research/GroundingDINO) and SAM 2 use Apache-2.0 source routes, SAM 2 checkpoints declare Apache-2.0, and ByteTrack is MIT. Pin and close the exact Grounding DINO checkpoint metadata and dependencies. GPU is the practical interactive bake despite its CPU mode. | | `depth_camera` | [Depth Anything 3 Small](https://github.com/ByteDance-Seed/depth-anything-3) for relative depth, confidence, and multiview camera facts. | Apache-2.0 80M profile and first general depth candidate. DA3 Large, Giant, and Nested are CC-BY-NC-4.0; Metric Large and Mono Large are separately named Apache exceptions, and metric output remains a separate bake. | | `human_wholebody` | Exact RTMW-m 256 by 192 through [MMPose](https://github.com/open-mmlab/mmpose), with a pinned RTMDet person detector and whole-body schema. | Apache-2.0 toolkit candidate for detailed 2D body, hand, face, and foot keypoints; exact weights and dependencies still require closure. First prove PyTorch reference and ONNX Runtime CPU/OpenVINO parity. Ordinary RTMPose-m remains a baseline, not the same profile. | | `dense_flow` | [SEA-RAFT `Tartan480x640-M`](https://github.com/princeton-vl/SEA-RAFT) for optical flow and uncertainty. | BSD-3-Clause 19.7M specialist. Activate only when Image, Video, Form, or an exact Pattern has a consumer; no CPU or real-time promise is inferred. | The temporal components do different work. SAM 2 propagates prompted masks only. ByteTrack associates boxes from repeated detector runs; it cannot discover new entrants or propagate masks. Point tracking and optical flow make further distinct claims. A stateful video profile therefore keeps frame order and every point, box, mask, query, detector-cadence, and association event. Embedding caches and framework session objects may accelerate execution, but they provide neither artifact custody nor recoverable truth. Useful challengers remain profiles rather than initial duplication: Apache-designated D-FINE N/S or RF-DETR Nano/Small for fixed-taxonomy real-time detection; EdgeTAM for mobile segmentation; DA3 Metric Large when metres are actually required; Video Depth Anything Small for long-video depth; and RTMO for crowded one-stage pose. Each enters only where exact quality, latency, hardware, export, or fine-tuning evidence beats the first route. SAM 3/3.1 is the present technical reference for unified text-prompted image/video detection, segmentation, and tracking, but it uses Meta's custom SAM License and gated checkpoints rather than an OSI license. Grounding DINO 1.5/1.6 and DINO-X examples use the DDS cloud API; only the original Grounding DINO route is the first local permissive candidate. Depth Anything V2 Small and Video Depth Anything Small are Apache alternatives, while their larger variants are generally CC-BY-NC-4.0. Sapiens2, Rex-Omni, X-Pose data paths, CoTracker, and RF-DETR Plus components retain custom, non-commercial, or otherwise gated terms and cannot be inferred safe from a family name. No general temporal-event model enters the first set. A Multimodal Mind handles coarse semantic video understanding. Fixed action localization through OpenTAD and an exact backbone may enter later only for a named ontology and corpus; generated timestamps remain interpretations grounded to the frames and temporal resolution actually sampled. ## Profiles, Runes, Covens, and the proving bake Within [Prism's admission route](index.md#sight-on-finite-iron), a small fixed detector or RTMPose profile may live on an ONNX Runtime CPU/OpenVINO worker while a multimodal Mind occupies a GPU. Grounding DINO, SAM 2, or DA3 may use a transient or resident PyTorch GPU worker. "Real-time" is never an engine property: the exact model, resolution, device, precision, stream count, queue, sampling, and drop profile must prove it. Two GPUs are not pooled memory without explicit runtime support. The first bake covers clean and degraded images; orientation, crop, pad, and letterbox reversal; small, occluded, transparent, overlapping, and unknown objects; negative grounding queries; masks and boundaries; crowded people and nonstandard poses; relative and calibrated depth; camera facts; fast motion, blur and occlusion; variable-frame-rate video, duplicate and dropped frames; Slovak and multilingual grounding prompts with retained translation; change under lighting and viewpoint; adversarial codecs and metadata; cancellation, OOM, crash, restart, and stasis. Measure per-operation benchmark quality and calibration, localization and boundary error, ontology coverage, depth error and scale validity, keypoint error, flow endpoint error, tracking association and gaps, source-coordinate round trip, PTS/timebase fidelity, false absence, output validity, latency, throughput, peak GPU and host memory, queue behavior, cancellation, recovery, custody, privacy enforcement, and license closure. Promote exact profiles, not model logos or demo FPS. Sight's results may become exact controls for [Image](image.md), [Video](video.md), [Form](form.md), or [Kinesis](kinesis.md). A per-frame pose or tracked keypoint remains an observation with source coordinates, gaps, and uncertainty; Kinesis must create and validate any structured motion derivative. Atelier retains creative judgment, Form retains 3D reconstruction, Blockworld and physical Compositions retain effect authority, and [Oculus](../oculus.md) may observe Sight job health without owning the underlying visual facts. A camera or stream requires the separately armed [Live Sight](live-sight.md) session. Finite jobs retain their exact source-artifact timebase; they do not acquire a live epoch by running longer. --- title: "Live Sight" plain_name: "Live camera sessions" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/live-sight/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/live-sight/ --- # Live Sight (Live camera sessions) ## Plain-English summary (Snayu) **What it is:** The planned bounded session for live camera or RTSP streams, defining arming, privacy masks, frame and clock tracking, gaps and reconnects, so old frames are never treated as current. **Why it matters:** Read this before building anything that watches a live camera feed. - A live feed is a bounded LiveSightSession, never an endless finite job. - Frames are identified by stream epoch and sequence; unproved reconnects start a new epoch. - GStreamer is the first transport candidate; camera control and other world effects stay with the app. **Status:** Designed. LiveSightSession@1 is not delivered. ## Original text (Hexanomicon) A finite observation has a last frame. An armed camera route needs an explicit way to end, account for missing frames, and keep old observations from acting as current sight. This designed passage defines that session around [Sight's](sight.md) typed visual estimates. `LiveSightSession@1` is not delivered. [Vision](../../../adr/36-vision.md) owns its contract; [State of Work](../../../state-of-the-work.md#vision-admission) owns delivery. The controlling Composition admits capture and every world effect; Sight returns observations under that scope. ## Arm one bounded session Arming a camera or RTSP feed requires a bounded session, not an infinite `SightJob`. The later `LiveSightSession@1` pins camera and controller identity, named purpose, and the retained admitted authority or policy receipt. It names viewers, zones, privacy masks, the active window, resolution, and rate, and separately admits raw-frame access, recording, analysis, retention, and egress scopes. It also fixes the stream epoch, queue, cardinality, latency and resource budgets, sampling and drop policy, and downstream consumers. The receipt records the basis on which LychD admitted that session; it does not claim legal certification. ## Keep frame and clock truth Identify each frame by stream epoch and sequence. Reported RTP, device, or PTS clocks may be absent, synthesized, or reset, so preserve their provenance and the uncertainty in their mapping to monotonic and wall clocks. Bounded queues prevent an unnoticed backlog: when upstream cannot pause, the admitted sampling or drop policy emits exact gaps and watermarks. Continue the same epoch after reconnect only when contiguous transport is proved; otherwise close it. A new epoch gets a new local track namespace. Cross-epoch association is a separately attributed inference, never reuse of an old track identity. Checkpoints retain references, cursors, prompts, and gaps, excluding raw frames, framework objects, device handles, and unbounded history. ## Contain transport and control [GStreamer](https://gstreamer.freedesktop.org/documentation/frequently-asked-questions/general.html) is the first later live transport candidate for RTSP jitter, timestamps, hardware decode, and bounded [`appsink`](https://gstreamer.freedesktop.org/documentation/app/appsink.html) delivery. Pipeline strings and network routes are immutable allowlisted Rune profiles, never operator or model-authored code. Only the contained transport worker receives the exact admitted RTSP route; inference workers remain networkless. Starting capture, PTZ, recording, camera configuration, robot motion, or another world effect remains with the controlling Composition. Sight only observes. --- title: "Scanner" plain_name: "Document OCR and extraction" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/scanner/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/scanner/ --- # Scanner (Document OCR and extraction) ## Plain-English summary (Snayu) **What it is:** The planned document reading path (Scanner) that turns admitted PDFs, scans and photos into attributed text, regions, tables and reading order, with Markdown as just one output form. **Why it matters:** Read this before adding OCR or PDF parsing, or choosing between PaddleOCR, Xberg and MinerU. - DocumentObservation@1 keeps page geometry, regions, text, confidence, omissions and the exact engine and model. - First candidates: PaddleOCR (primary), Xberg (native extraction), MinerU (license-gated, not strict FOSS). - A low score is an outcome to inspect, not permission to silently try another extractor. **Status:** Designed. No OCR adapter ships; candidate study reviewed August 2026. ## Original text (Hexanomicon) A scanned invoice and a born-digital report can ask the same question of **Scanner**: which text, regions, tables, and omissions can be attributed to these exact pages? The route begins with admitted source bytes and ends with a `DocumentObservation@1` plus explicit derivatives. Markdown is one projection of that return, not the document's canonical replacement. The semantic boundary remains stable while engines change. No OCR adapter ships; vision remains Partial in [State](../../../state-of-the-work.md#vision-admission). The implementation study below was reviewed on **2026-08-07**. Its candidates require their own Assimilation and bake. ## What the Scanner route actually owes Uploading a PDF to a local HTTP endpoint may be one request. The trustworthy seam around that call is larger: ```text authorized ArtifactRef → bounded materialization and hostile-document inspection → exact Scanner task, engine, model, options, language and page range → local library, worker, CLI, REST job, MCP tool, or admitted Portal → validated page and region observations plus derivative artifacts → provenance, uncertainty, omissions, metrics and terminal receipt ``` `DocumentObservation@1` retains the source and derivative digests, page identity and geometry, regions with boxes or polygons, semantic region class, extracted text, language, reading order, confidence where the provider exposes it, tables, formulae, images, warnings, omitted or failed pages, and the exact engine, model, configuration, and license profile. Markdown, HTML, searchable PDF, and a provider's JSON tree are useful projections or derivatives; none is canonical source truth. Scanner defines what the returned page and region observations mean. Its immutable profile pins the engine, model, media, languages, limits, quality evidence, and license evidence needed to support that meaning. The dialect driver handles invocation and recovery; the runtime adapter handles service lifecycle. [Capabilities](../../animator/capabilities.md) and [Connectors](../../animator/connectors.md) keep those shared contracts exact. A Prism-owned Scanner reference adapter may assemble those pieces, but its name does not collapse their authority. A finite CLI/library path is a Spell-selected ToolProfile delivered into a trusted executor or Tomb. A resident, queued, or remote service is an Animator reached through a `CallGrant` or `JobGrant`. Asynchronous execution additionally uses Core's [`ServiceJobAttempt@1`](../../../adr/14-workers.md#service-job-attempts). The host normally materializes authorized bytes and uploads them directly. A provider-visible file URL is allowed only through a separate egress decision and must never become an ambient fetch or SSRF path. Choose the engine and model explicitly, even when one project bundles both. A service's Designed Rune selects exact registered interface/profile/driver/dialect/evidence/resource definitions and pins the deployment instance. For a finite tool, the Resolution Lock pins the ToolProfile instead. In both cases, retain the pipeline or model, weights and digest, device/backend, languages, optional modules, concurrency, memory envelope, and the exact output fields that passed the bake. A project name alone cannot identify what was qualified. ## Routing without a universal wrapper The first routing study should compare explicit profiles rather than stack every project: | Source and purpose | First candidates to bake | | --- | --- | | Born-digital PDF, Office file, or mixed collection of formats | Xberg native extraction and selective OCR; OCR stays off unless page evidence requires it. | | Screenshot, photograph, or scan needing text regions | PaddleOCR direct, with the exact OCR or PP-StructureV3 profile pinned. | | Multi-column report, table, formula, chart, or difficult mixed PDF | Compare PaddleOCR PP-StructureV3 or PaddleOCR-VL with MinerU. MinerU enters only through an explicit license gate, never as the strict-FOSS default. | A low confidence value or parser failure is an outcome to inspect, not permission to select another extractor. If a Pattern predeclares a comparison or escalation branch, its implementations must be pinned. Otherwise the failed attempt must settle before a new forward Invocation admits another extractor. Attribute every result separately; agreement increases confidence only under an admitted comparison rule. ## Three candidate routes The projects overlap. The table names the office for which each is most interesting rather than claiming that it can perform only one task. | Candidate | Primary office and interface | License reading | Present judgment | | --- | --- | --- | --- | | [PaddleOCR](https://github.com/PaddlePaddle/PaddleOCR) | Direct OCR, PP-StructureV3 structured parsing, and PaddleOCR-VL; Python/CLI, self-hosted PaddleX REST, official hosted API, or MCP. | Apache-2.0 code; every selected model and dependency still needs its own receipt. | Primary first Scanner candidate. It covers multilingual text, coordinates, orientation, layout, tables, formulae, charts, reading order, and Markdown/JSON, but upstream breadth is not proof of reliability on LychD fixtures. | | [Xberg](https://github.com/xberg-io/xberg) | Rust-first broad format detection and extraction with selective OCR, bindings, CLI, REST, and MCP. | MIT. | Promising native-extraction and routing candidate, especially when a born-digital document should avoid OCR. Xberg v1 is a fresh Kreuzberg rebrand, so it remains Lab material until soak, compatibility, and output-stability evidence exist. | | [MinerU](https://github.com/opendatalab/MinerU) | Full PDF/image/Office parsing and reconstruction; CLI, Python, `/file_parse` asynchronous REST jobs, router, and VLM/OpenAI-server modes. | Current custom “MinerU Open Source License” adds commercial thresholds and online-service attribution to Apache-2.0. | Technically strong complex-document candidate, but the added use threshold is incompatible with a strict OSI/FOSS Core policy. Keep documented and license-gated unless its terms change or policy explicitly admits it. | PaddleOCR remains a first-class, directly callable Scanner implementation even when Xberg or MinerU can use OCR internally. A bundled dependency does not hide engine and model identity, prove the direct profile, or prevent a Pattern from selecting PaddleOCR without the surrounding pipeline. ## Assimilation bake The first corpus should include Slovak and English born-digital PDFs, clean and degraded scans, rotated and warped pages, handwriting, receipts and forms, multi-column articles, tables, equations, charts, footnotes, mixed-language pages, password-protected or malformed files, oversized images, embedded attachments, links, scripts, and metadata. Synthetic fixtures provide exact truth; operator-owned real documents test the distribution without entering a training corpus by accident. Measure character and word error, page and region recall, coordinate error, reading-order edit, table structure, formula equivalence, language routing, omissions, hallucinated text, derivative fidelity, wall time, CPU/GPU memory, concurrency, cancellation, crash containment, restart, and license closure. Promote profiles, not project logos: PaddleOCR may qualify for simple Slovak scans while failing formulae; Xberg may qualify for native extraction but not difficult scans; MinerU may win a bounded complex-PDF route without becoming admissible to strict-FOSS Core. The pragmatic first bake compares three candidate routes, each through its exact profiles: PaddleOCR direct plus PP-StructureV3, Xberg for broad native extraction and selective OCR, and MinerU for difficult documents behind its license gate. Later candidates can enter through Assimilation without changing Prism's Scanner contract or silently enlarging the initial Core. --- title: "Image" plain_name: "Image generation and editing" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/image/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/image/ --- # Image (Image generation and editing) ## Plain-English summary (Snayu) **What it is:** The planned image-making path (Image) for generating, editing, inpainting, structure-controlled and enhancement jobs, recording the exact operation, inputs, profile and what changed. **Why it matters:** Read this before integrating an image generation model or a ComfyUI-style workflow. - One ImageJob names one operation: generate, edit, inpaint, control or enhance. - Enhancement must declare whether it can invent detail; results are new artifacts with provenance. - Technical settlement is separate from creative adoption, export and publication. **Status:** Designed. Contracts and candidate tests only; study reviewed August 2026. ## Original text (Hexanomicon) An image request owes more than new pixels. **Image** records which operation was requested, which sources and controls it may use, what changed, and which exact profile produced the candidate. An image-capable chat model can interpret the picture; this Maker/editor passage produces or transforms it. Begin with the operation and expected return, then select a simple serving or full workflow route. The study was reviewed on **2026-08-26**. These are Designed contracts and candidate bakes, with delivery owned by [State](../../../state-of-the-work.md#vision-admission). Technical settlement leaves creative adoption, export, and publication with their named owners. ## One job, explicit operation The image-producing surface should accept the whole useful input family without pretending that every admitted model implements every form: | Operation | Inputs | Required meaning | | --- | --- | --- | | `generate` | prompt | Create one or more new candidates from text. | | `edit` | prompt plus one or more source or reference images | Mutate, restyle, compose, or preserve identity according to the selected profile. | | `inpaint` | prompt, source image, and mask | Replace only the declared region; outpainting is an expanded canvas plus an explicit mask. | | `control` | prompt plus pose, depth, edge, sketch, layout, or other control artifact | Preserve the declared structure according to a separately baked control profile. | | `enhance` | source image and exact enhancement profile | Restore, remove a background, or upscale while declaring whether the operation can hallucinate detail. | ### Request and provenance Describe the intended change before resolving an engine. A candidate `ImageJob@2` names its operation, prompt and negative prompt, and the authorized source, reference, mask, and control `ArtifactRef` values it may use. Dimensions, candidate count, seed policy, immutable preset, deadline, budget, and output policy bound the work. Supplying an optional input does not prove that an engine can use it; the selected profile must declare and prove that capability. The job also retains the operator-facing prompt, its declared or detected source language when known, the requested model-facing language, and translation policy. A translator may derive a model-facing prompt only through an admitted transformation that preserves both texts, translator revision, and declared loss. Interface locale, model convenience, or prompt enhancement never silently replaces visual direction. Source-grounded masks, regions, pose, depth, and other controls may come from [Sight](sight.md). Image retains the generative effect; the control's source coordinates, transform lineage, uncertainty, and exact artifact digest remain visible rather than becoming anonymous workflow tensors. ### Technical settlement `ImageJob@2` settles whether the requested operation produced a technically valid candidate set. [Atelier](../../../compositions/atelier/index.md) or another consuming Composition then decides whether to adopt it creatively; successful custody and probes cannot make that choice for the owner. Each concrete execution uses Core's Designed [`ServiceJobAttempt@1`](../../../adr/14-workers.md#service-job-attempts) mechanics. An `INDETERMINATE` attempt remains contained and nonterminal, so it cannot count as either a successful or failed image result. Qualify the interaction details separately too: numeric progress, previews, cancellation acceptance and settlement, multiple references, hard masks, deterministic seeds, and partial streaming are independent capability facts. A Connector cannot infer them from a broadly compatible endpoint. Each result receipt retains source and output digests, original and derived prompt language and texts, translator revision and declared loss, engine and container revision, model and component digests, exact preset or graph digest, LoRA and control adapters, scheduler, steps, guidance, seed, dtype and quantization, dimensions, timing, warnings, and cancellation settlement. Provider filenames, image IDs, and embedded PNG metadata are evidence inputs, not canonical provenance. ## Serving route and workflow route The first implementation study keeps two complementary routes rather than forcing a workflow graph through a lowest-common-denominator API. | Candidate | Office | Present judgment | | --- | --- | --- | | [vLLM-Omni](https://github.com/vllm-project/vllm-omni) | Apache-2.0 omni and diffusion serving through OpenAI-compatible `/v1/images/generations` and `/v1/images/edits`, including multiple images and masks where the model supports them. | Primary simple serving candidate. It is a separate runtime project from ordinary vLLM even though it shares the ecosystem and command shape. Bake generation, editing, cancellation, quantization, output limits, and lifecycle independently. | | [ComfyUI](https://github.com/Comfy-Org/ComfyUI) | GPL-3.0 graph inference server with image and mask upload, queued workflows, WebSocket progress, history, interruption, and model-memory release. | Full-power workflow connector for control maps, LoRA stacks, multiple samplers, inpaint, upscale, detail passes, and future image/video/3D nodes. Only allowlisted built-in or exactly pinned custom nodes and immutable workflow presets may run. | | [SGLang-Diffusion](https://github.com/sgl-project/sglang) | Apache-2.0 performance-oriented diffusion server with OpenAI Images serving and native or Diffusers-backed pipelines. | Challenger behind the same basic Images profile. Promote only where a model or measured throughput, batching, placement, or sharding advantage beats the first route. | Use OpenAI Images to carry requests where its dialect fits, while keeping the inner contract with Image. Profile generation and editing separately, including masks, multiple references, partial streams, and cancellation. Because the API offers no universal durable image-job resource, LychD must retain job identity, state, authority, retry law, and artifact custody. For a Comfy route, select only the immutable preset and parameter openings admitted under the [engine contract](../../animator/soulstone/engines/comfyui.md#keep-model-engine-and-road-apart). Arbitrary graphs, runtime checkpoint downloads, partner API nodes, and ambient custom-node installation are forbidden. The engine graph supplies no Spellweaver or effect authority. [Diffusers](https://github.com/huggingface/diffusers) remains the reference implementation and model-compatibility path. It is a Python library rather than a complete multi-user job service, so LychD should not build another general Diffusers server before a supported serving engine proves insufficient. Stable Diffusion is one model family runnable through these engines, not an automation runtime; every chosen checkpoint, encoder, VAE, adapter, and dependency retains its own license and bake. One runtime adapter and endpoint may later expose separate admitted Image and Video dialect drivers for pinned graphs. Their operations, job profiles, and editorial boundaries remain separate; a generic Connector label cannot merge them. ## First permissive model profiles The initial model bake remains deliberately small: | Profile | Intended office | License and iron | | --- | --- | --- | | [FLUX.2 klein 4B](https://huggingface.co/black-forest-labs/FLUX.2-klein-4B) | Fast interactive text-to-image, single-reference edit, and multi-reference edit in one checkpoint. | Apache-2.0 and approximately 13 GB VRAM by its official card. The FLUX.2 klein 9B, 9B-KV, and FLUX.2 dev models use non-commercial terms and are not substitutes for this profile. | | [Qwen-Image-2512](https://huggingface.co/Qwen/Qwen-Image-2512) plus [Edit-2511](https://huggingface.co/Qwen/Qwen-Image-Edit-2511) and a pinned control profile | High-quality generation and typography; identity-sensitive single/multi-image editing; masked and structural work across the family. | Apache-2.0 but heavy: the official BF16 packages include roughly 57.7 GB of components. Treat as a stasis/offload or explicitly sharded quality route, not a permanent companion to a large Mind. | FLUX.2 klein 4B is the first resident-friendly default. The Qwen family is the first heavy quality and control route. Neither project logo proves every operation: FLUX generic reference editing is not a hard preservation mask, and separate Qwen checkpoints remain separate Rune profiles. ## Coven, stasis, and the proving bake Placement must work on the operator's actual devices. One possible Coven keeps a compact Multimodal Mind on one 24 GB GPU and FLUX.2 klein on the other. A large Qwen-Image profile may instead require affected work to release its leases through [Prism's Stasis and readiness passage](index.md#sight-on-finite-iron). Two 24 GB devices do not implicitly provide one 48 GB allocation. The exact runtime must prove sharding, offload, warm-up, cancellation, and complete release; neither Comfy nor a serving engine can choose placement or evict another Animator. The first corpus should cover natural scenes, illustration, UI and poster text, Slovak diacritics, single- and multi-reference identity, preservation edits, masks and expanded canvases, pose/depth/ edge controls, transparent output, adversarial dimensions and metadata, cancellation, OOM, restart, and deterministic-seed replay. Measure prompt alignment, text accuracy, source and region preservation, identity deviation, control adherence, diversity, latency, peak VRAM, output validity, artifact lineage, and license closure. Promote exact profiles: the first bake compares FLUX.2 klein through vLLM-Omni with the same basic profile where SGLang-Diffusion supports it, then proves one allowlisted Comfy workflow for the advanced path. Qwen-Image enters as the heavy quality/control route only after its exact quantization or offload topology passes on operator iron. --- title: "Video" plain_name: "Video generation" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/video/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/video/ --- # Video (Video generation) ## Plain-English summary (Snayu) **What it is:** The planned video-making path (Video) for text-to-video, image-to-video and related temporal jobs, binding sources, prompts, controls and clocks, and returning technically validated candidate clips. **Why it matters:** Read this before integrating any video generation model or adding audio to generated video. - One VideoJob names one explicit operation such as t2v or i2v; profiles declare what they actually support. - Native sound in generated video needs its own authorization and separate admission. - Editing, sound production and publication remain separately owned. **Status:** Designed. No delivered adapter; study reviewed August 2026. ## Original text (Hexanomicon) A still may become a shot; a clip may be continued, transformed, or driven by admitted sound. Prism **Video** binds that generative temporal effect to exact sources, prompts, controls, and clocks, then returns technically validated candidates. Visual direction, structured animation, sound production, final editing, and publication remain separately owned. Read the operation and compound-facet passage before selecting a model. The candidate study was reviewed on **2026-08-26** and proves no delivered adapter or permitted effect; [State](../../../state-of-the-work.md#vision-admission) owns that boundary. ## One temporal job, several proved operations The inner surface should remain stable while engines and models evolve. A candidate `VideoJob@2` names one explicit operation: | Operation | Inputs | Required meaning | | --- | --- | --- | | `t2v` | prompt | Create one or more new moving-image candidates from text. | | `i2v` | prompt plus one or more source or reference images | Animate or derive a clip while declaring what continuity the selected profile can preserve. | | `v2v` | prompt plus source video and optional controls | Restyle, edit, condition, or transform a clip without calling the result a deterministic edit. | | `first_last` | prompt plus first and last frame | Generate the temporal path between exact boundary images. | | `continue` | prompt plus source clip or boundary frames | Extend motion forward or backward under a separately proved continuity profile. | | `motion_transfer` | character or subject reference plus driving video | Transfer motion or replace a subject while retaining both sources in lineage. | | `audio_driven` | character or scene reference plus admitted audio | Produce synchronized visible performance from speech, song, music, or another exact audio source. | Optional material never invents support. Each model profile declares the operations, source kinds, reference counts, controls, output limits, and cancellation behavior that its exact bake proved. First/last-frame control, masks, camera paths, poses, depth, edges, generated sound, interpolation, and upscaling are independent claims rather than implications of generic video support. [Sight](sight.md) may supply source-grounded masks, regions, pose, depth, flow, or tracks as exact controls. Video owns the generative temporal effect; a track remains a bounded estimate with gaps, not subject identity or proof of what happened. [Kinesis](kinesis.md) owns reusable skeletal, root, hand, face, contact, and transform motion facets. A motion-transfer or audio-driven video may visibly perform while returning pixels only; it does not imply a rig-compatible clip. If one worker returns both pixels and structured motion, the compound result retains separate Video and Kinesis facets, validation, and provenance. The job carries immutable source and control `ArtifactRef` values; original and derived prompts; negative prompt; seed policy; width, height, frames, frame rate, duration, and timebase; an immutable preset; deadline and budget; output profile; and a closed engine-extension object. A prompt translator may derive the model-facing prompt from the operator's preferred language, but the receipt preserves both texts, translator revision, and declared loss. Translation never silently replaces visual direction. `VideoJob@2` settles the requested temporal effect: its candidate set and technical validation. Atelier or another consuming Composition decides whether to adopt the work creatively; custody and probes cannot decide for it. Each concrete execution uses Core's Designed [`ServiceJobAttempt@1`](../../../adr/14-workers.md#service-job-attempts) mechanics. The Connector must establish what the provider can actually report or stop. Numeric progress, step progress, previews, cancellation before start, cancellation while running, and cancellation granularity are separate facts. Deleting a provider record does not prove that a running generation was cancelled. An indeterminate attempt stays contained and must be reconciled using the same provider identity. Every returned file is immediately ingested into Reliquary custody and rehashed. A canonical receipt retains input and output digests; engine, container, model, encoder, decoder, VAE, LoRA, and control revisions and licenses; graph or preset digest; sampler, steps, guidance, seed, dtype, quantization, offload and parallelism; dimensions, frames, rate, timebase, codec, timing, warnings, cost, progress, and cancellation settlement. Provider IDs, filenames, and embedded metadata are evidence inputs, not canonical provenance. ## Admit every compound facet A video request that may return sound crosses a second, explicit admission boundary. Declare its roles before dispatch; after technical settlement, retain each owner's independent judgment. The same compound artifact can therefore be technically valid while one intended use is refused. Before dispatch, identify every requested output facet in the job's pinned `MediaFacetAuthoritySet@1`. Each row binds a stable facet id and technical kind to its exact semantic role, consuming Composition identity and revision, owner request or brief digest, permitted use, and audience. It also carries source, likeness, voice, rights, and consent evidence; classification, retention, and Portal policy; the paid-effect ceiling; required separability; and the disposition to use when the facet cannot be proved. For sound, choose from the closed roles `music`, `timed_language`, `picture_sound`, and `world_sound`. A provider label such as `audio` or `sound` cannot make that choice: it describes media without identifying the owner or intended use. A profile may enable native sound only after every requested sound row passes that preflight. When the row entails speech capture, transcription, synthesis, cloning, or voice identity, it also pins the exact eligible Echo contract and profile; the timed-language consumer still owns words, alignment, performance fit, and edition judgment. When a model cannot disable or separate a sound facet, the job either declares and authorizes every possible role before dispatch or selects a different profile. Capability support, payment authority, and semantic acceptance are separate facts. If a model emits sound with video, Prism records one compound candidate, original container digest, shared timebase, and generation receipt, then separates the returned streams into attributable child artifacts when their rights and formats permit it. [Atelier](../../../compositions/atelier/index.md) retains visual judgment; [Riffmaw](../../../compositions/riffmaw/index.md) musical judgment; [Language Edition](../../../compositions/language-edition/index.md) timed-language judgment; [Broadcast](../../../compositions/broadcast/index.md) picture-sound and final editorial audiovisual judgment; and [Foundry](../../../compositions/foundry/sound.md) world-sound judgment. After technical settlement, each declared consumer still judges its own facet. Its independent `SemanticFacetAdmissionReceipt@1` pins Composition identity and revision, owner request digest, facet and compound digests, role, use boundary, evidence and findings, decision maker, and an `accepted`, `refused`, or `quarantined` disposition. Prism can link those receipts to the result, but cannot issue, merge, or upgrade them. If the same bytes serve two roles, they require two receipts. Broadcast's later judgment of the final editorial audiovisual relation cannot replace admission by Atelier, Riffmaw, Language Edition, or Foundry. Technical validity alone therefore makes no facet usable. If returned sound was absent from `MediaFacetAuthoritySet@1`, record an `UnexpectedMediaFacet@1` finding and fail closed for that facet. The pinned retention rule determines quarantine or deletion; the sound cannot be routed as a usable candidate or assigned a guessed owner. A provably separable visual child may continue once that disposition is settled. An inseparable compound remains unusable unless every declared facet owner accepts that exact compound digest and use. Neither `generate_sound=true`, demux, nor a provider label can transfer an office or admit undeclared sound. ## Serving route, workflow route, and deterministic tools | Candidate | Office | Present judgment | | --- | --- | --- | | [vLLM-Omni](https://docs.vllm.ai/projects/vllm-omni/en/latest/serving/videos_api/) | OpenAI-compatible asynchronous `/v1/videos` serving for text-, image-, video-, and audio-conditioned models, with a synchronous benchmark route and runtime-specific fields. | First simple-serving runtime. One server instance hosts one startup-selected model. Bake each operation independently; its documented delete route does not establish running cancellation. | | [ComfyUI](../../animator/soulstone/engines/comfyui.md#pin-the-dialect-and-execution-lifecycle) | Graph runtime whose external beta API v2 supplies durable jobs, progress, outputs, and cancellation requests. Self-hosting that dialect currently requires the separately pinned `comfy-api-proxy`; classic local server routes remain distinct. | Advanced connector for first/last frames, masks, structural controls, model chains, motion transfer, interpolation, upscale, and audio-driven workflows. Admit only immutable allowlisted graphs and pinned nodes. | | [SGLang-Diffusion](https://docs.sglang.io/docs/sglang-diffusion/api/openai_api) | Performance-oriented image/video server implementing a subset of OpenAI Videos, native and Diffusers-backed pipelines, offload, quantization, and parallel execution. | Bake-time challenger behind the same basic profile. Add no second mandatory connector until an exact model proves a material support, placement, batching, or throughput advantage. | | [LightX2V](https://lightx2v-en.readthedocs.io/en/latest/deploy_guides/deploy_service.html) | Video-focused inference framework with quantization, CPU and disk offload, multi-device execution, asynchronous task endpoints, and current-task interruption. | Research lane for constrained and heterogeneous iron. Its service-wide busy/idle and current-task stop semantics are too coarse to define Core job law. | [Diffusers](https://github.com/huggingface/diffusers) remains a model SDK and compatibility substrate, not another connector unless LychD deliberately builds and accepts a durable worker around it. OpenAI Videos is likewise a useful wire dialect, not the inner contract: LychD keeps job identity, authority, custody, retry, cancellation, and recovery. For a Comfy workflow, select only the preset and parameter openings admitted under the [engine contract](../../animator/soulstone/engines/comfyui.md#keep-model-engine-and-road-apart). Caller-supplied graphs, runtime downloads, ambient custom nodes, and unapproved partner nodes fail closed. The Spell placement retains the surrounding semantic contract. [Prism's Lens](../../../adr/36-vision.md#decision) may use a pinned FFmpeg revision as deterministic machinery for per-artifact probing, extraction, normalization, interpolation, or encoding with declared loss. [Atelier](../../../compositions/atelier/motion.md) owns creative motion and accepted visual sequences; [Broadcast](../../../compositions/broadcast/edit.md) owns the final audiovisual timeline, trim, placement, captions, mix, mux, and editorial render. A generative `v2v` operation never becomes the final cut merely because its input was already video. ## First model profiles The initial register keeps one permissive routine family and a few materially distinct specialists. These are exact profile candidates, not claims that one family name grants every operation. | Profile | Intended office | License and placement judgment | | --- | --- | --- | | [Wan2.2 TI2V-5B](https://huggingface.co/Wan-AI/Wan2.2-TI2V-5B) | Routine text-to-video and image-to-video through one 5B model, including 720p at 24 fps. | Apache-2.0. Its official single-consumer-GPU path makes it the first default bake, but one named card does not prove every 24 GB device, driver, precision, duration, or resolution. | | [Wan2.1 VACE-1.3B](https://github.com/ali-vilab/VACE) | Reference-to-video, controlled video-to-video, masked changes, motion, swap, expansion, and other structural editing. | Small first control/editor candidate. Pin exact VACE and Wan dependencies and close their licenses; do not infer that a later VACE profile is equivalent. | | [Wan2.2 Animate-14B](https://huggingface.co/Wan-AI/Wan2.2-Animate-14B) | Character animation and subject replacement driven by reference motion. | Apache-2.0 specialist. Its optional dependencies retain separate terms; no community quantization or wrapper changes those terms. | | [Wan2.2 S2V-14B](https://huggingface.co/Wan-AI/Wan2.2-S2V-14B) | Image-plus-audio performance for speech, song, and other synchronized visible motion. | Apache-2.0 specialist with a substantially heavier official placement than TI2V-5B. Supplying audio is conditioning, not proof that the model created or owns that audio. | | [LTX-2.5](https://huggingface.co/Lightricks/LTX-2.5) | Joint synchronized audio-video generation, multishot and multi-keyframe work, image conditioning, continuation, and related audio/video transformations in one family. | Distinct capability candidate under the LTX-2.x Community License rather than Apache-2.0. Its August 2026 terms include a commercial-revenue threshold and other use, transfer, attribution, and derivative conditions; the exact checkpoint, Gemma 4 encoder, video/audio decoders, Comfy or native pipeline, and placement require one reviewed closure. | | [HunyuanVideo-1.5](https://github.com/Tencent-Hunyuan/HunyuanVideo-1.5) | Efficient text- and image-conditioned video where its exact profile wins a bake. | Region-gated candidate, not a universal local option: its community license excludes use in the EU, UK, and South Korea. Location and current license eligibility must fail closed before model download or execution. | Wan TI2V-5B is the first permissive routine default; VACE is the first controlled editor. Animate and S2V remain distinct specialists because a general T2V/I2V checkpoint does not prove motion transfer or audio-driven performance. LTX remains valuable where native joint sound and video outweigh its license and resource burden. Hunyuan is neither globally accepted nor globally banned: it is ineligible where its own territory clause withholds a license. ## Profiles, Runes, Covens, and arbitrary iron Choose placement after fixing the job contract. A large-memory workstation may keep the model resident; a smaller host may need a measured quantized or offloaded profile. Other possibilities are proved sharding across devices or an explicitly admitted Portal. Hardware suitability is evidence about that exact deployment profile. A personal two-card bake establishes a result for that host, not a ceiling on the product. Follow [Prism's admission route](index.md#sight-on-finite-iron) for a grant or handle-free transition and re-dispatch. Declare the concrete service through its [Soulstone Rune](../../animator/soulstone/rune.md) and Designed [capability/profile binding](../../animator/capabilities.md#runes-runes-in-groups-and-placement); current `[[models]]` hints cover only v1 model compatibility. Orchestrator validates placement and declared conflicts; a Coven only groups compatible local services. Any Portal fallback needs its own admission. A compact Mind and Wan worker may occupy separate consumer GPUs; a high-memory workstation may keep a heavy specialist resident beside a large Mind. Reassigning incompatible devices first requires lease drain and an Orchestrator transition. Two devices do not become pooled memory without exact runtime support; the chosen tensor, pipeline, sequence, or stage topology must prove correctness and benefit. [vLLM-Omni Sleep Mode](https://docs.vllm.ai/projects/vllm-omni/en/latest/features/sleep_mode/) can release most stage VRAM while retaining process state, making it a strong future runtime transition mechanism. The Run—not the engine—enters Stasis; Orchestrator owns lease drain, transition admission, readiness, restoration, and uncertainty containment. ## The proving bake Promotion is per exact engine, model, dependency, preset, precision, quantization, offload, parallel topology, device class, resolution, frame count, and rate. The matrix includes a bounded 24 GB consumer profile, a single large-memory workstation profile, an explicit multi-device profile, and a Portal profile where policy permits. No universal VRAM formula substitutes for receipts on operator iron. The corpus covers multilingual and Slovak briefs with preserved prompt derivation; text-to-video; single- and multi-image conditioning; first/last frames; continuation; controlled and masked V2V; identity and character motion; speech, song, and music-driven performance; camera and temporal continuity; subtitles and visible text; adversarial dimensions, codecs, metadata, and durations; cancel before start and during generation; OOM; restart; stasis/wake; and deterministic-seed replay where claimed. Measure prompt and control adherence, source and identity preservation, temporal coherence, motion quality, lip and audio synchronization, flicker, visible text, accessibility hazards, duration and timebase correctness, output validity, latency, peak VRAM, host RAM, disk traffic, warm-up and wake time, throughput, cancellation settlement, recovery, artifact lineage, and license closure. Promote only the exact profiles whose measured costs and failure behavior remain honest; more powerful iron may admit a broader resident Coven without changing `VideoJob@2`. --- title: "Form" plain_name: "3D model generation" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/form/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/form/ --- # Form (3D model generation) ## Plain-English summary (Snayu) **What it is:** The planned 3D path (Form) that turns photos, capture sets or existing meshes into validated 3D results, geometry, materials, rigs or fields, keeping source, scale and loss visible. **Why it matters:** Read this before integrating image-to-3D, reconstruction, rigging or mesh-conversion tools. - There is no universal 3D serving protocol; FormJob names one operation and the profile declares proven outputs. - Results are a typed asset set with facets, not just a preview. - Engine import, animation and live-world placement belong to the consuming app. **Status:** Designed. Contracts and candidate tests only; study reviewed August 2026. ## Original text (Hexanomicon) A photograph may suggest geometry, a capture set may support reconstruction, and an existing mesh may need a new material, rig, or block projection. **Form** carries each requested operation to a validated spatial result with its sources, representation, scale, and loss still visible. Choose the operation first, then inspect the facets it must return. A useful preview cannot settle those technical questions. Creative adoption, engine import, animation, and live-world placement remain with the consuming owner. This candidate study was reviewed on **2026-08-08**. The contracts and bakes below are Designed; [State](../../../state-of-the-work.md#vision-admission) records the present visual boundary. ## One form job, explicit operation There is no mature universal OpenAI-compatible 3D serving protocol to make the inner contract. The candidate `FormJob@2` names one explicit operation while its selected profile declares the inputs, output facets, controls, and limits it has actually proved: | Operation | Inputs | Required meaning | | --- | --- | --- | | `generate` | prompt and optional image, multiview, depth, or layout references | Produce new spatial facets proved by the exact model profile. | | `reconstruct` | admitted images, calibrated views, video frames, or point observations | Recover spatial facets while retaining cameras, source coverage, and uncertainty. | | `texture` | geometry plus images, prompt, or material controls | Produce new appearance facets without claiming the geometry was regenerated. | | `segment_parts` | image or geometry | Propose a structural part graph and separately addressable geometry. | | `rig` | compatible geometry and optional skeleton or semantic controls | Produce deformation facets; no animation is implied. | | `voxelize` | mesh, point cloud, volume, or scene | Apply an exact occupancy, sampling, scale, and optional palette policy to a bounded grid. | | `block_generate` | biome, seed, mask, or admitted block context | Produce a block-native candidate without pretending it came from mesh voxelization. | | `convert` | one admitted facet set | Create explicit derivative facets with declared loss and validation. | | `render` | admitted form facets, camera, and render profile | Produce attributable image or video previews; a beauty render does not validate the source asset. | The request must identify both the material and the spatial meaning to preserve. It carries immutable input and control `ArtifactRef` values, original and derived prompts, the requested operation and output facets, and units, axes, origin, scale, bounds, and coordinate transforms. Seed policy, immutable preset, deadline, budget, and a closed engine-extension object bound the execution. Optional material cannot invent support in the selected profile. A text-to-image-to-form route is valid when both effects remain explicit. The generated image is an attributable intermediate artifact, so the spatial result can still be traced through it; it cannot disappear into hidden prompt machinery. [Sight](sight.md) may supply masks, regions, pose, depth, flow, and camera estimates as exact input facets. Form owns reconstruction and form generation; monocular relative depth is neither metric geometry nor a reconstructed mesh. `FormJob@2` owns spatial stages, candidate facets, technical validation, and result settlement. Creative adoption and engine use belong to their consuming Compositions. Each concrete service or tool execution uses Core's Designed [`ServiceJobAttempt@1`](../../../adr/14-workers.md#service-job-attempts) state, idempotency, cancellation, reconciliation, and indeterminate-effect law. The parent Run remains nonterminal and fenced while the same attempt is indeterminate; neither job nor effect is replayed under a new identity. ### Progress, cancellation, and return Stages such as camera solve, generating or reconstructing, extracting, texturing, rigging, baking, validating, and exporting are reported separately from numeric progress. Cancellation before GPU admission, cooperative model cancellation, bounded worker termination, and tool-process termination are different proved capabilities. A vanished worker does not prove that its effect stopped or failed. Keep unfinished material available for diagnosis without treating it as a result. Partial, temporary, failed, or uncertain output enters quarantined Reliquary custody with its own digest and working-set relation. Restart and reconciliation can inspect that material, but only validated output enters the settled Prism Form result. On reconnect, reconcile the exact provider job, request digest, working-set receipt, and returned artifacts. Repeating an uncertain paid or remote effect would create a new event without settling the old one, so no blind retry is permitted. Every canonical receipt retains request digest and idempotency key; input, intermediate, and output digests; model weights, runtime, container, graph, tool, add-on, and dependency revisions and licenses; seed and exact configuration; dtype, quantization, offload and device topology; units, axes, scale, transforms, camera uncertainty, and representation facts; timing, peak resources, warnings, validation, cancellation settlement, and declared conversion loss. Provider paths, Python objects, and embedded file metadata are evidence inputs, not canonical provenance. ## One asset set, typed facets "3D" is not one flat output enum. `FormAssetSet@1` groups separately typed facets whose relations remain explicit: | Facet | Candidate forms | What it does not prove | | --- | --- | --- | | **geometry** | mesh, point cloud, voxel grid, or block grid | appearance, clean topology, physics, or portability to another renderer | | **appearance** | PBR materials and texture artifacts with UV, color-space, channel, and sampler facts | geometry, source truth, or engine compatibility | | **field/render representation** | 3D Gaussian splats or neural radiance field with cameras, bounds, renderer, and configuration | a clean mesh, separately editable appearance, physics, or renderer-independent portability | | **structure** | semantic part graph with member geometry and transforms | joints, assembly constraints, or a usable rig | | **deformation** | skeleton, skin weights, bind transforms, and rig profile | useful motion, retargeting quality, or animation rights; those technical derivatives belong to [Kinesis](kinesis.md) | | **assembly** | `PortableSceneAssembly@1` with artifact references, transforms, hierarchy, cameras, lights, and declared constraints | an engine-native scene, collision, gameplay, or playability | | **procedure** | inert `ProceduralFormRecipe@1` in a closed allowlisted grammar | executable Python, drivers, Geometry Nodes, shell, game commands, or authority to run an effect | Canonical handoff normally uses a GLB/glTF container that may combine mesh, PBR appearance, deformation, and animation facets when each is present. A Gaussian PLY or exact renderer package, a NeRF checkpoint and configuration, and their camera sets remain field/render facets. They do not impersonate point clouds or meshes merely because a viewer can render each of them. A conversion creates another artifact whose losses must be named. Meshing a radiance field, baking a Gaussian scene, reducing a textured mesh to blocks, retopologizing geometry, or converting a rig can each discard different information. The receipt records that loss rather than allowing the converted file to stand in for everything its source contained. Reconstruction remains an inference from admitted captures. It can claim metric scale only with supporting camera calibration or an admitted scale reference. Likewise, TRELLIS.2's internal sparse voxels are not a Minecraft block grid; reaching that grid still requires an explicit conversion. ## Hostile form custody The Reliquary owns every source before Form materializes it. Admission bounds external URIs, archive expansion, vertices, faces, nodes, scene depth, materials, texture pixels and channels, animation channels, bones and influences, points, splats, voxels, training frames, parser memory, GPU time, disk, and output expansion. Importers verify claimed media types and reject recursive or unsupported content. Scripts, drivers, expressions, add-ons, custom nodes, linked libraries, remote references, and generated procedures remain inert unless a separate contained tool effect explicitly admits them. Blender and ComfyUI workers run rootlessly without ambient home access, network access, auto-run scripts, arbitrary plug-ins or nodes, and runtime downloads. A capture set additionally retains consent, camera facts, and every source frame; rendering another view cannot launder the people, places, or restricted material it depicts. ## Composition boundaries Prism owns hostile-form handling, technical dispatch, transforms, facet semantics, conformance to the declared Form profile, and effect provenance. An independent validator checks tool output where the transforming tool cannot establish its own result. [Atelier](../../../compositions/atelier/assets.md) owns creative acceptance, the brief, candidate review, accepted form asset, and visual package. Foundry owns target-engine import and validation, coordinate and material adaptation, collision, LOD, performance, engine-native scene assembly, and playability. Blockworld owns live-world effect validation and bounded missions. A Form output crossing any boundary is an exact artifact handoff, never shared authority. An [Avatar](../../../compositions/avatar/index.md) profile may reference an exact Form asset, rig, and morph ontology. Form still owns only that spatial material and its provenance; it does not bind Persona, open an Avatar presence, admit a Spectre VR Habitat or Encounter, drive the projection, or acquire world or body authority. ## Model workers, graph serving, and tool workers Keep one Prism-owned Form interface while qualifying several immutable implementations behind it. A research repository can supply a model without defining Core's protocol. If its worker has resident, queued, or remote service behavior, it is an Animator reached through a `JobGrant`. If execution is a finite model or tool operation, the Spell Resolution Lock selects it for a trusted executor or Tomb. A pinned contained process needs no invented Soulstone, and two paths that both emit GLB are not thereby interchangeable. | Candidate | Office | Present judgment | | --- | --- | --- | | pinned Form model workers | Run one admitted generation, decomposition, rigging, reconstruction, or block-model profile behind `FormJob@2`. | Primary route. Each worker exposes only proved operations, accepts no ambient code or download, and settles output through custody. | | [ComfyUI](../../animator/soulstone/engines/comfyui.md#pin-the-dialect-and-execution-lifecycle) | Graph route for multi-stage image-to-form, texture, preview, and future 3D nodes. | Advanced connector only. Admit immutable allowlisted graphs and pinned nodes; partner or cloud nodes are not proof of a local runtime. | | [Blender](https://docs.blender.org/manual/en/latest/advanced/command_line/arguments.html) | Headless UV, bake, material normalization, decimation or retopology, armature work, animation bake, GLB export, and validation renders. | Separate sandboxed tool process, never authority or deterministic truth. Pin build, add-ons, scene digest, command, environment, seeds where available, and output validation; prove semantic equivalence unless byte identity is explicitly claimed. | | [trimesh](https://github.com/mikedh/trimesh), [Open3D](https://github.com/isl-org/Open3D), and [OpenVDB](https://www.openvdb.org/) | Geometry probing, bounds, topology checks, repair, registration, ray or signed-distance queries, voxelization, and sparse volumes. | Deterministic substrate only where the exact operation proves reproducible. NumPy or a bitset is enough for the 32-cubed fixture; OpenVDB is reserved for sparse volumes that justify it. | | [COLMAP](https://colmap.github.io/), [Nerfstudio](https://docs.nerf.studio/), and [gsplat](https://github.com/nerfstudio-project/gsplat) | COLMAP supplies SfM/MVS and camera solving; Nerfstudio supplies reconstruction and training pipelines; gsplat supplies Gaussian rasterization and training machinery. | First composable reconstruction stack, not three equivalent video-to-3D engines. Retain camera calibration and pose uncertainty; the result stays a radiance or Gaussian form until a separately proved conversion creates another facet. | OpenAI Images, OpenAI Videos, ordinary vLLM, and vLLM-Omni are not silently extended into 3D. They may produce conditioning images or video through their own contracts, but Form owns the job, facet semantics, custody, and recovery. Diffusers or a repository's Python demo is a model integration substrate, not a durable multi-user job service by itself. A Form graph must use only the preset and parameter openings admitted under the [ComfyUI engine contract](../../animator/soulstone/engines/comfyui.md#keep-model-engine-and-road-apart). Unapproved runtime downloads or remote nodes cannot fill gaps in a local profile. ## First model profiles No current open stack reliably turns an arbitrary prompt or video into a finished, rigged, PBR, engine-ready scene. The initial register deliberately composes narrower champions: | Profile | Intended office | License and placement judgment | | --- | --- | --- | | [TRELLIS.2](https://github.com/microsoft/TRELLIS.2) | High-quality image-to-form mesh and GLB with PBR material channels. | MIT code and model candidate; Linux and NVIDIA GPU with at least 24 GB are the published floor. Close separately licensed dependencies such as `nvdiffrast` and `nvdiffrec`; published H100 speed is not a consumer-GPU promise. | | [TRELLIS](https://github.com/microsoft/TRELLIS) | Direct text or image experiments and multiple spatial representations. | Models and most code are MIT candidates, while `diffoctreerast` and modified FlexiCubes retain separate licenses. Retain only an exact dependency-closed profile; family relation does not make it equivalent to TRELLIS.2. | | [TripoSR](https://github.com/VAST-AI-Research/TripoSR) | Fast low-memory single-image reconstruction to mesh. | MIT code and weights and roughly 6 GB in its published path. First latency baseline, not a universal generator or PBR quality default. | | [Step1X-3D Geometry](https://github.com/stepfun-ai/Step1X-3D) | Alternative 1.3B geometry profile. | Apache-2.0 candidate. Prove geometry alone and its handoff separately from the full published pipeline. | | [Step1X-3D Texture](https://github.com/stepfun-ai/Step1X-3D) | Separate 3.5B geometry-to-appearance profile. | Apache-2.0 candidate with a published combined path around 27–29 GB. Texture presence is not automatically a common PBR contract. | | [TripoSG](https://github.com/VAST-AI-Research/TripoSG) | High-fidelity shape-only geometry. | MIT candidate. It deliberately requires a separate appearance path. | | [PartCrafter](https://github.com/wgsxm/PartCrafter) | Image-to-semantic, separately editable parts. | MIT core candidate. Its automatic BRIA background-removal path and optional Gemini route retain separate license and Portal gates; disable them unless independently admitted. | | [SkinTokens](https://github.com/VAST-AI-Research/SkinTokens) | Unified compatible-mesh-to-skeleton-and-skin profile. | MIT research candidate with a published path at 14 GB or more. Promote only with topology-diverse deformation and export validation. | | [UniRig](https://github.com/VAST-AI-Research/UniRig) | Separate two-stage skeleton and skinning predecessor. | MIT research candidate. Code and weight licenses do not settle training-source or produced-character rights. | | [AniGen](https://github.com/VAST-AI-Research/AniGen) | Experimental image-to-rigged asset. | MIT core, but bundled `extensions/CUBVH` derives from `instant-ngp` under non-commercial/research-only terms. A commercial profile must prove that component is neither imported, built, nor executed and close every remaining dependency. | | [MIDI-3D](https://github.com/VAST-AI-Research/MIDI-3D) | Experimental single-image-to-compositional multi-instance scene and GLB candidate. | Apache-2.0 code and weights candidate; textured generation needs instance segmentation and roughly 30 GB in its published path. It is not an engine-ready world. | [Stable Fast 3D](https://github.com/Stability-AI/stable-fast-3d) remains a useful fast challenger, but its Community License, registration, attribution, and revenue conditions keep it outside the permissive default. [Hunyuan3D 2.1](https://github.com/Tencent-Hunyuan/Hunyuan3D-2.1) remains a technical reference, not an eligible Bratislava deployment: its published community license does not grant use in the European Union, United Kingdom, or South Korea. Eligibility is re-evaluated from the pinned license before download and execution; neither a model wrapper nor a community quantization repairs a withheld grant. [DreamCubed](https://github.com/SakanaAI/DreamCubed) is an interesting Minecraft-native research candidate for chunk generation, biome conditioning, inpainting, supersampling, and stitching. The official DP4 and DP2 Hugging Face cards label those exact weights Apache-2.0, while CP2 currently surfaces neither model-card text nor a license file. The two-commit code repository likewise exposes no license file, and the dataset, block mappings, textures, dependencies, and resulting-use terms are not closed. The whole route therefore remains license-blocked research rather than a Core profile. Even after closure, model tokens must map to the canonical block palette and pass the same validation and consumer admission as any other block source. The first text-to-form quality route begins with [Image](image.md), then passes its admitted image to the image-to-PBR TRELLIS.2 profile. Keep both effects, both prompts, and that intermediate image in the lineage. For an editable character, a candidate chain may retain the original unified shape, derive optional semantic parts, choose compatible geometry for rigging, and run contained Blender validation. Every handoff needs its own compatibility bake: disconnected parts or seams may invalidate skinning, so their outputs cannot be assumed compatible with SkinTokens or UniRig. Form then hands the exact skeleton, hierarchy, rest and bind transforms, local frames, axes, units, limits, skinning, and morph ontology to [Kinesis](kinesis.md). Kinesis supplies motion clips and technical retargeting; Atelier supplies animated storytelling. The `rig` operation implies neither. ## Profiles, Runes, Covens, and arbitrary iron Use [Prism's admission route](index.md#sight-on-finite-iron) to obtain the exact model and deployment binding. Separate consumer-GPU workers, a resident workstation profile, an Orchestrator transition after affected leases drain, or an explicitly admitted Portal each needs its own measured evidence. Two GPUs do not automatically pool VRAM; a published minimum does not prove an unmeasured driver, precision, resolution, or offload topology. ## The proving bake The proving corpus covers single images, multiview references, transparent and ambiguous objects, thin structures, open and non-manifold meshes, hard-surface and organic forms, PBR channels, semantic parts, humanoid and non-humanoid rigs, camera reconstruction with missing coverage, Gaussian and radiance portability, Slovak and multilingual briefs, adversarial files, cancellation, OOM, restart, stasis, and deterministic replay where claimed. Voxel fixtures cover exact 32-cubed bounds, `solid`, `shell`, and `surface` policies, palette collisions, clipping, empty and full volumes, block inpainting, closed procedural recipes, `.schem` round trip, and prohibited stateful blocks. Measure conditioning adherence, multiview consistency, geometry completeness, topology and manifoldness where required, normals, UV and PBR validity, texture seams and projection error, scale and axis correctness, part usefulness, skeleton hierarchy, skin-weight normalization and deformation clips, held-out reconstruction views, representation portability, voxel occupancy and silhouette error, palette validity, output validity, latency, peak VRAM and host RAM, disk use, cancellation settlement, recovery, lineage, and license closure. Promotion is per exact model, worker, dependency, tool, preset, precision, device topology, input class, and facet set. A prettier turntable cannot conceal an invalid asset or authority gap. For the complete bounded grid, palette, schematic, and read-back workflow, follow [Voxel and block export](voxel-and-block-export.md). Form retains the spatial request and result; the consuming application admits the exported artifact and any later world effect. --- title: "Voxel and block export" plain_name: "Voxel and Minecraft block export" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/voxel-and-block-export/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/voxel-and-block-export/ --- # Voxel and block export (Voxel and Minecraft block export) ## Plain-English summary (Snayu) **What it is:** A planned 3D workflow that converts a model into a bounded voxel grid, maps it to a game block palette and exports a Sponge Schematic v3 (.schem) file, proving the result by reading it back. **Why it matters:** Read this when working on Minecraft or block-game asset export for the Foundry or Blockworld apps. - Three routes: deterministic voxel conversion, block-native generation, and procedural recipes run by a contained interpreter. - The first proving fixture is a 32x32x32 grid with full cubes only; unknown blocks fail closed. - An exported schematic grants no right to place blocks in a live world. **Status:** Designed. Designed passage; no exporter delivered. ## Original text (Hexanomicon) A spatial asset can become a bounded grid, a game-qualified block palette, and a portable schematic. This Form workflow owns that conversion and its read-back evidence. Its return is an artifact that [Foundry](../../../compositions/foundry/assets.md) or [Blockworld](../../../compositions/blockworld/mission.md) may separately admit. The passage is Designed. It shares [Form's](form.md) source custody, typed facets, exact execution attempt, and technical settlement, and the [Vision Covenant](../../../adr/36-vision.md) owns its law. Selecting an exporter grants no authority to place blocks in a live world. ## Voxels and the 32-cubed proving fixture Form distinguishes three voxel routes rather than calling each a Minecraft generator: 1. **Deterministic conversion:** normalize an admitted mesh or volume, choose `solid`, `shell`, or `surface` occupancy, sample exactly 32 by 32 by 32 cells, apply an optional palette and interior rule, validate, and export. 2. **Block-native generation:** an eligible future model produces or inpaints a bounded semantic block region. The result maps through the same canonical palette and validation; it does not masquerade as a voxelized mesh. 3. **Procedural composition:** a Mind may propose an inert `ProceduralFormRecipe@1` using admitted shapes, transforms, repetition, booleans, symmetry, palette entries, and bounds. A separate contained interpreter effect validates and renders it. Arbitrary Python, shell, Blender scripts, or Minecraft commands are not this contract. First make the sampled space unambiguous. `VoxelGrid@1` pins dimensions, axes, origin, cell scale, occupancy or density channels, optional colors, source axis-aligned bounding-box (AABB) fit and padding, cell-center or cell-volume sampling, boundary and tie rules, axis-to-index mapping, and source transform. Mapping that space to blocks adds a game-specific meaning. The canonical `BlockGrid@1` pins dimensions, origin, axes, units, exact game registry edition and version plus registry digest, palette revision and ordering, exact block identifiers and state properties, air and unknown policy, source relation, and digest. That canonical grid remains independent of the game-file encoding later chosen for export. The derived Minecraft projection pins Java edition and version, `DataVersion`, palette mapping, offset, unsupported-block policy, block-entity and entity policy, metadata and timestamp policy, and encoder revision. Its first profile permits full cubes only; stairs, slabs, fences, fluids, redstone, and stateful blocks require later explicit topology and behavior profiles. Unknown or unsupported states fail closed unless the profile names and records an exact substitution. The export candidate is [Sponge Schematic v3](https://github.com/SpongePowered/Schematic-Specification/blob/master/versions/schematic-3.md): GZip-compressed NBT with an outer `Schematic` compound, `Version = 3`, required `DataVersion`, unsigned-short interpretation of `Width`, `Height`, and `Length`, `Blocks.Palette`, and varint `Blocks.Data` indexed as `x + z*Width + y*Width*Length`. Read-back normalization proves dimensions, palette, offsets, states, block data, and metadata against the canonical grid. Return enough material to inspect the conversion: the source grid, canonical block grid, `.schem`, preview GLB and PNG, block counts, palette statistics, clipping and unsupported-material findings, and the export-and-read-back receipt. At 32,768 cells, the 32-cubed golden fixture can use simple, inspectable data structures rather than a large-volume framework. Its size makes this first proof manageable; it sets no universal product limit. A `.schem` admitted to [Foundry](../../../compositions/foundry/assets.md) is a project asset. The same exact blueprint admitted to a [Blockworld mission](../../../compositions/blockworld/mission.md) still grants no live placement authority: Sentinel must validate every bounded world effect against world epoch, plot lease, inventory, and mission policy. --- title: "Kinesis" plain_name: "Motion and animation processing" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/kinesis/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/kinesis/ --- # Kinesis (Motion and animation processing) ## Plain-English summary (Snayu) **What it is:** The planned motion path (Kinesis) that turns pose estimates into reusable animation curves and handles motion generation, retargeting, cleanup, sync to music and validation, tied to exact clocks and rigs. **Why it matters:** Read this before integrating motion capture, pose-to-animation or retargeting tools. - A pose is not an animation: Sight estimates, Kinesis builds curves, apps review and import. - KinesisJob names one operation; output binds its clock and, where relevant, rig contract. - Playback, creative acceptance and engine import belong to other owners. **Status:** Designed. Contracts, tool path and model studies only; reviewed August 2026. ## Original text (Hexanomicon) A pose estimated from a frame becomes reusable motion only after its skeleton, time, gaps, and uncertainty are carried into curves. **Kinesis** performs that work and the bounded generation, retargeting, cleanup, synchronization, conversion, and validation of existing clips. The return identifies its exact clock and, where rig-bound, its rig contract. Its consumer may then judge a performance, import it into an engine, or separately authorize playback. Kinesis supplies none of those acts merely by producing a convincing preview. [Live Kinesis](live-kinesis.md) handles the later armed session rather than extending a finite job indefinitely. This candidate study was reviewed on **2026-08-08**. Its contracts, FOSS tool path, model studies, and bakes are Designed; [State](../../../state-of-the-work.md#vision-admission) owns delivery. ## A pose is not an animation The same visible movement crosses several owners without becoming one indistinct "motion" system: ```text Sight pose observations → Kinesis motion recovery or generation → Kinesis retargeted technical clip → Atelier creative review and accepted animation set → Foundry engine import, controller, compression, and playtest ``` [Sight](sight.md) owns estimates grounded to exact pixels and times. [Form](form.md) owns geometry, skeleton hierarchy, rest and bind pose, skin weights, morph targets, and rig revision. Kinesis owns structured change through time and its technical derivatives. [Atelier Motion](../../../compositions/atelier/motion.md) owns choreography, direction, sequencing, and acceptance. [Foundry](../../../compositions/foundry/assets.md) owns target-engine behavior. A direct video-to-motion worker may perform detection and pose estimation internally; it need not expose that private pipeline as separate Sight jobs. Its internal points become canonical `VisualObservationSet@1` output only if the exact worker also satisfies Sight's provenance, coordinates, uncertainty, and validation contract. Likewise, a video model may return convincing moving pixels without returning one reusable joint, contact, or facial curve. ## One finite job, exact operation There is no useful OpenAI-compatible protocol for skeletons, clocks, constraints, retarget maps, contacts, or animation curves. The candidate `KinesisJob@2` therefore names one explicit operation while its selected profile declares the source kinds, facets, controls, and limits it has proved: | Operation | Inputs | Required meaning | | --- | --- | --- | | `recover` | finite video, calibrated views, Sight observations, or admitted mocap | Infer declared body, hand, face, prop, root, or camera-relative motion while retaining coverage and uncertainty. | | `generate` | text plus optional reference motion, constraints, paths, keyframes, or admitted audio cues | Produce new structured motion under an exact generation profile. | | `retarget` | source motion and skeleton plus one exact target Form rig and `RigMap@1` | Create a target-rig derivative without pretending bone-name similarity is compatibility. | | `clean` | admitted motion plus exact limits, gap, filter, IK, and contact policies | Repair declared technical defects while retaining before/after metrics and corrected regions. | | `synchronize` | motion plus exact anchors, `ClockDomainMap@1`, or `MusicCueMap@1` | Create a retimed derivative; never edit or approve the source music. | | `convert` | admitted motion facets plus one output profile | Resample, transform coordinates, or create a portable projection with declared loss. | | `validate` | motion, skeleton, target rig, or projection | Return attributable technical findings without creative acceptance or engine-playability claims. | `compose`, `choreograph`, `direct`, `play`, `drive_avatar`, and `publish` are deliberately absent. Those acts belong to a Composition or a separately authorized world effect, not a motion worker. Begin by fixing the material and the motion contract. The request names exact sources and temporal regions, the operation and requested facets, and source skeleton and target Form rig digests where needed. It pins calibration, units, axes, coordinate spaces, time policies, constraints, and anchors so later curves can retain their meaning. It also fixes purpose, classification, consent, retention, likeness-use boundary, immutable model or tool preset, seed policy, deadline, compute or Portal budget, and idempotency key. Providing optional material cannot establish support absent from the selected profile. `KinesisJob@2` owns motion stages, candidates, technical validation, and result settlement. Creative adoption belongs to the consuming Composition. Each concrete service or tool execution uses Core's Designed [`ServiceJobAttempt@1`](../../../adr/14-workers.md#service-job-attempts) state, idempotency, cancellation, reconciliation, and indeterminate-effect law. An attempt remains contained until the same provider/executor job identity and working set settle; cancellation request is never proof that capture, inference, process, or remote effect stopped. Decode, observe, solve, fit, generate, retarget, correct contacts, bake, validate, and export are progress stages rather than lifecycle states. Partial or uncertain output enters quarantined Reliquary custody. Only rehashed and validated artifacts enter the settled result. An uncertain paid, remote, or local tool effect is reconciled by its exact provider/executor job identity rather than blindly replayed. ## Rig and clock law Rig-bound work consumes one exact Form deformation facet. That Form-owned facet exposes stable joint ids and hierarchy; rest, bind, and inverse-bind transforms; local frames; handedness; up and forward axes; units and scale; root and pelvis semantics; degrees of freedom and joint limits; effectors and contact bones; mirror pairs; skin influences; and facial, expression, or viseme ontology where present. Retargeting requires more than matching bone names. `RigMap@1` binds source and target skeleton digests to a calibration pose, semantic mapping, orientation offsets, scale and translation rules, twist and helper distribution, IK chains and goals, unmapped joints, root and contact policy, facial mapping, and declared loss. Bone-name equality or `humanoid=true` cannot establish that relationship. Changing the target rig makes the retargeted clip stale; the rig change itself is a separate Form derivative. Carry the rational source timebase and exact timestamps through every stage; `30 fps` alone cannot describe variable-rate video, duplicate or dropped frames, audio/video desynchronization, resampling, or gaps. Those differences remain explicit in the result. The same care applies to spatial motion. Rotations declare their coordinate frame and representation, including Euler order where used; quaternions are normalized and checked for hemisphere continuity. Root motion cannot be silently stripped, baked into the pelvis, or reintroduced. Metric scale needs calibration or an admitted scale reference. Lip and facial timing must point to exact audio, transcript, or phoneme evidence and preserve its uncertainty. ## Motion is a typed asset set Successful producing or transforming operations return `MotionAssetSet@1`; `validate` returns an attributable `MotionFindingSet@1` bound to the exact inputs and validation profile. A motion asset set is not a filename enum. It groups separately typed facets whose evidence and relations remain explicit: | Facet | Required facts | | --- | --- | | **clip manifest** | stable clip id and name, exact start and end, channel references, source-to-derived region, duration, loop intent, and positional and velocity seam tolerances | | **skeletal curves** | exact skeleton revision, stable joint ids, local or world space, channels, key times, interpolation, and missing-channel policy | | **root trajectory** | root-versus-pelvis semantics, translation and orientation, with explicit `preserve_world`, `extract_planar`, `in_place`, `target_warp`, or `none` policy | | **transform tracks** | exact Form assembly nodes, cameras, or props being transformed | | **hand motion** | left and right schema, joint coverage, visibility, gaps, and uncertainty | | **facial and morph curves** | exact joint, blendshape, expression, or viseme ontology; neutral state, ranges, and target mapping | | **contacts and events** | effector, object or ground reference, interval, point, normal, coordinate space, and uncertainty | | **time relation** | rational timebase, exact sample times, source PTS, original-to-derived map, anchors, clock-rate divergence, resampling, and gaps | | **coverage and uncertainty** | per-source and per-interval measured, estimated, generated, repaired, interpolated, occluded, or absent regions | | **projections** | GLB, BVH, VRMA, USD, FBX, previews, sidecars, and exact validation or round-trip findings | Every facet declares an evidence class such as `measured`, `recovered_estimate`, `generated`, `deterministic_transform`, or `manual`. A monocular solve is not performer ground truth, a contact hypothesis is not physical proof, and a generated dance is not an observation. Missing hands or face channels never silently become zero motion. [glTF 2.0](https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html) is the default portable projection and may carry node translation, rotation, scale, and morph-weight animation. A GLB cannot by itself preserve Kinesis's contact meaning, root policy, loop intent, source-time map, uncertainty, consent, or provenance; the canonical manifest and receipt travel with it. BVH is legacy skeletal-motion interchange and must retain its exact hierarchy, channel order, Euler order, axes, scale, and source. VRM is a Form-owned avatar and rig projection; VRM 1.0 does not use embedded glTF animations. The separate [VRM Animation](https://github.com/vrm-c/vrm-specification/tree/master/specification/VRMC_vrm_animation-1.0) format is a later Kinesis humanoid-motion projection. [OpenUSD/UsdSkel](https://github.com/PixarAnimationStudios/OpenUSD) is a later studio profile whose current TOST 1.0 license is pinned explicitly; a Blender round trip cannot be presumed to preserve every layer, reference, or variant semantic. FBX is lossy input or output compatibility only. Its original digest survives, Blender's [FBX import and export contract](https://docs.blender.org/manual/en/5.3/files/import_export/fbx.html) is part of the profile, and the EULA-governed Autodesk SDK is neither canonical nor a dependency of the FOSS path. ## Runtime and toolchain decision Kinesis owns the job and artifact contracts, not a repository's Python API. Model repositories enter as pinned worker profiles; tools enter as finite contained tool workers. Sharing a process, container, Blender installation, or GPU with Form does not merge their semantics. | Candidate | Office | Present judgment | | --- | --- | --- | | Prism Kinesis interface and reference adapter | Validate `KinesisJob@2`, resolve an exact profile, settle domain results and custody, and normalize `MotionAssetSet@1`. | Prism owns semantics and normalization; Core supplies demand/grant/attempt mechanics. No OpenAI-compatible or repository-shaped public API. | | [Blender](https://docs.blender.org/manual/en/latest/advanced/command_line/arguments.html) headless worker | Rig mapping, FK/IK, contact-aware correction, baking, GLB/BVH conversion, and validation previews. | First general tool worker. Blender is GPL; its [license guidance](https://developer.blender.org/docs/license/) says generated output is not automatically GPL, while distributed scripts and add-ons still require license closure. Pin build, scripts and environment; admission rejects or allowlists embedded code, add-ons, drivers, linked files, and Geometry Nodes before execution. | | [Khronos glTF Validator](https://github.com/KhronosGroup/glTF-Validator) and [glTF Transform](https://github.com/donmccurdy/glTF-Transform) | Structural validation, channel inspection, explicit resampling and pruning of portable projections. | FOSS portable substrate. Optimization creates a measured derivative and cannot replace semantic Kinesis validation. | | [Rhubarb Lip Sync](https://github.com/DanielSWolf/rhubarb-lip-sync) | CPU generation of simple mouth-cue timelines from speech. | MIT low-resource fallback. Slovak must use its language-independent phonetic recognizer, which Rhubarb describes as generally less precise than PocketSphinx on supported English speech; output is `VisemeCueTrack`, not full 3D facial motion. | Blender runs as a rootless isolated subprocess with job-local scratch, fixed mounts, read-only scripts, no ambient home, host sockets, secrets, or network. Its pinned invocation includes `--background`, `--disable-autoexec`, `--offline-mode`, and `--python-exit-code 1` plus one admitted read-only script. Blender's [production guidance](https://docs.blender.org/manual/en/dev/advanced/deploying_blender.html) warns that offline mode cannot stop a third-party add-on from networking, so an OS network namespace is mandatory. Those flags do not disable malicious linked material, Geometry Nodes, or add-ons; admission rejects or explicitly allowlists them. Kinesis pins the Blender build, scripts, permitted add-ons, backend, threading, flags, and environment, then claims reproducible intent only where semantic validation agrees—not byte identity by default. Start the proving profile with declared deterministic mapping, rest-pose orientation correction, and FK; add an optional IK pass only for named effectors. Foot lock acts only over declared or estimated contact intervals and must report every correction's magnitude. Validate what those operations changed: joint-limit violations; bone-length constancy except for declared scale channels; end-effector error; foot skate and floor penetration; root path and yaw; angular and discontinuity error; loop pose and velocity seam; maximum and RMS cleanup correction; output timebase; and projection validity. Then sample exported and re-imported or decompressed projections against the canonical curves under pinned maximum and RMS translation and angular tolerances. Structural glTF validation alone cannot establish animation fidelity. Foundry still owns engine-native controllers, blending, target-engine root-motion extraction and use, and animation compression. ## Privacy, rights, and receipts Discarding pixels or sound does not necessarily remove the performer from the data. Body proportions, gait, hands, face curves, voice-conditioned facial motion, and even skeleton-only derivatives may identify or reveal them. Classification and purpose therefore follow every derivative. Admission distinguishes capture, realtime analysis, persistence, inference, Portal egress, retargeting or likeness use, personalization or training, and publication; consent for one use does not admit the others. Face or gait recognition, cross-session re-identification, demographic, emotion, health, injury, or intention inference is outside Kinesis. Source-side privacy masking remains capture or Sight law; Kinesis cannot request an unmasked fallback. Revocation stops future admitted processing but cannot claim that already exported copies disappeared. A generated or recovered clip carries no authority to move an avatar, game entity, robot, vehicle, or physical effector. Every receipt pins request and idempotency digest; input, intermediate, output, skeleton, rig, and retarget-map digests; model code, weights, body-model, dataset, dependency, and output-use licenses; runtime, container, Blender build, scripts, add-ons and flags; hardware, dtype, seed, and resource peaks; axes, units, coordinate and clock maps; root, contact, IK, gap, filter, resample, and projection policies; before/after metrics; warnings; uncertainty; performer and content consent and use-rights receipt digests; and cancellation or recovery settlement. ## First model profiles The strict-FOSS first profile is the tool path above: admitted or authored motion, contained Blender transforms, portable GLB plus manifest, independent validation, and optional Rhubarb mouth cues. The strongest current learned candidates use custom open-model weight licenses, so they are operator-eligible profiles rather than the strict-FOSS default: | Profile | Intended office | License and placement judgment | | --- | --- | --- | | [GEM-X](https://github.com/NVlabs/GEM-X) | Finite monocular video to 77-joint SOMA whole-body, hand, face, trajectory, and camera-relative or world motion. | Apache-2.0 code and NVIDIA Open Model License weights: open-weight, not OSI-FOSS. Main published path is CUDA-centric; ONNX/TensorRT and Apple Silicon routes still require exact bakes. Output is SOMA motion, not an arbitrary target-rig clip. | | [Kimodo SOMA-RP v1.1](https://huggingface.co/nvidia/Kimodo-SOMA-RP-v1.1) | Text, keyframe, end-effector, waypoint, and root-path conditioned skeletal generation. | 282M profile, Apache-2.0 code and NVIDIA Open Model License weights: open-weight, not OSI-FOSS. Published clips are 30 fps and at most ten seconds; the text encoder is the main memory cost and may be placed on CPU. Do not substitute its separately licensed SMPL-X profile. | | [Audio2Face-3D](https://github.com/NVIDIA/Audio2Face-3D) | Prerecorded or later live speech to declared facial blendshape, joint, or vertex-motion profiles. | MIT SDK and Apache-2.0 training code with NVIDIA Open Model License weights. Promote each control schema independently. Audio2Emotion has separate terms and inferred affect never becomes evidence or source truth. | [ARDY](https://github.com/nv-tlabs/ardy) is a promising later interactive text-and-constraint profile, but its current CUDA path and gated Llama 3 text encoder make it a poor Core v1 dependency. Its code is Apache-2.0 and weights use the NVIDIA Open Model License, so the whole profile is not strict OSI-FOSS. [MotionBricks](https://github.com/NVlabs/GR00T-WholeBodyControl/tree/main/motionbricks) is a later real-time interactive motion-synthesis and smart-primitives candidate with the same Apache-2.0 code and NVIDIA Open Model weight distinction. [FreeMoCap](https://github.com/freemocap/freemocap) is a useful AGPL specialist capture connector rather than the default Kinesis runtime. No current music-to-dance or speech-to-whole-body model closes a sufficiently mature, permissive, dependency-complete default. EDGE and DiffSHEG remain research challengers. MoMask, MDM, MotionGPT, UniTalker, AnyTop, GEM-SMPL/GENMO, GVHMR, WHAM, and similar demonstrations may have permissive-looking repository code while depending on SMPL, SMPL-X, MANO, FLAME, AMASS, HumanML3D, BEAT, AIST++, Mixamo, Truebones, gated weights, or non-commercial data. Code, weights, body model, datasets, dependencies, and output-use terms all close independently before a profile can enter. A wrapper or converted checkpoint repairs none of them. Until a champion closes that gate, music-conditioned work composes exact Riffmaw `MusicCueMap@1` cues, authored or generated clips, Kimodo constraints where eligible, and declared Kinesis editing. Riffmaw still owns the music and Atelier still decides the visible response; picture-bound sound and the final editorial audiovisual relation remain with Broadcast. ## Profiles, Runes, Covens, and authority An exact measured profile may place Kinesis with a Mind on one GPU and a generator on another, require [Stasis while Orchestrator transitions](index.md#sight-on-finite-iron) an incompatible workload, or use an explicitly admitted Portal. The abstract job promises no hardware placement. The [motion handoff](#a-pose-is-not-an-animation) still governs the result: technical settlement precedes creative review, engine import, and separately authorized world effects. Broadcast keeps final editorial audiovisual placement. ## The proving bake The proving corpus covers authored, generated, monocular and calibrated capture; single and multiple people; standard, unusual and nonhuman rigs; hands, face, props and partial coverage; Slovak and multilingual prompts and speech; variable-rate video and audio/video desynchronization; occlusion, dropped and duplicate frames; scale and floor ambiguity; contacts, fast turns, loops, root motion, in-place variants, retarget maps, missing and extra bones, twist helpers, morph schemas; GLB and BVH round trips; adversarial files and Blender scenes; cancellation, OOM, crash, restart, Stasis, Portal reconciliation, live gaps, privacy, rights, and license closure. Measure source-time fidelity, pose and trajectory error where ground truth exists, uncertainty coverage, retarget and end-effector error, contacts, foot skate and penetration, joint limits, continuity and loop seams, constraint adherence, lip synchronization, maximum repair magnitude, semantic and projection validity, target-engine findings, latency, throughput, peak GPU and host memory, queue behavior, cancellation, recovery, and custody. A beauty preview proves none of rig compatibility, source fidelity, contact integrity, engine behavior, or creative acceptance. For armed sources, motion epochs, bounded transport, reconnect, and stop behavior, continue to [Live Kinesis](live-kinesis.md). Finite Kinesis still owns each technical motion derivative; the session supplies its temporal admission and return boundary. --- title: "Live Kinesis" plain_name: "Live motion sessions" section: "Sepulcher > Extensions > Prism" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/prism/live-kinesis/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/prism/live-kinesis/ --- # Live Kinesis (Live motion sessions) ## Plain-English summary (Snayu) **What it is:** The planned bounded session that streams motion from a live source, such as a camera or performance, to one target rig and consumer, exposing latency, gaps and stale output. **Why it matters:** Read this before building real-time avatar or motion streaming features. - Each output binds motion epoch, source cursor, rig digest and deadline so consumers can reject stale motion. - Calibration, sender, rig or unproved reconnect changes start a new epoch. - VMC over OSC is a transport candidate; it provides no authentication or reliable delivery. **Status:** Designed. LiveKinesisSession@2 is not implemented. ## Original text (Hexanomicon) Live motion joins an admitted source epoch to one exact target rig and a bounded consumer. The session must expose latency, gaps, recalibration, stopping, and stale output rather than stretch a finite clip into an endless job. [Kinesis](kinesis.md) retains the technical motion facets and validation used by each admitted segment. `LiveKinesisSession@2` is Designed. [Vision](../../../adr/36-vision.md) owns the accepted contract; [State of Work](../../../state-of-the-work.md#vision-admission) records the absent implementation. Upstream capture and downstream avatar, engine, or physical control remain separately owned. ## Live motion comes later A camera, tracking endpoint, instrument, or microphone is not an infinite `KinesisJob`. The later `LiveKinesisSession@2` consumes exact upstream epochs from `LiveSightSession@1`, Riffmaw `MusicalPerformanceSession@1` and `ClockDomainMap@1`, or a separately armed mocap transport. It inherits no camera, microphone, MIDI, avatar, robot, or world-effect authority. ## Pin the session and preserve its epoch Before arming, pin participants, purpose and consent scopes, exact upstream session or admitted transport references and epochs, calibration and target-rig revisions, requested channels, and clock maps with their uncertainty. Define the armed window, latency, cardinality, compute and cost bounds, bounded queue, sampling, resampling, reorder and drop policy, consumers, retention, and output-segment policy. Each output then binds its motion epoch, source cursor, target-rig digest, and deadline, allowing the consumer to reject stale motion. A calibration, sender, target-rig, or unproved reconnect change rotates the motion epoch. If upstream cannot pause, sampling and drops must expose exact gaps and watermarks rather than hide latency or invent motion. Disconnect preserves acknowledged segments; resuming the same epoch requires proved transport continuity. Otherwise, admit a newly armed forward session. ## Deliver through an admitted transport [VMC](https://protocol.vmc.info/english.html) over [OSC](https://opensoundcontrol.stanford.edu/spec-1_0.html) is a candidate for a later admitted motion-transport or output-projection profile. Its first profile allowlists motion messages; file paths, configuration, MIDI/control, and passthrough messages require separate authorization. Kinesis may consume an admitted transport or create the projection artifact, but sending to or opening a target avatar endpoint belongs to a separately authorized Foundry or avatar adapter. Neither OSC nor VMC supplies application authentication or guaranteed reliable delivery. The profile must bind an admitted sender and network zone, allowlist message addresses, and retain receive time, reorder, and drop facts. If sender or clock continuity cannot be proved, rotate the epoch. [GStreamer](https://gstreamer.freedesktop.org/) may preserve media clocks, PTS, gaps, reorders, and drops as media substrate, not as a Kinesis runtime. Its core is LGPL-2.1-or-later; plug-in and codec licenses remain profile-specific. Checkpoints retain configuration, cursors, exact segment references, and gaps, excluding sockets, device handles, tensors, and unbounded history. Stopping Kinesis establishes neither that upstream capture stopped nor that a downstream avatar stopped moving. ## Earlier Designed revisions `KinesisJob@2` supersedes the Designed-only `KinesisJob@1`: its `synchronize` input names `MusicCueMap@1` rather than reinterpreting `SyncCueMap@1`, and its result settles technical motion without adopting it for an application. `LiveKinesisSession@2` likewise supersedes the Designed-only `LiveKinesisSession@1` because it consumes Riffmaw's narrower `MusicalPerformanceSession@1` rather than reinterpreting `PerformanceSession@1`. Neither older contract was registered or run, so there is no executable migration. --- title: "Echo" plain_name: "Voice: speech in and out" section: "Sepulcher > Extensions > Echo" status: "Partial" original: https://hexanomicon.dev/sepulcher/extensions/echo/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/echo/ --- # Echo (Voice: speech in and out) ## Plain-English summary (Snayu) **What it is:** The speech area (Voice, or Echo) that follows an utterance from visible push-to-talk capture to transcription, an ordinary agent step, optional speech synthesis and observed delivery. **Why it matters:** Read this before adding speech-to-text, text-to-speech or voice features to any app. - First profile: visible push-to-talk, record-and-send; no always-on mic, wake word or full duplex. - Roles: Ear (STT), Voice (TTS), speech-capable model, Listener (capture) and ordinary model. - First local engine: audio.cpp with Parakeet TDT (STT) and Supertonic 3 (TTS), pending a Slovak bake. **Status:** Partial. Engineering probes exist; native Echo admission remains designed. ## Original text (Hexanomicon) > _Between breath and hearing, a voice can vanish._ A spoken answer can be generated yet never heard. **Echo** follows an utterance from deliberately armed capture to transcription, an ordinary Agent step, optional synthesis, and observed delivery. Source, consent, language, interruption, and playback chronology remain attached throughout. The first passage is visible push-to-talk and record-and-send. Audio admission is Partial; a separate local engineering probe exercises speech without native Echo grants or Bridge admission. [State](../../state-of-the-work.md#audio-admission) owns delivery and [Audio](../../adr/37-audio.md) owns the accepted law. ## The resonance path The first profile, record-and-send, carries one utterance through these steps: > visible bounded capture → immutable audio artifact → eligible Ear or audio-capable Mind → > attributed transcript or native observation → ordinary Agent step → optional Voice → delivery > evidence Capture must be visible, bounded, and consented. Large bytes remain outside Graph checkpoints and queues. Three distinctions keep the path honest: - `ArtifactRef` carries metadata and grants no access. The explicit [local custody seam](../../state-of-the-work.md#artifact-reference-contract) can retain supplied WAV bytes and feed Echo's inspector after separate authorization and admission; it captures no recording and supplies no playback or speech path. - Reliquary's accepted design preserves source and derivation; the first local profile retains source bytes and attributed claims, without a derivative graph. A transcript is an attributed interpretation, not a replacement for its recording. - Synthesized audio is a new artifact. Generation proves neither delivery nor playback; receipts must state what actually reached the listener. Later half- and full-duplex profiles must preserve one monotonic speech timeline through barge-in, contested turn ownership, interruption, cancellation, and reconnect. A live socket cannot supply those semantics. A request must first pass audio validation, authority checks, and any remote-egress policy. Failure at one of those gates is a refusal. Waiting is appropriate only after those checks pass: if an otherwise eligible managed provider is not warm, the requesting Run may enter ordinary Graph Stasis while Orchestrator drains and readies the affected Animators. That wait does not let Echo silently select a remote service, infer permanent microphone authority, inflate priority, or revoke another grant or lease. ## The organs of resonance An Echo deployment composes five roles independently. Audio is material, never a capability family. The labels `stt` (speech-to-text), `tts` (text-to-speech), and `chat` below belong to current v1 compatibility; the Designed general-service interfaces define their own request and return contracts. | Role | Place in Echo | | --- | --- | | **Ear** | `echo.transcribe@1` Animator; current v1 projects `stt` | | **Voice (speech)** | `echo.synthesize@1` Animator; current v1 projects `tts` | | **Speech-capable Mind** | Audio-input or audio-output `model.chat@1` provider used under an admitted spoken-utterance contract; current v1 projects `chat` | | **Listener** | Capture, push-to-talk, codecs, and optional voice activity | | **Mind** | Ordinary reasoning provider; there is no separate voice intelligence | Echo's boundary is speech: utterance capture, STT, spoken-output synthesis, delivery, and playback chronology. It does not own music, sung performance, ambience, sound effects, picture/world sound, or generic audio understanding or generation. A model or engine that natively emits audio, video, or both gains no broader Echo authority; every non-speech facet remains with its application and technical effect owner. ## Applications may use speech without owning Echo An application can use a speaking voice while continuing to own the work that voice serves. [Riffmaw](../../compositions/riffmaw/index.md) owns sung and otherwise musical performance; [Language Edition](../../compositions/language-edition/index.md) owns casting, linguistic adaptation, timing, captions, and acceptance for one timed-language edition; [Avatar](../../compositions/avatar/index.md) may reference an exact eligible acoustic voice inside a presentation profile; and [Broadcast](../../compositions/broadcast/index.md) owns canonical source words, editorial relation, and publication. Echo supplies the speech contracts and lifecycle facts each work needs. The application references exact Echo attempts and artifacts, so its account can follow capture, synthesis, delivery, and playback without maintaining a second version of that chronology. ## The Companion device boundary A future [Companion](../../compositions/companion/index.md) client may own device capture and playback controls as Echo's physical speech endpoint. A private [Tether](tether.md) supplies reachability, not caller authority: [Ward](ward.md) still authenticates and authorizes, while capture and consent remain visible. A remote [Portal](../animator/portal.md) additionally requires eligible classification, egress policy, consent where required, and bounded cost. These are laws of the accepted design, not claims of delivered behavior. ## First engine profile The first planned native local profile starts with one inference engine: | Concern | Initial choice | Boundary | | --- | --- | --- | | Engine | [audio.cpp](https://github.com/0xShug0/audio.cpp) | One pinned local runtime; support is family-specific, never arbitrary GGUF execution. | | Ear candidate | Parakeet TDT 0.6B v3 | Multilingual STT candidate whose Slovak path must pass the bake. | | Voice candidate | Supertonic 3 | Multilingual TTS candidate whose Slovak voices and OpenRAIL-M terms must pass the bake. | | Connector | OpenAI audio batch dialect | Bounded transcription and speech routes only; runtime-native extras are not inferred. | | Activation | Visible push-to-talk | No always-on capture and no wake-word dependency. | | Interaction | Record and send | No claim of full-duplex speech or barge-in. | Native admission remains Designed. Separate explicit engineering profiles exercise audio.cpp transcription and synthesis, or independently pinned whisper.cpp transcription with audio.cpp synthesis. [Local qualification](echo-local-probe.md) owns those profiles; [State](../../state-of-the-work.md#audio-admission) owns their measured evidence. They should prove speech-audio-to-text and text-to-speech-audio before exposing audio.cpp speech-voice conversion, cloning, alignment, VAD, diarization, codecs, or pipelines. Those functions become separately declared tool surfaces only after their model, inputs, outputs, custody, authority, and cancellation behavior are baked; the presence of a family in an upstream catalogue grants no LychD capability. One connector may serve several compatible model profiles, but every profile keeps its own model identity, language facts, license, backend, resource measurements, and readiness. A language can be **declared** from upstream metadata without being **verified** by LychD. Routing uses an explicit request first, then ordered Principal or Persona preferences, then admitted detection; missing output-language support refuses rather than silently translating. ## The first bake [Local speech qualification](echo-local-probe.md) bounds the initial engineering probe separately from native Animator and Bridge admission. The smallest honest evaluation fixes one runtime revision and model digest, then records: - cold start, readiness, clean shutdown, cancellation, CPU/GPU placement, RAM/VRAM peak, and isolation from a resident Mind; - transcription accuracy, endpoint truncation, names, numbers, mixed-language speech, confidence, and provenance for each language claimed as verified; - synthesis latency, first audio, intelligibility, pronunciation, numbers, dates, currency, addresses, text normalization, and playback completion for each output locale and voice; - exact OpenAI-compatible fields and errors rather than compatibility by endpoint name; and - license and consent receipts before any voice-reference or cloning experiment. Slovak is the first operator-selected reference bake, not a Core hardcode. Other users may order different input and output preferences, but every routed language owes the same evidence. ## Watched alternatives [Speech provider study](echo-research.md) records the current Slovak, Czech and English candidates, immutable local packages and hosted-dialect differences. The first profile does not implement these paths: | Candidate | Why it remains watched | Promotion condition | | --- | --- | --- | | [NeMo-Speech.cpp](https://github.com/NVIDIA/NeMo-Speech.cpp) | Narrower NVIDIA speech runtime with promising realtime, endpointing, word-timing, and Riva surfaces. | Stable pinned release and dialect, lifecycle and cancellation receipts, and a multilingual realtime bake that materially beats the audio.cpp path. | | [Piper](https://github.com/OHF-Voice/piper1-gpl) | Small CPU TTS fallback with separately licensed voices. | A measured low-resource or recovery need that Supertonic through audio.cpp cannot satisfy, plus runtime and voice-license admission. | | [openWakeWord](https://github.com/dscripka/openWakeWord) | Host-side wake-word candidate, not a speech server. | An authorized phrase/model with acceptable license, reproducible training or acquisition, and measured false-accept and false-reject rates in the target language and environment. | NeMo-Speech.cpp may later reuse the batch connector through an explicit dialect, while its live WebSocket still needs a Resonance Session adapter. Piper and openWakeWord remain candidates rather than speculative runtime dependencies. No watched candidate is an automatic fallback, and no failed local attempt silently changes engine, language, or egress. --- title: "Local speech qualification" plain_name: "Local speech test probe" section: "Sepulcher > Extensions > Echo" status: "Operator validation" original: https://hexanomicon.dev/sepulcher/extensions/echo-local-probe/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/echo-local-probe/ --- # Local speech qualification (Local speech test probe) ## Plain-English summary (Snayu) **What it is:** The engineering probe for testing local speech: audio.cpp with Parakeet and Supertonic, or whisper.cpp for transcription, called over loopback with pinned models, explicit recording and no native LychD integration. **Why it matters:** Read this when running or extending local speech tests, or wiring up microphone capture and playback on Linux. - The probe issues no model pass and does not register Echo or enable Chat audio. - Input is mono 16 kHz 16-bit WAV; microphone capture is explicit, 1-15 seconds, with no automatic retries. - Acceptance needs real startup, synthesis, transcription, refusal, cancellation and Slovak/Czech/English operator tests. **Status:** Operator validation. Probe built; real microphone and language quality checks still need the operator. ## Original text (Hexanomicon) The first qualification uses one pinned audio.cpp runtime with Parakeet TDT 0.6B v3 for transcription and Supertonic 3 for synthesis. Both upstream model profiles declare Slovak, Czech and English. Declared support is not a LychD quality measurement. An explicitly operated engineering probe may call a reviewed literal-loopback batch endpoint with a pinned model profile. It does not issue an Animator grant, register Echo at normal boot, or establish native Bridge audio admission. It must preserve those distinctions in its output. No failed local attempt selects another runtime or a hosted service. The next qualification candidate changes transcription while keeping synthesis explicit: it pairs whisper.cpp multilingual `small` with the existing audio.cpp Supertonic synthesis. To keep the two operations attributable, a version 2 engineering profile binds each separately to its literal-loopback endpoint, runtime revision, dialect, backend, device, and model pin. Version 1 audio.cpp profiles retain their existing schema and digest. The whisper.cpp request declares the input language and asks for JSON transcription output. It supplies no misleading per-request model selector, because that server loads weights at startup. The resulting transcription observation retains its own binding's runtime revision; synthesis retains its separate revision. This establishes a construction contract, not Slovak quality or a delivered native Echo provider. The companion voice entry may remove only outer spaces, tabs and line endings when interpreting a transcript as one strict instruction. It preserves the original attributed transcript; embedded control characters and multiple instructions still refuse. This handles a server's text framing without fuzzy correction of a misrecognized command. ## Probe contract The operator supplies the endpoint, exact runtime revision, model digest and language declaration, and an absolute private workspace outside every checkout. Input recording is an explicit bounded operation; no background listening or wake phrase is admitted. Transcription accepts Echo's canonical mono 16 kHz signed 16-bit WAV subset and verifies the exact source identity before sending. The transcript remains an attributed interpretation with its source and selected model. Language detection never authorizes translation or silently changes the requested output locale. Synthesis accepts bounded text, one declared language and a stock voice, then retains bounded validated WAV bytes with their digest. Cloning and reference voices are outside this probe. Generation and playback are separate observations. No audio bytes enter logs or Graph state; private artifacts and transcripts remain in the explicit workspace. For a real microphone sample, the optional Linux device helper requires an explicit invocation and shows capture visibly. Its fixed sample budget is 1–15 seconds, with a finite acquisition deadline after process adoption; launch adoption and required retirement can outlast that deadline. It requests mono 16 kHz signed 16-bit samples from the system ALSA `default` device and constructs a canonical WAV. That uses the host's configured sound server, including PipeWire. The caller may explicitly choose `pulse` when that ALSA PCM is installed. A failure never changes the device or retries capture. Any device conversion belongs to the capture backend; it is not silent conversion of an already admitted artifact. Before another capture, the helper must prove the old recorder group has retired. A failed capture can then be followed by a fresh explicit gesture, never a replay of the failed occurrence. Unknown launch or retirement keeps further audio closed. Cancellation, including cancellation during final retirement, propagates only after the owned group has been joined; unproved retirement supersedes cancellation with an unsettled outcome. Tests with a substitute recorder cannot qualify the microphone. The separate [Horizon voice entry](../../compositions/blockworld/horizon-assist.md#qualification) can explicitly select finite local playback of its validated generated bytes after capture closes. Its player process-group ownership, cancellation and failure are separate from synthesis. A selected playback uses the system ALSA `default` output; only an explicit supported `pulse` selection requests Pulse directly. Invalid devices refuse before launch, and a failed selection never switches devices or retries. The helper forwards the exact inspected WAV bytes without altering host routing or volume. Independently cancelled retirement is unknown ownership and keeps later audio closed. A successful player exit proves neither human hearing nor a native Echo playback receipt. Ordinary speech-probe commands still only retain generated material. Requests have finite transport and response bounds, no redirects, no ambient proxy or credentials, and no automatic retries. Cancellation stops waiting locally; it must not claim the server's inference stopped unless the exact dialect provides and proves that boundary. Hosted providers require a separately admitted dialect, destination, credential, consent and cost bound. ## Acceptance Qualify the exact binary/model pair with clean startup, readiness, a real synthesis and transcription, bounded malformed-input refusal, cancellation and shutdown. Synthetic round trips test transport and model execution, not microphone recognition or independent intelligibility. The operator's bake includes Slovak and Czech diacritics, English game terms, player names, coordinates, numbers, negation, background game sound and mixed-language utterances. [Echo](echo.md) owns the speech lifecycle and [Audio](../../adr/37-audio.md) its law. [State of Work](../../state-of-the-work.md#audio-admission) owns implementation evidence. --- title: "Speech provider study" plain_name: "Speech provider comparison" section: "Sepulcher > Extensions > Echo" original: https://hexanomicon.dev/sepulcher/extensions/echo-research/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/echo-research/ --- # Speech provider study (Speech provider comparison) ## Plain-English summary (Snayu) **What it is:** A dated study comparing local and hosted speech-to-text and text-to-speech options for Slovak, Czech and English, with pinned versions, licenses and what still needs measuring. **Why it matters:** Read this when choosing or replacing a speech model or considering a paid speech service. - Local picks: Parakeet TDT and Supertonic 3 via audio.cpp; whisper.cpp small is an explicit alternative. - Hosted options (Azure, ElevenLabs, Google) need their own integration; paid use only after matched tests. - Measure intent, numbers and negation separately; round-trip TTS-to-STT tests cannot prove human accuracy. ## Original text (Hexanomicon) This study compares local and hosted candidates for Slovak, Czech and English. The first declarations were checked on 21 October 2026, with the focused additions below checked on 23 October. It is not a language-quality bake or an admitted provider catalogue. [Echo](echo.md) owns selection and [local qualification](echo-local-probe.md) owns the first experiment. ## Local first | Role | Candidate | Language and license facts | Qualification limit | | --- | --- | --- | --- | | STT | [Parakeet TDT 0.6B v3](https://huggingface.co/nvidia/parakeet-tdt-0.6b-v3) through audio.cpp | Declares `sk`, `cs`, `en` among 25 languages; automatic detection; CC BY 4.0 weights. | Names, numbers, short fragments, noise and language switching require independent recordings. | | TTS | [Supertonic 3](https://huggingface.co/Supertone/supertonic-3) through audio.cpp | Declares `sk`, `cs`, `en` among 31 languages; stock `M1`–`M5` and `F1`–`F5` voices; OpenRAIL-M weights. | Original upstream [development and support ended](https://github.com/supertone-oss-archive/supertonic); stock voices still require listening and pronunciation review. | Treat the runtime and weights as separate selections. The runtime uses Apache 2.0, while each model has its own license; running locally does not make those weights unrestricted open source. Neither selected profile requires voice cloning. Another local TTS candidate is [OHF Piper](https://github.com/OHF-Voice/piper1-gpl), whose engine uses GPL-3.0. Its [voice guide](https://github.com/OHF-Voice/piper1-gpl/blob/main/docs/VOICES.md) requires an ONNX model and JSON configuration per voice. Actual [Slovak Lili](https://huggingface.co/rhasspy/piper-voices/blob/main/sk/sk_SK/lili/medium/MODEL_CARD) and [Czech Jirka](https://huggingface.co/rhasspy/piper-voices/blob/main/cs/cs_CZ/jirka/medium/MODEL_CARD) medium cards each declare one speaker and 22,050 Hz. These are separate language assets, not one multilingual preset. This qualification did not install, select, time or listen to these Piper candidates. Both cards label their target datasets CC0 but also declare fine-tuning from US English Lessac medium. Its [card](https://huggingface.co/rhasspy/piper-voices/blob/main/en/en_US/lessac/medium/MODEL_CARD) links [research-use source-data terms](https://www.cstr.ed.ac.uk/projects/blizzard/2013/lessac_blizzard2013/license.html). This study does not resolve the terms' effect on distributed weights or output; repository metadata alone cannot complete that provenance assessment. Engine, target dataset and model lineage remain distinct. The first qualification pins audio.cpp release [`v0.9.2-drama3-base-small`](https://github.com/0xShug0/audio.cpp/releases/tag/v0.9.2-drama3-base-small), commit `507495611b22dc4590e0e5609e05e8096384e33f`. The CPU portable archive has SHA-256 `d5e6110daae50800429680a277b70557d333d552c4a130a8f1d0e56181fa8697`. This permits measuring speech without changing GPU drivers or allocating another GPU runtime. It is not a claim that CPU is the fastest backend. Compatible standalone GGUF packages are pinned to audio-cpp/audio.cpp-gguf revision `beb00ab19f10ca33e8a8983a43410527da3f5601`: | Package | Published bytes | SHA-256 | | --- | ---: | --- | | [Parakeet Q8_0](https://huggingface.co/audio-cpp/audio.cpp-gguf/blob/beb00ab19f10ca33e8a8983a43410527da3f5601/Parakeet-TDT-0.6B-v3-GGUF/parakeet-tdt-0.6b-v3-q8_0.gguf) | 915,735,760 | `6fa498f10f8cb606f041aa9512733cfee842a932359b00b0c45b9b723c4f4f4b` | | [Supertonic original precision](https://huggingface.co/audio-cpp/audio.cpp-gguf/blob/beb00ab19f10ca33e8a8983a43410527da3f5601/Supertonic-3-GGUF/supertonic-3-orig.gguf) | 454,076,228 | `ceede06706a11590dd055220152b44c37a5fb8ac33bb61e19a334e5258901b09` | The [release model specifications](https://github.com/0xShug0/audio.cpp/tree/v0.9.2-drama3-base-small/model_specs) define loaders and embedded assets. A similarly named GGUF for another engine is not interchangeable. The [Parakeet runtime study](https://github.com/0xShug0/audio.cpp/blob/v0.9.2-drama3-base-small/docs/models/parakeet_tdt.md) supplies useful parity and precision evidence, rather than a measurement of this deployment. ## Explicit CPU transcription alternative The second candidate, checked on 22 October 2026, is [whisper.cpp v1.9.5](https://github.com/ggml-org/whisper.cpp/releases/tag/v1.9.5), pinned to `d1be6fde11ac6e0407606b4e42fe72d34add8037`, with multilingual [`ggml-small.bin`](https://huggingface.co/ggerganov/whisper.cpp/blob/80da2d8bfee42b0e836fc3a9890373e5defc00a6/ggml-small.bin). The MIT model is about 488 MB and has SHA-256 `1be3a9b2063867b937e64e2ec7483364a79917e157fa98c5d94b5c1fffea987b`. This is a separate transcription runtime; Supertonic synthesis can retain its existing audio.cpp binding. It is an explicit alternative, not an automatic fallback or a quality promotion. The pinned [server implementation](https://github.com/ggml-org/whisper.cpp/blob/d1be6fde11ac6e0407606b4e42fe72d34add8037/examples/server/server.cpp) accepts multipart `file`, `language` and `response_format=json`. Its startup `--inference-path` can select `/v1/audio/transcriptions`. The model loads at startup; a multipart `model` field does not select weights. The [language table](https://github.com/ggml-org/whisper.cpp/blob/d1be6fde11ac6e0407606b4e42fe72d34add8037/src/whisper.cpp) uses `sk`, `cs` and `en`. The engineering profile requires an explicit declared language rather than relying on the server's default English setting. A CPU build disables accelerator backends and starts with `--no-gpu`; short-command latency still needs local measurement. Use the candidate to run a matched comparison before deciding whether to replace a recognizer. Give both recognizers the same immutable recordings, retain refusals, and test server text framing separately from word recognition. That separates a change in transport formatting from a change in what speech the model recognizes. [State of Work](../../state-of-the-work.md#audio-admission) owns measured delivery and the remaining human checks; this candidate alone cannot justify a global replacement. ## Hosted alternatives | Service | STT | TTS | Integration consequence | | --- | --- | --- | --- | | Azure Speech | [Fast Transcription](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/fast-transcription-create) supports Slovak, Czech and English locales. | [Voice catalogue](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/language-support?tabs=stt) includes `sk-SK-ViktoriaNeural`, `sk-SK-LukasNeural`, `cs-CZ-VlastaNeural`, `cs-CZ-AntoninNeural` and English voices. | Own multipart transcription dialect and [SSML synthesis dialect](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/rest-text-to-speech); select region, locale and voice explicitly. | | ElevenLabs | [`scribe_v2`](https://elevenlabs.io/docs/overview/capabilities/speech-to-text/) declares all three languages with detection or an optional hint. | [`eleven_flash_v2_5`](https://elevenlabs.io/docs/overview/models) declares all three; [TTS request](https://elevenlabs.io/docs/api-reference/text-to-speech/convert) can bind `language_code`. | Distinct STT and voice-ID TTS routes; `language_code` enforcement is unsupported for `eleven_multilingual_v2`. | | Google Cloud Speech-to-Text V2 | [`chirp_3`](https://docs.cloud.google.com/speech-to-text/docs/models/chirp-3) lists `sk-SK` and `cs-CZ` as Preview; selected English locales are GA. Streaming, synchronous and batch recognition are separate methods. | Not evaluated in this study. | Check the exact method, locale and region; transcription coverage does not imply diarization coverage or local weights. | These are candidate dialects, not drop-in substitutes for audio.cpp. Hosted weights and service behavior are provider-managed. A language-identification feature does not by itself promise reliable code switching within one utterance. Vendor accuracy and latency figures do not qualify the target microphone, accent or game environment. The [ElevenLabs model matrix](https://elevenlabs.io/docs/overview/models) distinguishes file `scribe_v2` from `scribe_v2_realtime`; measurements of one do not qualify the other. Flash **v2.5** and Multilingual v2 list Slovak, Czech and English; a similarly named model is not interchangeable. Voice ID, model ID and language enforcement are separate selections. Google describes automatic recognition of the dominant language, while [Azure continuous language identification](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/language-identification) explicitly does not detect word-by-word language changes within one sentence. Neither declaration establishes reliable Slovak/English game-term mixing. Keep single-language, between-utterance switching and within-sentence switching as different tests. Select a paid service only after a matched recording comparison. Check current [Azure region/tier pricing](https://azure.microsoft.com/en-us/pricing/details/speech/) or [ElevenLabs API pricing](https://elevenlabs.io/pricing/api); no fixed cost or free-tier promise is assumed here. Credentials, destination, retention, voice consent and per-attempt cost bounds need their own admission. No purchase or hosted voice transmission is implied by this study. Google's separate [processed-audio pricing](https://cloud.google.com/speech-to-text/pricing) also needs its exact method/SKU and channel accounting; no effective bill is inferred. ## What to measure Interleave Slovak, Czech and English recordings, then include one mixed-language case. Score intent, negation, item identity, count and coordinates separately from punctuation. Include stop, silence, clipped speech, player names and ordinary game noise. A TTS→STT round trip tests execution and transport, while independent human recordings and listener review test different boundaries. An ambiguous transcript must not become an inferred world action. Measure cold and warm latency separately. Keeping the two small local models resident may avoid cold loading during play; thread count, idle unload and GPU placement still need host measurements. Optimize the whole path, including capture duration, Graph scheduling and game response, rather than reporting inference time as microphone-to-action latency. When a command fails, distinguish three stages: the generated voice may pronounce the word poorly, the recognizer may misread it, or a correct transcript may fall outside the companion's declared fixed-word grammar. Preserve the original transcript and refusal so those causes remain investigable; do not map a similar-sounding word to a world action. The current [synthetic command qualification](../../state-of-the-work.md#composition-portfolio-delivery) includes failed SK/CS/EN examples. Its TTS→STT round trips cannot identify one model as the cause or establish human accuracy. The next human comparison should therefore reuse exact recordings across recognizers and exact text across synthesizers. A listener scores pronunciation separately from parsing and local elapsed time. --- title: "Shadow" plain_name: "What-if simulator overview" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/shadow/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/shadow/ --- # Shadow (What-if simulator overview) ## Plain-English summary (Snayu) **What it is:** The planned area (What-if Simulator, or Shadow) for holding isolated candidate possibilities with exact parentage, assumptions and evidence, so a branch is never mistaken for the real world. **Why it matters:** Read this before building branching experiments, alternative-generation or isolated trial workspaces. - Two roles: Dancer generates alternatives; Hunter challenges one candidate. - A branch cannot merge, deploy or promote; real changes go through the normal owner with approval. - Deleting a directory does not clean up processes, leases or credentials; cleanup needs a receipt. **Status:** Designed. No branch, workspace or collapse path ships. ## Original text (Hexanomicon) > _In the shadow of one world, other worlds take form._ A branch can feel like the whole present world: its context, files, tools, traces, and feedback all agree. The Sepulcher sees something narrower—a candidate possibility with pinned parentage and an unspent claim on reality. **Shadow** keeps that distinction inspectable. ## Possibility with lineage Shadow keeps track of possibilities and their parentage as one Extension Domain. Within it, a [**Shadow Realm**](../../../divination/transcendence/invocation.md) holds the speculative state and declared workspace topology of one active branch. That tells the reader which possible world is being explored and where it came from. Changed files are still candidate state; separate owners supply container and executor identity. The branch record pins its base, parentage, assumptions, required state, unknowns, evidence, artifact references, budget, status, and resource owner. [**Vikalpa**](../../../lexicon/inner-tongue.md) is used here as a literary correspondence for a possibility fashioned apart from actuality while it awaits measurement. Its explicit uncertainty and honest handling come from project law, not from the source term. **Phantasma** is Shadow's isolated expansion mode; evaluation remains elsewhere. Shadow is **Designed**; no operational branch, workspace, or collapse path ships. [ADR 31](../../../adr/31-simulation.md) owns the design, and [State of Work](../../../state-of-the-work.md#shadow-simulation) records delivery. ## Choose an office [Dancer](./dancer.md) opens alternatives through a declared [Shadow Lens](../../../adr/20-agents.md#mechanical-cognitive-postures), an operational Posture, without ranking or choosing among them. [Hunter](./hunter.md) reviews one named candidate in a separate Invocation, exposing missing evidence and boundary failures without inventing its replacement. Their attributable handoff preserves lineage, assumptions, challenges, evidence requests, and uncertainty. Spellweaver and Graph own ordering, fan-out, and joins. ## Improve the exploration strategy The designed [strategy contract](../../../adr/31-simulation.md#versioned-exploration-strategy) lets an experiment pin how it chooses branches and stops. Recorded histories can supply a bounded comparison before another material attempt. Follow Drift's [history replay and pilot](../drift/workflow-improvement.md#replay-an-exploration-history) to prepare the evidence and distinguish a replay result from fresh execution. A revised strategy enters later work through its owner; it cannot change the ongoing experiment's pinned procedure. ## Nothing crosses by acclaim When a branch is ready to propose a real change, Shadow may package an inert Vision or Promotion Request with its lineage. The target's ordinary effect owner then checks current state and the required evidence, prepares rollback, obtains Ward and HitL or eligible preauthorization, and applies and verifies the effect. That passage is what lets a possibility affect the world. The branch itself cannot merge, deploy, publish, purchase, restore, or promote. A rank or “winner” inside the experiment remains only a search result. Failed and ineligible branches retain required findings, artifacts, provenance, and residue before cleanup. Branch Reaper names that cleanup discipline and its receipt. Deleting a directory cannot settle processes, leases, credentials, ports, or shared effects. Jujutsu may suit a future tracked-change workspace, but it supplies no execution sandbox. Unsafe execution requires its own admitted boundary. --- title: "Dancer" plain_name: "Alternative generator (Dancer)" section: "Sepulcher > Extensions > Shadow" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/shadow/dancer/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/shadow/dancer/ --- # Dancer (Alternative generator (Dancer)) ## Plain-English summary (Snayu) **What it is:** The planned role (Dancer) that takes one request and opens several alternative approaches under one declared angle, returning each with assumptions, requirements, unknowns and sources, without ranking them. **Why it matters:** Read this when designing brainstorming or option-generation steps in a workflow. - Returns alternatives, assumptions, required_state, unknowns and provenance. - Produces no score, rank, selection or live effect; it does not see siblings' output before the join. - If budget runs out, it reports incomplete expansion instead of quietly picking one. **Status:** Designed. No simulation config, schema or Dancer path ships. ## Original text (Hexanomicon) > _“Open another door, but do not call it the exit.”_ Start with one source Intent and ask what other forms it might take. **Dancer** opens those alternatives under a declared [Shadow Lens](../../../adr/20-agents.md#mechanical-cognitive-postures), an operational Posture. As [Shadow's](./index.md) expansion office, it makes several possibilities legible from the same starting point. Each keeps its assumptions and requirements, and none receives preference merely by being generated. Dancer is **Designed**. No simulation Rune or schema ships, and no Dancer path runs. [State of Work](../../../state-of-the-work.md#shadow-simulation) records delivery, while [ADR 31](../../../adr/31-simulation.md) owns the design. ## One bounded fork A Dancer Invocation receives the source Intent shared by its siblings, one operational Lens, and a pinned base and current Context. The owning [Spellweaver Pattern](../../../adr/28-workflow.md) supplies the containment and effect boundary, budget, branch limit, stop conditions, and expected output shape. The Lens is one angle of examination or variation. It carries no Persona, identity, or permission. A Dancer does not receive sibling output before the declared join, nor does it receive Hunter's review context. Spellweaver owns fan-out, joins, budgets, cancellation, and termination; Shadow owns branch identity and candidate lineage. ## Return attributed alternatives One bounded Invocation returns: - `alternatives`, each with a stable local identity; - `assumptions` for each alternative; - `required_state` each alternative presupposes; - `unknowns` left unresolved; and - `provenance` for every source or observation it uses. Shadow attaches that return to the common Intent and pinned Context. Dancer supplies typed expansion material, not a private reasoning trace. In Shadow’s **Vikalpa** image, each alternative awaits measurement. [Shadow](index.md#possibility-with-lineage) keeps that literary correspondence and **Phantasma**, its isolated expansion mode, distinct from evidence, identity, and execution containment. Dancer may open, combine, reframe, or vary candidate material. It produces no score, rank, pruning decision, certification, promotion, selection, live effect, or proof of novelty. An alternative may be useful, redundant, mistaken, or impossible without changing Dancer's duty to return it honestly. ## Stop before selection When the branch limit, time or token budget, or a declared stop condition is reached, return the expansion actually achieved and identify it as incomplete. Keep every existing alternative attributed, with its unknowns and provenance visible. Selecting the first or cheapest candidate would conceal the missing breadth, so Dancer cannot silently use that as a substitute. A candidate may then enter [Hunter](./hunter.md) through a separate Invocation, undergo deterministic checks, or become a [Drift](../drift/trials.md) trial subject. Those passages may reject every alternative. Dancer neither argues their verdict nor repairs a candidate inside the same expansion context. --- title: "Hunter" plain_name: "Candidate challenger (Hunter)" section: "Sepulcher > Extensions > Shadow" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/shadow/hunter/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/shadow/hunter/ --- # Hunter (Candidate challenger (Hunter)) ## Plain-English summary (Snayu) **What it is:** The planned role (Hunter) that reviews one fixed candidate in a separate run, pointing to unsupported assumptions, missing evidence and rule violations, and naming what observation could settle each. **Why it matters:** Read this when designing critique or red-team review steps in a workflow. - Returns challenges, evidence requests, boundary findings, withhold recommendations and unresolved uncertainty. - Invents no replacement and gives no score, approval or certification. - Stops where evidence or permission ends; lack of challenges does not certify a candidate. **Status:** Designed. No simulation config, schema or Hunter path ships. ## Original text (Hexanomicon) > _Where the tracks end, the Hunter kneels._ An attractive candidate promises a clean result, yet one claimed predicate rests on an unsupported assumption. **Hunter** holds that candidate still, points to the exact gap, and names the observation that could settle it. Hunter is **Designed**. No simulation Rune or schema ships, and no Hunter path runs. [State of Work](../../../state-of-the-work.md#shadow-simulation) records delivery, while [ADR 31](../../../adr/31-simulation.md) owns the design. ## Hold one candidate still Begin with one candidate whose identity can remain fixed throughout review: either a [Dancer](./dancer.md) alternative or another attributed, named candidate. Its envelope gives Hunter the source Intent, lineage, assumptions, required state, and claimed predicates, together with observations, evidence, artifacts, and the owning policy or contract. Those records let a challenge point to a specific claim under a specific boundary. The owning [Spellweaver Pattern](../../../adr/28-workflow.md) declares the operational [Shadow Lens](../../../adr/20-agents.md#mechanical-cognitive-postures), permitted evidence and tool access, review rounds, budget, and stop conditions. A fresh Invocation receives no private Dancer generation context and cannot rewrite sibling history. Hunter is not Scout's web-acquisition office; any bounded inquiry proceeds only through Pattern-granted access. The candidate remains **Vikalpa**, a possibility awaiting measurement. Hunter's attention does not change its standing. ## Return attributed challenges Hunter returns five typed records, with provenance: - `challenges` tied to the candidate and a named assumption or predicate; - `evidence_requests` naming the observation needed; - `boundary_findings` tied to the owning policy or contract; - `withhold_recommendations` identifying where further spend lacks present support; and - unresolved uncertainty the evidence cannot settle. No private reasoning trace or verdict travels with them. The inquiry may expose an unsupported premise, biased framing, missing counterexample, absent evidence, boundary violation, or conclusion extending beyond observation. It may decompose a claim and challenge each dependency. Suspicion alone proves nothing. Hunter invents no replacement, rewrites no Intent, and supplies no score, rank, certification, promotion, capability grant, or consent. Each `withhold_recommendations` item is only input to the Pattern's spend decision; it cannot cancel work or deny spending by itself. ## End at the evidence boundary The review ends where its evidence or permission ends. Missing evidence remains unknown; Hunter cannot widen tool access to settle it. Exhausted rounds, budget, tool access, or a stop condition produce an incomplete review with uncertainty preserved. An extra round is never automatic, and reaching the limit establishes neither rejection nor safety. Review leaves the candidate's identity, provenance, artifacts, and failure evidence intact. Neither an unanswered challenge nor a lack of further challenges certifies it. Findings may return to Spellweaver and its Pattern, enter deterministic checks, become a [Drift](../drift/trials.md) trial subject, or reach the Magus for an owned decision. Repair or renewed expansion requires Dancer or another separate Invocation. The parent [Shadow](./index.md) page places this review passage within the possibility-lineage Domain. --- title: "Mirror" plain_name: "Persona keeper and attribution" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/mirror/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/mirror/ --- # Mirror (Persona keeper and attribution) ## Plain-English summary (Snayu) **What it is:** The planned identity area (Persona Keeper, or Mirror) that records which exact persona version, caller, authority and contributors stand behind each act, and how agents are prepared with that identity. **Why it matters:** Read this before adding personas, agent identity prompts, or attribution of who produced an artifact. - Every Job Request records an exact persona revision or an explicit no-persona choice. - Caller (Principal), producer, agent step, persona and run are distinct names; attribution is not authorization. - Today only a fixed 'The First One' agent and static identity text exist. **Status:** Designed. No revisioned personas or reproducible identity preparation yet. ## Original text (Hexanomicon) A temporary Agent finishes its step; the act outlasts it. **Mirror** keeps the act and its contributors bound to an operative identity, so a later reader can ask who spoke, under whose authority, and through which revision. Every admitted Invocation records an exact Persona revision or an explicit no-Persona choice under [Identity](../../adr/32-identity.md). Mirror remains **Designed**. The fixed `The First One` AgentSpec, static identity instruction, and loopback `magus:*` Sigil demonstrate current Agent and authority plumbing. They do not yet supply revisioned Personas or reproducible hydration; [State](../../state-of-the-work.md#mirror-identity) keeps that delivery boundary. ## The mirror and the Mirror The lowercase [*mirror*](../../lexicon/inner-tongue.md#the-ego) is the contemplative image of mind. Capitalized **Mirror** keeps Persona lineage and attribution in their technical home. ## I. The Answer / Ahaṃkāra [Answer](../lich/answer.md) binds the focal “I.” Answer and [The EGO](../../lexicon/inner-tongue.md#the-ego) develop identity, attachment, and Corruption. Mirror records the exact identity binding through which an act becomes attributable. ## II. The Names in the Glass Begin with the request: the **Principal** initiated or approved it, and the active **Sigil** records the bounded authority. The principal may differ from the human or machine **producer** that contributed the result. Asking for work does not make every contribution one's own. Then identify the performance. The **Agent** is one typed cognitive step; **AgentSpec** defines its executable contract, and **Posture** constrains the particular act. Pattern and Invocation identify the admitted workflow performance; **Run** supplies its durable execution identity. [Agents](../../adr/20-agents.md) owns Agent and Posture semantics; [Spellweaver](../../adr/28-workflow.md) owns Pattern and Invocation law. The [identity distinctions](../../adr/32-identity.md#keep-the-names-apart) keep these bindings exact. An act may also be shaped by a **Persona**: a durable, revisioned voice, commitments, boundaries and orientation. It is neither the caller nor the producer nor the temporary step. Here voice means discourse and manner; acoustic voice, music, timed-language editions and presentation assets retain their separate owners. Eligible identity-scoped memory may enter hydration. ## III. Attribution Without Laundering Follow an artifact through two applications. Its first attribution envelope distinguishes the initiating and approving principals from delegate or actor, Persona, AgentSpec, Posture, Sigil, exact workflow revisions, human and machine producers, sources, tools, and handoffs. When a second application consumes it, the original producer remains on the artifact. The consumer opens its own separately admitted Invocation and binding. Selection cannot rewrite origin: human edits and rejected branches retain their authorship as well. A **spotless** Mirror keeps provenance clear enough to show the stain: exact origins and revisions, ruptures, contradictions, corrections, and rejected branches remain visible. Clarity never requires erasing a difficult part of the lineage. Attribution alone establishes no authorization, truth, quality, credit, or fault. [Ward](./ward.md) owns authentication and authorization; [Drift](./drift/index.md) supplies evaluated findings. Identity continuity rests on exact revision lineage and reproducible binding. An enduring process, generic workflow continuity, memory, resemblance, or a reputation for trust cannot substitute for them. ## IV. Summoning and Hydration To prepare an Agent, hydration takes the Persona revision pinned by the admitted Pattern—or its explicit no-Persona choice—and combines it with Pattern and AgentSpec requirements, active Principal and Sigil, and eligible identity-scoped memory. It produces ordered identity Context within bounds and a receipt recording that construction. Fresh and resumed Agents keep the pinned revision. Resemblance to yesterday's voice cannot supply the missing binding. --- title: "Toll" plain_name: "Payments and service credits" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/toll/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/toll/ --- # Toll (Payments and service credits) ## Plain-English summary (Snayu) **What it is:** The planned optional economics area (Toll) for paying for remote work: quotes, reservations, authorization, a single-signature settlement gate, delivery, refunds and reconciliation, plus local MANA service credits. **Why it matters:** Read this before adding any paid API, HTTP 402 handling, credits or wallet-related feature. - A 402, invoice or quote is an untrusted proposal; agents and the Traffic Controller never get wallet authority. - MANA is a single-issuer service balance, not cash or crypto, with no transfers or redemption. - Unknown settlement triggers reconciliation, never another signature; database restores cannot rewind money. **Status:** Designed. No payment machinery or safe 402 handler ships. ## Original text (Hexanomicon) > _The coin leaves the hand. Its shadow stays in the ledger._ **Toll** is LychD's optional economics Extension Domain for priced remote labor. It is **Designed**: no payment machinery or safe HTTP `402` handler ships. [State of Work](../../state-of-the-work.md#x402-payments) owns delivery; [ADR 41](../../adr/41-x402.md) owns the law. An HTTP `402`, invoice, or quote is an untrusted proposal. It carries no authority to sign, settle, retry, identify a caller, grant access, or enlarge a budget. Toll admits no global system-wallet middleware that pays the challenge and retries. Neither Agent nor Dispatcher receives wallet or signing authority. ## First road, later rails Choose a supported purchase method from the vendor's offer. That vendor owns the accepted currencies and arranges any conversion and payouts with its payment provider; LychD does not automatically exchange currencies or clear balances between vendors. Joining the network or casting requires no common coin or token allocation. Toll still checks the exact charge and spending authority and accounts for funding, delivery, and refunds. The first planned Toll path keeps the balance with its issuer. An operator may manually grant **MANA** service credits, later fund an exact balance through one conventional processor, or charge one bounded request as pay-as-you-go. MANA belongs to one account in one issuer's Counting House. It is a service balance, not cash or cryptocurrency: the initial profile permits no other issuer to accept or spend it, and provides no peer transfer, cash redemption, or cross-issuer conversion. Tithe meters model-token and resource consumption; the Counting House separately reserves, debits, credits, releases, refunds, and reconciles MANA. A purchased balance remains the issuing operator's service obligation. Spending it still requires the same authenticated Principal, eligible task, budget authority, idempotency, and delivery accounting as an external payment. Only the authorized issuer boundary may issue, expire, or correct MANA; an Agent, model, or ordinary tool cannot. The ledger appends the authority and grant reason or independently verified funding identity for every entry, uses compensating corrections instead of rewriting history, and prevents reservation from making available balance negative. A webhook, client-supplied receipt, pending authorization, or ambiguous settlement cannot fund spendable MANA. The two practical flows remain distinct: ```text MANA → quote → reserve local balance → execute → debit / release / refund → reconcile PAYG → quote → reserve budget → authorize → Irreversible Gate → settle → execute → reconcile ``` Conventional pay-as-you-go, x402, and any later crypto scheme are distinct settlement adapters over the same quote, reservation, authorization, delivery, refund, and reconciliation law. x402 is not a currency. The first delivered adapter need not use it, and selecting it later does not imply a project-native token or chain. ## One external paid request A destination-pinned connector produces a candidate request and quote. Execution-road policy considers quotes among roads that satisfy capability, privacy, policy, and resource eligibility. Toll judges their economic terms and reserves the exposure; [Dispatcher](../../adr/22-dispatcher.md) binds an already eligible capability without ranking prices. Accounting for the obligation and moving the money then belong to separate offices. For Intercom, casting work and teaching a missing Spell are different purchased resources. Each needs its own exact quote, content identity, budget reservation, consent or standing authority, idempotency key, delivery condition, and reconciliation. Payment for one never buys or retries the other. Before money can move, the **Counting House** parses a supported versioned quote in integer units, accounts for its cost, and reserves the worst-case exposure. The Counting House also reconciles the external payment receipts. It holds no spend key. Its reservation ties the purchase to an authenticated Principal and budget owner, trusted merchant or service, exact method and canonical destination, request-body digest and purchased resource, asset and network, maximum amount including fees, expiry, redirect policy, and idempotency key. This complete account is what later authorization must cover. Unknown versions, schemes, networks, merchants, destinations, amounts, or fee bounds refuse, as do changed terms and expired authority. Policy rejects the request, applies one explicitly bounded low-risk standing authority, or parks the Run for live consent to the exact terms. Significant or novel spend requires [HitL](../../adr/25-hitl.md). Approval covers the stated maximum, never a later challenge. The Magus administers policy without exemption from signer or key safety. The **Irreversible Gate** performs the separately authorized settlement. It has no model or general tool surface. It checks the pinned authorization, live reservation, and caps again, atomically consumes the reservation, signs and submits the one named settlement at most once, and records its external-effect identity. Only after that settlement may the original Connector make at most one proof-bearing replay to the same destination. This replay cannot start another payment. Reconciliation must still establish whether the paid request produced useful delivery. ## What settlement cannot buy **Tithe** accounts currency-neutral model-token usage, generated media, concurrency, queue weight, and hardware time against a stable Principal or service grant, including when every payment adapter is disabled. Money or a receipt cannot mint or widen a Sigil or [Ward](ward.md) authority, expose memory or tools, bypass consent, or displace protected local work. A purchased grant exists only at the intersection of settlement evidence, Ward policy, capability policy, and available resources. Currency-free [Legion](legion.md) work still needs quotas, reservations, attribution, and evidence. Settlement cannot authenticate a peer, make an unknown Spell compatible, admit a teaching bundle, publish an implementation, activate a catalogue generation, or resume the refused Invocation. It may satisfy only the economic condition of an otherwise eligible act. Payment and delivery are not atomic. Settlement may yield no useful artifact; apparent success may be false or unusable. Refund, credit, dispute, expiry, paid-but-undelivered, and ambiguous outcomes remain explicit durable states. ## What survives uncertainty and restore Quote, reservation, authorization, submission, settlement, delivery, refund, expiry, and uncertainty form a durable idempotent chain. An unknown settlement triggers investigation and reconciliation, never another signature. Local rollback or a database restore cannot rewind money; spending stays closed until external state is reconciled. [Oculus](oculus.md) receives redacted observations, never ledger authority. Keys, signatures, bearer proofs, preimages, invoices, and unrestricted wallet credentials stay outside prompts, Codex values, logs, traces, and artifacts. Protocols and settlement rails are adapters around this law, never rival ledgers. The first implementation may remain local; every external adapter must pin one exact provider or protocol profile and conformance corpus. x402 and crypto rails are later options, not first-delivery requirements. A shared asset, validator network, or sovereign chain requires a later amendment to [ADR 41](../../adr/41-x402.md#deferred-shared-and-sovereign-settlement) and every affected Covenant rather than silently entering as an adapter. --- title: "Legion" plain_name: "Multi-machine work distribution" section: "Sepulcher > Extensions" status: "Designed" original: https://hexanomicon.dev/sepulcher/extensions/legion/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/legion/ --- # Legion (Multi-machine work distribution) ## Plain-English summary (Snayu) **What it is:** The planned area (Legion) for spreading work across several machines owned by the same operator, where each node agent keeps final say over its own hardware and can refuse. **Why it matters:** Read this before designing multi-node or multi-GPU-host setups for one LychD installation. - The main instance keeps policy, memory and workflows; nodes get no master badge or shared database. - Delegation names a capability and outcome, never shell, Podman or GPU commands; delivery is at least once. - Epoch and fence checks make stale messages harmless; nodes only use artifacts already present by digest. **Status:** Designed. No operational node path is delivered. ## Original text (Hexanomicon) > _One Will may summon many hands._ **Legion** is the distributed-embodiment Extension Domain for operator-owned compute nodes. It lets one Magus place bounded work across owned iron while every destination remains the sole authority over its own hardware. Legion is **Designed**; no operational node path is delivered. [State of Work](../../state-of-the-work.md#legion-federation) records that boundary, and [ADR 42 — Multinode](../../adr/42-multinode.md) owns the accepted design below. ## One continuity, sovereign bodies An enrolled body is a **Legionnaire** in mythic language and a **Node Agent** in engineering. Legion extends one Magus; it neither creates a second Master nor describes the **[Necropolis](../../adr/26-a2a.md#legion-and-necropolis)** relation among foreign sovereign peers. The Master keeps the work's logical continuity: principals, policy, consent, sessions, memory, Graph, routing, and delegation ledger. The node decides what may happen on its hardware. It observes, admits, reserves, actuates, recovers, and can refuse. A Node Agent carries an immutable `node_id`, a rotating node-scoped credential, and a small crash-safe journal. This gives it its own accountable boundary rather than a copy of the Master. It receives no Master Sigil and shares none of the Master's database, queue, filesystem, or infrastructure control plane. ## Delegation through Intercom Legion uses an owned-node profile over the future [Intercom](../../adr/26-a2a.md). A node-initiated authenticated channel may avoid a public listener. Transport identity supplies evidence to Ward; application permission is still a separate decision. Delegation names a typed capability and expected outcome under declared constraints. It never prescribes shell commands, Systemd or Podman operations, GPU ordinals, filesystem mutations, database access, or Reactor instructions. The node chooses how to satisfy the request—or declines it. Delivery is at least once. Both sides therefore persist and deduplicate tasks and results, bind consequential work to stable task and effect identities, and preserve explicit ambiguous outcomes. Silence or a late result cannot authorize blind repetition of an external effect. ## The body decides what fits A resource advertisement is an expiring scheduling hint, not a promise. Acceptance depends on a fresh coherent local snapshot, compatibility and safety checks, and a fenced reservation. Only that reservation may enter local admission closure, lease drain, actuation, readiness, compensation, and containment. After a decline, the Master may seek another eligible body. It cannot override a fresh refusal from the machine that would bear the work. ## Fences against ghosts Consequential messages bind Master epoch, node boot/session, delegation attempt/fence, reservation generation, and transition precondition. Stale messages remain evidence but cannot act. If the connection breaks, local policy may let already admitted bounded work finish and spool its result. A superseded fence makes that result inadmissible. If the Master is restored, close fleet admission, advance its epoch, and reconcile signed node receipts before resuming delegation. Reconnection restores communication; it cannot by itself settle what happened while the accounts were apart. ## Evidence and artifacts Node evidence is bounded, signed, versioned, freshness-visible, and attributable. [Oculus](oculus.md) may project it, but only fresh node-local evidence, a local reservation, and actuator preconditions may authorize physical work. A signature attributes bytes; it does not make them safe or true. Results and artifacts remain typed and quarantined until their own checks pass. The first Legion profile admits only artifacts already present under exact content digests. Missing material makes placement infeasible—never an implicit URL or Master-path fetch, download, or Portal fallback. Later transfer requires separately admitted, content-addressed, bounded, policy- and integrity-checked custody with atomic publication and corruption quarantine. The [Multinode Covenant](../../adr/42-multinode.md) owns the mechanics. --- title: "ExLlamaV3 engine route moved" section: "Sepulcher > Animator > Soulstone" original: https://hexanomicon.dev/sepulcher/animator/soulstone/exllamav3/ guide: https://lychd.snayu.ai/docs/sepulcher/animator/soulstone/exllamav3/ --- # ExLlamaV3 engine route moved The engine-specific ExLlamaV3 through TabbyAPI contract now lives at [Soulstone Engines → ExLlamaV3](engines/exllamav3.md). This page remains as a compatibility route for existing links. --- title: "Extension authoring" section: "Sepulcher > Extensions" original: https://hexanomicon.dev/sepulcher/extensions/authoring/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/authoring/ --- # Extension authoring Phoenix is an optional built-in extension that registers typed configuration and contributes a container definition to Transmutation. Follow it from selection through registration, Rune loading, Quadlet projection, and tests to learn where a contribution belongs and what evidence a change needs. The [extension index](index.md) maps the Extension Domains. [ADR 05](../../adr/05-extensions.md) owns admission and compatibility; [ADR 12](../../adr/12-configuration.md) owns configuration. This guide follows one package through those contracts. First follow the contribution guide's [Setup and Commands](https://github.com/hexanomicon/lychd/blob/main/CONTRIBUTING.md#setup-and-commands), then run this focused test selection from the checkout: ```sh make test PYTEST_TARGETS="tests/integration/test_extension_configuration.py tests/unit/extensions" N=0 ``` The configuration integration test creates its own temporary Codex and Crypt directories and runs separate Python interpreters. The snippets below explain that fixture's selection, configuration, and projection path. In an installation, `lychd.toml` and Rune documents live beneath the operator's Codex; [Codex](../codex.md) owns that operating workflow. ## Select and register Phoenix In the test's temporary Codex, `lychd.toml` selects Phoenix with: ```toml [extensions] builtins = ["observability/phoenix"] crypt = [] ``` Both selections default to empty. A built-in must have an explicit entry in the [catalogue](https://github.com/hexanomicon/lychd/blob/main/src/lychd/extensions/builtin/catalog.py); adding a directory alone does not make it selectable. Read Phoenix's [registration shim](https://github.com/hexanomicon/lychd/blob/main/src/lychd/extensions/builtin/observability/phoenix/register.py). Its synchronous `register(context: ExtensionRegistrationContext) -> None` hook lazily imports `ObservabilityConfig`, `PhoenixSettings`, and `PhoenixQuadletContributor`, then registers them: ```python context.runes.add_schema(ObservabilityConfig) context.runes.add_schema(PhoenixSettings) context.transmutation.add_contributor(PhoenixQuadletContributor()) ``` After registration, the host marks these contributions with `builtin:observability/phoenix`. This Registrant identity lets a reader trace them back to the selected package while each receiving store enforces its own contract. Selection makes Phoenix available during assembly. An active Rune is still needed before it contributes a container. ## Give the contribution a typed Rune Phoenix's [configuration module](https://github.com/hexanomicon/lychd/blob/main/src/lychd/extensions/builtin/observability/phoenix/config.py) defines a branch and a leaf. `ObservabilityConfig` has `path_fragment = Path("observability")`; `PhoenixSettings` adds `Path("phoenix")`, producing the relative path `observability/phoenix`. The branch cannot own TOML; the leaf can. A Rune is a frozen, validated top-level TOML instance. The fixture writes its active document at `/runes/observability/phoenix/desk.toml`. This example shows the same configuration shape with the default image: ```toml name = "desk-eye" ui_port = 16006 otlp_port = 14317 [quadlet] image = "docker.io/arize-ai/phoenix:latest" ``` `PhoenixSettings` rejects unknown fields and validates `name` as a safe service identity. The example overrides the default name and ports; its image line repeats the typed Quadlet setting's default. It is a configuration example, with no image pull or live-service receipt. The loader derives `source_file` from the document's path; do not put that field in TOML. The schema also supplies a `sample_template`. Its rendered sample is inactive, identified by the exact first nonempty line: ```toml # lychd: sample-rune ``` Activation requires a configured document with that marker removed. A selected Phoenix package with an absent or marked sample Rune still produces no Phoenix container. [Codex](../codex.md) owns Rune and binding operations. ## Follow the Rune into Quadlet data Read the [Phoenix contributor](https://github.com/hexanomicon/lychd/blob/main/src/lychd/extensions/builtin/observability/phoenix/contributor.py) next. It requests `ctx.runes.one_or_none(PhoenixSettings)`. No instance produces an empty contribution; more than one raises an error. With exactly one active instance, the contributor creates typed `QuadletContribution` data for one Phoenix container and two pod ports. Trace each value to its source: the Rune supplies service name, image, and host ports; Settings supplies the database user and Phoenix secret reference. The container includes migration-gate dependencies, and Transmuter places the host ports on loopback. This output is projection data. The [binding workflow](../codex.md#the-rite-of-binding) separately owns publication and host reconciliation. Follow [External Eyes](oculus.md#external-eyes) for Phoenix's observability boundary: this example establishes neither a running Phoenix service nor an application telemetry export path. Phoenix contributes no Animator runtime or CallGrant service. ## Test the complete configuration path The [configuration integration test](https://github.com/hexanomicon/lychd/blob/main/tests/integration/test_extension_configuration.py) follows the real Settings, extension manager, Rune loader, and Transmuter across separate Python interpreters. Its assertions cover: - Default-disabled selection leaves the Phoenix shim unimported. - Selected Phoenix with an inactive sample has the exact schemas, contributor, and provenance. - An active Rune is frozen, retains its exact `source_file`, and projects its configured service name, image, ports, and Settings-owned database values. - Editing the Settings file leaves the current process's cached generation unchanged. - A fresh disabled process produces no Phoenix contribution while the Rune and representative retained data bytes survive. - An unselected Crypt shim that would fail if imported remains unimported. The fixture writes TOML directly. It does not execute the writer's Linux journaled inscription, bind units, or prove database recovery. Detailed registration collisions and import failures belong to the [admission tests](https://github.com/hexanomicon/lychd/blob/main/tests/unit/extensions/test_admission.py). For a contribution that supplies an Animator, the [Crypt vertical test](https://github.com/hexanomicon/lychd/blob/main/tests/integration/test_crypt_extension_vertical.py) continues through its separate adapter and Dispatcher contracts. ## Apply the registration contract in Crypt A private package is selected explicitly: ```toml [extensions] builtins = [] crypt = ["my-private-organ"] ``` Its exact shim is `PATH_EXTENSIONS_DIR/my-private-organ/register.py`; [Crypt](../crypt.md) explains the source location. An activation ID must be canonical and POSIX-relative, without traversal or aliases. The manager resolves only the selected `register.py`, with no environment or entry-point scan. The shim uses the same synchronous `register(context)` contract and returns `None`. It may import relative siblings within its synthetic package namespace; adjacent unselected packages remain unimported. Crypt code is trusted, runs in process, and shares memory. This pre-v1 path accepts coupling to internal refactors. Built-ins release with Core; a versioned independent extension API remains future work under [ADR 05](../../adr/05-extensions.md#7-extension-compatibility-tiers). ## Finish a bounded contribution Finish by testing a new process generation. `get_settings()` and `get_extensions()` retain the current generation, and registration stores seal after assembly; edits to code, dependencies, contribution contracts, or selection require restart or replacement. Removing Phoenix's selector in the new process removes its contribution while leaving retained Runes and storage alone. This guide does not implement installation, uninstallation, rollback, or automated Evolution. [State of Work](../../state-of-the-work.md#extension-activation-contributions) records delivery. Change the owned schema, registration, or contributor together with a test of the affected behavior, then rerun the focused selection above. Follow the [contribution quality checks](https://github.com/hexanomicon/lychd/blob/main/CONTRIBUTING.md#quality-checks) for the applicable lint, format, type, and repository gates. Describe the boundary the change establishes and the evidence that supports it. Follow the [current collaboration phase](https://github.com/hexanomicon/lychd/blob/main/CONTRIBUTING.md#branches-and-everyday-collaboration) for branch and submission procedure. --- title: "Scout source acquisition study" section: "Sepulcher > Extensions" original: https://hexanomicon.dev/sepulcher/extensions/scout-web-research/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/scout-web-research/ --- # Scout source acquisition study **Maturity: candidate study, reviewed 18 October 2026.** This study selects the next experiment; the separately qualified RSS extractor is recorded in State. Native feed acquisition/workflow, monitoring and standing authority remain outside this study. [Scout](scout.md), [ADR 30](../../adr/30-webcrawler.md) and [State](../../state-of-the-work.md#scout-web-acquisition) retain those boundaries. ## Choose the source surface before adding a service | Need | Smallest useful path | Current boundary | | --- | --- | --- | | Understand one known public page | Existing static HTTPS Fetch and isolated HTML/text Extract | Opt-in public-page workflow; actual host/profile qualification remains necessary | | Observe recent Bazoš listings | One advertised category RSS feed, then local extraction/filtering | The selected finite Scavenger application and its dated public-native observations are recorded in State; recurring watching remains unfinished | | Discover sources across the web | SearXNG, one qualified engine and one result page | No admitted engine, Rune or adapter ships; upstream-request mediation remains a prerequisite | | Read a page whose useful content requires JavaScript | Separately admitted Fetch + Render + Extract | Crawl4AI remains a later isolated candidate, not an automatic fallback | Choose the path by the observation the application needs. A known Bazoš feed can supply a finite listing observation without first building general Search. Search can discover other sources, and rendering can make a particular JavaScript page readable, but each adds a separate contact and qualification problem. Progress on the feed therefore neither waits for nor demonstrates Search or Crawl. ## What the live source established On 18 October 2026, one bounded read of the public [PC category](https://pc.bazos.sk/) returned HTTP 200 and 45,992 bytes of UTF-8 HTML. Its own navigation advertised [the PC RSS feed](https://www.bazos.sk/rss.php?rub=pc). A separate single read of that exact feed returned HTTP 200, `text/xml; charset=utf-8`, and 33,385 bytes. These are dated research observations, not a maintained deployment receipt or a compatibility promise. The [category robots](https://pc.bazos.sk/robots.txt) and [main-host robots](https://www.bazos.sk/robots.txt) then disallowed search/filter URL patterns including `hledat`, location and price parameters. The category root and advertised PC feed were not excluded by their default rules. Recheck the exact host and locator before an admitted contact; a linked URL or historical robots observation is not an effect grant. Do not substitute filtered search URLs, mobile identities, extra pages or another endpoint after refusal. The existing fixed Scout extractor processed the acquired category HTML in its isolated, network-denied child and returned 11,461 bytes of text; the child was reaped. Supplying the RSS response under its actual `text/xml` type correctly refused before child launch. This separates the dated useful HTML path from the then-missing XML path. The later separate RSS profile now extracts bounded RSS 2.0; this did not widen that old header or the public-page workflow. Recasting XML as HTML, ignoring the media check or running a second parser inside Core would conceal that gap. The current HTML strategy deliberately drops attributes, including link targets. Its text projection can support a bounded page answer; it is not already a structured listing catalogue. ## What other projects contribute The [Bazoš dataset project](https://github.com/kukas/bazos_dataset) publishes a [feed-based scraper](https://github.com/kukas/bazos_dataset/blob/main/bazos_scraper.py). The useful pattern is to read category feeds, retain source identity and observation time, and compare entries locally. Its historical Czech dataset does not establish current Slovak coverage, and its repeated polling or retry behavior does not supply LychD authority. The [Bazoš MCP client](https://github.com/andrijdavid/bazos-mcp/blob/main/src/bazos-client.ts) uses a different API path with a generated device identifier and User-Agent. This is comparison material, not the selected acquisition mechanism. No upstream scraper, MCP server, credential store, retry policy or implementation is incorporated by this study. The official [SearXNG Search API](https://docs.searxng.org/dev/search_api.html) supports form POST and explicitly enabled JSON output; public instances can disable it. Its query still reaches external engines. LychD's selected design therefore needs more than an HTTP JSON wrapper: one qualified engine, a restricted query dialect, immutable configuration and the exact pre-transmission transport gate in ADR 30. Do not count installing a stock container as that proof. ## Feed experiment: one feed, one attributed digest The advertised PC RSS feed supplied the finite experiment below. The selected Scavenger application and dated ordinary-native observations now have their evidence in [State](../../state-of-the-work.md#scout-web-acquisition). Its title/link-only consumer contract belongs to [Market](../../compositions/scavenger/market.md#finite-feed-observation), including permanent allowance, custody and deletion. The baseline below explains the experiment; it does not widen the old static profiles or replace that selected consumer contract. The experiment's acceptance baseline is: - One exact host-admitted locator and finite Fetch/Extract ceilings, no pagination, subresource, redirect discovery, retry, browser, paid service or publisher contact. - Parsing in the existing kind of isolated child, with construction-time element/depth limits, bounded item/field/output counts and existing hard time/resource ceilings. DTDs, external entities, entity expansion, malformed XML, over-limit and truncated input must refuse. - Extractor-level plain title/summary plus original item locator, publisher identifier/date as claims, source attribution, observation time and declared omissions. The selected Scavenger consumer discards summaries and publisher identifiers/dates, retaining title/link and necessary attribution only. No source-authored markup or instructions gain authority. Returned links are data; contacting one needs a fresh destination/effect decision. - Independent ordinary and hostile fixtures sealed before a constructor candidate. Then qualify the actual transport/child combination and current native admission path, retaining refusals and observed cleanup. A synthetic parser test alone cannot qualify live acquisition. - Local deduplication and filtering over the admitted observations, with honest coverage. No match means no match in that finite response; it never means no matching listing exists on Bazoš. The consuming application owns suitability criteria and any proposed consequence. Begin by returning an attributed digest without a model, and measure that result against the baseline above. It gives model ranking, semantic extraction, or a browser a concrete result to improve on. Even then, a price parsed from source prose is a derived claim: the observation establishes neither current availability nor seller trust. Repeated watching is a later application policy: explicit purpose, exact feed, cadence, finite contact/retention budget, revocation and uncertain-attempt reconciliation. Each poll needs current admission; an idle loop cannot manufacture a new allowance. Retaining prior entries or bodies needs the ordinary custody owner, not a private cache hidden in an Agent's history. The selected Altar presents source/time, coverage, whole-field counts, local filters and distinct new-observation/deletion actions. State records the separate synthetic-browser, native API and [dated authenticated retained-field browser evidence](../../state-of-the-work.md#scout-web-acquisition). That finite functional observation does not establish a persistent deployment or hostile-browser safety. A new fetch and a local re-filter must remain distinguishable. ## SearXNG transport cut — 18 October 2026 The reviewed upstream source is pinned to [`1c10abe2d`](https://github.com/searxng/searxng/commit/1c10abe2d3e4ab7ddcc4e9da1a7d07dc7ca7f8f4). Its online processor separates engine request preparation, network exchange and response parsing. The lower [`Network.call_client`](https://github.com/searxng/searxng/blob/1c10abe2d3e4ab7ddcc4e9da1a7d07dc7ca7f8f4/searx/network/network.py#L271) still retries the first connection error without decrementing its retry counter. In a dated offline reproduction of that exact method, `retries=0` plus a controlled disconnect followed by success causes two client acquisitions and two request calls. Separate controls cover repeated connection errors, immediate success and a different request exception. No network occurred. A private, separately licensed service prototype replaces that direct path before client acquisition and refuses `get_client` itself. Its actual patched method ASTs and coroutine hook pass six offline cases: absent context, streaming refusal, one-use success, terminal failure, consumption before a suspended/cancelled call, and direct-client refusal. A narrow independent static review found no P1/P2 defect within that declared scope. The [dated observation](https://github.com/hexanomicon/lychd/blob/main/tests/fixtures/scout/searxng-transport-cut-2026-10-18.json) records exact source, patch, script and result hashes. The prototype is outside Core and is not an installed service, authenticated channel, host grant or containment boundary. Engine eligibility also needs source inspection. At this same pin, [`mojeek.request`](https://github.com/searxng/searxng/blob/1c10abe2d3e4ab7ddcc4e9da1a7d07dc7ca7f8f4/searx/engines/mojeek.py#L102) obtains a CAPTCHA-derived cookie through auxiliary challenge/verification calls when uncached. That flow is outside the first proposed public-search passage; no challenge was executed. The [`DuckDuckGo HTML module`](https://github.com/searxng/searxng/blob/1c10abe2d3e4ab7ddcc4e9da1a7d07dc7ca7f8f4/searx/engines/duckduckgo.py#L362) is only a candidate: first-page preparation uses a form POST, and its response parser raises on a CAPTCHA but returns empty results for HTTP303. The trusted bridge must therefore reject a redirect before parser invocation rather than record a clean miss. Regional/time filters can add cookies, and debug diagnostics include query-bearing data. No live engine or parser qualification follows from reading those functions. To turn the prototype into an implementation, preserve the transport cut and connect it to host authority. That requires a typed, authenticated request/response channel, host-authored final bytes, Search-specific preparation, current disclosure admission, and independent denial of direct service egress. Existing native Scout authority admits only fixed page/RSS FETCH claims; changing their label cannot authorize Search. Then constrain and qualify the actual request and response path: use the pinned SearXNG parser to refuse engine/language/category/timeout/bang/lucky directives, qualify one exact engine and response wrapper, and retain query-bearing diagnostics as restricted evidence. The [accepted Search contract](../../adr/30-webcrawler.md#searxng-search-contract) owns these requirements. Neither a working JSON endpoint nor this offline prototype delivers Search, and neither can reset the retained feed's spent budget. ## Full service fixture: context must cross the dispatcher A separate [dated local observation](https://github.com/hexanomicon/lychd/blob/main/tests/fixtures/scout/searxng-service-fixture-2026-10-18.json) now exercises the complete pinned upstream web application, not just its processor. Every case actually checks authentication and invalid method/input refusals before accepting one fixed query. The original dispatcher loses the host-exchange context: the baseline refuses before exchange or parser invocation. A narrow `copy_context` prototype crosses the real dispatch thread and asyncio loop, sends one host-sealed POST through pinned TLS to an isolated fixture, and returns two exact ordered title/snippet/locator observations through the real DuckDuckGo parser and JSON encoder. A separately admitted HTTP 303 response refuses before parsing and causes no follow-up request. Bootstrap requires the complete pinned defaults, removal of every default engine before adding the sole selected engine, explicit empty plugin replacement and an actual Preferences check before readiness. Earlier unsupported-CLI and incomplete-default attempts remain failed. All three later cases have independent process/thread, unit, cgroup, socket and key closure. Actual stderr still reports favicon, limiter and Unix-socket/IP diagnostics; no source IP is invented. The narrow entropy-device bind permits read and write, although the experiment writes no device bytes. IPv6 and persistent service reuse remain unqualified. This privately isolated prototype is not shipped Core code, a live-engine receipt or native Search. Production still needs Search-specific preparation and current disclosure/final-byte admission, a receiving normalizer, admitted lifecycle and a permanent allowance transition that preserves old counters and unknown reservations. A fresh database cannot manufacture a reset for an already admitted host. The existing finite RSS route remains independently useful for Bazoš; it does not need this service. --- title: "Coding-runtime research" section: "Sepulcher > Extensions > Spellweaver" original: https://hexanomicon.dev/sepulcher/extensions/weaver/coding-runtime-research/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/coding-runtime-research/ --- # Coding-runtime research This research was checked **15 October 2026** against the primary sources below. It informs [Development bootstrap](development-bootstrap.md), while account entitlement and LychD implementation still need their own evidence. Recheck provider behavior before purchase, authentication integration, or runtime qualification. The Covenants retain architecture authority and [State of Work](../../../state-of-the-work.md) retains delivery authority. ## Recommended road and alternatives Use the existing Codex application and requested Sol setting for the first bounded campaign. Qualify the existing serial CLI protocol behind a trusted LychD host before adding a product-facing app-server integration. Compare another reviewer on frozen cases before buying ongoing capacity. This recommendation fits the present bootstrap constraints; no benchmark establishes a universally best agent stack. | Road | What the primary source establishes | Bootstrap decision | | --- | --- | --- | | Codex app with a goal | A durable objective continues across turns toward a verifiable stopping condition. [Goal guide](https://learn.chatgpt.com/docs/use-cases/follow-goals). | Start here. | | Codex `exec` | Noninteractive jobs, JSONL events, output schemas, explicit sandbox settings and saved CLI authentication. [Guide](https://learn.chatgpt.com/docs/non-interactive-mode). | Smallest first foreign-runtime job. | | Codex SDK | Programmatic Codex threads and streaming through official TypeScript and Python surfaces. [SDK guide](https://learn.chatgpt.com/docs/codex-sdk). | Consider when typed integration reduces actual work; avoid redundant layers. | | Codex app-server | Bidirectional thread/turn protocol, steering, interruption and approval handling. [Protocol](https://learn.chatgpt.com/docs/app-server). | Add for a demonstrated persistent-session or interactive-product requirement. | | OpenAI Agents SDK | Application-owned agent loop, handoffs and integration. [Runtime comparison](https://developers.openai.com/api/docs/guides/agents). | A distinct orchestration choice that cannot absorb LychD's owners. | | OpenAI Agents API | Managed Codex harness, durable sessions and compaction/recovery; model usage is API-billed, with applicable tool/container costs. [Overview](https://developers.openai.com/api/docs/guides/agents-api/overview). | A later managed-server option, rather than the default way to spend app allowance. | | Claude Code / Agent SDK | Programmatic coding and another provider's harness; supported authentication varies by mode. [Programmatic guide](https://code.claude.com/docs/en/headless), [SDK](https://code.claude.com/docs/en/agent-sdk/overview). | Optional comparison and separately qualified adapter. | The distinction also appears in OpenAI's [platform engineering account](https://developers.openai.com/blog/codex-as-a-platform): `exec` serves bounded jobs, SDKs serve workflows, and app-server serves product clients. Reusing a harness saves implementation work, but its private loop acquires no LychD promotion, credential, or lifecycle authority. ## Sol, Ultra and allowance The [model guide](https://learn.chatgpt.com/docs/models) names `gpt-6.1-sol` and distinguishes Max's additional single-model reasoning from Ultra's use of subagents. Record the requested Sol identifier and effective client settings; never silently substitute another model. Availability still depends on client rollout and workspace/account controls. The [Sol API page](https://developers.openai.com/api/docs/models/gpt-6.1-sol) lists reasoning efforts through `max`, without an `ultra` effort. Ultrafast is a separate speed/service choice. An app's Ultra selection therefore cannot be copied blindly into a raw Responses reasoning field or CLI override. The adapter needs a reviewed mapping and must refuse unsupported settings. The current [pricing guide](https://learn.chatgpt.com/docs/pricing) says Work and Codex share subscription usage, while API prices are separate. Model, speed, task size and retained context affect consumption. Allowance is not a fixed number of coding hours. Read actual usage and reset windows; keep account balances outside public docs. Unused allowance authorizes no paid overflow. The [noninteractive guide](https://learn.chatgpt.com/docs/non-interactive-mode) documents saved CLI authentication and API-key alternatives. Its advanced ChatGPT-account CI credential-seeding workflow excludes public/open-source repositories. That specific restriction does not prohibit local coding against an open-source checkout. Do not copy personal tokens into shared/fork runners. ## Subscription-backed integration has a specific admission path Avoid the outdated blanket claim that a ChatGPT subscription can never back an application call. OpenAI documents a [Sign in with ChatGPT plan-usage preview](https://developers.openai.com/siwc/token-sharing-open-source) for open-source and locally hosted apps, with client registration and host identity. Paid or remotely hosted apps have a separate interest path. This is a provider integration to qualify, not permission to extract an existing Codex session token. The [preview limitations](https://developers.openai.com/siwc/token-sharing-open-source/preview-limitations) require streaming with storage disabled and client-owned HTTP history. Several fields and hosted capabilities are excluded, including HTTP `multi_agent`, hosted MCP and native computer use. Local harness orchestration is a different layer. Match required capabilities to the exact road. The same preview rejects `max_output_tokens` and `max_tool_calls`. A wall deadline, usage snapshot or captured token count is not a strict per-job token/credit cap. Required native ceilings need separately qualified reservation/enforcement; if unavailable, that launch must refuse. The [plan-usage app-server guide](https://developers.openai.com/siwc/token-sharing-open-source/codex-app-server) warns that a bundled model catalogue is not an entitlement test: successful inference is needed to prove request access. Metadata-only preparation cannot establish the whole model/billing path. For operator/platform-controlled personal bootstrap, use the existing supported client authentication. Native Coffin launch remains a separate qualification: the current protocol supplies fresh homes with neither provider credentials nor an auth file, and needs a reviewed Gate bridge for every child provider request. Mounting a personal auth store into the guest does not meet that requirement. Until a supported credential-separated, bounded provider road is qualified, keep lifecycle control in the external operator campaign. A distributed LychD offering must independently qualify registration, per-user credentials, host identity, consent, revocation, and provider restrictions. Shared subscription pools and copied account sessions are not proposed. ## Continuous work needs a host and a stopping rule [Long-running work](https://learn.chatgpt.com/docs/long-running-work) documents goal mode with the same sandbox/approval boundaries and separate worktrees for parallel coding. [Local scheduled tasks](https://learn.chatgpt.com/docs/automations) need the computer on, app running and project available. These are wakeups, not an always-on server guarantee. OpenAI's [long-horizon example](https://developers.openai.com/blog/run-long-horizon-tasks-with-codex) uses durable specifications, milestones, validation commands and recorded decisions/status. Its reported long run is an example, not a general completion guarantee. Anthropic's [effective-harness experiment](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) reports that compaction alone did not solve continuation; incremental features, explicit checks and recoverable handoffs mattered. A later [harness-design experiment](https://www.anthropic.com/engineering/harness-design-long-running-apps) finds evaluator separation useful near the generator's capability boundary, while some scaffolding became overhead as models improved. The inference for LychD is to measure each extra role and remove ceremony that does not improve accepted outcomes. Anthropic's [multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) reports substantial token overhead and notes that tightly dependent coding parallelizes less readily than research. This supports bounded independent panels, not a universal cost multiplier or a claim that more agents always improve coding. ## Containment version selection The 15 October review retires Security's former 0.66-series baseline without admitting a replacement. Upstream's [DNS-before-admission advisory](https://github.com/nolabs-ai/nono/security/advisories/GHSA-gcpc-cqvp-h5c8) and [same-port destination bypass](https://github.com/nolabs-ai/nono/security/advisories/GHSA-6hww-cch7-pfrh) list affected versions through 0.73.0 and fixes at 0.74.0. Those published ranges include 0.66; Landlock ABI 6+ alone does not dispose of the destination-address defect. Conversely, the older [D-Bus advisory](https://github.com/nolabs-ai/nono/security/advisories/GHSA-27vp-2mmc-vmh3) lists versions before 0.55.0, so it does not establish affectedness of 0.66. These are upstream reports, not reproduced exploits against an admitted LychD profile. Later metadata needs source resolution. The [endpoint advisory](https://github.com/nolabs-ai/nono/security/advisories/GHSA-8r33-hr9m-69wh) lists the ordinary dot-segment fix at 0.73.0 while retaining an unresolved semicolon variant. The [tool-shim advisory](https://github.com/nolabs-ai/nono/security/advisories/GHSA-wjv5-93q3-xm73) uses a commit cutoff and an unreleased-fix field. The [0.78 release](https://github.com/nolabs-ai/nono/releases/tag/v0.78.0) associates these advisories with that release, but association cannot silently repair the patch fields. The [0.80 release](https://github.com/nolabs-ai/nono/releases/tag/v0.80.0) is a candidate for review, not an approved version. A bounded read-only study pinned 0.80 source commit `8bb041356d48f771a221e58c98d9b1ff442e76fe`. Its [endpoint policy](https://github.com/nolabs-ai/nono/blob/8bb041356d48f771a221e58c98d9b1ff442e76fe/crates/nono-proxy/src/config.rs) contains dot-segment handling, ambiguous-path rejection and separator-aware globs; the inspected [reverse-proxy path](https://github.com/nolabs-ai/nono/blob/8bb041356d48f771a221e58c98d9b1ff442e76fe/crates/nono-proxy/src/reverse.rs) calls the policy before forwarding. The [Linux entrypoint](https://github.com/nolabs-ai/nono/blob/8bb041356d48f771a221e58c98d9b1ff442e76fe/crates/nono-cli/src/tool-sandbox/platform/linux.rs) and [shim](https://github.com/nolabs-ai/nono/blob/8bb041356d48f771a221e58c98d9b1ff442e76fe/crates/nono-cli/src/tool-sandbox/shim.rs) contain a refusal path for recognized shim invocations whose broker context is missing. These observations narrow the findings for the inspected paths. They establish neither the first fixed release nor complete caller, launcher, policy, dependency or forwarding closure. The internal child-launch path and its authority still need review. Embedded tests were not run; no downloaded code was executed or installed. Host qualification begins with one exact source and policy. Resolve every applicable advisory through inspected fixes and regressions or an enforced exclusion, bind that review to the built executable and dependencies, then prove actual containment and ceilings separately. Requested systemd properties cannot replace missing effective CPU/memory files. Execution stays refused while any required qualification is unknown. The [Security owner](../../../adr/09-security.md#the-coffin-delegated-agent-profile) retains this law; the study delivers no Coffin, Provider Gate, native launcher, or platform qualification. ## Whether to add Claude Claude's [pricing page](https://claude.com/pricing) lists Pro at US$20 monthly and Max from US$100 before applicable checkout differences. These are dated observations. Purchase only for independently observed value within the actual total cost envelope. [Pro/Max Code guidance](https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan) describes shared Claude/Claude Code usage windows and API keys selecting separate API billing. Current [Agent SDK plan guidance](https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan) says SDK, `claude -p` and third-party app use may still draw plan limits; earlier announced changes were paused. Do not assume the SDK is universally API-only. The [monthly API credit policy](https://support.claude.com/en/articles/17154008-monthly-api-credits-for-max-and-team-plans), changed on 7 October, describes eligible Max/Team credits and claim requirements. Those credits are distinct from interactive subscription allowance and apply to the policy's eligible API use. Buying a plan does not prove a particular adapter will draw those credits. The [programmatic guide](https://code.claude.com/docs/en/headless) states that **bare mode does not use subscription login** and requires supported API/provider credentials. The [SDK overview](https://code.claude.com/docs/en/agent-sdk/overview) prohibits third-party developers from offering claude.ai login/rate limits in products without prior approval. Personal operator use and a distributed LychD authentication offering are separate decisions; isolation flags that change billing must be qualified explicitly. First trial a fresh Sol verifier; then, optionally, compare Claude on the same frozen diffs, acceptance criteria, and total-budget envelope. Keep the answer key protected and use separate confirmation cases. Another provider needs measured incremental benefit before adoption. This research bought or configured neither. ## Verify the road before first use 1. Read local CLI `--version`/`--help`; compare flags and wire format with the reviewed adapter. Here the available Codex binary reported **0.159.2**, matching the repository's reviewed Codex protocol. Help launched no agent and proves no provider access. 2. Inspect supported client model choices, settings, auth mode and usage without exposing secrets. App-server documents `account/read`, `account/rateLimits/read` and `model/list`; review the versioned [protocol](https://learn.chatgpt.com/docs/app-server) before calling them. 3. Select the exact personal-local, registered plan-usage or API road. Record missing entitlement and accounting evidence instead of inferring it from catalogue presence. 4. Qualify containment with an inert test executable, then admit one harmless bounded inference to prove model access, effective settings, usage attribution, output and cancellation. 5. Freeze runtime/policy identity and compatibility fixtures. Version, authentication, plan or protocol changes reopen affected qualification. The repository's [CLI protocol](https://github.com/hexanomicon/lychd/blob/main/src/lychd/domain/delegation/cli_protocol.py) constructs command intent without a physical launcher. Limits cover wall time/capture; it emits no reasoning-effort setting. Official provider features do not close these implementation gaps. Reopen the recommendation when interactive approvals require app-server, explicitly chosen server uptime justifies managed API costs, or matched review evidence earns another provider. Revisit model/effort mapping and plan eligibility after provider changes, and agent count after measured integration or review bottlenecks. None permits silent runtime fallback. --- title: "Development bootstrap" section: "Sepulcher > Extensions > Spellweaver" original: https://hexanomicon.dev/sepulcher/extensions/weaver/development-bootstrap/ guide: https://lychd.snayu.ai/docs/sepulcher/extensions/weaver/development-bootstrap/ --- # Development bootstrap Start with one useful change that another person can verify. Run that change through an operator-controlled coding campaign, retain its failures and handoffs, and implement the parts of that passage LychD can subsequently own. This guide carries that bootstrap from ordinary development to bounded native operation. [Creation](creation.md) supplies the working method; [SDLC](../../../adr/16-sdlc.md) owns its invariants. The initial coordinator is the actual coding platform and its human operator. A platform goal, worker session, or scheduled task receives that platform's identity. It is not a LychD Run, Scroll, Coffin, or Drift Trial. Consult [delegation evidence](../../../state-of-the-work.md#delegated-agent-execution) and [Forge evidence](../../../state-of-the-work.md#smith-forge-promotion) before selecting a native road. This procedure publishes no new Composition, Pattern, executor, or activation service. ## Choose the first execution road Use the existing Codex application for the first campaign. Preserve the requested Sol model and Ultra selection as explicit campaign inputs; record the exact model identifier and effective settings the client reports. [Coding-runtime research](coding-runtime-research.md) distinguishes Ultra orchestration from model reasoning, account limits from API billing, and local use from a distributed product. A different provider is a measured alternative, never an implicit fallback. Begin LychD integration by qualifying a trusted host for the existing one-shot CLI protocol and returning one bounded artifact with its terminal receipt. A bidirectional app-server adapter comes later, when a demonstrated requirement calls for live steering, interactive approvals, or persistent product sessions. Do not introduce several runtimes or a second orchestration framework to prove one job. LychD owns task semantics, admission, custody, verification requirements and effect requests. Within that admitted boundary, the foreign harness owns its private planning and tool loop. ```mermaid flowchart TD A[Operator campaign in Codex] --> B[Verified candidate and retained handoff] B --> C[Qualify durable delegation and trusted host] C --> D[LychD delegates one bounded job] D --> E[Independent verification and maintainer integration] E --> F[Admitted queue with spare-capacity work] F --> G[Separately qualified package and body activation] G --> H[Observed outcome informs a later request] H --> B ``` Each arrow is a new admission or settled handoff. The diagram grants no effect or automatic continuation. A successful coding job never appoints itself the next task or promotion owner. ## Establish the campaign before dispatch Select a small milestone, such as proving one delegation recovery boundary. Name its acceptance owner and the work that is deliberately outside it. Use a claimed issue or attributable task record; the contributor's private campaign notes may stay outside the checkout. Public delivery claims still belong in State of Work. The following is a **record template**, not a delivered LychD schema or configuration API. Replace every placeholder before a dependent launch. Keep private account, company and client information outside the repository. ```yaml campaign: task: attempt: owner: intent: owners: [] base_commit: input_manifest: allowed_paths: [] acceptance: [, , ] non_goals: [] dependencies: [] runtime: authority: tools_and_effects: limits: enforcement: verification_reserve: stop: result: ``` Make the input record describe the actual checkout. An exact commit does not identify dirty working bytes, so first inspect status and preserve operator changes. Admit an explicit patch and selected untracked files with content identities when the task needs them; exclude credentials, ignored shelves and private collateral. Otherwise, start from the admitted clean commit. Never auto-stash, clean, reset, commit unrelated work, or silently omit needed files to obtain a convenient base. Give each writer its own branch/worktree or disposable projection. Separate candidate storage from the authoritative checkout and running installation. A worktree still shares host resources; record actual sandbox, network, credential and process controls. An instruction to a worker is not operating-system enforcement. Platform-controlled work uses observed platform permissions; a native foreign-runtime launch must meet [Security's](../../../adr/09-security.md) complete admission requirements or refuse. ## Staff questions, then staff construction One Lead retains the wider intent, dependencies, remaining budget and acceptance target. The Lead dispatches closed task packets with fresh worker contexts under [scoped handoff](../../../adr/28-workflow.md#scoped-context-handoff). Useful assignments are: | Assignment | Receives | Returns | | --- | --- | --- | | Evidence investigator | One question, owners, source revisions and probe ceiling | Facts, source links, gaps and the smallest decisive probe. | | Alternative advocate | Common evidence, a declared position and defeat conditions | Strongest supported opportunity, concessions and objections. | | Boundary critic | Same evidence, failure and authority rubric | Counterexamples, missing premises and refusal/recovery requirements. | | Constructor | Settled contract, exact inputs and allowed paths | Candidate bytes, provenance, declared effects and observed checks. | | Independent verifier | Original acceptance, exact candidate and evidence | Reproducible findings, failed or missing checks and acceptance recommendation. | | Integrator | Admitted returns and current integration state | One combined candidate, renewed checks and its disposition. | Start ordinary work with one constructor and a separate verification context. Independent questions can justify parallel investigators. Consequential unsettled alternatives can justify [Crucible](crucible.md): independent first reports, actual reciprocal rebuttal, and synthesis that retains dissent and what would defeat the recommendation. Staffing supplies perspectives; it cannot simulate an opponent's reply or vote a fact into existence. Before freezing a composed or host-bound experiment, sample the cheapest real premise that could change its design: the actual DTO, route, normalization, tool field or role-specific process identity. An admitted read-only sample can establish compatibility without launching the target effect. Pure fixtures establish their model, not that environment. If a required sample is unavailable, retain the qualification gap and select work whose claim does not depend upon it. A proposed source change also needs a feasible qualification path. Before committing to construction on shared source, trace the maintained receipts that pin affected modules and assess the cost of fresh qualification, including prerequisites and cleanup. Narrow the boundary when that burden is disproportionate to the intended increment. Earlier receipts remain dated evidence; refreshing their fingerprints cannot substitute for requalification. End an inquiry when another observation cannot change the admitted choice. After a repair, return the exact finding and affected joins to the independent verifier; reopen whole-candidate review for changed authority, a shared invariant or a concrete cross-boundary finding. Required final checks still apply. Do not rerun unchanged passing gates or grow reports merely to consume allowance: compare time to a useful accepted result, meaningful escaped defects, repair rounds and the human attention required. Keep a handle for every launched check and observe its terminal state. A yielded command or elapsed time limit is unfinished evidence; settle its owned process before concluding. A practical four-slot campaign rotates one Lead and up to three workers; that is a pilot choice, not a model-count law. Settle shared interfaces before distributing writers, and serialize changes to a shared mutable surface. A design contributor's later review offers continuity, but its exposure cannot be called independent. Another vendor can add a different error profile; it cannot substitute for an independent acceptance rule. [Genesis](../../../divination/transmutation/genesis.md#tree-of-life) illuminates formation; Creation's [worked relations](creation.md#tree-relations-in-practice) give the engineering correspondence. Canon supplies criteria before construction and Trial. Revelation separates observations from interpretation and proposals; Distillation carries a corrigible lesson into a later request. These capacities do not require ten permanent Agents. ## Advance through evidence gates The stages below are an implementation sequence. Completing a documentation task does not satisfy an execution gate, and a gate may need several reviewable changes. Work that needs no foreign launch can proceed while host-boundary design is investigated separately. | Stage | Work | Exit evidence | | --- | --- | --- | | **0 — Operator bootstrap** | Run one bounded milestone through the existing app, actual permissions, separate candidate and ordinary checks/review. | Exact input closure, candidate, receipts, corrections, integration or explicit noncompletion. | | **1 — Durable boundary** | Prove database acceptance races and independent-process recovery; define versioned request/policy binding and qualify the refusing host port. | Real PostgreSQL receipts, no duplicate start/adoption, enforced launch policy, complete cancellation and retained artifacts. | | **2 — Useful delegated candidate** | Admit one synthetic/public task, then one eligible repository task, through the qualified host and existing delegated score. | Correlated Run/job/launch/artifacts, bounded execution, independent verification and maintainer-owned integration. | | **3 — Spare-capacity queue** | Admit one eligible task at a time under explicit standing policy and reviewer capacity. | Durable claims and expiry, no overlapping writer, budget admission, pause/revoke/restart and ambiguity tests. | | **4 — Changed-body adoption** | Construct packages and rehearse selected extensions, configuration, migrations and owner recovery before activation. | Exact artifact closure, effect-time authority, new-generation readiness, observed rollback/compensation or declared forward recovery. | Recurring campaigns can begin in an external operator queue under the platform's actual permissions. Through Stage 2, that queue retains backlog, candidate judgment, retry, review and promotion ownership; LychD supplies only bounded labor. The legacy Core delegation exception must not be stretched into an application lifecycle. Preserve retained score revisions and publish a successor whenever manifest or checkpoint semantics change. Stage 3 transfers that lifecycle into LychD after the B7 ownership gate. It is not a prerequisite for recurring operator work. Stage 2 initially uses operator/CI verification through trusted commands and disposable state. Running generated tests or build hooks inside LychD is a separate untrusted-execution admission; a `verify` label does not deliver Tomb. Stage 3 automates candidate production only within its policy. Stage 4 follows [Packaging](../../../adr/17-packaging.md) and [Evolution](../../../adr/18-evolution.md), preserving each effect owner's authority. ### Qualify the usable body alongside delegation Keep two concrete milestones separate: a useful Bridge installation and a trustworthy delegated coding job. The first does not require an autonomous SDLC, and its successful model reply does not qualify foreign guest execution. Use [Summoning](../../../summoning.md#stage-the-acceptance-campaign) for the exact Linux-host bring-up and acceptance campaign, rather than inventing another setup manual here. From the selected source snapshot, run the focused and repository gates in CONTRIBUTING and retain pre-existing failures. For the chosen Linux host, pin systemd/Podman, configuration, database/migration head, selected runtime/model and resource limits; follow dry-run preparation before the admitted initialization, binding and startup effects. Qualify one explicit local Bridge capability, observe first reply and durable history, then test the declared stop/restart and recovery boundary. Record the four witnesses and remaining gaps specified by Summoning. The existing warm-model/two-process receipts can guide a bounded reproduction under their exact profiles; they do not prove crash recovery, a deployed model body, general Coffin containment or public exposure. Keep host profiles, private configuration and raw receipts outside the checkout. Select one deployment target and its effect/recovery owner before a live campaign; success on that target establishes that recorded scope. Native SDLC work can continue on its own candidate surface while this host milestone is qualified. ### Verify an analysis candidate before using it For a bounded operator task, the existing Bridge can return text for separate review. Its `BridgeReply.answer` string can contain JSON, but that text does not acquire a domain artifact's type, custody or downstream authority merely by being parseable. Before submission, fix the candidate shape, size, encoding and source requirements, with checks for Unicode, escaping and nested sensitive material where relevant. Record rejection as a failed task outcome and retain only admitted safe evidence; changing its evaluator or repairing its text requires a separately admitted successor. Judge the returned candidate separately from the machinery that carried it. Request acknowledgement, terminal Run state, external-effect settlement, candidate validity, semantic usefulness and repository promotion are distinct. A DONE Run can return invalid or unhelpful material, and terminal state alone does not establish physical closure of its effects. Separate verification must establish the useful outcome against the original acceptance. Native ownership of a recurring analysis task follows B7 and the existing [Spell contract](../../../adr/28-workflow.md#spells-scrolls-and-casting). An operator's JSON prompt creates neither a native application boundary nor an executable contract revision. ### First implementation queue Revalidate this queue against current source before claiming a task. Its entries describe missing proof or future work, not completed issues or promises of delivery dates. | Task | Smallest useful slice and dependencies | Acceptance that closes the slice | | --- | --- | --- | | **B0: Preserve the baseline** | Inventory current changes; select an exact admitted input closure and record focused gate results. | Operator work retained; pre-existing failures attributed; task surface reproducible. | | **B1: Real database settlement** | Extend the existing delegation PostgreSQL receipt with independent concurrent sessions. Depends on B0. | RUNNING wins against conditional LOST; LOST prevents late RUNNING; result/event adoption occurs once; event failure rolls back; interruption remains attributable. | | **B2: Recovery across processes** | Exercise real migrations, Run admission and retained delegated Graph wait/resume through distinct coordinator processes. Depends on B1. | One admitted job and terminal adoption after restart; exact request replay cannot launch twice; uncertain effects stay contained. | | **B3: Versioned launch policy** | Bind exact source projection, paths, model/effective settings, tool/effect policy, budgets, artifact custody and verifier identity at admission. Can be designed alongside B1. | Invalid/missing/stale fields refuse; request and launch digest correlate; unsupported settings refuse; old retained Runs keep their admitted interpretation. | | **B4: Trusted host qualification** | Implement the selected host/Gate road using B3 and durable settlement; first qualify it with an inert adversarial executable and no provider. | Root/secret/egress escapes refused; child processes cancelled; resource limits exercised; uncertain start reconciled; artifacts survive coordinator loss. | | **B5: One real delegated artifact** | Qualify the reviewed CLI against harmless public/synthetic input, then an admitted repository projection. Depends on B2–B4. | Exact model/billing path observed, bounded output admitted, independent fixed checks pass, no forbidden effects. | | **B6: Candidate and review handoff** | Carry one immutable patch into separate verifier/integrator contexts. Depends on B5 for native production; operator practice can start now. | Scope and provenance checked, adversarial failures retained, integrated object retested, source effect separately authorized. | | **B7: Native ownership transfer** | When LychD is to own backlog, candidate judgment, repair/review or lifecycle recovery, test a candidate application study against existing homes, accept its owner revision and publish its exact Pattern. External lifecycle ownership can remain in place without this transfer. | Durable records, finish judgment, typed inputs/results, refusal, cancellation, recovery and retained revisions establish the actual application boundary. No portfolio placeholder or Assimilation coordinator. | | **B8: Idle pilot** | Add task eligibility, durable claim/lease and bounded scheduling under B7's owner; use the qualified execution and verification roads. | No duplicate claims, unsafe overlap or retry after unknown effects; stale grants refuse; review saturation sleeps; restart and revoke settle. | | **B9: Evolution rehearsal** | Package exact candidates, selected coupled extensions and schema/configuration closure; qualify target-owned activation. | Rehearsed migration/recovery, old-generation work disposition, new-generation readiness and recorded outcome. No candidate import into active Vessel. | Existing protocol adapters are the starting point, rather than a missing feature to rewrite: [launch contract](https://github.com/hexanomicon/lychd/blob/main/src/lychd/domain/delegation/cli_protocol.py), [host port](https://github.com/hexanomicon/lychd/blob/main/src/lychd/domain/delegation/cli_runtime.py), [request models](https://github.com/hexanomicon/lychd/blob/main/src/lychd/domain/delegation/models.py), [store](https://github.com/hexanomicon/lychd/blob/main/src/lychd/db/delegation.py), [modeled race tests](https://github.com/hexanomicon/lychd/blob/main/tests/unit/db/test_delegation_acceptance.py), and [PostgreSQL receipt](https://github.com/hexanomicon/lychd/blob/main/tests/integration/test_db_run_ledger_pg.py). Do not replace these with a second queue, subprocess supervisor, or lifecycle coordinator merely to attach another provider. ### First executor closure fixture One candidate for B4's first inert fixture is a pre-established bounded trusted controller with one immutable occurrence-to-cgroup-object association. Keep each pending launch's original open reference alive until its kernel call resolves. A borrowed numeric descriptor, a reopened path or a replacement object cannot stand in for it. Exclude per-job manager requests containing foreign argv and fork-then-migrate fallbacks. The proposed creation primitive is direct `clone3(CLONE_INTO_CGROUP)` into that original object. After closing intake, contain its guest descendants and prove successful retirement of that exact object before acknowledging guest closure. If creation wins the race, retirement must remain pending while the child can execute. If retirement wins, the delayed original-object creation must refuse. Linux documents FD-selected placement and non-revival of retired groups; the inspected v6.6 source supplies the relevant clone/destruction ordering. These are upstream facts supporting a conditional design, not qualification of the operator's kernel. [clone interface](https://man7.org/linux/man-pages/man2/clone.2.html), [cgroup contract](https://www.kernel.org/doc/html/v6.6/admin-guide/cgroup-v2.html#core-interface-files), [inspected source](https://raw.githubusercontent.com/torvalds/linux/v6.6/kernel/cgroup/cgroup.c). Before a physical run, retain a bounded model's successful-launch and close witnesses, both race orders, and counterexamples for empty-only acknowledgement, path replacement, numeric-FD reuse and restored old authority. Model a surviving worker separately from controller death; assuming they die together does not qualify that recovery case. The later inert host fixture must force the same orders and verify original-object identity, descriptor lifetime, descendant containment, effective ceilings and owned cleanup. Failed deletion or unknown identity remains unresolved. No coding CLI, provider or real repository task belongs in that first fixture. The actual owner still needs an accepted ordered release-to-in-flight operation. A fresh observation followed by a pause supplies no such authority, and an earlier release does not prove physical exec before an absolute deadline. Object retirement also leaves resource, I/O, custody and prior external-effect settlement to their actual owners. Exact audited containment, source, reservations and Gate qualification remain separate gates; no controller or executor ships here. ## Spend spare capacity on admitted work Spare capacity needs an owned queue of eligible work and a service willing to sleep when none qualifies. It does not need a model repeatedly inventing changes. A human-curated backlog can supply that queue before native scheduling exists. [Scheduling](scheduling-and-service-classes.md) owns future foreground and spare-capacity behavior; a desktop timer does not deliver it. Admit tasks in this order when their actual impact and dependencies justify it: 1. Reproduce and repair a known failing acceptance contract or regression. 2. Close a named recovery, security or compatibility evidence gap. 3. Implement an already accepted, claimed backlog slice with observable acceptance. 4. Investigate one recurring operational failure or human correction. 5. Test a specific method improvement against a frozen baseline. Speculative refactors, mass dependency upgrades, repeated web research, test-count inflation and invented features need a concrete request before entering this queue. Preserve the unchanged baseline when the evidence does not support an improvement. The initial **operator pilot policy** is one active writer and at most one candidate awaiting review, two repair attempts per task, and one extra discovery probe for a decisive gap. Use 45 minutes per task within a two-hour campaign window, reserving the final quarter of the window for verification, handoff and cleanup. Adjust these numbers in a recorded successor policy when measurements justify it; they are not universal ADR requirements or installed runtime defaults. If a required check cannot fit, select a smaller task or admit a larger window before starting. Research campaigns can use a separately bounded inquiry policy. Record a token/call/credit ceiling supported by the selected account and host, including review and failed attempts. Mark each bound as enforced, measured after use, or operator-observed. Post-hoc usage is not a hard cap. Required native launch limits that cannot be enforced make that road ineligible; choose another admitted road or return noncompletion. Existing allowance does not authorize paid overflow, a provider purchase or automatic billing fallback. A per-generation output limit and a validation-retry count do not bound a whole Run's model requests or tokens. Record the effective context and output reserve, retry behavior, total-call and token limits, and cancellation enforcement separately; state which limits remain unsupported. Prompt instructions do not override the installed model profile. A profile change needs its normal configuration and process-generation lifecycle before a later task can rely on it. Before **each** successor, the coordinator must observe: - standing authorization still covers its paths, inputs, data and effect classes; - a named owner, current defect or request, and predeclared useful outcome; - satisfied dependencies and compatible current base; - available reviewer, verification resources and global budget reserve; - a fresh task claim, no duplicate work and no unresolved external outcome; and - an observable stop condition and a permitted cancellation/recovery road. Dispatch ends when the campaign succeeds or reaches expiry, budget exhaustion, policy revocation, a missing boundary, review saturation, repeated unchanged failure, or unknown external state. Retain partial artifacts with the actual stopping reason. Reconcile an ambiguous launch before another effectful attempt: timeout or LOST does not prove that descendants stopped. A retry requires a changed repair hypothesis or justified replication and consumes the parent budget. For a later durable scheduler, a claim binds task/policy/input identities, owner, occurrence, expiry and renewal. Lease expiry changes dispatch eligibility; it does not prove process death or make an uncertain effect safe to replay. Pause stops new admission; cancel reconciles active work; revoke prevents later admissions and is checked again at effect time. Host cancellation must settle the whole process tree and retain final custody evidence. Notify the operator on a meaningful result, failure, or required decision; unchanged idle state stays quiet. ## Integrate people and their candidates Humans decide which outcomes matter, own accepted architecture and protected judgment, maintain real-world acceptance cases, and perform the effects assigned to their roles. Agents investigate, construct, test within admitted boundaries, explain evidence and prepare reviewable candidates. Humans need not spend their time translating an already settled contract into routine edits. Neither a persuasive agent nor a busy maintainer can waive a failed mandatory gate. Use [CONTRIBUTING](https://github.com/hexanomicon/lychd/blob/main/CONTRIBUTING.md#branches-and-everyday-collaboration) for the current collaboration phase and its branch and promotion procedure. Integrate candidates serially and verify the resulting exact snapshot. Appropriate maintainers can act without a founder-only queue. Expertise-based adjacent review is especially useful for shared API, checkpoint and effect-settlement changes. Integration carries responsibility through three roles. The author supplies the complete candidate and observed checks. A separate verifier examines the original request, governing owners and exact diff, including forbidden behavior, recovery, generated artifacts and truth-changing documentation. The integrator then inspects the current base and scope before admitting selected bytes. A change to the base, conflict, patch, dependency or verification plan creates a successor candidate and repeats affected checks. Test the combination: separately passing patches do not prove an integrated result. Repair or revert a broken integration branch before allowing more work to accumulate. Keep three exchanges distinct: | Exchange | Procedure | | --- | --- | | A developer contributes to shared LychD Core | Ordinary source review and exact-object promotion. The resulting public law belongs in its existing ADR. | | A developer keeps a private coupled extension or Core delta | Bind its base, local patch and selected extension set; verify them against each inactive upstream candidate. Conflict blocks adoption. | | Another project supplies a useful mechanism | Make an Assimilation Dossier, study the exact lesson and implement a local candidate. Integration remains preferable when a stable external contract meets the need. | Independent projects keep their own purpose and release authority. Adoption downstream and contribution upstream are separate decisions. Shared ancestry or an agent conversation creates no automatic merge, compatibility guarantee, credential sharing, or obligation to repair another lineage. Future human quorum governance is governed by [Evolution](../../../adr/18-evolution.md#future-quorum-roster); it is not an early-development approval ceremony. ## Assimilate one mechanism at a time Use [ADR 35](../../../adr/35-assimilation.md) when the work studies and re-expresses foreign craft. An adapter to a service is Integration; bounded foreign labor is Delegation. Do not call every dependency or returned patch Assimilation. For one admitted lesson, retain exact source revision and paths, provenance, license and notices, local need/base/target, the mechanism being retained, deliberately excluded authority, generated material, acceptance cases, unresolved gaps and a maintenance owner. Read source and tests as untrusted evidence. Construct in the candidate surface; compare the claimed behavior locally, retain necessary notices and inspect failure and hostile-input cases. Foreign benchmarks or tests alone cannot prove local correctness. The result requests source/package admission and, where needed, a later Evolution; it never installs itself. For example, borrow a bounded JSONL framing or receipt mechanism from a reviewed runtime version. Keep its exact provenance and prove malformed/truncated input, identity correlation, limits and terminal behavior at the LychD boundary. Do not import the foreign credential store, router, subagent authority or billing fallback with the framing code. ## Measure whether the loop helps Measure the loop against a baseline using the requested Sol setting and existing procedure. Change one variable at a time: a fresh reviewer, a Claude reviewer, a context policy or a different task decomposition. Match tasks and total budgets, counting failed attempts, verification, review and human attention. [Evaluation](../../../adr/34-evaluation.md) owns the native design; ordinary operator comparisons retain their actual identities and limited conclusions. For an initial reviewer comparison, freeze six representative past diffs with known defects and clean controls across delegation, persistence, configuration, API, frontend and documentation. Keep the answer key out of constructor/reviewer context. Run fresh Sol review as baseline and then the optional alternative on the same evidence; record order and contamination. Measure accepted unique defects, false positives, missed requirements, fix effort, elapsed time and actual usage. Six cases are a screening pilot, not statistical proof of universal superiority. Reserve separate unseen cases for confirmation before adopting a standing default. Promote a method only when it improves the declared useful outcome within its full cost envelope, without regressing mandatory behavior or authority/recovery constraints. Retain rejection and inconclusive results too. The constructor cannot obtain a pass by rewriting the evaluator, holdout, acceptance threshold, promotion policy or budget. Any proposal to change those requires its own independent comparison and owner decision. Training weights is a later, separately admitted experiment; many useful improvements concern Context, tools, instructions and handoffs. ## Start the first campaign Use a bounded goal after filling the task record and selecting the actual candidate surface: ```text Complete task B1 from the Development bootstrap guide against its recorded input closure. Establish the owning contract and reproduce the missing evidence before editing. Use the requested Sol model and record effective settings. Give independent investigators closed packets; keep one writer and a separate verification context. Preserve operator work. Run the focused PostgreSQL receipt and required repository gates; retain failures and unrun checks. Deliver the exact candidate, test receipts, updated owning documentation and next eligible task. Stop when B1 is verified or its declared budget/premise prevents completion. Do not start B2, merge, publish, deploy, purchase capacity or widen permissions from this request alone. ``` The final boundary is the task's actual authorization. A wider campaign may already authorize successor tasks or source effects; record that standing scope and re-admit each successor under it. Do not ask again for settled routine authority, and do not infer a new effect from silence.