Understand ARPA
Use this path when you need the conceptual model before touching implementation code. ARPA separates identity, relationships, assurance, authority, federation and evidence so that discovery never silently becomes permission to act.
Recommended reading order
- Design principles — the protocol’s non-implication and governance rules.
- Protocol modules — what each module owns and depends on.
- Architecture-to-module mapping — how protocol responsibilities map into an implementation.
- Candidate Specification v0.10.0 — the current consolidated normative baseline.
- Worked scenarios — how the model behaves under operational and failure conditions.
Keep these boundaries explicit
| Question | ARPA surface |
|---|---|
| Who or what is this agent? | ARPA-Core |
| What relationships connect it to principals/operators? | ARPA-Relations |
| What evidence supports claims about it? | ARPA-Assurance / ARPA-Evidence |
| May it perform this action now? | ARPA-Authority |
| Which external governance domains are recognized? | ARPA-Federation |
A discoverable, authenticated or signed agent is not automatically authorized. Implementations should preserve that separation in APIs, data models and user interfaces.
Next
Developers should continue to Build ARPA. Reviewers can go directly to Assure an implementation.