Policy Relation Rule¶
Governance document — instantiates Relation Constraint Enforcement
A written governance rule that states which relationships are required, permitted, or forbidden under a policy regime, along with its exception conditions, override authority, and owner.
A Policy Relation Rule is the written, authoritative statement of a relationship constraint: which relationships must exist, which may, and which are forbidden under a given governance regime — together with the conditions under which an exception may be granted, who is empowered to grant it, and who owns the rule. Its defining move is that it is a source, not an executor. It cannot itself intercept a violation or reject a request; it declares the constraint in human-readable, contestable form and delegates enforcement to other mechanisms. What a foreign key or a workflow guard does, a policy relation rule says — and it also says the things code rarely captures well: when the rule bends, who may bend it, and who is accountable for keeping it current.
Example¶
A research funding agency's peer-review policy states the relationship constraints on reviewer assignment: a reviewer may not be assigned a proposal from their own institution, from a collaborator with whom they have co-authored within the last forty-eight months, or from anyone with whom they hold a financial interest. Those are forbidden pairings — a compatibility rule in prose. The policy then defines a waiver: in a specialty so small that no unconflicted expert exists, the program officer may grant a documented, time-bound exception recording the specific conflict and the mitigation (for example, a second independent reviewer). It names the program officer as the bounded override authority and the Research Integrity Office as the rule's owner, responsible for revisiting the forty-eight-month window and reviewing every waiver annually. The default handling for a conflict the policy does not waive is recusal — the reviewer steps aside.[n1]
Nothing in the document blocks an assignment by itself; a screening step or a workflow gate must read this rule and act on it. What the document guarantees is that the constraint, its exceptions, its override, and its owner are all explicit and reviewable.
How it works¶
- State the constraint testably. Write the forbidden, required, and permitted relationships precisely enough that a person or system can apply them.
- Define the exception. Specify when an otherwise-invalid relationship may be allowed, by whom, for how long, and with what documentation.
- Bound the override. Name the authority who may grant exceptions and the scope, reason codes, and expiry that limit them.
- Assign ownership and cadence. Name the accountable owner and the review interval, then hand the rule to executable mechanisms that enforce it.
Tuning parameters¶
- Rule precision — bright-line versus judgment-based wording. Bright lines are testable and rigid; judgment is flexible and inconsistent.
- Exception breadth — narrow, tightly-scoped waivers versus broad discretion. Broad language preserves flexibility but erodes into routine bypass.
- Override bounds — how tightly the authority is constrained by scope, reason codes, and expiry.
- Review cadence — how often the owner revisits the rule against changing reality. Rare review lets the rule go stale; frequent review costs governance effort.
- Coverage scope — which relations and domains the policy reaches.
When it helps, and when it misleads¶
Its strength is that it makes a relationship rule explicit, contestable, and ownable. Without the written rule, enforcement is ad hoc and no one can say why a relationship was allowed or refused; with it, exceptions and accountability are on the record.
Its failure mode is that a policy is only paper. If no mechanism enforces it, it becomes a policy-practice gap — a rule everyone cites and no one applies — and the document lends false comfort that the risk is handled. Over-broad exception language quietly turns waivers into the normal path, and a rule with no named owner drifts out of date as roles and systems change. The guarding discipline is to pair every relation policy with an executable enforcement mechanism, keep the override tightly bounded, and give the rule a living owner and a review date rather than filing it and forgetting it.
How it implements the components¶
This document fills the governance-source slice of the archetype — stating the rule and its exception structure, not performing enforcement:
compatibility_rule— states in prose which relationship pairings are forbidden, required, or permitted under the regime.exception_rule— defines when an otherwise-invalid relationship may be allowed, by whom, for how long, and with what documentation.override_authority— names the bounded authority empowered to grant those exceptions.relation_owner— assigns accountability for maintaining the rule and its review cadence.
A written rule performs nothing: it does not sit at an enforcement_point, run a validation_rule, or open a safe_rejection_or_deferral_path — those executable duties belong to mechanisms like Workflow Transition Guard and Authorization Relationship Check, which enforce what this policy declares.
Related¶
- Instantiates: Relation Constraint Enforcement — it is the authoritative written source of a relationship constraint and its exception structure.
- Sibling mechanisms: Authorization Relationship Check · Foreign-Key Constraint · Graph Schema Validation · Relational Integrity Test Suite · Dependency Constraint Check · Workflow Transition Guard · Role Compatibility Check
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Policy Relation Rule operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it a written governance rule that states which relationships are required, permitted, or forbidden under a policy regime, along with its exception conditions, override authority, and owner.
Independent corroboration: The frozen evidence defines Policy Relation Rule as 'A written governance rule that states which relationships are required, permitted, or forbidden under a policy regime, along with its exception conditions, override authority, and owner', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Rules declaring relationships required, permitted, or forbidden are a legal-governance form.
Related originating lineages:
- Public Administration & Policy — Public administration contributes ownership, override, and implementation details for operating the rule.
Review resolution: Both blind reviewers agree that law governance is the primary origin. Reconciliation resolves origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement. Formative alternate lineages are retained as public_administration_policy; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A screening step like Role Compatibility Check and a Workflow Transition Guard are the natural executors of a Policy Relation Rule: the policy states the forbidden pairing and its waiver conditions, and those mechanisms apply it at appointment or at a transition. Keeping the rule separate from its enforcers is what lets the constraint be debated and revised without rewriting the systems that apply it.
[n1] Recusal — the practice of removing a decision-maker from a matter in which they hold a conflicting relationship or interest. It is the standard default remedy a conflict-of-interest policy prescribes when no waiver applies. ↩