Dispatch Spec is the small contract that lets an operator chain sigils by intent, validate the order, and preserve every handoff as evidence.
A user can already name a sequence in living language. The missing part is the inspectable middle object: what runs, why that order, what each step consumes, what each step emits, and which gate stops unsafe promotion.
Necronomicon can interpret route intent. Dispatch Spec validates the shape. Spellcraft makes recurring routes reusable. Invoke authors define/design/plan artifacts. Observability binds the run together with `dispatch_id`.
This is a route you can say out loud, then validate as a graph before letting it become a spell or execution plan.
Dispatch Spec does not flatten Arcanum into generic workflow steps. It preserves the operator's method language while giving validators something concrete to check.
One frame feeds the next. Best when lifecycle order is obvious.
Alternate exploration and critique until a stop condition is met.
Roles debate a tension while preserving stable disagreement.
Multiple proposal tracks compete under explicit elimination criteria.
Reduce to the smallest coherent unit before planning or execution.
Expose hidden actors, flows, transformations, and relationships.
Test a selected abstraction in a small controlled scenario.
Run examples, capture evidence, observe, reflect, revise.
Checkpoint useful residue without promoting it into truth.
Dispatch can describe parallel proposal lanes without letting them drift into unrelated work. Every lane names assumptions, evidence, and the condition that would eliminate it.
It names enough to validate route shape and handoffs. It does not copy sigil internals, decide promotion, or execute anything by itself.
// dispatch.schema.yml, concept shape { "dispatch_id": "dispatch-abstraction-research-001", "intent": { "raw": "dialectic -> distill -> x-ray -> toy games", "objective": "find the best abstraction" }, "steps": [ { "capability_ref": "distill", "pattern": "tournament", "inputs": ["tension-ledger"], "outputs": ["optimization-frame"], "join_policy": "pareto" } ], "gates": ["promotion_guardrail"], "observability": { "signal_grouping": "dispatch_id" } }
Dispatch Spec is useful because it stays humble. It validates the graph so the right owner can do the real work.
Recovers repository memory, extracts vocabulary, suggests route menus, records gaps, and preserves no-promotion guardrails.
Turns repeated, validated dispatches into reusable spell contracts with phases, gates, handoffs, and observability.
Authors define, design, plan, handoff, and refresh artifacts when the route needs lifecycle documents.
Finds the smallest coherent unit and proves it recomposes into the larger problem.
Executes one bounded SWU after the route and plan are ready enough to act.
Runs controlled examples, toy games, fixtures, and validation evidence before promotion.
A dispatch sequence is not good because it sounds impressive. It is good when uncertainty is reduced before commitment, critique happens before promotion, and every output has a named consumer.
Context first, then exploration, then selection, then explanation, then controlled tests, then decision.
Execution first, hidden assumptions, no frame handoffs, no gate, and no residue ledger.
Session output can become candidate evidence. It does not become canonical truth without the owner route.
It lets the operator speak in Arcanum vocabulary, lets the system validate the sequence, and lets future reflection understand what actually happened.
That sentence is no longer just prose. It is a route candidate.