3.2 Roles
A specification with more than one party MUST name its roles in its scope article, and MUST state every requirement against a role rather than against a program.
A role is a position in an interaction, not a piece of software. One program frequently occupies several — a repository operator is usually also a package producer, and a daemon that answers one protocol may consume another.
3.2.1 Why the distinction is load-bearing #
Naming a program in a requirement makes the requirement untestable against anything else, which defeats the purpose of writing the specification down. The whole reason a contract is published is that somebody other than the current implementation may satisfy it.
3.2.2 Enumerating roles #
A chapter's scope article SHOULD present its roles as a table giving, for each, the obligation it carries:
| Role | Obligation |
|---|---|
| Producer | Builds the artifact. Everything the artifact contains is a producer obligation. |
| Consumer | Validates and applies it. Every validation and rejection rule binds the consumer. |
Two or three roles is typical. A specification finding itself with six has probably merged two interactions that want separate chapters.
3.2.3 Conformance follows the roles #
Because requirements attach to roles, a conformance article (§3.4) states what each role must do, separately. A reader implementing one side needs to know which requirements are theirs without reading the other side's.