The format.

Authority is permission — a specific decision the role can make without asking anyone. Every authority is a MAY line, bounded by a limit and an escalation path; a flat prohibition is a MAY NOT line.

Be specific, not broad. "Discount a sale up to 7% of contract value" is authority. "Manages the sales process" is not — if you can't put a number or a boundary on it, it isn't finished.

Every limit names a real escalation. Anything past the limit routes to a role that actually holds the authority to decide it — which you can check against that role's own MAY lines.

Hard boundaries are MAY NOT. Some limits aren't a number but a flat prohibition — write those as a MAY NOT line that routes the decision to whoever owns it. And a constraint on what the role may do is authority, not responsibility: "sell only from the approved list" is a MAY NOT, not a MUST.

Authority is priced in risk. What a role is paid tracks the risk it carries on the company's behalf, not the depth of its knowledge. A documented authority list makes that risk legible.

Responsibility is obligation — something the role must produce, and someone who receives it. Written as a MUST line with a deliverable, a recipient, and a cadence or trigger.

A deliverable, not an activity. "Attends the weekly meeting" is an activity. "Delivers a pipeline report to the CEO by 17:00 every Friday" is a responsibility — you can assess it at review time.

Format is not a deliverable. Tone, length, and structure describe how the deliverable should look — keep them as attributes of the line, never as responsibilities of their own.

A limit is not a duty. If a line constrains what the role may do rather than naming something it produces, it belongs in Authority — a MAY or MAY NOT — not here. "Sell only from the approved list" is a boundary, not a deliverable.

Name the recipient. A deliverable with no recipient is where information quietly stops flowing — with no one at fault, because no one was ever told it was theirs.

Responsibilities define the process for free. Chain each MUST to the role that receives it and the delivery process falls out of the specs — one role's output is the next role's input.

Ability is capability — a skill the role must be able to perform. Written as a CAN line naming a specific, real skill, tool, or framework.

A skill, not knowledge. Ability is what a person can do, not facts they happen to hold. "Administer Salesforce" is an ability; "understands sales" is not.

Name it concretely. "Salesforce administration", "Lean Six Sigma (DMAIC)", "financial modelling in Excel" — not "good with systems". If it can't be named, it can't be taught, hired for, or assessed.

Certifications count. A required credential is a concrete, checkable way to name an ability — "PMP", "AWS Certified Solutions Architect", "CIPD Level 5", "Lean Six Sigma Black Belt". The certificate names the skill and evidences it in a single line.

Ability is the diagnostic. When someone underperforms, ARA tells you where to look: overreaching authority, an undelivered responsibility, or a missing ability. Three different problems, three different fixes.

A complete spec is a role's name, its reporting line, and its three blocks — MAY, MUST, CAN. Assemble it in that order and keep every line declarative.

Keep it declarative. A spec states what is true of the role — it never describes how the work flows. The person in the role owns the process. See complete examples in the role library.