Getting Started · The ARA Role Spec
Every role,
defined as a spec.
A role isn't a process — the person holding it defines the process. ARA defines the envelope they work within: what they may decide, what they must deliver, and what they can do. Three declarative statements. One structured, readable, machine-legible spec per role.
May · Must · Can
One keyword per pillar. Each carries its own fields — the structure is identical for every role, so specs are comparable, diff-able, and auditable.
Authority
What the role is empowered to decide without asking. Bounded — every permission carries a limit and an escalation path; hard prohibitions are written as MAY NOT.
up to [limit]
else [escalate to]
Responsibility
What the role must produce, and for whom. A deliverable and a recipient — not an activity.
to [recipient]
when [cadence]
Ability
The named skills, tools, frameworks, or certifications the role must hold to do the above. Concrete, not aspirational.
framework / cert]
A role, in full
One complete spec makes the shape obvious — read it top to bottom and you know exactly what this role may decide, must deliver, and can do.
The three failure modes
Each maps to one missing pillar — the same failure whether the role is held by a person or an AI. Leave a pillar undefined and this is what you get.
Undefined authority → scope creep
A role with no authority boundaries makes decisions nobody meant to delegate — a person oversteps; an AI rewrites your CTA. Any decision taken that wasn't explicitly granted was made without authority.
Undefined responsibility → drift
With no clear deliverable — format, recipient, cadence — the output is technically responsive but practically useless: it answered the question asked, not the one that needed answering. Responsibility pins the output.
Undefined ability → generic craft
Name the skill, tool, or framework the work demands — PAS copywriting, Lean Six Sigma, Excel, Jira — and the work meets a known standard. Leave it blank and you get a generic version you have to redo.