Map
In plain words: Architecture map of one request
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.
- 1A Request (Intent) resolves to a pinned Workflow Version (Scroll); admission creates a durable Job Record (Run).
- 2If a model is warm, the Traffic Controller (Dispatcher) grants a Model Pass; otherwise the job pauses while the Stage Manager loads it.
- 3The result returns to a receiving owner who inspects, accepts, refuses or corrects it.
Words on this page, decoded click one for its card
Request Intent
What you are asking for, in a structured form the system understands.
It's like: An order ticket in a restaurant.
Click a dot to open that part's card.
One body, many roads, one return.
Suppose you want to turn a set of sources into a publication. You need a workflow to prepare it, a model or tool to carry out each step, and a record of what happened. You also need someone to decide whether the result is fit to publish. Follow that work through LychD below. This map explains the accepted architecture; State of Work identifies the parts the current revision can actually run.
For the larger question of how making becomes learning, enter Transmutation. It follows formation, symmetry, life and death through the software-development cycle and the Ouroboros return of evaluation and learning.
One body in one breath
In Broadcast's local publication candidate, the inputs are frozen sources and an editorial brief. The result is a candidate for an editor to judge. Preparing that candidate and releasing it are separate acts. Here is how the preparation passes through the body.
Your request is ana IntentRequest. Spellweaver resolves the workflow that will perform it. That workflow belongs to a named PatternWorkflow; one immutable Pattern revision is called a ScrollWorkflow Version. Pinning the revision keeps the instructions identifiable even if a later version is published.
When the request is admitted, it opens ana InvocationJob Request. A RunJob Record gives that execution a durable identity. Performing the ScrollWorkflow Version is its casting: Graph carries the work through stations, each placing a named action called a SpellStep. The diagram follows the request to its result and back to the person or application responsible for judging it:
flowchart TD
M["Magus<br/>purpose and authority"] --> W["Spellweaver<br/>resolve an exact Scroll for Intent"]
O["Application owner<br/>exact Pattern revision / Scroll"] --> W
W --> I["Run admission pins the score<br/>Invocation / Circle opens"]
I --> R["Run ledger + delivery<br/>Workers claim an exact hop"]
R --> G["Casting<br/>Graph carries Spell placements"]
G --> C["Result, artifact reference<br/>or effect receipt"]
C --> J["Receiving owner<br/>inspect, accept, refuse, correct"]
J -. "a new question or forward Invocation" .-> M
From logical work to iron
flowchart TD
G["Graph station<br/>requests a faculty"] --> D["Dispatcher<br/>match demand; refresh readiness"]
D -->|"eligible and WARM"| L["Admit a scoped grant and lease"]
L --> A["Animator through its Connector<br/>perform the admitted operation"]
A --> E["Release lease; return result to station"]
D -->|"managed capability needs transition"| S["Graph Stasis<br/>waiting Run holds no lease"]
S --> O["Orchestrator<br/>plan, close admission, drain, converge"]
O -->|"ready"| D
O -->|"unresolved physical outcome"| U["Contain for recovery"]
When a station requests a model or another service-backed capability, Dispatcher chooses an eligible capability. If it is already warm, DispatcherTraffic Controller can grant scoped use of it directly. If a managed local service needs to load or change, Orchestrator makes it ready. The RunJob Record waits in GraphStep Map StasisPause without holding a capability lease, then asks DispatcherTraffic Controller again. An unresolved physical outcome leaves the service contained for recovery.
Current grants cover the narrow v1 chat and non-empty toolset path, and the exact local embedding profile through its dedicated counted lease. General call, job, and session grants remain designed.
An Animator presents the selected local SoulstoneLocal Model or remote PortalCloud Model through its exact Connector. Remote work also follows the privacy and effect rules of its execution road. A PortalCloud Model call, a job in a delegated coding runtime, and work entrusted to a sovereign A2AAgent-to-Agent Line peer use different contracts; choosing one does not authorize another.
The return has several records
As Broadcast's candidate is prepared, Ghouls deliver the work and record its settlement. The Phylactery retains committed RunsJob Records and checkpoints. A checkpoint identifies a permitted place to resume; the RunJob Record ledger establishes terminal status even when an event is missing from the live view.
Oculus explains what was observed and where observation ends. Drift evaluates claims about the result. Those findings help the editor judge the candidate; they do not make the editorial decision. The receiving owner accepts the result or admits a new correction. Keeping a lesson has a separate decision, too: Archive law governs admission to memory. Completing work does not automatically promote a memory or admit a training example.
The application road
A Composition gives an application such as Broadcast its own records, judgment, permitted effects, and PatternWorkflow catalogue. If the work needs several applications to start, wait, cancel, or recover together, a Suite may own the PatternWorkflow that coordinates them. Its parent RunJob Record records their relationship. Each member still has its own RunJob Record and authority.
An optional ProductPackaged Offer packages selected CompositionApp or SuiteApp Bundle revisions around a profession or market promise. A Deployment is one configured instance of that ProductPackaged Offer, or of an exact Composition-owned reference profile. These choices determine what is offered and where it runs; the CompositionApp continues to own the application's records and decisions.
Identity, presentation, media, and place
The same LichAssistant may speak, appear in an image, or meet someone in another world. These uses connect several responsibilities. Mirror binds Persona identity; Avatar chooses an eligible presentation. PrismVision & Media and EchoVoice provide visual and speech mechanisms, while the application using them decides whether the creative result is acceptable. A Habitat, game world, physical Familiar, or Companion session keeps the meaning and consequences of its own encounter.
Use the ownership tables in Choosing a Home when deciding which application should make a particular judgment. Extensions explains where packages may contribute. A Registrant identifies the contribution's provenance; a Provider identifies a mechanism. Neither designation transfers the application's judgment.
Choose your road
| You need to find… | Open… |
|---|---|
| An organ and its operating guide | Sepulcher |
| The owner of an application idea | Choosing a Home |
| The way separate applications work together | Products and Suites |
| An undertaking's continuing brief, concerns, and decisions | Atlas |
| A term's exact meaning | Lexicon |
| The decision behind a boundary | Covenants |
| The purpose behind the whole | Transcendence |
Continue into the owning chapter
Follow the relevant chapter for its records, refusal and recovery rules, and the architectural decision behind them. Follow State for evidence of what runs. The Lich names this connected whole; the Great Work asks what it should learn and become through the work it returns.