Role-Specific Policy Table¶
Role-indexed policy table — instantiates Directed Asymmetry Mapping and Calibration
Writes down, role by role, what each side of the relation must do, may do, and is owed — so unequal treatment is explicit, addressable, and paired with the controls that offset it.
Once an asymmetry has been judged warranted, someone has to say concretely what each side now does. The Role-Specific Policy Table is that artifact: a table indexed by role, where each side's row spells out its obligations, permissions, and entitlements — and, crucially, the compensating controls attached to whichever side holds the advantage. Its defining move is to make the asymmetry legible and role-addressed rather than buried in symmetric prose: instead of "both parties shall protect the data," it states what the powerful side must do because it is powerful, and what the exposed side is owed in return. It is where a warranted difference becomes an operating rule with an offset built in.
Example¶
A SaaS analytics vendor and its client are signing a data-processing agreement. Rather than a flat "both parties will handle personal data responsibly," they build a role table. The client, as the party that decides why and how data is used, carries the row: establish a lawful basis, define retention, field data-subject requests, authorize any new use. The vendor, as the party that merely acts on instructions but holds the technical access, carries a different row: process only on documented instruction, notify a breach within a set window (≈72 hours as an illustrative gate), never sub-contract processing without sign-off.
Because the vendor's row concentrates access, the table pairs it with compensating controls — audit logs the client can inspect, encryption at rest, a right-to-audit clause — that offset the access asymmetry rather than pretend it away. The result is not "equal treatment" but explicit, role-appropriate treatment: each side's duties fit its actual position, and the one structural advantage in the relation comes with a counterweight written on the same page. This role split mirrors real data-protection regimes that assign distinct duties to a controller and a processor.[n1]
How it works¶
- Index by role, not by party name. Rows attach to positions (advantaged / exposed, upstream / downstream, controller / processor), so the same rules apply to whoever occupies the role and the asymmetry is stated structurally.
- Split obligations, permissions, and entitlements. Each role's cell separates what it must do, may do, and is owed, so a duty on one side lines up with an entitlement on the other.
- Attach a compensating control to every advantage. Wherever a role holds disproportionate power, access, or information, its row carries an offsetting obligation, so the codified asymmetry is never left bare.
Tuning parameters¶
- Role granularity — two coarse roles or many fine ones. Finer roles fit obligations precisely but multiply the table's complexity and its edge cases.
- Control strength — how heavy the offsets on the advantaged side are, from a light disclosure duty to a hard veto for the exposed side. Heavier offsets protect more but can stall the relation.
- Bindingness — whether a row is a firm rule, a default, or guidance. Firmer rules are more protective but less adaptable to odd cases.
- Symmetry of entitlements — how much of each duty on one side is mirrored by a claimable right on the other, which is what makes the table enforceable rather than merely descriptive.
When it helps, and when it misleads¶
Its strength is that it drags a warranted asymmetry into the open and makes it actionable and contestable: duties sit where the position actually is, and every advantage carries a visible counterweight, so the exposed side has something concrete to hold the other to. Assigning distinct duties to distinct roles — and pairing power with accountability — is the backbone of most controller/processor and fiduciary regimes.[n1]
Its failure modes are political. A role table is only as legitimate as the warrant behind it: written without an upstream relevance judgement, it simply codifies whoever held the pen — the drafting-party advantage, entrenched and now official-looking. It is a favourite site for the run-it-backwards move, where obligations are shaped to protect an incumbent's position and dressed as principled role design (a small-scale regulatory capture). And a table with duties on the weaker side but no matching, claimable entitlements on the stronger is asymmetry with the offset quietly omitted. The discipline is to require a Relevant Asymmetry Test behind every asymmetric row, to check that each advantage carries a real compensating control, and to expose the table to the side it burdens before it is adopted.
How it implements the components¶
The Role-Specific Policy Table fills the archetype's governing slots — what a policy artifact, not a diagnostic or a monitor, can fill:
role_specific_obligation_map— its core: the role-indexed map of duties, permissions, and entitlements for each side of the relation.compensating_control_set— it codifies, into each advantaged role's row, the offsetting controls the asymmetry requires; which controls to use is chosen by Compensating Control Selection, and the table turns that selection into binding rules.
It does not judge whether the asymmetry was warranted to begin with (relevant_difference_warrant → Relevant Asymmetry Test), choose the offsets from scratch (that selection is Compensating Control Selection), or decide when the whole asymmetry should be wound down (normalization_or_sunset_path → Asymmetry Sunset Review).
Related¶
- Instantiates: Directed Asymmetry Mapping and Calibration — it is where a warranted asymmetry becomes concrete, role-addressed operating rules.
- Consumes: Relevant Asymmetry Test supplies the warrant that licenses each asymmetric row; Compensating Control Selection supplies the offsets it codifies.
- Sibling mechanisms: Relevant Asymmetry Test · Compensating Control Selection · Asymmetry Sunset Review · Asymmetry Exception Register · Directed Relation Matrix
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Role-Specific Policy Table operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it writes down, role by role, what each side of the relation must do, may do, and is owed — so unequal treatment is explicit, addressable, and paired with the controls that offset it.
Independent corroboration: The frozen evidence defines Role-Specific Policy Table as 'Writes down, role by role, what each side of the relation must do, may do, and is owed — so unequal treatment is explicit, addressable, and paired with the controls that offset it', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: A table of what each role must do, may do, and is owed is structurally a legal matrix of duties, permissions, entitlements, and safeguards. Organizational responsibility charts, role-based access control, and administrative policy independently operationalize the same asymmetry.
Related originating lineages:
- Computer Science & Software Engineering — computer_science contributes algorithms, versioned state, credential validation, and software deployment to the mechanism’s formative or independently convergent form; that contribution does not displace the primary law_governance lineage.
- Organizational & Management Science — organizational_management contributes decision records, operating routines, knowledge reuse, and institutional learning to the mechanism’s formative or independently convergent form; that contribution does not displace the primary law_governance lineage.
- Public Administration & Policy — public_administration_policy contributes program oversight, public allocation, implementation, and continuity obligations to the mechanism’s formative or independently convergent form; that contribution does not displace the primary law_governance lineage.
Review resolution: The blind reviewers disagreed on primary lineage (law_governance versus organizational_management); authoritative or primary research supports law_governance as the best historical origin. A table of what each role must do, may do, and is owed is structurally a legal matrix of duties, permissions, entitlements, and safeguards. Organizational responsibility charts, role-based access control, and administrative policy independently operationalize the same asymmetry. The cited NIST Role Based Access Control FAQ; NIST, Role-Based Access Control Models directly supports the defining operation used in that choice. All independently supported contributing domains are retained without an arbitrary cap, while domain_reach=multi_domain records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The table is downstream of judgement, not a substitute for it. A crisp, well-formatted role table can lend an unwarranted asymmetry an air of legitimacy it never earned, so the guardrail is procedural: no asymmetric row without a warrant on file behind it. Keeping the licence to differ (the Relevant Asymmetry Test) upstream of the codification of difference (this table) is what prevents the artifact from becoming a laundering step for power.
[n1] Under the EU General Data Protection Regulation, a controller (which determines the purposes and means of processing) and a processor (which acts only on the controller's instructions) carry distinct legal obligations — a real regime that assigns duties by role rather than treating every data-handler alike, and pairs the processor's technical access with accountability duties. ↩a ↩b