Generalized Allocation Management System
LATER LAYER · DEFERRED BY DESIGN

Make it so.

Later layer · deferred by design

GAMS waits, deliberately. Allocation over a living topology only matters once there is a fleet to allocate: agents, sessions, budgets, capacity. The factory builds runtime, ledger, foreman, relevance, and intent first; GAMS arrives when contention does. See the blueprint →

GAMS is the organ designed to hold the operational topology of the organization: who can do what, who substitutes for whom, what's available, what's committed, what's blocked. It is the part of the stack that will turn "I want this to happen" into a feasible plan, or surface, fast, that it isn't one.

Most organizations carry this topology in the heads of a few senior people. GAMS will externalize it. Capacity, dependencies, substitutions, budgets, timelines: all become first-class objects the rest of the stack can query.

ENG 70% DESIGN 95% ⚠ QA 45% 2 substitutes DATA 30% OPS 60% CAPACITY · DEPENDENCY · SUBSTITUTION

When a new project hits, the question is never just "can we do this?" It's: who, by when, instead of what, depending on whom, at what cost, and what breaks if one of those people gets sick? That tangle lives almost entirely in the heads of a few senior operators.

They are the bottleneck — and worse, the topology they carry decays the moment they're offline. New hires don't know it. Cross-team handoffs collapse on it. The fact that the operational topology isn't a first-class object is the single biggest hidden tax in most organizations.

The operational topology, externalized

Not just headcount. The full shape: who can do what, what they're already on, how loaded they are, who their viable substitutes are, what budgets are committed against them, and what timelines depend on their throughput.

CAPACITY
load · per-skill · per-role
DEPENDENCIES
who blocks whom · cascade depth
SUBSTITUTABILITY
who can sub for whom · cost
TIMELINE STATE
commitments · slack · drift
Allocation as a continuously-solved problem

GAMS is not a project tracker. The design: a constraint solver running over a living topology. When the topology changes — someone leaves, capacity opens, a dependency slips — the solver re-runs and the rest of the stack finds out.

eng design ops
01 · WHO CAN DO IT
Roles map to people, but people aren't fungible — they map to skill vectors. For any task, GAMS will know not just who's qualified, but who's qualified-but-overloaded, who's a viable stretch, and who's a substitute if the first choice falls through.
now
02 · WHEN, IN WHAT ORDER
Timelines are not a Gantt chart you draw once. They're a derived view over commitments, dependencies, and capacity. Slippage propagates automatically — if engineering starts a week late, GAMS will already know which downstream commitments are now at risk and propose the smallest set of reshuffles.
VIABILITY · proposals scored
03 · IS IT FEASIBLE
When a new project arrives, GAMS will run it against the topology and answer fast: feasible / feasible-with-substitutions / infeasible. Each proposal includes the specific cost of feasibility — money, slippage elsewhere, who has to switch context. You see the trade before you commit, not after.
minimal reshuffle proposed
04 · REALLOCATE ON CHANGE
When the topology shifts — someone leaves, a deadline moves, a budget contracts — GAMS will propose the smallest disruption that restores feasibility. The proposal goes back through GONS for human review on anything material. Routine reallocations won't need you. Material ones will surface clean.
A live topology, not a snapshot

The GAMS view is not a sheet you update. It will be a continuously recomputed picture of the organization's operational shape, refreshed as the underlying ledger changes.

214
Skill-Role Bindings
87
Active Commitments
3
Capacity Hot Spots
11
Substitution Paths
A realistic staffing plan, before you ask

A new project proposal hits the factory. GAMS will return, within seconds: "This is feasible if we pull A off the migration project (4-week slip on that, acceptable per recent priorities), pair B with C on the technical lead (B is at 85% — would put them at 100%), and contract for design overflow for 6 weeks (estimated cost: $42K). Without the design contract, this delays Q3 launch by 5 weeks."

It is not estimating. It is reading. The topology already exists in the ledger. GAMS will just make it legible, answering in seconds the questions that used to take senior operators days. The senior operators are then free for the questions GAMS can't answer.

And the first real GAMS topology is likely the agent fleet itself: which worker bodies exist, what they've claimed, what tokens and compute they consume. GAMS will learn to schedule agents long before it ever schedules humans.

GAMS in the graph

GAMS is designed as the feasibility membrane. Every other organ that proposes work will pass through it. GOMS asks "can this decomposition actually happen?" GEDS asks "is this reallocation realistic?" GRAMS asks "do we have the capacity to take this contract?" GAMS answers — or rejects — fast.

GONS route GEDS infer GOMS intent GIMS memory GEMS artifacts GRAMS market GAMS fleet command
GAMS — Fleet Command
Will hold the operational topology, answer feasibility in seconds, and reshuffle on change.
↔ GOMS
The intent compiler decomposes goal → campaign → sprint → task; GAMS will test each decomposition against capacity. Tight feedback loop.
↔ GEDS
The relevance engine surfaces tensions and anomalies that suggest reallocation; GAMS will evaluate whether they're realistic in the topology.
→ GONS
Material reshuffles will surface in the GONS-Console approval queue for human review; GONS-Core, the foreman, gives approved plans their sessions.
↔ GRAMS
The market membrane, another later layer: external contracts will pass through GAMS for feasibility before they become commitments.
→ GIMS
Every reshuffle, feasibility check, and commitment lands in the institutional ledger as an append-only sentence: subject · verb · object · at · by · under.
GAMS will be the membrane every other proposing organ has to clear. Capacity is the constraint that makes ambition operational.