SYS.40 / RUNTIME
Task in, explained plan out
A sentence becomes a routing plan: which [Skills](/docs/skills) activate, in what order, with what context — each with a reason you can go and check. No model is consulted.
The loop
Seven stages, each with a typed contract between it and the next.
TASK ↓ what a person types — bounded data, no control characters TASK INTENT ↓ domain, entities, risk, signals with sources, execution mode SKILL ROUTING ↓ candidates, each carrying at least one reason SKILL COMPOSITION ↓ steps in parallel groups, gates, unresolved issues CONTEXT PACK ↓ frozen versions, facts, files, graph, rules, constraints, findings, unknowns VERIFICATION ↓ the evidence that actually ran REVIEW ↓ one report per reviewer, findings with citations GO / FIX_REQUIRED / BLOCKED
No model is consulted
Nothing in the routing pass needs semantic interpretation.
A domain is a verb, a signal is a word the person wrote, an entity is a string that matches something the scanner found, and risk is a set of rules over those. Routing is therefore deterministic — the same task against the same snapshot produces a byte-identical plan.
The grounding rule, applied to what you typed
A file you name becomes an entity only if the project has it.
What reaches the plan is the project’s spelling: somebody writing webhook.ts gets the real path from the snapshot. Anything that matches nothing is reported as unmatched and shown, rather than quietly becoming part of a plan built around a file that is not there.
Matching is on whole tokens, never substrings. The first version used a substring test and produced three false positives immediately: a module named web matched "webhook", a technology Go matched "going", and a technology R matched every sentence in the language.
What the composer decides, and what it refuses to
It resolves duplicates and ordering. It does not resolve conflicts.
| Issue | Resolved? | Plan still executable? |
|---|---|---|
| Duplicate | yes — strongest role, reasons merged | yes |
| Unavailable | yes — dropped, and said | yes |
| Missing requirement | no | no |
| Conflict | no — both sides stay as candidates | no |
| Cycle | no — the step list comes back empty | no |
Choosing which of two conflicting experts to drop is a judgement about the task, and the composer has no task in front of it. A blocked plan is a plan that says why it is blocked.
Which relations impose order
Three of them reverse, and that is the trap this table exists for.
| Relation | Reads as | Execution edge |
|---|---|---|
| REQUIRES | a needs b | b → a — the prerequisite runs first |
| PRECEDES | a before b | a → b |
| PROVIDES_CONTEXT_FOR | a informs b | a → b |
| VERIFIES | a verifies b | b → a — the work runs before its verification |
| REVIEWS | a reviews b | b → a |
| COMPOSES_WITH | side by side | none |
| CONFLICTS_WITH | must not co-occur | none — recorded as a blocking issue |
"a requires b" and "b precedes a" say the same thing, while "a requires b" and "a precedes b" are a two-Skill cycle — and both sentences read as true on their own.
The Review Board
Four to six reviewers who cannot read each other.
| Reviewer | Asks |
|---|---|
| Code reviewer | What does this code do that it does not say it does? |
| Security auditor | Who can reach this, and what can they make it do? |
| Test engineer | What would fail if this broke, and is there such a test? |
| Architect | Does this fit the project as it is? |
| Performance specialist | What does this cost, and what does the cost grow with? |
The first four always sit; the performance specialist is seated when the task touches something whose name the graph suggests is a hot path, or when the mode demands it. Composition is a pure function with a stated reason per seat, so the board can be interrogated.
The result returns every seat in whatever state it is in, including the ones that failed and why. A response listing only the reviewers that answered would draw a clean board over a broken one.