How Arcanum Arrives at SCU

Start with the user's actual problem: vague work becomes risky when it jumps straight into execution. Arcanum answers by building a method that narrows intent into bounded, source-backed units a reader and worker can both understand.

Problem

Execution starts too early

Without a method, a broad idea turns into unclear files, vague tasks, missing validation, and arguments about what "done" means.

Method response

Turn intent into bounded artifacts

Invoke, work-packs, layering, distill, refine, and task-session each solve one step in that narrowing path.

1

Invoke

Authors define, design, plan, work-pack, handoff, or refresh artifacts before lifecycle execution.

2

Work-pack

Turns the plan into executable tasks, SWUs, gates, validation, write scope, and evidence expectations.

3

Implementation Layering

Asks for Layer 0: the smallest end-to-end proof that teaches whether the concept can work.

4

Distill

Asks what unit still has responsibility, inputs, outputs, closure, and recomposition after reduction.

5

Refine

Repairs ambiguity, critique, and design gaps before the route pretends it is execution-ready.

6

Task Session

Executes one bounded task or SWU with context, gates, validation, and synchronized evidence.

Why it matters

SCU appears where proof pressure meets meaning pressure.

Implementation layering says, "make the first proof small enough to learn." Distill says, "make the unit coherent enough to still mean something." SCU names the overlap.

Layering question

What is the smallest proof that unlocks a real decision?

+
Distill question

What is the smallest concept that still recomposes upward?

=
SCU

Smallest coherent unit, not smallest possible fragment.

Dependencies

Ownership boundaries keep the method readable

  • Invoke owns intent-to-artifact authoring.
  • Work-packs carry execution contracts.
  • Task Session owns bounded execution.
  • Sigil and spell lifecycle owners handle reusable capability mutation.
Evidence boundary

Source-backed does not mean runtime-proven

The page explains repository contracts and method structure. Runtime adapter readiness, installed command behavior, and promotion status require separate validation.

Risk questions

Check the candidate unit

  • Is it too tiny to carry responsibility?
  • Is it too broad to validate safely?
  • Does it hide glue that belongs in another unit?
  • Can it recompose without smuggling future scale?
Execution gate

SCU is not SWU by default

An SCU is a coherent concept boundary. An SWU is an executable implementation boundary with write scope, acceptance evidence, and verification.

Reader outcomes

What the reader should be able to do after this page

Surface

Name the starting problem: vague intent needs a method before execution.

Flow

Trace invoke to work-pack to layering to distill to refine to task-session.

Dependencies

Explain why each capability hands off at its authority boundary.

Risks

Ask if the candidate unit is too tiny, too broad, or under-evidenced.

SCU vs SWU

Separate concept coherence from executable implementation handoff.

Evidence

Tell source-backed claims from inference and from runtime validation gaps.

Evidence and inference

What this x-ray can and cannot prove

source-backed

Repository contracts define the method loop, invoke authoring, work-pack/SWU requirements, Layer 0 proof, distill closure checks, refine routing, and task-session gates.

inference

The teaching structure treats SCU as the convergence of proof pressure and meaning pressure. That is an explanatory synthesis of the source-backed method contracts.