The policies it ships with

People and their agents follow these when they record in a collection made from this template. Its owners can change them.

1. A node belongs in an org chart when it documents organizational STRUCTURE: a seat / role (Principal), a team or department (Intent), a decision right or accountability (Decision), or a supporting role charter / job description (Reference). Pass when the candidate is one of these. Fail when it instead describes how WORK flows — a process step, a task, a product feature, an event, or a one-off incident — which belongs in a process collection, not here.
2. Every seat (Principal) declares who fills it so the chart can draw the right marker. Set the seat's `kind` to `human` for a person or `agent` for an AI agent; or, if the seat is budgeted but unfilled, say so in its `prose` (e.g. "Vacant — open req for a Staff Engineer"). Pass when the occupant kind — person, AI agent, or vacant — is unambiguous; fail when a seat leaves it unstated.
3. Only Principal, Intent, Decision, Reference, and Rule belong in an org chart. A Principal is a seat (a role); an Intent is a team or department that seats belong to; a Decision records a decision right and its accountable seat; a Reference attaches a role charter or job description; a Rule states a governance constraint. Process steps (Action), milestones (State), and tests (Eval) describe how work flows — they belong in a process collection, not an org chart.
4. Only these relationship edge types belong in an org chart: `has_parent` (the solid reporting line, and a seat's membership in a team), `attributed_to` (a seat's team, or a Decision's single accountable seat), `relates_to` (dotted-line / matrix coordination — influence without authority), `supports`, `replaces`, and `derived_from`. Process-flow edges (`flows_to`) and guard edges (`constrained_by`) model how work runs and don't belong here.
5. Unity of command: each seat reports to at most one manager — a single `has_parent` edge (its solid line). A seat with two `has_parent` parents is no longer a tree; model the secondary relationship as a dotted line (`relates_to`) instead, so accountability stays unambiguous.
6. Positions define the structure, not the people who fill them. Name each seat (Principal) by its role or title — "Head of Engineering", not "Dana Lee" — and record the current occupant in its `prose`. That way a hire, departure, or transfer updates one seat instead of forcing the chart to be redrawn.
7. Give every seat exactly one solid reporting line: a `has_parent` edge from the report to its manager, which the org-tree perspective draws as the solid hierarchy. A seat with no manager is top-of-chain — say so in its `prose` (e.g. "Top of chain — reports to the board") so its rootedness reads as deliberate, not missing.
8. Group seats into teams or departments: model each team as an Intent and link its members with `attributed_to` edges from the seat to the team. This is how a functional, divisional, or matrixed structure shows up without overloading the single reporting line each seat already has.
9. Record decision rights as Decision nodes with a single accountable seat — one `attributed_to` edge to the Principal who is Accountable (RACI's single point of accountability). Name the escalation path in the Decision's `prose` when the call can be escalated above that seat.
10. Model dotted-line / matrix relationships with `relates_to`, drawn from the seat to its secondary manager: influence and coordination without formal authority (e.g. a regional lead who coordinates with a global function). The org-tree perspective renders these dashed, layered over the solid tree — keep the solid `has_parent` line for the one primary manager.
11. Mark unfilled seats vacant rather than deleting them. A budgeted-but-open role is part of the structure and matters for headcount and succession planning; say "Vacant" (and what you are hiring for) in the seat's `prose`. The org-tree perspective draws a vacant seat with its own marker (🪑).
12. The chart shows the shape; written role scope carries the detail. Attach a Reference (job description or team charter) describing a seat's responsibilities and decision authority, linked with `supports`, rather than packing all of it into the seat's `prose`.
13. Keep the chart current: update it after every reorganization, hire, departure, and role change. When a seat's occupant changes, update its `prose`; when reporting lines move, retire the old `has_parent` edge and add the new one. An org chart is only useful while it is accurate.