| name | decomposition |
| description | Break a coarse requirement into atomic children — as PROPOSALS a human approves, never as work the machine authors and then grades itself on. Use this whenever a requirement is too big to close in one scoped pass, when splitting work into atomic units, or when running `aegis propose`. Trigger it any time the agent is tempted to invent sub-requirements, write its own acceptance criteria, or decide on its own what "atomic" means. |
decomposition
The reason a weak local model is trustworthy in this stack is that scope and acceptance
criteria come from human-authored, test-linked requirements. Decomposition is the one
place that principle is most at risk, because splitting work feels like authoring work.
The rule holds anyway: the machine proposes decompositions; a human approves them. The
model is a consumer of intent, never the author of it.
Why this is gated, not autonomous
If the loop could add and approve its own atomic requirements, it would decide what
"atomic" means, write its own acceptance criteria, and then grade itself against criteria
it just invented — a closed, self-validating loop with no external ground truth. That is
the exact failure mode the architecture was built to prevent. It is also the worst task to
hand a 4B-active model unattended: decomposition is long-horizon, ambiguous design
reasoning, the region where the model is weakest. And for ITAR, a system that authors its
own work on controlled data with nobody reviewing what it decided to build weakens the
human-accountability story the Technology Control Plan depends on.
The flow
aegis propose <requirement> reads a coarse requirement and emits atomic children.- Children land in a
proposed state — not claimable. The loop's rtmx next must
skip them. (This needs an rtmx convention: a proposed status, or a tag next
excludes, that only a human approval promotes to active.)
- Children inherit the parent's acceptance tests rather than inventing new criteria.
Where a child genuinely needs a narrower test, it is flagged for the human to write —
the machine does not author the bar it will be graded against.
- A depth limit and a child cap bound the split — no runaway trees, no backlog
explosion. Exceed either and
propose stops and asks for a human decision.
- Every proposed requirement is tagged machine-authored in the audit trail, so
provenance is always visible on review.
- A human reviews and approves; only then do children become claimable by the loop.
The division of labor
The machine does the tedious splitting — pulling apart a coarse requirement into plausible
atomic pieces, wiring up inheritance, flagging gaps. The human keeps authority over intent
— what the pieces are, what "done" means, which to admit. Assistive, not autonomous. That
preserves the design's integrity instead of inverting its core principle.
Example
aegis propose LOOP on a coarse "make the loop production-ready" → emits proposed children
(drain, park-on-escalation, circuit breaker, run budget), each inheriting the parent's
tests, each tagged machine-authored, all in proposed state, none claimable. You review,
tighten two acceptance tests, approve all four. Now the loop can pick them up. The machine
saved you the breakdown; you kept the say over what's real.
