GUTSGeneralized Orchestration Management System — The Intent Compiler
DESIGNED · MVP 7
Intent → Structure · L4 of the factory stack
Decomposition itself is the transformation problem.
Designed · MVP 7
GOMS is the layer that will turn intent into actionable structure, and it
is one ladder for any domain: goal → project/campaign → sprint → task →
action. A repo sprint is one subtype. A marketing campaign, a job search, a
compliance push, a research program: they decompose the same way, down to the same bottom
rung, an action a worker body can take.
Jira and Linear assume the humans have already done the hard part — they assume the
decomposition is correct and you just need a place to write it down. GOMS assumes the
opposite: that turning a goal into the right tasks is precisely the work that no
existing tool helps with.
Every project tool on the market starts after the hard part. You bring it tickets,
it tracks tickets. But the act of generating the right tasks in the right shape
from a vague goal is the work that nobody helps you with — and it's the work that,
done badly, sinks projects before they start.
The cost shows up later: rework because the wrong slice was cut, friction because
dependencies weren't seen, sprints full of busywork because the intent was never properly
compressed into structure. Decomposition isn't a setup cost. It's a
transformation cost, and it recurs every time the intent shifts.
What This Is Not
GOMS is not project management with AI on top
The category error is treating decomposition as a UX problem. It's a transformation problem.
The thing that's expensive isn't writing tasks down; it's knowing what the tasks
should be.
JIRA / LINEAR / EVERYTHING
You decompose. The tool stores.
Tickets are user-authored from day zero.
Cross-ticket dependencies are manually wired.
If the intent shifts, you re-decompose by hand.
Estimation lives in the operator's head.
The shape of the project lives in the shape of the operator who set it up.
GOMS · AS DESIGNED
The tool decomposes. You correct.
Tasks are proposed structure, edited by you, not authored from scratch.
Dependencies are inferred from the intent and from what the ledger already knows.
When the intent shifts, the decomposition re-runs.
Sizing is honest about being a draft; capacity-aware sizing arrives with GAMS, later.
The shape of the project is a function of the goal, not the operator.
The Mechanism
Refine, decompose, re-decompose
The designed loop: decomposition runs as a conversation, not a one-shot. The intent gets
sharper as the structure appears. The structure gets sharper as the intent clarifies.
Both converge.
01 · REFINE INTENT
The user states a goal. GOMS asks the questions that would make the goal decomposable:
what does success look like, what's in scope, what's the time horizon, what's the
constraint. The questions are not boilerplate — they're the specific ones whose
answers would change the decomposition.
02 · PROPOSE STRUCTURE
The refined intent generates a proposed decomposition: campaigns → sprints → tasks. The
proposal is shaped by historical decompositions of similar intents (recorded in GIMS)
and by the constraints the operator has stated.
It's a draft, not a delivery. The operator edits.
03 · CONVERGE
The operator edits the proposal; GOMS treats the edits as signal about the intent
and re-runs. After 2-3 iterations, the structure and the intent agree. The work that
used to take a senior person a week (turning a goal into the right tasks) happens in
an afternoon, with the senior person reviewing structure, not authoring it.
04 · RE-DECOMPOSE ON DRIFT
The intent changes, and it always does. GOMS doesn't throw out the existing structure;
it finds the smallest decomposition shift that conforms to the new intent.
What can stay, stays. What has to change, changes — and the operator sees only the diff,
not the whole project.
Generalization
One ladder, any domain
The old GOMS spoke only in repos: epics, sprints, tickets. The generalized design speaks
one grammar everywhere. A repo sprint is one subtype of the same ladder that decomposes a
marketing campaign or a job search. Same rungs, same convergence loop, same ledger.
The bottom rung is always the same: an action taken inside a worker session, recorded as a
sentence in GIMS. Anything that leaves the factory, an application submitted, a devlog
published, an outreach message sent, will sit behind the human gate and the operating modes.
Nothing outbound moves on its own.
The Boundary
GOMS defines. GONS operationalizes.
Two layers, one clean handoff. GOMS owns the shape of the work; GONS owns its execution.
Neither reaches into the other's half.
GOMS says:this is the sprint and the tasks.GONS says:these sessions need to exist, these contexts must be
loaded, these questions go to GEDS, these decisions need human approval.
The boundary is physical, not rhetorical. In the designed factory, every GOMS task bottoms
out in the same end state: a tmux session in a git worktree, holding a GIMS work
claim, visible as a card in the Bridge. GOMS never spawns anything itself. It
hands the structure to GONS-Core, which gives the tasks bodies and writes every step to
the ledger.
Task:event logging(sprint: bridge-stability-s1 · defined by GOMS)Body:tmux sessiongoms-evtlog-1·worktree ~/worktrees/bridge-evtlog(spawned by GONS-Core)Claim:bridge/src/events/**(exclusive-write · expiring · recorded in GIMS)Mode:normal·merge gated on human approvalVisible:Bridge dashboard card — cwd · last output line · status badge
The Bridge already ships the last line of that card: one card per session, working
directory, last output line, and agent-stopped detection. The rungs above it are the
designed layers that will fill the card in.
The Defining Capability
Well-crafted tasks you didn't write
The morning this layer exists will look like this. A GEDS handoff packet arrives in the
GONS-Console: evidence chain attached, confidence stated, a tension worth acting on.
You read it and approve. GOMS drafts the campaign decomposition: one campaign, two
sprints, nine tasks, acceptance criteria written, dependency edges drawn, every rung a
record you can edit. You correct two tasks; the draft converges. GONS-Core spawns the
worktree sessions, each holding a GIMS work claim, each appearing as a card in the Bridge.
You will not have written any of those tasks. You will have opened the Console
and found a coherent, executable campaign waiting for you to approve, edit, or
reject. And every step of that morning, the packet, the approval, the draft,
the edits, the spawns, will already be sentences in the ledger before the first worker
types a character. The thing decomposition has always cost you: that is what GOMS is
designed to reclaim.
Where It Fits
GOMS in the stack
GOMS sits at the top of the dependency stack, L4, and it is deliberately last on the MVP
ladder: generalized execution only after memory, coordination, and interpretation exist
beneath it. Its neighbors are GEDS (tensions and packets in), GONS (tasks operationalized
out), GIMS (every decomposition recorded), and the human (who converges the structure).
GOMS — The intent compiler
Turns goals into campaigns, sprints, and tasks: structure GONS can give bodies to. Designed, MVP 7.
← GEDS
Tensions and handoff packets arrive as decomposition prompts. Insight becomes structure in one hop.
→ GONS
GOMS defines the work; GONS-Core will operationalize it: sessions spawned, contexts loaded, questions routed, approvals requested.
↔ GIMS
Every draft, edit, and convergence is recorded as decomposition lineage; past decompositions inform new ones.
↔ HUMAN
The operator converges the structure and holds the gate. No decomposition executes unapproved.
GAMS · GRAMS — later layers
Allocation and the market membrane are real designs that do not gate GOMS. They join the orbit when there is a fleet to allocate and a market to face.
GOMS is paired with GONS the way a plan is paired with a crew: one defines the sprint and
the tasks, the other decides which worker bodies must exist to carry them. The pairing is
the point.