Invoke

Identity

• Canonical ID: invoke
• Aliases: none
• Scope: library

Purpose

Invoke turns vague development intent into governed authoring artifacts. The root spell file stays intentionally compact and delegates mode behavior to per-mode contracts under spells/invoke/.

Invoke is an authoring front door, not the lifecycle owner for every artifact it can describe. It discovers intent, shapes definitions, designs, and plans, then hands off to the capability that owns the target lifecycle.

Invoke does not require deprecated command files, slash commands, or command-resolution bridges as authoring readiness evidence. When an Invoke-authored plan prepares later execution, it should name native capability handles, expected receipts, validation surfaces, and subagent/local fallback boundaries. Legacy command adapters may remain as explicit example-runner compatibility only.

Deterministic CLI

tools/arcanum invoke is the stateless machine authoring surface for Define and Design. It converts a complete authoring request into canonical JSON, then invokes the existing closure, producer, admission, and capability consumers. It never calls a model or runtime adapter and never infers definitions, architecture, approvals, reviewer evidence, promotion, or execution authority.

Start with tools/arcanum invoke modes, then inspect one exact stage with tools/arcanum invoke <mode> describe [stage]. Plan, Handoff, and Refresh use the native Invoke skill until they expose equivalent deterministic source and admission contracts.

Human Result Contract

Every user-facing Invoke result must follow framework/OUTCOME-BRIEF-CONTRACT.md: lead with a short plain-language Outcome Brief, then state Boundary and Next Decision, and only then return the existing technical result. The brief is a human projection of the same run evidence; it does not change receipt schemas, authority, promotion, mutation, or lifecycle state.

The opening must explain the objective, result, and why it matters without requiring the operator to decode paths, hashes, status axes, or internal identifiers. The boundary must explicitly name what changed, what did not, remaining uncertainty, any exact user decision, and the next bounded action.

Trigger Conditions

• The user has something to build but the authoring baseline is missing or inconsistent.
• A reusable spec and glossary are needed before architecture or execution planning.
• The workflow needs one-question clarification, explicit approvals, and auditable outputs.

Mode Contracts

Mode	Status	Contract File	Notes
define	implemented (L0)	define.md	Human overview. Closure-bound v3 authoring: one source produces a thirteen-file candidate bundle, then independent admission proves current replay parity and typed semantic-drift closure.
design	W1 v2, W2 v2, and W3 v3 bundle/admission implemented	design.md	Human overview. Agent authoring guide. Requires admitted Define v3, closes approved inputs, compiles one typed six-view candidate, binds independent Distill PASS, publishes a deterministic fifteen-file bundle, and admits only artifact_authored after byte-equal replay.
plan	implemented (L2 contract)	plan.md	Converts approved design outputs into implementation plans, layering artifacts, and work-packs.
handoff	implemented (L2 companion contract)	handoff.md	Creates a new session/thread handoff from a prompt, source session reference, and Context Builder selection.
refresh	implemented (L2 refresh contract)	refresh.md	Updates existing invoke-authored workflow artifacts from new session evidence through typed deltas while separating phase completion from handoff readiness.
full	deferred	full.md	Composite execution mode, pending L2 and L3 readiness.
validate	deferred	validate.md	Lifecycle validation mode, pending L3.

Evidence Capability Contract

The machine-readable capability table is mode-capabilities.json. The production resolver is scripts/capability_status_resolver.py. It returns three independent axes:

• artifact_authored.status: pass, flag, block, or unsupported, based only on the mode's artifact receipt;
• registry_released.status: boolean, based only on a registry owner receipt bound to the current capability-table digest;
• mutation_runtime_ready.status: boolean, based only on a passing material package receipt plus a current mode-runtime receipt containing every required gate.

An earlier axis never implies a later axis. In particular, a valid Plan may be authored while registry release and runtime readiness remain false. Deferred full and validate return artifact_authored=unsupported, registry_released=false, and mutation_runtime_ready=false even if a caller supplies receipts. The request schema rejects legacy collapsed fields such as a single capability status or mutation_handoff_allowed.

This capability result is distinct from a mode run's phase_status and handoff decision. Active-mode validation may consume evidence before routing, but it cannot substitute its run verdict for any of the three capability axes. Define PASS additionally requires the exact v3 compiler receipt and matching current bundle-admission receipt declared by the capability table. Valid v1/v2 producer receipts are historical/read-only. Even a valid v3 stage/admission pair opens only artifact_authored. Agents author that v3 source through the closure-first, ownership-aware Define authoring guide and its compiler-and-admission-valid mixed example; the guide never replaces the JSON Schemas as shape authority.

Design input production adds another independent evidence family. Its DesignInputBoundaryApproval, DesignInputClosureReceipt, DesignScopeManifest, DesignDenominatorReceipt, DesignSelectionResult, and DesignInputProductionReceipt establish only approved-boundary-relative input closure and the selected Design contract. They do not establish a six-view Design artifact or final Design stage PASS. The production receipt carries the exact evidence ceiling. These artifacts imply neither registry release nor runtime readiness, and they never count planned witnesses as Plan evidence.

Design W2 adds one canonical architecture source, deterministic candidate projection, independent coherence validation, and atomic candidate closure. W3 then accepts only that exact passing candidate plus independently validated Distill evidence through DESIGN-BUNDLE-CLOSURE.json. It publishes fourteen payloads plus a v3 stage receipt atomically; an independent v2 validator recompiles the bundle and emits an external admission receipt only when all fifteen files are byte-equal. The capability resolver requires both receipts. Generic Design PASS envelopes and v1/v2 Design stage receipts remain blocked. Agents author the complete chain through the Design authoring guide, which links the detailed W1, W2, and W3 guides and explains each formal stage with concrete components, interfaces, workflows, decisions, and dependencies. The guide does not replace the JSON Schemas or the stage catalog as machine authority.

Core Required Sigils

Sigil	Role In Spell	Required Mode
structured-interview-kits	Clarify missing context one question at a time and capture approvals.	mode-dependent
inventory	Resolve local templates and record template usage evidence.	mode-dependent
context-builder	Build bounded context for invoke inputs and artifact linking.	mode-dependent
dispatch-spec	Select and validate the Dispatch Spec technique trace that shapes each invoke route.	technique trace or dispatch validation

Core Optional Sigils

Sigil	Use When	Notes
decision-gate	A blocker-level decision cannot be resolved from available evidence.	Route only consequential unresolved choices.
spellcraft	Approved invoke output targets spell authoring or spell revision.	Invoke prepares handoff context only; Spellcraft owns spell lifecycle mutation, validation, install, observation, and reflection.
sigil-development	Approved invoke output targets sigil authoring or sigil revision.	Invoke prepares handoff context only; Sigil Development owns sigil lifecycle mutation, validation, observability, reflection, and promotion readiness.
architecture-pattern-inventory	Design-stage work needs reusable pattern evidence or alternatives.	Optional design-mode evidence source; does not override design gates.
task-session	Plan output is ready for bounded execution.	Invoke emits handoff context; Task Session owns execution.
distill	A broad output needs smallest coherent unit validation, scope reduction, or gap discovery.	Required as automatic validate pass for plan, full, and validate; triggered for other modes when scope is broad or overbuilt.

Lifecycle Authority Chain

Use this chain to avoid responsibility overlap:

1. invoke owns intent-to-artifact authoring: define, design, plan, work-pack creation, and handoff context.
2. sigil-development owns sigil lifecycle: create, revise, validate, observe, reflect, iterate, and prepare promotion evidence.
3. spellcraft owns spell lifecycle: compose sigils, define phases and gates, install/adapt spells, validate, observe, reflect, and revise.
4. task-session owns bounded execution from an approved work-pack task or SWU.

Invoke may write handoff artifacts inside a target capability's development/ folder, but it must not claim the target lifecycle is complete. The handoff route becomes the next owner.

Chaining Workflow

For a new sigil:

invoke define/design/plan -> sigil-development --new/--update -> task-session when implementation work-pack tasks are ready

For a new spell:

invoke define/design/plan -> spellcraft design/install/validate -> task-session when implementation work-pack tasks are ready

For an ordinary feature or module:

invoke define/design/plan -> task-session to WORK-PACK.md

For a new thread split from the current session:

invoke handoff -> workflow-reflect | invoke define/design/full | research | task-session

For artifact refresh after a session result:

direct-user invoke refresh -> apply-approved when material gates pass
delegated/continuation invoke refresh -> proposal-only refresh report
either -> task-session | workflow-reflect | deferred

When a target is already clearly a sigil or spell, Invoke should produce a compact handoff packet and route early instead of expanding into lifecycle execution.

Cross-Cutting Transmutations

Transmutation	Role In Spell	Application Rule
implementation-layering	Keeps plan/full/validate outputs bounded by explicit layer decisions and promotion evidence.	Optional seed in define and design; required companion artifact in plan, full, and validate.

Dispatch Technique Discipline

Every invoke mode must record a Dispatch Spec technique trace before it returns a pass or flag result. The trace selects only techniques from formulae/dispatch-spec/TECHNIQUE-CATALOG.md or explicitly names a local-extension source, then connects each selected technique to a mode phase, output artifact, gate, evidence expectation, or unresolved gap.

Minimum trace fields:

• selected technique ids,
• activation trigger,
• affected phase or artifact,
• validation expectation,
• skipped technique reasons when an obvious technique was considered and rejected,
• whether a full dispatch JSON was needed and, if so, the validation result.

Common invoke techniques include sequence, frame_handoff, handle_handoff, residue_ledger, owner_boundary_check, artifact_contract_bridge, validation_loop, concrete_path_evidence, and observability_grouping. Plan, full, and validate modes additionally consider scu_swu_reduction, recomposition_proof, execution_receipt_handoff, and authority_split_gate.

Do not list techniques as decoration. A technique citation that does not affect a phase, output, gate, evidence check, or gap route is a flag. When the invoke route crosses multiple capabilities, delegates work, defines subagent strategy, creates a reusable route artifact, or carries protected/private context, create a dispatch document and validate it with formulae/dispatch-spec/scripts/validate-dispatch.py.

Distill Validation

Plan, full, and validate must run automatic Distill validation against the draft implementation plan, layering artifact, work-pack, and handoff route before reporting mutation-capable readiness. Distill validation checks whether the selected unit is small enough to execute, large enough to preserve meaning, owns one primary behavior with an independently reviewable acceptance boundary, records why it cannot be split further, recomposes into the approved design, exposes hidden gaps, and avoids overbuilt or vague task structure. The first selected SWU must be the narrowest reversible trust-building step, not a task-shaped bundle.

Distill verdict handling:

• pass: the output may route to its next owner if all other gates pass.
• flag: the output may route only when the gap ledger names each Distill gap, owner, and repair path.
• block: the output must not route to mutation-capable execution until the smallest coherent unit, SWU boundary, recomposition proof, or acceptance-critical gap is repaired.

Define, design, handoff, and refresh should run Distill when the requested output is broad, ambiguous, overbuilt, or likely to hide lifecycle gaps, but they may record a skipped reason when the output is already narrow and locally bounded.

Invoke-To-Distill Telemetry

When Invoke actually runs Distill and a repository observability package exists, Invoke must append exactly one linked Distill child signal in addition to its own Invoke signal. The child envelope uses the Distill run ID from the run request, sets lineage.parent_run_id to the Invoke run ID, identifies Invoke and its mode as the caller, and preserves available request, runtime-event, execution-receipt, and validator-result references.

Completed, partial, blocked, and failed meaningful Distill executions are observed. A skipped or not-required Distill route does not create child telemetry; Invoke records the skip rationale in its own row. Signal Observer deduplicates the child append by Distill run ID. Telemetry failure is visible observability residue and must not change the Distill verdict, the validator result, or mutation authority.

Prerequisites

• Repository root is known.
• Development pack context is available under spells/invoke/development/.
• Local template inventory is available, or candidate-template creation is allowed by user approval.
• Current prebuilt template inventory is rooted at arcanum/spells/invoke/templates/ and includes the DomainSpec template family (domainspec-spec/ — define baseline SPEC.md + aspect docs, design-stage architecture-bundle.md, plan-stage execution-pack.md), standalone companion templates, and dedicated candidate family scaffolds. The legacy module-formulae/ family is deprecated and retained only for the invoke validation fixtures and the mogt research project; physical removal is gated on regenerating those (see templates/module-formulae/README.md).
• Implementation layering transmutation is available at arcanum/transmutations/implementation-layering/.
• Implementation-layering template is available at arcanum/spells/invoke/templates/implementation-layering.md.
• Work-pack template is available at arcanum/spells/invoke/templates/work-pack.md.
• Necronomicon concept sources are reachable when glossary linking is requested.

Shared State

State	Owner	Updated By	Consumed By
define intent record	spell	structured-interview-kits and invoke define	define synthesis, decision routing
template selection record	spell	inventory and invoke define	define synthesis, validation, handoff
spec artifact	spell	invoke define	downstream design or plan routing
candidate definition registry (DEFINITIONS.json)	spell	invoke define	deterministic views and downstream definition-aware routing
definition view (DEFINITIONS.md)	spell	invoke define	human review; derived from the machine registry
glossary view (GLOSSARY.md)	spell	invoke define	downstream design or plan routing; derived from the machine registry
Define identity denominator request and result	spell	invoke define and identity denominator validator	Define pass and downstream Design/Plan activation
design artifact	spell	invoke design	downstream plan routing and validation
Design input boundary approval	target owner	owner-approved W1 input process	Design input closure validator
Design input closure	Design input author	W1 authoring	closure validator and scope projector
Design input production receipt	spell	W1 atomic input producer	input review or later normal Design authoring
Design scope manifest	spell	invoke design	denominator extraction and exact source closure
Design denominator receipt	spell	Design scope extractor	total Design selection and stale-input diagnostics
Design selection receipt	spell	Design selection validator	evidence-state reporting and handoff routing
glossary consistency report	spell	invoke design	design validation and gap routing
implementation layering artifact	spell	invoke design, invoke plan, and invoke full	plan validation, execution handoff, and release checks
implementation plan artifact	spell	invoke plan and invoke full	work-pack mapping, validation strategy, and execution handoff
work-pack artifact	spell	invoke plan and invoke full	stable planning manifest and execution handoff
session handoff artifact	spell	invoke handoff	new session/thread start, reflection, research, or continuation route
refresh report	spell	invoke refresh	evidence-backed artifact deltas, proposals, no-op decisions, and next route
define transport report	spell	invoke define	Necronomicon context
design transport report	spell	invoke design	Necronomicon context
plan transport report	spell	invoke plan	Necronomicon context
unresolved gap ledger entry	spell	invoke define, invoke design, and optional decision-gate	follow-up routing

Mode Router

1. Resolve requested mode and load the corresponding mode contract.
2. Select a Dispatch Spec technique trace for the mode route and determine whether a full dispatch document is required.
3. Execute the mode contract phases and collect mode outputs.
4. Run automatic Distill validation when required by mode or triggered by broad/ambiguous output shape.
5. When Distill ran, append one linked child Distill signal through Signal Observer.
6. Apply global gates, observability, and handoff policy from this root contract.
7. Render the human result in Outcome Brief -> Boundary and Next Decision -> Technical Details order.

Target Artifact Provenance

Invoke may author artifacts for another capability, module, spell, sigil, or repository feature. In those cases, invoke remains the observed authoring capability, but the produced artifact belongs to the target development cycle.

Every invoke run that targets another artifact should record:

• observed capability: always invoke,
• invoke mode: define, design, plan, handoff, refresh, full, validate, or a composed mode,
• target artifact name and type,
• target artifact owner or lifecycle cycle,
• output paths owned by the target artifact,
• invoke-specific gaps,
• target-artifact gaps,
• recommended next route for the target artifact.

Reflection and telemetry from such a run should preserve both layers. If the gap is caused by invoke behavior, template routing, output contract drift, or missing invoke guidance, route the follow-up through the invoke development cycle. If the gap is in the authored subject matter, state schema, design, plan, or implementation readiness of the target artifact, route the follow-up through the target artifact's development cycle.

Global Handoff Artifacts