Units and slots

Inside a model, structure is made of two things: units, which form a tree, and slots, which are the positions inside that tree.

Keeping them separate is what lets Resorcerer talk about headcount you haven’t hired yet. A slot exists whether or not anyone is in it, so a plan for twelve engineers is twelve slots regardless of how many are filled today.

Units

A unit is an organizational group — a division, a department, a team, a squad. Units nest: a unit may have a parent and any number of children, and the models’s Units view renders the whole thing as a tree you can expand, search, and rearrange by dragging.

Field	Notes
Name	Required.
Labels	Optional, any number: `Department`, `Team`, `Squad`, or whatever your organization uses. Labels are defined once for the organization (on the Labels page, with an optional colour) and shared with models. Add them by editing the unit.
Description	Optional notes.
Parent	The unit above it, or none for a root unit.
Start / end date	Optional. When the unit is planned to go live and to wind down. A start date can be an exact day, a month, or a quarter, so “Q1 2027” is recorded as just that.

The Units view shows each unit’s labels beside its name when Show unit labels is on, and the selected unit’s details always list them. The Counts view breaks units down by label.

Moving a unit takes its children and slots with it. A unit can’t be moved beneath its own descendant — that would make a loop, and Resorcerer blocks it. Deleting a unit deletes everything below it, which is why it asks first.

Rollout state

Units with dates let you stage a rollout inside the model itself: this team goes live in November, that one in Q1 next year, these two are still undecided. Each unit has a rollout state, worked out from its dates as of the model’s effective date (or today, when the model has none):

State	When
Planned	The start date is after that date.
TBD	No start date and nobody in any of its slots yet. An end date doesn’t change that; it’s shown alongside.
Live	The start date is on or before that date, or there’s no start date but someone already fills one of the unit’s slots — and there’s no end date.
Ending	Live, with an end date on or after that date.
Ended	Live, with an end date that has already passed.

Every view uses the same state for a unit: the Units view, its filter, the Org chart and the Rollout tab all show the same word.

Set the dates in Edit unit: pick any day in the period and choose Day, Month or Quarter, and the dialog shows how it will read (“Shown as Q1 2027”). TBD clears the start date. The Units view shows each unit’s state as a chip beside its name — Live, Planned, Ending, Ended or TBD — with the dates behind it next to the chip (Starts Q1 2027, Started Nov 2026 · ends Mar 31, 2027, Start TBD for a unit that is live without a start date), and the first line of its description underneath. Every view writes a unit’s dates the same way, at the precision they were set (Nov 17, 2026, Nov 2026, Q1 2027). The Org chart adds the same chip to each unit when Show units is on; there the chip moves under the unit name when both don’t fit, and hovering it shows the dates. The Units view’s Filter button narrows the tree by state and by a start-date range; a unit’s parents stay visible, dimmed, so you can see where it sits.

A unit’s dates are separate from its slots’ own start and end dates. Copying a model keeps them, and comparing or merging two models treats a date change like any other change to the unit.

Unit templates

When the same shape comes up again and again — a squad of one lead and four engineers, a regional team with its own support desk — define it once as a unit template under Configuration → Unit Templates. A template is a hierarchy of units with slots, exactly like the real thing minus the people and dates: template slots describe positions (role, level, location, company, how many) but nobody can be assigned to one.

The template is the root. Pick it in Add Unit and the unit you create is that root — it gets the template’s slots and labels, and the template’s own units nest beneath it. You can also go the other way: Save as template on any unit captures it, its sub-units and their slots as a new template, leaving the people behind.

To check that units keep the shape a template gives them, open the template and choose Create rule from template. It starts a composition rule from the template’s root slots and label, which the Problems view then checks in every model.

Readiness checklists

A readiness checklist tracks whether a unit is ready to start: people named, capacity cleared, tooling set up, the first piece of work done. An organization admin defines a checklist once, and it applies to every unit carrying its label (for example Type: Pod) in every model. A checklist has gates, such as “Can start” and “Has run once”, each with its own items.

An item is one of two kinds:

Set by hand: Not started, In progress or Done, with an optional note. Who set it, and when, is recorded.
Derived from a composition rule: the item follows one of the rule’s requirements, such as “one Product Builder”. It is Done when every required position is filled, In progress when some are, and Not started when they are vacant or missing. You don’t set it; filling the position does.

Readiness counts Done as a whole item and In progress as half, averaged over the items that apply, for each gate and for the whole checklist. A model’s readiness averages every applicable item of every unit the checklist applies to.

Hand-set states are part of the unit. A copy or snapshot carries them, comparing two models shows a checklist change on the unit, and merging the unit brings its states across. Each change is in the model’s audit log.

Checklists live under Configuration → Checklists. Everyone in the organization can see them; an admin adds, edits and deletes them there. In the editor you name the checklist, pick the label of the units it applies to, and add its gates and their items. Each item has a short label (the heading it gets in readiness grids), a longer label, optional help text, and a key that identifies it in imports and for AI agents. For a derived item, pick the composition rule and then the requirement it follows. Drag the grip beside a gate or an item to reorder it, or use its up and down arrows; an item can move into another gate. Editing keeps what units have recorded for the items you keep. Removing an item, or turning a hand-set item into a derived one, removes what every unit recorded for it, and deleting a checklist removes all of it.

Deleting the checklist’s label deletes the checklist too, with everything units recorded against it in every model; the Delete Label confirmation says how many checklists that is. Deleting the composition rule a derived item follows leaves the item in place but stops it counting toward readiness; the Delete Composition Rule confirmation lists those items.

A unit’s checklist appears in the Checklist section of its details in the Units view, under its positions. Each gate shows a readiness ring and its items. If you can edit the model, choose Not started, In progress or Done for a hand-set item, and use the note button beside it to add or change its note. A derived item shows its state and which rule and requirement it follows, with how many of the required positions are filled. If you can only view the model, every item is read-only.

To see readiness across units, open the model’s Readiness view: a grid of every unit the checklist applies to against every item, which editors can update cell by cell. The Rollout view shows each unit’s readiness beside it, and the Summary has a Readiness card. See Analyse a model.

Slots

A slot is one position — one line of headcount. It’s described by the same attributes a person has, and it may or may not have a person assigned.

Field	Notes
Units	Which unit(s) it belongs to. A slot with none sits on the bench.
Role, Level, Location, Company	What kind of position it is. All optional, all used for filtering, grouping, and costing.
Person	Who fills it. Empty means vacant.
Placeholder, Hiring stage, Requisition	For a vacant slot only: who the seat is spoken for, where the hire stands, and the requisition it’s hired through. See Placeholders and planned hires.
Reports to	Another slot in the same model.
Start / end date	When the position is active. See Planning over time.
Notes	Free text.

Filled and vacant

A slot with a person is filled; without one it’s vacant. Both are counted, and both are costed — a vacancy has a price, and seeing it is usually the reason you’re building the model. The Summary view splits headcount and cost along exactly this line.

Assigning and unassigning is not destructive: taking a person out of a slot leaves the slot in place, and frees that person for another one.

Placeholders and planned hires

Some seats are spoken for before anyone is named: a backfill, a pending transfer, a contractor still to be found, a seat another team will supply. Rather than inventing a person for them, give the vacant slot a placeholder label, such as “Backfill (transfer from Team X)” or “Contractor TBD”. A vacant slot with a label is a placeholder, so every slot is one of three things: filled, placeholder, or vacant.

Any vacant slot, placeholder or not, can also track its hire:

Field	Notes
Hiring stage	None, Planned, Approved, Open, or Offer accepted.
Requisition	The requisition’s id in your hiring or HR system.
Start date	The slot’s own start date doubles as the hire’s target start.

Set them in the slot’s details (edit its attributes while it has no person), or when adding a slot; clearing the label turns a placeholder back into a plain vacancy.

These fields only describe an empty seat. A slot with a person can’t have them, and assigning a person clears all three, whether you assign them yourself, a merge does, or a live model fills the slot. The audit log keeps the values that were cleared.

Placeholders are costed like vacancies, but Counts, Costs, Compare and the Summary show them on their own, so you can tell the seats that are still open from the ones already spoken for. Every slot view shows a placeholder’s label in italics with a Placeholder tag, and a vacant slot’s hiring stage as a chip. They also travel with the slot when you copy, compare, merge, or export a model.

Slots in more than one unit

A slot can belong to several units at once — the shared designer who works across two teams, or a matrix reporting arrangement. The slot then appears in each unit’s list, but counts only once toward headcount, and its cost is split across the units it belongs to so that unit rollups still add up.

Taking a slot out of the unit it’s in from that unit’s list removes it from the model when it was the slot’s only unit. To keep the position and the person while you decide where they go, move it to the bench instead.

The bench

When you reshape a model you often take people out of a unit before you know where they’ll land. The Bench panel under the unit hierarchy in the Units view holds them: it lists every slot that belongs to no unit, with the count in its header. Click the header to fold the list away when you need more room for the hierarchy; you can still drop a person on the folded panel.

Drag a person from a unit’s list onto the bench to take them out of all their units.
Drag a person from the bench onto a unit in the hierarchy, or into the open unit’s list, to place them there.
Without a mouse, use the Move to button on a person’s card or bench row and pick the bench or a unit. Focus then moves to that move’s Undo, so you can take it back straight away, and a screen reader announces where the person went.

Every move you make this way is listed under Moves this session, showing who moved, from where and to where, with an Undo on each row. The panel shows your latest move, so its Undo is always at hand; Show all lists the rest. After an Undo, focus returns to the person’s row (on the bench, or in the open unit’s list), or to the Bench header when that row isn’t shown. Only a person’s latest move can be undone, and only while they’re still where that move put them. The list clears when you reload the page, or when you choose Clear list, which moves focus to the Bench header; the audit log keeps the full history.

By default the Problems view reports slots on the bench as a low-severity problem. Turn on Bench is intentional in the bench panel and they’re reported as information instead: listed, but no longer counted as a problem. A copy of a model has it turned on from the start, since copies are where restructuring is usually planned.

The hierarchy, the bench and your moves share one column that scrolls as a whole when they don’t fit, so every row and every Undo is one scroll away. On a phone the Units view stacks its panels: the hierarchy first, then the bench and your moves, then the selected unit and the people list, each at the full width of the screen.

Reporting lines

Setting reports to on a slot points it at another slot in the same model. Chain those together and you have the reporting structure that the Org Chart view draws.

Reporting is a property of slots, not of people, which means a plan can express “the new Head of Platform, whoever that turns out to be, has these six reports” before anyone is hired.

Resorcerer refuses to create a reporting cycle, and the Problems view flags any that pre-date the check.

Where slots come from

You can add slots one at a time from a unit in the Units view, or work in the Slots view, which lists every position in the model as a table you can filter by unit, attribute, or fill status, sort by any column, and export to CSV.

Models — the container units and slots live in.
People and attributes — roles, levels, locations, and companies.
Cost profiles — how a slot gets its cost.
Build your first model — a walkthrough.