# LychD docs (Snayu plain-English edition)

> LychD is an open-source, self-hosted AI platform. Its official docs, the Hexanomicon (https://hexanomicon.dev), use dark-fantasy names. This mirror has every page as Markdown with a plain-English summary on top, plus a glossary mapping each fantasy name to a plain one.

Read the glossary first. Treat the State of Work page as the source of truth for what works today.

## Start here

- [Glossary](https://lychd.snayu.ai/ai/GLOSSARY.md): every docs name with its plain name, analogy and status
- [Table of contents](https://lychd.snayu.ai/ai/INDEX.md): all pages with one-line summaries
- [Everything in one file](https://lychd.snayu.ai/llms-full.txt): glossary and all 302 pages

## Chapters

- [Overview pages (home, getting started, install, map, state of work, roadmap)](https://lychd.snayu.ai/ai/chapters/overview.md): 6 pages
- [Sepulcher](https://lychd.snayu.ai/ai/chapters/sepulcher.md): 88 pages
- [Divination](https://lychd.snayu.ai/ai/chapters/divination.md): 22 pages
- [Compositions](https://lychd.snayu.ai/ai/chapters/compositions.md): 139 pages
- [Lexicon](https://lychd.snayu.ai/ai/chapters/lexicon.md): 3 pages
- [Covenants](https://lychd.snayu.ai/ai/chapters/adr.md): 44 pages

## Pages

- [Prophecy (Docs home page)](https://lychd.snayu.ai/ai/docs/index.md): The front page of the official docs (Hexanomicon).
- [Getting Started](https://lychd.snayu.ai/ai/docs/getting-started.md): A short page for new contributors that explains LychD is pre-alpha and helps you choose a first path: verifying the repository on a checkout, or attempting a live Linux host install.
- [Summoning (Installation on a Linux host)](https://lychd.snayu.ai/ai/docs/summoning.md): The intended step-by-step procedure to install LychD on one Linux host with an NVIDIA GPU: build from source, create settings and data folders, bind one local llama.cpp model, start the system and get a first reply.
- [Map (Architecture map of one request)](https://lychd.snayu.ai/ai/docs/map.md): Follows one piece of work through LychD from request to result: how a Request picks a Workflow Version, becomes a Job Record run by Workers, draws on models via the Traffic Controller and Stage Manager, and returns for human judgment.
- [State of Work (What actually works)](https://lychd.snayu.ai/ai/docs/state-of-the-work.md): The single ledger of what the current LychD revision can really do, with evidence.
- [Roadmap — Metamorphosis (Roadmap for the founding year)](https://lychd.snayu.ai/ai/docs/roadmap.md): The project's plan for 2 November 2026 to 1 November 2027, told as five books and 53 weekly chapters named after Python methods.
- [Sepulcher (The Body: core parts overview)](https://lychd.snayu.ai/ai/docs/sepulcher/index.md): An overview of all core parts (The Body / Sepulcher) and how they run on Linux as rootless containers managed by systemd.
- [Lich (The Assistant as a whole)](https://lychd.snayu.ai/ai/docs/sepulcher/lich/index.md): Explains the Assistant (Lich) as the whole running system over time: one server process, its workers and its database memory together.
- [Call (Listen: receiving and routing requests)](https://lychd.snayu.ai/ai/docs/sepulcher/lich/call.md): A conceptual page on the Listen function (Call): receiving a request and opening possible routes for it, without yet deciding which route is right.
- [Blade (Judge: testing against evidence)](https://lychd.snayu.ai/ai/docs/sepulcher/lich/blade.md): 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'.
- [Spirit (Remember: experience over time)](https://lychd.snayu.ai/ai/docs/sepulcher/lich/spirit/index.md): Introduces the Remember function (Spirit): how experience is carried forward.
- [Flux (Flux: the present moment)](https://lychd.snayu.ai/ai/docs/sepulcher/lich/spirit/flux.md): 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.
- [Seed (Memory Seed: what is kept)](https://lychd.snayu.ai/ai/docs/sepulcher/lich/spirit/seed.md): A conceptual page on the Memory Seed: something a past action leaves behind that can shape a future action.
- [Recall (Remembering: bringing memory back)](https://lychd.snayu.ai/ai/docs/sepulcher/lich/spirit/recall.md): A short conceptual page on Remembering (Recall): retrieving a stored memory, judging if it is relevant, and letting it influence the current task.
- [Answer (Own it: accountable answers)](https://lychd.snayu.ai/ai/docs/sepulcher/lich/answer.md): A conceptual page on Own it (Answer): attributing an action and its consequences to a specific local 'I' tied to an ID Badge (Sigil).
- [Codex (Settings Folder and config files)](https://lychd.snayu.ai/ai/docs/sepulcher/codex.md): Describes the Settings Folder (Codex) at ~/.config/lychd/: the main lychd.toml for process-wide settings and per-service config files (Runes) under runes/.
- [Crypt (Data Folder layout)](https://lychd.snayu.ai/ai/docs/sepulcher/crypt.md): 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.
- [Gateway (Gateway: separate edge machine)](https://lychd.snayu.ai/ai/docs/sepulcher/gateway.md): An optional design for putting public internet traffic on a separate machine (a Gateway Host), keeping data and authority on the main host.
- [Intercom (Agent-to-Agent Line sessions)](https://lychd.snayu.ai/ai/docs/sepulcher/intercom.md): 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.
- [Vessel (Engine Room: the server process)](https://lychd.snayu.ai/ai/docs/sepulcher/vessel/index.md): Describes the Engine Room (Vessel): the single application process (Granian, Litestar, Pydantic AI) that serves the web UI, admits requests and hosts the workers.
- [Ghouls (Background workers)](https://lychd.snayu.ai/ai/docs/sepulcher/vessel/ghouls.md): 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.
- [Phylactery (Memory Vault (PostgreSQL))](https://lychd.snayu.ai/ai/docs/sepulcher/phylactery/index.md): 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.
- [Reanimation (Crash recovery after restart)](https://lychd.snayu.ai/ai/docs/sepulcher/phylactery/reanimation.md): Explains Crash Recovery (Reanimation): how a new server process reads the database after the old one died and decides which jobs may resume.
- [Animator (Model Runtime overview)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/index.md): Introduces the Model Runtime (Animator): an addressable handle for any service that can do typed work, such as a model, search or renderer.
- [Capabilities (Model and service capabilities)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/capabilities.md): Defines a capability: an exact, versioned contract for what you can ask a service to do and what comes back.
- [Connectors (Connectors and API dialects)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/connectors.md): Explains Connectors: the adapters that speak a service's exact wire protocol.
- [Audio Hardware and Host Routes](https://lychd.snayu.ai/ai/docs/sepulcher/animator/audio-routes.md): 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.
- [Soulstone (Local Models overview)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/index.md): 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.
- [Soulstone Rune (Local model config file reference)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/rune.md): Reference for the Local Model Service Config File (Soulstone Rune): a TOML file under runes/animator/soulstones/<runtime>/ listing fields like image, port, devices, volumes, secrets and the model catalogue.
- [Soulstone Disciplines (Local model runtime families)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/disciplines.md): 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.
- [Soulstone Engines (Local model engines index)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/engines/index.md): 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.
- [vLLM (Engine: vLLM)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/engines/vllm.md): 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.
- [SGLang (Engine: SGLang)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/engines/sglang.md): 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.
- [llama.cpp (Engine: llama.cpp)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/engines/llamacpp.md): 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.
- [ExLlamaV3 through TabbyAPI (Engine: ExLlamaV3 via TabbyAPI)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/engines/exllamav3.md): 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.
- [ComfyUI (Engine: ComfyUI)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/engines/comfyui.md): 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.
- [audio.cpp (Engine: audio.cpp)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/engines/audiocpp.md): 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.
- [Soulstone Resources and Secrets (Local model devices, mounts, secrets)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/resources.md): Rules for what a local model service may receive: explicit devices, volume mounts, non-secret environment, Podman secret references and a unique host port.
- [Portal (Cloud Models (remote APIs))](https://lychd.snayu.ai/ai/docs/sepulcher/animator/portal.md): Describes a Cloud Model (Portal): a remote API provider declared in a config file, with no container or local GPU use.
- [Portal Roads (Choosing cloud provider routes)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/portal-roads.md): 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.
- [Coven (Model Groups)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/coven.md): Explains Model Groups (Covens): a named systemd target for two or more compatible local model services.
- [Runtime transitions (Switching and loading models)](https://lychd.snayu.ai/ai/docs/sepulcher/animator/runtime-transitions.md): 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.
- [Extensions (Plug-in areas overview)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/index.md): 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.
- [Smith (Code assimilation agent)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/smith.md): 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.
- [Spellweaver (Workflow engine)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/index.md): The workflow engine (Spellweaver) that validates immutable workflow versions (Scrolls), admits their execution, and keeps them intact through pauses, resumes and endings.
- [Discovery and router delegation (Finding docs, scopes and workflows)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/discovery.md): 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.
- [Scroll and Pattern lifecycle (Workflow versions and admission)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/pattern-lifecycle.md): 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.
- [Crucible (Structured two-round debate)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/crucible.md): 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.
- [Creation (Software change method (Creation))](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/creation.md): 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.
- [Ouroboros (Improvement loop: work, evaluate, learn)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/ouroboros.md): 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.
- [Scheduling and service classes](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/scheduling-and-service-classes.md): 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.
- [Stasis and return (Pausing and resuming workflows)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/stasis-and-return.md): 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.
- [Execution roads (Choosing where work runs)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/execution-roads.md): 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.
- [Anonymization, taint, and egress (Privacy filter and data egress)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/anonymization.md): 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.
- [Delegated agents (Delegating tasks to external agents)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/delegated-agents.md): 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.
- [Oculus (Observability and evidence tracing)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/oculus.md): 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.
- [Soulforge (Model trainer overview)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/soulforge/index.md): 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.
- [Corpus (Training data admission)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/soulforge/corpus.md): 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.
- [Training Run (Running a training job)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/soulforge/training-run.md): 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.
- [Candidate Handoff (Evaluating and promoting trained models)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/soulforge/candidate-handoff.md): 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.
- [Discernment Training (Training judgment from experience)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/soulforge/discernment-training.md): 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.
- [Drift (Evaluator overview)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/drift/index.md): 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.
- [Trials (Evaluation trials and verdicts)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/drift/trials.md): 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.
- [Capability Claims (Expiring capability claims)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/drift/capability-claims.md): 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.
- [Returning Findings (Tracing failures back to a cause)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/drift/returning-findings.md): 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.
- [Workflow Improvement (Evaluating and improving workflows)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/drift/workflow-improvement.md): 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.
- [Scout (Web fetcher)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/scout.md): 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.
- [Tether (Private network link (WireGuard))](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/tether.md): The planned private-reachability area (Tether) that would use WireGuard to open exact private network paths between hosts, without granting any application authority.
- [Veil (Public ingress proxy)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/veil.md): 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.
- [Ward (Security desk: identity and permissions)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/ward.md): 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.
- [Prism (Vision and media overview)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/index.md): 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.
- [Sight (Computer vision estimates)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/sight.md): 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.
- [Live Sight (Live camera sessions)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/live-sight.md): 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.
- [Scanner (Document OCR and extraction)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/scanner.md): 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.
- [Image (Image generation and editing)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/image.md): The planned image-making path (Image) for generating, editing, inpainting, structure-controlled and enhancement jobs, recording the exact operation, inputs, profile and what changed.
- [Video (Video generation)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/video.md): 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.
- [Form (3D model generation)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/form.md): 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.
- [Voxel and block export (Voxel and Minecraft block export)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/voxel-and-block-export.md): 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.
- [Kinesis (Motion and animation processing)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/kinesis.md): 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.
- [Live Kinesis (Live motion sessions)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/prism/live-kinesis.md): 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.
- [Echo (Voice: speech in and out)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/echo.md): 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.
- [Local speech qualification (Local speech test probe)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/echo-local-probe.md): 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.
- [Speech provider study (Speech provider comparison)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/echo-research.md): 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.
- [Shadow (What-if simulator overview)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/shadow/index.md): 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.
- [Dancer (Alternative generator (Dancer))](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/shadow/dancer.md): 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.
- [Hunter (Candidate challenger (Hunter))](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/shadow/hunter.md): 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.
- [Mirror (Persona keeper and attribution)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/mirror.md): 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.
- [Toll (Payments and service credits)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/toll.md): 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.
- [Legion (Multi-machine work distribution)](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/legion.md): 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.
- [Divination (Using and learning: overview)](https://lychd.snayu.ai/ai/docs/divination/index.md): Overview of the Divination section: the Control Panel for acting and inspecting, the learning cycle (Transmutation), the philosophical path (Transcendence), and research correspondences.
- [Transmutation (The learning cycle overview)](https://lychd.snayu.ai/ai/docs/divination/transmutation/index.md): Introduces the cycle by which making something becomes learning: design it (Genesis), test it (Trial), judge it against criteria (Canon), interpret results (Revelation), and pass lessons on (Distillation).
- [Genesis (Genesis: designing a candidate)](https://lychd.snayu.ai/ai/docs/divination/transmutation/genesis.md): A long conceptual chapter on giving an idea form: pairing opposing questions (why/how, challenge/expand, review/test) using the Kabbalistic Tree of Life as a map of capacities, so a proposal can be examined and tested.
- [Trial (Trial: testing a candidate)](https://lychd.snayu.ai/ai/docs/divination/transmutation/trial.md): Short chapter on testing a candidate under declared conditions (revision, environment, cases, budget) and preserving what happens, including failures.
- [Canon (Canon: defining success criteria)](https://lychd.snayu.ai/ai/docs/divination/transmutation/canon.md): Short chapter on declaring how a candidate will be judged, including criteria, constraints, a rubric and required evidence, before making or testing it.
- [Revelation (Revelation: interpreting results)](https://lychd.snayu.ai/ai/docs/divination/transmutation/revelation.md): Short chapter on interpreting test results against the declared criteria, keeping what happened, possible causes and proposed fixes as separate claims.
- [Distillation (Distillation: passing lessons on)](https://lychd.snayu.ai/ai/docs/divination/transmutation/distillation.md): Chapter on turning a finding into a reusable lesson with its condition, reason, evidence and limits, and choosing where it should go (context, memory, prompt, workflow or training).
- [Altar (Control Panel overview)](https://lychd.snayu.ai/ai/docs/divination/altar/index.md): Overview of the web Control Panel (Altar) at http://127.0.0.1:7134/: how to log in locally, send a request in Chat, and follow a Job Record across the Project Board, Run Inspector, Workflow Viewer and Model Status Board.
- [Atlas (Project Board)](https://lychd.snayu.ai/ai/docs/divination/altar/atlas.md): Guide to the Project Board (Atlas): keep a project's brief, concerns, judgments and next step across conversations and Job Records, and record assessments like Sufficient, Insufficient or Disputed.
- [Owned Technology Map](https://lychd.snayu.ai/ai/docs/divination/altar/technology-map.md): A candidate project idea for using the Project Board to map a device or app you own: its components, dependencies, documentation, control and recovery options, preferring open source.
- [Bridge (Chat panel)](https://lychd.snayu.ai/ai/docs/divination/altar/bridge.md): Detailed guide to Chat (Bridge): the side panel where you send requests, follow each turn to completion, answer approval cards, retry safely and use public notes or public web pages for answers.
- [Circle (Task Bubble for one request)](https://lychd.snayu.ai/ai/docs/divination/altar/circle.md): Explains the Task Bubble (Circle): the boundary around one admitted Job Request, holding its request, ID Badge, Briefing Pack, memory and authority, and the compact status card shown in Chat.
- [Orb (Run Inspector)](https://lychd.snayu.ai/ai/docs/divination/altar/orb.md): Guide to the Run Inspector (Orb) at /orb: browse Job Records, zoom into stations and records, and read the retained evidence of one run with clear labels for gaps and capture limits.
- [Nexus (Model Status Board)](https://lychd.snayu.ai/ai/docs/divination/altar/nexus.md): Guide to the Model Status Board (Nexus) at /nexus: see which models are active, warming or cold, preview a model switch plan, and request a real transition.
- [Loom (Workflow Viewer)](https://lychd.snayu.ai/ai/docs/divination/altar/loom.md): Guide to the read-only Workflow Viewer (Loom) at /loom: open one exact Workflow Version by id and revision and inspect its stations and allowed transitions.
- [Transcendence (The philosophical path overview)](https://lychd.snayu.ai/ai/docs/divination/transcendence/index.md): Introduces the project's long-term purpose as five philosophical stages: giving form, encountering the world, learning from consequence, identity surviving failure, and living among many others.
- [Incantation (Docs-first development philosophy)](https://lychd.snayu.ai/ai/docs/divination/transcendence/incantation.md): Philosophical chapter on giving an intention a clear form, which in practice is Docs-First Development (xDDD): write the documentation and specification before the code, then compare what was built against it.
- [Invocation (Encounter and model power)](https://lychd.snayu.ai/ai/docs/divination/transcendence/invocation.md): Philosophical chapter on what happens when a request meets a model and the wider world: the model lends power but is not the caller or the answerer, and imagination must be checked by judgment.
- [Illumination (Learning from consequences)](https://lychd.snayu.ai/ai/docs/divination/transcendence/illumination.md): Philosophical chapter on letting results change future behaviour through attribution, evaluation, memory policy, consent and recall, while keeping stored memories correctable.
- [Immortality (Identity surviving restarts)](https://lychd.snayu.ai/ai/docs/divination/transcendence/immortality.md): Philosophical chapter on what can survive when the server dies: committed memories that stay attributable and revisable, not an unchanged mind.
- [Infinity (Living among many agents)](https://lychd.snayu.ai/ai/docs/divination/transcendence/infinity.md): Philosophical chapter on how an assistant should relate to other people, agents and cultures: no single system owns the whole, power should serve the common good, and others must keep the ability to refuse.
- [Correspondence (Research links: brains and models)](https://lychd.snayu.ai/ai/docs/divination/correspondence.md): An essay connecting neuroscience and machine-learning research (interpretability, network geometry, memory, value) with older philosophical maps of mind, framing each as a testable question.
- [Compositions (Apps built on LychD)](https://lychd.snayu.ai/ai/docs/compositions/index.md): Index of Apps (Compositions): reusable applications that keep their own records, judge their own results and control which side effects they may request.
- [Choosing a Home (Guide: where an idea belongs)](https://lychd.snayu.ai/ai/docs/compositions/choosing-a-home.md): A routing guide for deciding whether a new idea needs a new App or fits as a Packaged Offer (Product), profile, Workflow, view, integration, typed reference or App Bundle (Suite).
- [Products and Suites (Guide: Products and Suites)](https://lychd.snayu.ai/ai/docs/compositions/products-and-suites.md): Explains Packaged Offers (Products, a named promise to an operator), App Bundles (Suites, which coordinate live jobs across several apps), Installations (Deployments) and the different kinds of views onto an app.
- [Creative Works (Area: Creative Works)](https://lychd.snayu.ai/ai/docs/compositions/creative-works/index.md): Index of the creative apps: visual work (Atelier, Canvas), music (Riffmaw), dubbing and captions (Language Edition), game builds (Foundry) and publications (Broadcast), each listed with the outcome it produces.
- [Canvas (App: Canvas (drawing board))](https://lychd.snayu.ai/ai/docs/compositions/canvas/index.md): Canvas is a visual whiteboard at /canvas: draw freehand, add nodes and arrows, select part of the board, export it for a model, and review a proposed change before applying it, with undo and local save.
- [Atelier (App: Atelier (visual art))](https://lychd.snayu.ai/ai/docs/compositions/atelier/index.md): Atelier takes a visual commission, such as a still image, animation or visual effects package, from brief to an accepted, traceable result, keeping direction, sources, candidates and approved revisions on record.
- [Brief (Atelier: the visual brief)](https://lychd.snayu.ai/ai/docs/compositions/atelier/brief.md): How Atelier fixes a commission before generation starts: purpose, audience, target format, budget, roles, acceptance criteria and a frozen set of reference images with their rights and consent.
- [Direction (Atelier: visual style rules)](https://lychd.snayu.ai/ai/docs/compositions/atelier/direction.md): How Atelier turns your taste into a reviewable style guide covering palette, composition, light, camera and exclusions, and uses it to judge and correct candidates.
- [Assets (Atelier: making visual assets)](https://lychd.snayu.ai/ai/docs/compositions/atelier/assets.md): How Atelier produces and reviews images, sprites, textures and 3D models as candidates, with full lineage of sources, tools, transforms and review findings.
- [Motion (Atelier: animation and video)](https://lychd.snayu.ai/ai/docs/compositions/atelier/motion.md): How Atelier handles moving visuals: animation, transitions, camera moves and generated video, typically from an accepted first frame through video generation to a reviewed sequence.
- [Package (Atelier: sealed visual package)](https://lychd.snayu.ai/ai/docs/compositions/atelier/package.md): How Atelier seals accepted visuals into a VisualAssetBundle that other apps can inspect, plus how it handles effects, failures, restarts and deletion.
- [Riffmaw (App: Riffmaw (music making))](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/index.md): Riffmaw is the planned music app: describe an idea, bring a reference or performance, hear alternatives and shape the music with AI help, through four roads: Forge, Perform, Jam and Produce.
- [Sources (Riffmaw: reference material)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/sources.md): How Riffmaw admits specific audio files as references and marks an exact musical moment (for example a drop at 01:32) without turning the whole media library into influence.
- [Sessions (Riffmaw: recording and jamming)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/sessions.md): How Riffmaw records performances (takes) and runs live jam sessions with human and machine players on shared, mapped clocks, preserving raw audio and MIDI before any editing.
- [Music Hardware Boundary (Riffmaw: audio hardware routes)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/hardware.md): How Riffmaw admits an exact audio input route (interface, channel, clock, latency, monitoring) for a take, keeping the dry instrument signal separate from the processed sound you hear.
- [Music (Riffmaw: composing and mixing)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/music.md): How Riffmaw develops material into an arrangement, mix and master: composing with models or humans, lyrics and sung language, live answer latency classes, autonomy levels, and mixing and mastering.
- [Studio (Riffmaw: production tools)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/studio.md): The production loop and the replaceable tool roles (planner, generator, analyzer, renderer, live host, mastering and so on), plus a dated map of candidate tools like MiniMax Music 3, DawDreamer and PipeWire.
- [Workbench (Riffmaw: build plan and probes)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/workbench.md): The construction plan for an edit-and-listen music loop, plus a working offline engineering tool: render bounded recipes through DawDreamer, audition them, make guarded edits, and probe a local ComfyUI server.
- [Voice boundary (Riffmaw: vocal boundary)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/voice.md): Explains which vocals Riffmaw owns (singing, rap, musical spoken word, harmonies) and which belong elsewhere, and how performer consent and lyrics are bound to takes.
- [Sound boundary (Riffmaw: sound-effects boundary)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/sound.md): Explains that sound belongs to whichever app judges its intended role: musical textures and effects to Riffmaw, picture-bound effects to Broadcast, game sound to Foundry.
- [Sync (Riffmaw: music cue maps)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/sync.md): How Riffmaw publishes a MusicCueMap: exact musical events (drops, sections, entrances) on a declared timebase that visual or editing apps can respond to without editing the music.
- [Package (Riffmaw: sealed music bundle)](https://lychd.snayu.ai/ai/docs/compositions/riffmaw/package.md): How Riffmaw seals accepted music, stems, mixes and masters into a MusicAssetBundle for other apps, and how it handles effects, recovery, revocation and deletion.
- [Language Edition (App: Language Edition (dubbing, captions))](https://lychd.snayu.ai/ai/docs/compositions/language-edition/index.md): Language Edition produces replacement dialogue, narration, translation and captions aligned to a locked video source, from verified transcript to performance, captions and an optional track replacement.
- [Foundry (App: Foundry (game builds))](https://lychd.snayu.ai/ai/docs/compositions/foundry/index.md): Foundry turns a game idea into a playtested local build another person can reproduce, keeping design, source, imported assets, worlds, game sound, playtests and build receipts.
- [Project (Foundry: project setup)](https://lychd.snayu.ai/ai/docs/compositions/foundry/project.md): How Foundry binds a requested feature to an exact repository revision and pinned engine environment before any code or editor changes the work.
- [Assets (Foundry: importing assets)](https://lychd.snayu.ai/ai/docs/compositions/foundry/assets.md): How Foundry imports visual, music and dialogue bundles into a game engine, recording how each source became an engine asset and returning problems to the producing app as findings.
- [World Sound (Foundry: in-game sound)](https://lychd.snayu.ai/ai/docs/compositions/foundry/sound.md): How Foundry designs world sound tied to exact game events, states, zones and listener positions (door variants, machine loops, ambience zones) and proves it works in the engine.
- [World (Foundry: building game worlds)](https://lychd.snayu.ai/ai/docs/compositions/foundry/world.md): How Foundry compiles an inert world plan (space, placements, spawns, physics, navigation, gameplay) into an engine-native world, with Godot as the first engine candidate.
- [Playtest (Foundry: automated playtests)](https://lychd.snayu.ai/ai/docs/compositions/foundry/playtest.md): How Foundry runs a declared gameplay scenario against an exact build with a restricted controller and records structured engine observations as evidence.
- [Build (Foundry: local build candidate)](https://lychd.snayu.ai/ai/docs/compositions/foundry/build.md): How Foundry tests, builds and freezes a reproducible local game candidate for human review, and why release and distribution stay outside it.
- [Broadcast (App: Broadcast (publishing))](https://lychd.snayu.ai/ai/docs/compositions/broadcast/index.md): Broadcast turns sourced claims into an article or video: evidence ledger, canonical script, picture sound, timeline edit and render, ending in a local publication candidate.
- [Sources (Broadcast: sources and claims)](https://lychd.snayu.ai/ai/docs/compositions/broadcast/sources.md): How Broadcast freezes evidence as snapshots and builds a claim ledger linking each factual claim to supporting spans, confidence and dependent content.
- [Script (Broadcast: canonical script)](https://lychd.snayu.ai/ai/docs/compositions/broadcast/script.md): How Broadcast owns the canonical article, narration, titles and caption words built from claim revisions, and how they feed language editions.
- [Picture-Bound Sound (Broadcast: picture-bound sound)](https://lychd.snayu.ai/ai/docs/compositions/broadcast/sound.md): How Broadcast designs sound tied to exact picture: effects, foley, room tone and ambience judged against a locked cut, including sound returned by video models.
- [Edit (Broadcast: timeline editing)](https://lychd.snayu.ai/ai/docs/compositions/broadcast/edit.md): How Broadcast admits visual, music, language and sound bundles by exact digest and arranges them in one revisioned timeline, with review and bounded repairs.
- [Render (Broadcast: reproducible render)](https://lychd.snayu.ai/ai/docs/compositions/broadcast/render.md): How Broadcast renders a reproducible, accessible local candidate by pinning every input and setting, then probing the output.
- [Release (Broadcast: publishing and corrections)](https://lychd.snayu.ai/ai/docs/compositions/broadcast/release.md): How Broadcast publishes a candidate to an external destination as a separate approved effect, and later issues corrections or takedowns.
- [Stewardship & Acquisition (Area: Stewardship & Acquisition)](https://lychd.snayu.ai/ai/docs/compositions/stewardship-and-acquisition/index.md): Index of apps that care for people, animals, plants, places and supplies: Health, Wellbeing, Homestead, Keeper, Cultivator and Scavenger, each with its outcome.
- [Health (App: Health (medical records))](https://lychd.snayu.ai/ai/docs/compositions/health/index.md): Health helps one consenting adult turn medical documents into a reviewed, correctable clinical history, discuss one health question, and carry diagnostic or treatment proposals to a qualified human.
- [Health record assimilation (Health: importing medical records)](https://lychd.snayu.ai/ai/docs/compositions/health/assimilation.md): How Health turns photographed or typed medical records into source-linked claims and, after review, a new profile revision, keeping originals, OCR and extracted claims separate.
- [Health consultation (Health: one health question)](https://lychd.snayu.ai/ai/docs/compositions/health/consultation.md): How Health reviews one bounded health question against the reviewed profile and proposes next diagnostic steps without declaring a diagnosis.
- [Health care planning (Health: treatment options and follow-up)](https://lychd.snayu.ai/ai/docs/compositions/health/care.md): How Health compares treatment options for human review, binds an exact approval, and records follow-up of what actually happened.
- [Wellbeing (App: Wellbeing (food and movement))](https://lychd.snayu.ai/ai/docs/compositions/wellbeing/index.md): Wellbeing helps one adult plan meals and ordinary exercise that fit their restrictions, time and kitchen, edit the plan, and record what actually happened.
- [Profile (Wellbeing: personal profile)](https://lychd.snayu.ai/ai/docs/compositions/wellbeing/profile.md): How Wellbeing stores a person's restrictions, preferences, equipment and consent as immutable revisions with provenance, plus export and deletion.
- [Eating (Wellbeing: meal planning)](https://lychd.snayu.ai/ai/docs/compositions/wellbeing/eating.md): How Wellbeing plans meals from restrictions, available food, time and equipment, with strict hard-constraint checks and minimal handoffs to Homestead.
- [Fitness (Wellbeing: movement plans)](https://lychd.snayu.ai/ai/docs/compositions/wellbeing/fitness.md): How Wellbeing fits ordinary exercise within the person's time, equipment and limits, and records only confirmed outcomes.
- [Journal (Wellbeing: check-ins and journal)](https://lychd.snayu.ai/ai/docs/compositions/wellbeing/journal.md): How Wellbeing records confirmed check-ins, skips, substitutions and the person's own reflections, separate from what was planned.
- [Homestead (App: Homestead (household stores))](https://lychd.snayu.ai/ai/docs/compositions/homestead/index.md): Homestead tracks a household's equipment, energy and water, stores, ordinary shopping and maintenance, working from manual records or commissioned devices.
- [Utilities (Homestead: energy and water)](https://lychd.snayu.ai/ai/docs/compositions/homestead/utilities.md): How Homestead observes and balances energy, water, fuel and network resources, and handles environment requests from Keeper or Cultivator within commissioned device limits.
- [Stores (Homestead: pantry and stores)](https://lychd.snayu.ai/ai/docs/compositions/homestead/stores.md): How Homestead tracks food and supplies as lots with quantity ranges built from receipts, harvests, confirmed use and corrections.
- [Provision (Homestead: shopping and orders)](https://lychd.snayu.ai/ai/docs/compositions/homestead/provision.md): How Homestead turns approved needs into shop offers, carts and a single checkout, reporting what became available, substituted or uncertain.
- [Maintenance (Homestead: repairs and maintenance)](https://lychd.snayu.ai/ai/docs/compositions/homestead/maintenance.md): How Homestead tracks a fault from first report through a bounded work order to verified closure, including parts sourcing and inspection cameras.
- [Keeper (App: Keeper (animal care))](https://lychd.snayu.ai/ai/docs/compositions/keeper/index.md): Keeper records the life of animals and colonies, from pets to livestock and ant colonies: identity, housing, life changes, feeding and care events.
- [Keeper subjects (Keeper: animals and observations)](https://lychd.snayu.ai/ai/docs/compositions/keeper/subjects.md): How Keeper establishes a durable identity for an animal, group or colony, attaches a reviewed care profile, and records observations.
- [Keeper territory (Keeper: housing and placement)](https://lychd.snayu.ai/ai/docs/compositions/keeper/territory.md): How Keeper records enclosures, where an animal actually is, proposed moves, and environment requests sent to Homestead.
- [Keeper lifecycle (Keeper: life stages)](https://lychd.snayu.ai/ai/docs/compositions/keeper/lifecycle.md): How Keeper reviews development, breeding, seasonal mode and placement as separate axes and proposes changed requirements.
- [Keeper feeding (Keeper: feeding plans)](https://lychd.snayu.ai/ai/docs/compositions/keeper/feeding.md): How Keeper proposes feeding plans from reviewed profiles, requests supplies from Homestead, and keeps food offered separate from food eaten.
- [Keeper care (Keeper: care records and yields)](https://lychd.snayu.ai/ai/docs/compositions/keeper/care.md): How Keeper records care that was done (feeding, cleaning, transfers) and collected material like eggs or milk as yield receipts for Homestead stores.
- [Cultivator (App: Cultivator (plants and fungi))](https://lychd.snayu.ai/ai/docs/compositions/cultivator/index.md): Cultivator records the life of plants and cultivated fungi: identity, growing space, cycles, tending and harvests, for ornament, food, seed or propagation.
- [Culture records (Cultivator: plant records)](https://lychd.snayu.ai/ai/docs/compositions/cultivator/cultures.md): How Cultivator identifies a plant, batch or fungi culture, tracks lineage through cuttings and splits, pins a growing profile and records observations.
- [Growing space (Cultivator: pots and beds)](https://lychd.snayu.ai/ai/docs/compositions/cultivator/growing-space.md): How Cultivator records containers, substrate and placement, and sends reviewed environment needs to Homestead.
- [Lifecycle (Cultivator: growth cycles)](https://lychd.snayu.ai/ai/docs/compositions/cultivator/lifecycle.md): How Cultivator reviews development and recurring seasons for annuals, perennials and fungi without forcing universal stages.
- [Tending (Cultivator: watering and tending)](https://lychd.snayu.ai/ai/docs/compositions/cultivator/tending.md): How Cultivator plans watering, repotting and pruning with safe bounds, requests supplies, and records what work actually happened.
- [Harvest (Cultivator: harvest records)](https://lychd.snayu.ai/ai/docs/compositions/cultivator/harvest.md): How Cultivator records each harvest as a receipt and hands it to Homestead stores, keeping collection and store acceptance separate.
- [Scavenger (App: Scavenger (smart shopping))](https://lychd.snayu.ai/ai/docs/compositions/scavenger/index.md): Scavenger runs a finite buying campaign for second-hand items, tech parts or property: watching listings, qualifying and ranking candidates, negotiating, committing and receiving parcels.
- [Campaign (Scavenger: campaign setup)](https://lychd.snayu.ai/ai/docs/compositions/scavenger/campaign.md): How a Scavenger campaign fixes the need, budget, deadline, region, criteria and autonomy level, with subject profiles for Bazaar, Technology and Property.
- [Market (Scavenger: watching listings)](https://lychd.snayu.ai/ai/docs/compositions/scavenger/market.md): How Scavenger observes a finite market snapshot, keeps the whole candidate field, filters it locally, qualifies and ranks candidates, and learns from your judgments.
- [Bargain (Scavenger: seller negotiation)](https://lychd.snayu.ai/ai/docs/compositions/scavenger/bargain.md): How Scavenger sends approved questions or offers to sellers within fixed limits and stops automatic messaging on refusal, silence or expiry.
- [Acquisition (Scavenger: purchase and delivery)](https://lychd.snayu.ai/ai/docs/compositions/scavenger/acquisition.md): How Scavenger commits to approved terms, checks arriving parcels, and records acceptance, dispute, return or loss.
- [Presence & Embodiment (Apps: Presence and embodiment)](https://lychd.snayu.ai/ai/docs/compositions/presence-and-embodiment/index.md): Index of the apps that put the Assistant somewhere: a chat channel, a game world, a VR room, a physical robot or a phone.
- [Blockworld (App: Blockworld (Minecraft missions))](https://lychd.snayu.ai/ai/docs/compositions/blockworld/index.md): An app that lets the Assistant act in a Minecraft-style world for one finite mission, such as building a reviewed blueprint on a private plot, with receipts for every placed block and recovery after interruption.
- [Companion lab (Blockworld: Companion lab)](https://lychd.snayu.ai/ai/docs/compositions/blockworld/companion-lab.md): An experimental Minecraft profile where you speak or type a short instruction (Slovak, Czech or English) to a controlled wolf NPC, see it queued, and get a result tied to what the server actually did.
- [Horizon assist (Blockworld: Horizon assist)](https://lychd.snayu.ai/ai/docs/compositions/blockworld/horizon-assist.md): An experimental profile where the operator speaks a short instruction while playing and a separately controlled Horizon game client performs one bounded action (follow, build a few cells, look) and reports what it observed.
- [Playing with a companion (Blockworld: Playing with a companion)](https://lychd.snayu.ai/ai/docs/compositions/blockworld/horizon-play.md): User stories and acceptance trials for playing Minecraft with a companion: prepare, speak, observe, follow, build a few blocks and leave, with clear feedback and a quiet idle state.
- [Mission (Blockworld: Mission)](https://lychd.snayu.ai/ai/docs/compositions/blockworld/mission.md): How one Minecraft mission is admitted (exact bot, world, plot, blueprint, deadline and budgets) and how a single block placement is prepared, frozen and reviewed before it can run.
- [Sentinel (Blockworld: Sentinel (action guard))](https://lychd.snayu.ai/ai/docs/compositions/blockworld/sentinel.md): The guard between the Assistant's proposed action and the game server: it checks each read or effect against the mission, and only issues a receipt when the server's own evidence confirms the result.
- [Continuity (Blockworld: Recovery after interruption)](https://lychd.snayu.ai/ai/docs/compositions/blockworld/continuity.md): Where each kind of truth lives (world, app records, mission/action records, volatile adapter state) and how Blockworld reconciles an uncertain action after a crash or restore before continuing.
- [Reach (App: Reach (external channels))](https://lychd.snayu.ai/ai/docs/compositions/reach/index.md): An app that prepares and sends the Assistant's messages in outside places: email (Gmail, Fastmail), chat (Discord, Telegram, WhatsApp), code forges (GitHub) and social posts, plus a public Discord bot profile.
- [Connected preparation (Reach: Offline message preparation)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/preparation.md): An offline tool that prepares a ready-to-send request for Gmail, Fastmail, Discord, Telegram, WhatsApp, GitHub or social posts, recording account, target, payload, policy and expiry, without connecting to any provider.
- [Email (Reach: Email family)](https://lychd.snayu.ai/ai/docs/compositions/reach/email.md): How Reach represents an email request (sender, recipients, subject, content, reply references) and how Gmail and Fastmail each translate it into their own protocol.
- [Gmail connection (Reach: Gmail connection)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/gmail.md): A proposed profile for connecting one Gmail or Google Workspace mailbox, choosing what Reach may read, and preparing replies, including Google's registration, consent and verification hurdles.
- [Fastmail connection (Reach: Fastmail connection)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/fastmail.md): How Reach prepares a Fastmail read or send using the JMAP protocol, keeping account, sender identity, draft mailbox and recipient envelope explicit.
- [Chat (Reach: Chat family)](https://lychd.snayu.ai/ai/docs/compositions/reach/chat.md): How Reach represents a chat message for one exact conversation and how Discord, Telegram and WhatsApp Business each build it with their own identifiers and rules.
- [Prepare Reachy (Reach: Set up the Reachy Discord bot)](https://lychd.snayu.ai/ai/docs/compositions/reach/preparation.md): A step-by-step guide to create a private Discord application named Reachy, invite it to your own server, copy IDs and validate local policy while the bot stays offline.
- [Reach preparation architecture (Reach: Preparation architecture)](https://lychd.snayu.ai/ai/docs/compositions/reach/architecture.md): How Reach keeps platform-specific details at the edge: events are normalized into shared concepts (platform, account, space, conversation, subject), checked against policy, and only then enter a workflow.
- [Discord operator profile (Reach: Discord operator profile)](https://lychd.snayu.ai/ai/docs/compositions/reach/operator.md): A Linux development profile that runs a real Discord bot for a small server: a token-holding edge, a networkless documents worker that answers from public docs, and local operator commands for server setup.
- [Discord connection (Reach: Discord connection)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/discord.md): A proposed profile for installing Reach in a Discord server with selected channels, slash commands and direct mentions, answering one admitted question per response, plus proposed workflow views in the Run Inspector.
- [Telegram connection (Reach: Telegram connection)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/telegram.md): How Reach prepares a Telegram bot message for an exact numeric chat, and why reading chat history and personal-account access are outside this profile.
- [WhatsApp assessment (Reach: WhatsApp assessment)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/whatsapp.md): An assessment of WhatsApp options for Reach: business messaging via Meta's Cloud API, general AI assistant use, and Meta's limited third-party agent platform.
- [Forge (Reach: Forge family (code hosts))](https://lychd.snayu.ai/ai/docs/compositions/reach/forge.md): How Reach reads a bounded issue conversation or prepares an issue/PR comment on a code host, kept separate from any permission to change or run code.
- [GitHub connection (Reach: GitHub connection)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/github.md): A proposed GitHub App profile where a repository owner installs Reach on selected repos so it can read issue/PR conversations and post timeline comments as a bot.
- [Social (Reach: Social family)](https://lychd.snayu.ai/ai/docs/compositions/reach/social.md): How Reach prepares an original public text post for a Facebook Page, a LinkedIn member or organization, or an X account, keeping the exact publishing author.
- [Social accounts and advertising (Reach: Social accounts and advertising)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/social.md): An assessment of what account access each social provider (Facebook, LinkedIn, X) requires for posting, and why posting permission never becomes permission to run paid advertising.
- [Habitat (Reach: Discord server boundary)](https://lychd.snayu.ai/ai/docs/compositions/reach/habitat.md): Defines the first public social place: one private Discord server, one channel, and a minimal-permission bot, and how Discord identity is kept separate from local authority.
- [Turn (Reach: One question-and-answer turn)](https://lychd.snayu.ai/ai/docs/compositions/reach/turn.md): The step-by-step life of one Discord question: authenticate and deduplicate, resolve caller authority, assemble the briefing, commit the answer, then attempt delivery and record whether it arrived.
- [Deployment profiles (Reach: Deployment profiles)](https://lychd.snayu.ai/ai/docs/compositions/reach/deployments/index.md): Compares three ways to deploy the public Reach bot: all at home, a VPS edge relaying to a home core, or a standalone VPS, and what each means for availability and security.
- [Home-only (Reach deployment: Home-only)](https://lychd.snayu.ai/ai/docs/compositions/reach/deployments/home-public.md): The home-only Reach profile: every service, record and credential stays on one home machine with outbound-only connections, so Reach is unavailable whenever home is down.
- [VPS edge + home core (Reach deployment: VPS edge, home core)](https://lychd.snayu.ai/ai/docs/compositions/reach/deployments/vps-edge-home-core.md): A split profile where a VPS only holds the Discord connection and a bounded message spool, relaying over a private WireGuard tunnel to home, where all thinking, data and authority stay.
- [Standalone VPS (Reach deployment: Standalone VPS)](https://lychd.snayu.ai/ai/docs/compositions/reach/deployments/vps-public.md): A standalone restricted Reach on a VPS with its own database and services, plus the shared end-to-end contract for answering one public Discord question from a public docs corpus.
- [Avatar (App: Avatar (appearance across places))](https://lychd.snayu.ai/ai/docs/compositions/avatar/index.md): An app that keeps the Assistant's chosen appearance (look, voice, motion) consistent and attributable across places like VR and Minecraft, recording what each place reported.
- [Profile and Morphe (Avatar: Profile and form selection)](https://lychd.snayu.ai/ai/docs/compositions/avatar/profile.md): How an avatar profile bundles visual, voice, motion, locale and disclosure references for one persona, and how a Morphe picks a style within it without changing who the persona is.
- [Presence across places (Avatar: Presence across places)](https://lychd.snayu.ai/ai/docs/compositions/avatar/presence.md): How Avatar admits a separate projection for each place (VR room, game world), supports mirrored or parallel presence, and handles one place dropping out without inventing its state.
- [Spectre (App: Spectre (VR meetings))](https://lychd.snayu.ai/ai/docs/compositions/spectre/index.md): The VR app: it admits a virtual place (VR Habitat) and runs one bounded meeting (Encounter) with participants, consent, events, interruption and exit.
- [Admitting a VR Habitat (Spectre: Admitting a VR place)](https://lychd.snayu.ai/ai/docs/compositions/spectre/habitat.md): How a VR place is checked and recorded: exact world build, runtime capabilities, seated or room-scale space, comfort, accessibility and a visible exit.
- [Entering and leaving an Encounter (Spectre: Entering and leaving a meeting)](https://lychd.snayu.ai/ai/docs/compositions/spectre/encounter.md): How one VR meeting is admitted, how runtime events (focus loss, revoked tracking, disconnects) are recorded, how each participant can leave, and how the meeting is settled.
- [Familiar (App: Familiar (physical bodies))](https://lychd.snayu.ai/ai/docs/compositions/familiar/index.md): An app for physical bodies such as drones, rovers, robots and phones: it admits a body's exact capabilities and stop path, then runs bounded missions like following a person, keeping observations and effects attributable.
- [Embodiment (Familiar: Admitting a physical body)](https://lychd.snayu.ai/ai/docs/compositions/familiar/embodiment.md): How a specific physical body is admitted with its exact hardware, sensors, actuators, operating limits and stop behaviour, with example considerations for drones, rovers, legged robots, phones and cars.
- [Follow (Familiar: Follow mission)](https://lychd.snayu.ai/ai/docs/compositions/familiar/follow.md): A bounded mission where a body follows a designated, consenting person along a path, pauses to talk, handles obstacles and signal loss, and reports exactly where it stopped.
- [Robotic Dance (Familiar: Robotic dance (idea))](https://lychd.snayu.ai/ai/docs/compositions/familiar/dance.md): A candidate use case where a person wearing motion trackers leads a group of robots in a dance, with each robot adapting the movement to its body, plus related research.
- [Companion (App: Companion (phone client))](https://lychd.snayu.ai/ai/docs/compositions/companion/index.md): The mobile app: press to speak, review the words, submit a request, and later see or hear the result.
- [Utterance (Companion: One spoken request)](https://lychd.snayu.ai/ai/docs/compositions/companion/utterance.md): How one push-to-talk utterance is authenticated, transcribed, reviewed and submitted as a request handoff, and how the result is later presented as text or speech.
- [Return (Companion: Reconnecting)](https://lychd.snayu.ai/ai/docs/compositions/companion/return.md): What happens when the phone reconnects: it looks up the settled handoff or result instead of resending audio, and how local drafts expire and stay in memory only.
- [Companion Android Development (Companion: Android development slice)](https://lychd.snayu.ai/ai/docs/compositions/companion/android-development.md): The first Android implementation: a Kotlin/Compose debug screen talking to a fake Chat fixture, plus bounded microphone recording and local replay.
- [Companion Access and Views (Companion: Access and views)](https://lychd.snayu.ai/ai/docs/compositions/companion/access-and-views.md): How the phone app decides which screens and actions to show, based on the authorized instance, account, work context and enrolled device, never on role names alone.
- [Professional Operations (Apps: Professional operations)](https://lychd.snayu.ai/ai/docs/compositions/professional-operations/index.md): Index of apps for client casework: Broker (insurance office cases) and Creation investigation (software questions), with a pointer to the Accounting Office study.
- [Creation investigation (App: Creation (software investigation))](https://lychd.snayu.ai/ai/docs/compositions/creation/index.md): An app that answers one bounded question about public source code, such as whether a test proves a change, by building an answer and then having a separate reviewer challenge it, keeping everything retained.
- [Broker (App: Broker (insurance office))](https://lychd.snayu.ai/ai/docs/compositions/broker/index.md): An app for a Slovak insurance intermediary handling client requests (starting with compulsory motor liability insurance): it carries each case to an answer, a prepared act, a human handoff or a clear blocker.
- [Cases (Broker: Service cases)](https://lychd.snayu.ai/ai/docs/compositions/broker/cases.md): How each client contact becomes a service case with its own purpose, evidence, checks, review and single submission, so the next staff member can see exactly where it stands.
- [Insurance Product Knowledge (Broker: Insurance product knowledge)](https://lychd.snayu.ai/ai/docs/compositions/broker/products.md): How Broker keeps dated, attributable insurance product releases (coverage, exclusions, eligibility, pricing) and makes comparisons that state exactly which offers and criteria were considered.
- [Channels (Broker: Channels and views)](https://lychd.snayu.ai/ai/docs/compositions/broker/channels.md): How clients, staff and technical operators each get their own view (Business Console, Client Web, Control Panel) and how incoming messages and outgoing answers are handled safely.
- [Connected work study (Reach: Connected work study)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/index.md): A candidate study for a successor Reach that answers private email, GitHub issues and Discord mentions from the right account, plus optional WhatsApp, without mixing customers' data or authority.
- [Accounts and updates (Reach: Accounts and updates)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/accounts.md): The proposed onboarding for connecting Gmail, Discord and GitHub: registering provider apps, authorizing each account, assigning local policy, and handling updates and secret custody.
- [Acceptance and delivery (Reach: Acceptance and delivery plan)](https://lychd.snayu.ai/ai/docs/compositions/reach/connected-work/delivery.md): The ordered implementation plan for connected Reach: close the contract, prove preparation, prove durable delivery, then qualify Gmail, Discord and GitHub, with failure tests for each.
- [Companion Android Foundation (Companion: Android foundation study)](https://lychd.snayu.ai/ai/docs/compositions/companion/android-foundation.md): A candidate study for building the live Android client on a Samsung S20 FE: pairing with LychD, voice capture, transcript review, submission and spoken replies, with chosen languages, frameworks and API rules.
- [Companion Phone Workspace (Companion: Phone workspace study)](https://lychd.snayu.ai/ai/docs/compositions/companion/phone-workspace.md): A candidate direction for Companion to grow into an everyday phone workspace, starting with an offline music player, then selected photos and explicit file copy, each a revocable capability.
- [Thorn (App: Thorn (security workbench))](https://lychd.snayu.ai/ai/docs/compositions/thorn/index.md): A proposed whitehat security app that turns a scoped security question or incident into supported findings, a bounded protective response, and an accountable report or correction.
- [Follow the Campaign (Thorn: Following an attack campaign)](https://lychd.snayu.ai/ai/docs/compositions/thorn/investigation.md): How Thorn investigates: open leads with answerable questions, ask other defenders for bounded evidence, keep hostile material from steering the work, and return correctable findings.
- [Thorn Response Policy (Thorn: Response policy presets)](https://lychd.snayu.ai/ai/docs/compositions/thorn/response-policy.md): Proposed presets for how hard Thorn works: Iron Shield (just protect), Guided Inquiry (suggest leads) and Hornet (actively pursue), with each control adjustable separately.
- [Thorn Trials (Thorn: Trial plan)](https://lychd.snayu.ai/ai/docs/compositions/thorn/trials.md): An unexecuted trial plan to prove Thorn is useful, using synthetic defenders and simulated attacks to compare its case coordination against ordinary local protection.
- [Accounting Office (App: Accounting Office (bookkeeping))](https://lychd.snayu.ai/ai/docs/compositions/accounting-office/index.md): A candidate app for one business's bookkeeping: connect invoices and bank movements, review journal entries, reconcile, and close a period with clear exceptions and handoffs to an accountant.
- [Knowledge and obligations (Accounting Office: Rules and obligations)](https://lychd.snayu.ai/ai/docs/compositions/accounting-office/knowledge-and-obligations.md): A study on turning published accounting and tax rules into entity-specific obligations: researching questions, getting scoped professional review, and scheduling what a business actually must do.
- [Transmuter (App: Transmuter (archive import))](https://lychd.snayu.ai/ai/docs/compositions/transmuter/index.md): A candidate app that works through conversation archives and attachments, identifies what each source actually says, and prepares grounded proposals for memories or persona changes.
- [Extractor (Transmuter: Extractor stage)](https://lychd.snayu.ai/ai/docs/compositions/transmuter/extractor.md): The stage that splits imported material into source-located units with author, timestamps, proposed names, labels and uncertainty, separating what is in the source from what a model infers.
- [Synthesizer (Transmuter: Synthesizer stage)](https://lychd.snayu.ai/ai/docs/compositions/transmuter/synthesizer.md): The stage that relates extracted units to dates, purposes and existing knowledge, groups them into claims and contradictions, and prepares reviewable proposals for memory, persona or training.
- [Workshop (App: Workshop (vehicle service cases))](https://lychd.snayu.ai/ai/docs/compositions/workshop/index.md): A candidate app for guided repair diagnosis, starting with car service (the proposed 'Mechanic' product): it keeps the vehicle, symptoms, hypotheses, checks and results together until a scoped outcome or handoff.
- [Lexicon (Glossary overview)](https://lychd.snayu.ai/ai/docs/lexicon/index.md): Entry page to the two glossaries: the Iron Tongue for technical project terms and the Inner Tongue for the philosophical and inherited words.
- [Iron Tongue (Glossary: technical terms)](https://lychd.snayu.ai/ai/docs/lexicon/iron-tongue.md): Alphabetical dictionary of LychD's technical lore names (Agent, Altar, Animator, Run, Scroll, Vessel and many more), each with a short meaning and a link to its owning page or design rule.
- [Inner Tongue (Glossary: philosophical terms)](https://lychd.snayu.ai/ai/docs/lexicon/inner-tongue.md): Glossary of the philosophical vocabulary (Mechamancy, Consciousness vs Cognizance, the EGO, Emotion and Will, Polypsyche) and source notes for words borrowed from Sanskrit, Greek, Kabbalah and others.
- [Covenants (Design rules index)](https://lychd.snayu.ai/ai/docs/adr/index.md): The index of LychD's 43 numbered design rules (Architecture Decision Records, called Covenants), grouped by area: foundation, core runtime, agents and memory, and senses and networking.
- [0. License (Design rule 00: The license)](https://lychd.snayu.ai/ai/docs/adr/00-license.md): Explains why LychD uses the MPL-2.0 license (the Iron Pact): changes you distribute to core files must stay open, while separate files you add can carry their own terms.
- [1. Philosophy (Design rule 01: Development philosophy)](https://lychd.snayu.ai/ai/docs/adr/01-doctrine.md): Sets out how LychD is built: Docs-First Development (xDDD), where the written spec comes first, then the domain model, tests, code and observed results.
- [2. Documentation (Design rule 02: Documentation tooling)](https://lychd.snayu.ai/ai/docs/adr/02-documentation.md): A historical record of why the official docs are plain Markdown built with Zensical and kept in the same repository as the code, and how different kinds of writing (rules, guides, lore) are kept apart.
- [3. Quality (Design rule 03: Code quality tools)](https://lychd.snayu.ai/ai/docs/adr/03-quality.md): Fixes the shared Python toolchain - uv for dependencies, Ruff for linting and formatting, BasedPyright for strict type checks and pytest for tests - all run through one Makefile so any failure can be reproduced.
- [4. Testing (Design rule 04: Testing approach)](https://lychd.snayu.ai/ai/docs/adr/04-testing.md): Defines how LychD is tested: pytest with typed fixtures and Polyfactory test data, run inside a dedicated test container, with markers that say what kind of evidence each test provides.
- [5. Extensions (Design rule 05: Extensions)](https://lychd.snayu.ai/ai/docs/adr/05-extensions.md): Decides how features plug into LychD: either as trusted in-process Python contributions accepted by a named owner, or as separate external services.
- [6. Persistence (Design rule 06: Persistence)](https://lychd.snayu.ai/ai/docs/adr/06-persistence.md): Decides that all committed data lives in one PostgreSQL database, the Memory Vault (Phylactery), accessed through async SQLAlchemy and asyncpg.
- [7. Snapshots (Design rule 07: Whole-system snapshots)](https://lychd.snayu.ai/ai/docs/adr/07-snapshots.md): Defines how a whole-system checkpoint must be taken and restored: stop new work, drain or park running jobs, pause writers, then capture every store together with a manifest of exact code, config and image versions.
- [8. Containers (Design rule 08: Containers and services)](https://lychd.snayu.ai/ai/docs/adr/08-containers.md): Decides that LychD runs as rootless Podman containers managed by systemd user units (Quadlets), with no external control plane.
- [9. Security (Design rule 09: Security boundaries)](https://lychd.snayu.ai/ai/docs/adr/09-security.md): Defines the trust zones of LychD - the server, an optional gateway host, sandboxes for running untrusted code (Tomb) and for foreign agents (Coffin) - what each may hold, and how data leaving for cloud models passes a Privacy Filter.
- [10. Privilege (Design rule 10: Host privileges)](https://lychd.snayu.ai/ai/docs/adr/10-privilege.md): Defines how actions that change the host (starting services, writing units) are requested and performed.
- [11. Backend (Design rule 11: Server application)](https://lychd.snayu.ai/ai/docs/adr/11-backend.md): Decides that the Engine Room (Vessel) is one Litestar web application built once in create_app(), run as a single Granian process and event loop, with HTTP, database, extensions and workers assembled and shut down in order.
- [12. Configuration (Design rule 12: Configuration)](https://lychd.snayu.ai/ai/docs/adr/12-configuration.md): Defines how settings are loaded: one typed Settings model from lychd.toml in the Settings Folder (Codex), plus validated Service Config Files (Runes) for models and services, all checked before they can generate infrastructure.
- [13. Layout (Design rule 13: Folder layout)](https://lychd.snayu.ai/ai/docs/adr/13-layout.md): Defines where LychD keeps files, following XDG: Settings Folder (~/.config/lychd), Data Folder or Crypt (~/.local/share/lychd) and a disposable build cache (~/.cache/lychd), and which paths it may create, change or delete.
- [14. Workers (Design rule 14: Background workers)](https://lychd.snayu.ai/ai/docs/adr/14-workers.md): Defines how jobs run: each job is first recorded as a Job Record (Run) in the database, then executed by in-process SAQ queue workers (Ghouls).
- [15. Frontend (Design rule 15: Web control panel)](https://lychd.snayu.ai/ai/docs/adr/15-frontend.md): Defines the Control Panel (Altar): a static SvelteKit front end with no server-side rendering, using TypeScript types generated from the backend's OpenAPI.
- [16. SDLC (Design rule 16: Software change lifecycle)](https://lychd.snayu.ai/ai/docs/adr/16-sdlc.md): Defines how a code change moves from request through candidate work, verification and delivery: each handoff keeps its evidence, and only the owner of the target system may apply the change.
- [17. Packaging (Design rule 17: Packaging and releases)](https://lychd.snayu.ai/ai/docs/adr/17-packaging.md): Defines how source, dependencies, the built web UI, license notices and build evidence are bound into inspectable release artifacts.
- [18. Evolution (Design rule 18: Updating the system)](https://lychd.snayu.ai/ai/docs/adr/18-evolution.md): Defines how LychD adopts upstream updates while keeping local changes: the update is built, merged, migration-rehearsed and verified as an inactive candidate, then started as a new generation with a recorded recovery point.
- [19. CLI (Design rule 19: Command line)](https://lychd.snayu.ai/ai/docs/adr/19-cli.md): Defines the Command Line (Pulse), the lychd command: a small, closed set of verbs (init, bind, start, stop, status, logs, access, del) that name operator intent and delegate to typed services.
- [20. Agents (Design rule 20: Agents)](https://lychd.snayu.ai/ai/docs/adr/20-agents.md): Defines an Agent as one typed thinking step with fixed instructions and output contract, while the model, settings, tools and permissions are attached fresh for each step.
- [21. Context (Design rule 21: Briefing pack assembly)](https://lychd.snayu.ai/ai/docs/adr/21-context.md): Defines how the Briefing Pack (Context) given to a model is built: typed, ordered layers - stable rules, environment, history, continuation and the query - kept within the model's limits.
- [22. Dispatcher (Design rule 22: Model selection)](https://lychd.snayu.ai/ai/docs/adr/22-dispatcher.md): Defines the Traffic Controller (Dispatcher), which matches a request's needed capability to a ready model and issues a temporary Model Pass (grant).
- [23. Orchestrator (Design rule 23: Model runtime management)](https://lychd.snayu.ai/ai/docs/adr/23-orchestrator.md): Defines the Stage Manager (Orchestrator), the single owner of starting and stopping local model runtimes.
- [24. Graph (Design rule 24: Step maps and pausing)](https://lychd.snayu.ai/ai/docs/adr/24-graph.md): Defines how a workflow runs as a Step Map (Graph) using Pydantic Graph: serial steps, checked against a pinned manifest, that can checkpoint, Pause (Stasis) for approvals or hardware, and resume without replaying from the start.
- [25. HitL (Design rule 25: Human approval)](https://lychd.snayu.ai/ai/docs/adr/25-hitl.md): Defines the Approval Step (consent): an agent may propose an effect but never authorize it.
- [26. A2A (Design rule 26: Agent-to-agent calls)](https://lychd.snayu.ai/ai/docs/adr/26-a2a.md): Defines the Agent-to-Agent Line (Intercom): how one independent LychD install asks another for bounded work, sending requests and results, never weights, credentials or internal state.
- [27. Memory (Design rule 27: Long-term memory)](https://lychd.snayu.ai/ai/docs/adr/27-memory.md): Defines Long-term Memory (Archive): records, sources, policy and lifecycle stored in PostgreSQL with pgvector indexes behind LychD's own interfaces.
- [28. Workflow (Design rule 28: Workflows and apps)](https://lychd.snayu.ai/ai/docs/adr/28-workflow.md): Defines the Workflow Engine (Spellweaver): who owns each Workflow (Pattern) and its versions, how an App (Composition) publishes workflows, and how one exact workflow version is selected, run, paused and migrated.
- [29. Observability (Design rule 29: Observability)](https://lychd.snayu.ai/ai/docs/adr/29-observability.md): Defines how logs, events and traces make execution understandable without becoming authority.
- [30. Webcrawler (Design rule 30: Web fetching)](https://lychd.snayu.ai/ai/docs/adr/30-webcrawler.md): Defines the Web Fetcher (Scout): every web action - search, fetch, extract, crawl, render, download and so on - is a separate permitted effect with its own limits, and fetched content is treated as untrusted with its source kept.
- [31. Simulation (Design rule 31: What-if simulation)](https://lychd.snayu.ai/ai/docs/adr/31-simulation.md): Defines the What-if Simulator (Shadow): exploring alternative branches against a pinned starting point, with separate roles proposing (Dancer) and reviewing (Hunter) branches, while the target owner decides any real change.
- [32. Identity (Design rule 32: Personas and attribution)](https://lychd.snayu.ai/ai/docs/adr/32-identity.md): Defines the Persona Keeper (Mirror): it owns persona definitions and revisions, binds an exact persona version to a job, and keeps attribution between people and machinery.
- [33. Training (Design rule 33: Model training)](https://lychd.snayu.ai/ai/docs/adr/33-training.md): Defines the Model Trainer (Soulforge): only explicitly admitted data can become a training corpus, training runs in isolation, and the resulting model must pass independent evaluation and an explicit promotion decision before serving.
- [34. Evaluation (Design rule 34: Evaluation)](https://lychd.snayu.ai/ai/docs/adr/34-evaluation.md): Defines the Evaluator (Drift): it tests an exact version of a model, workflow or app against a declared goal and real conditions, using versioned test suites and rubrics, and reports findings with uncertainty.
- [35. Assimilation (Design rule 35: Adopting outside code)](https://lychd.snayu.ai/ai/docs/adr/35-assimilation.md): Defines how external code or ideas are re-written as attributable local LychD code under the Smith area: the result is only a candidate that must pass review, testing and a separate promotion before use.
- [36. Vision (Design rule 36: Vision and images)](https://lychd.snayu.ai/ai/docs/adr/36-vision.md): Defines Vision & Media (Prism): images, video and documents are handled as tracked artifacts with custody, permissions and safe decoding, and every transformation keeps a record of its source.
- [37. Audio (Design rule 37: Voice and audio)](https://lychd.snayu.ai/ai/docs/adr/37-audio.md): Defines Voice (Echo): speech-to-text and text-to-speech treat audio as a timeline with capture consent, privacy, interruption and delivery tracking, rather than as text with an attachment.
- [38. IAM (Design rule 38: Identity and access)](https://lychd.snayu.ai/ai/docs/adr/38-iam.md): Defines the Security Desk (Ward) as the single authority for who someone is and what they may do: principals, users, credentials, sessions, ID Badges (Sigils), roles and grants, all starting with zero power.
- [39. VPN (Design rule 39: Private network (VPN))](https://lychd.snayu.ai/ai/docs/adr/39-vpn.md): Defines the Tether extension: a self-hosted WireGuard tunnel giving the operator a private road to the host.
- [40. Proxy (Design rule 40: Reverse proxy)](https://lychd.snayu.ai/ai/docs/adr/40-proxy.md): Defines the Veil extension: Caddy as an optional, separately managed reverse proxy handling TLS, certificates and routes for remote access, without becoming a second authority over the application.
- [41. Toll (Design rule 41: Payments)](https://lychd.snayu.ai/ai/docs/adr/41-x402.md): Defines Toll, an optional payments area with two parts: a ledger for quotes, budgets and accounting, and a separate gate that performs one verified, hard-to-reverse settlement.
- [42. Multinode (Design rule 42: Multiple machines)](https://lychd.snayu.ai/ai/docs/adr/42-multinode.md): Defines how one operator's control plane can delegate bounded work to other machines they own through node agents (Legion), without sharing the database or letting a scheduler override what each node knows about itself.
- [Communion moved to Companion](https://lychd.snayu.ai/ai/docs/compositions/communion/index.md)
- [Communion Return moved to Companion](https://lychd.snayu.ai/ai/docs/compositions/communion/return.md)
- [Communion Utterance moved to Companion](https://lychd.snayu.ai/ai/docs/compositions/communion/utterance.md)
- [Cultivation](https://lychd.snayu.ai/ai/docs/compositions/homestead/cultivation.md)
- [ExLlamaV3 engine route moved](https://lychd.snayu.ai/ai/docs/sepulcher/animator/soulstone/exllamav3.md)
- [Extension authoring](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/authoring.md)
- [Scout source acquisition study](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/scout-web-research.md)
- [Coding-runtime research](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/coding-runtime-research.md)
- [Development bootstrap](https://lychd.snayu.ai/ai/docs/sepulcher/extensions/weaver/development-bootstrap.md)