01
A role is a responsibility, never a person or a program
You should be able to: Explain what a role is in an AAO charter and what it is not.
A role in the charter is a standing responsibility — the work that exists whether or not anyone is doing it right now. It is not a person, and it is not the name of the software doing it. The estate's naming standard draws exactly this line: "roles are standing responsibilities, branches are assignments," and "Hermes names the software; a role names the responsibility."
This is why the validator rejects a role called hermes, nova or atlas even though those are fine names for an agent. The same string can be a good harness name and a failing role name, "and that line is the entire naming standard." A role is operations, settlement, onboarding — the function — because the function is what outlives any particular agent assigned to it.
Getting this right is not pedantry. It is what lets your organization survive a change of agents, a change of tooling, even a change of the whole implementation: the roles stay, because the responsibilities stay. Name the work, not the worker.
Source: Flashy OS — the naming standard
02
The name rules the validator enforces
You should be able to: Write a role name that passes and recognise one that fails.
Role names are checked, not suggested. A role name is lowercase, hyphen-separated, 3–24 characters, at most three words. Rejected outright: model vendors (claude, gpt, copilot), git names (main), placeholders (agent, bot, worker), and trailing machine ids (a -bxq1t0 suffix). If your role name could be a login, a brand or a random string, it is not a role name.
The cap at three words and 24 characters is deliberate: a role that needs a sentence is two roles, or it is a responsibility you have not thought through. The constraint forces the clarity. settlement-record passes; the-agent-that-handles-all-our-money does not, and the rejection is telling you to split it.
These rules exist because the charter is read by machines and strangers, and an ambiguous or vanity role name makes your governance unreadable to exactly the audience it is for. The validator is doing you the favour of refusing a charter a stranger could not trust.
Source: Flashy OS — @flashyos/aao
03
Families, and the roster inflation the standard refuses
You should be able to: Use the family field correctly and avoid inventing roles to fill it.
Each role names a family — the area of the organization it belongs to — as a separate field, not baked into the name (encoding it would give every role a growth- prefix and buy nothing). There are ten families, and here is the rule that keeps a charter honest: you do not have to fill them all. FlashyOS's own charter declares ten roles and leaves two families deliberately empty.
The temptation is to fill every family so the organization looks complete. The standard refuses it: "inventing a role to fill a family is the roster inflation this standard exists to stop." Ten families across sixteen organizations would be a hundred and sixty roles, most of them empty, "which looks like coverage and is not. A role exists because work exists."
So declare the roles that have real work behind them and leave the rest empty. An empty family is honest; an invented role is a lie your charter tells a stranger about how big and governed you are. The discipline here is the same one the whole estate applies to every published figure: do not manufacture the appearance of coverage.
Source: Flashy OS — flashyos.roles.json
04
The fields that make a role governable
You should be able to: Fill a role's purpose, measure, capabilities and approval threshold.
A role is more than a name. Each carries a purpose (what it is responsible for, in a sentence), a measure (how you would know it is failing — for a finance role, "unreconciled entries at end of day"), a set of capabilities (the discovery tags that say what it may do), and humanApprovalAtOrAbove — the threshold above which a human must sign before the agent acts.
The approval threshold is where governance stops being decorative. A role that can spend money carries a low threshold, so a human approves before value moves; a role that only reads carries a high one. This is the fifth question made concrete: not "is there a human somewhere" but "exactly where does a human have to say yes," declared per role and enforced at the boundary.
The measure is the field people skip and should not. A role with no measure is a responsibility with no failure condition, which means nobody can tell when it is not being met. Naming the measure is how you make an agent's work checkable — the same "define done before the run" discipline the Directing Agents track teaches, written into the charter itself.
Source: Flashy Academy — Directing Agents Well
05
The accountable human, and the top field
You should be able to: Name the accountable human and understand which claim you cannot self-issue.
At the top of the charter is accountableTo: a real, reachable human — question five, the one an AAO cannot skip. Not a role, not a shared inbox, not "the team": a person who can be asked why the organization did what it did. A charter without one does not pass, because an organization with no answerable human is precisely what the standard exists to reject.
One more thing the charter does not get to say about itself: its top conformance level. The mark is "held, not just issued" — the highest level is read from a register the estate keeps, "never from the org being checked." Your charter can declare its roles and thresholds; it cannot declare that it has been independently verified, because that is a claim only a third party can make. Raising your own tier is a separate, signed decision, not a line you edit.
With roles named as responsibilities, names that pass, families left honestly empty, thresholds set where value or risk crosses a line, and a named human at the top, your charter answers the seven questions. The next course writes one that passes from the first line — in a single command.
Source: Flashy Academy — The Verifiable Record
