Relation Constraint Enforcement¶
Define and enforce which relationships are valid so the system cannot enter inconsistent, unsafe, or contradictory relational states.
The Diagnostic Story¶
Symptom: Something is wrong with a record, assignment, or workflow, but nobody can pinpoint it because each piece looks valid on its own. A dependency points to an entity that no longer exists, a role combination creates an unchecked authority nobody intended to grant, and a process advances past a gate that should have been locked. Exceptions quietly accumulate into a shadow structure that contradicts the official one.
Pivot: Stop validating entities in isolation and start enforcing the constraints on what they can be connected to. Define which relationships are allowed, required, or forbidden — including direction, multiplicity, compatibility, and authority — and enforce those constraints at every point where relationship state is created, modified, or acted upon.
Resolution: Invalid, orphaned, or contradictory relationship states are blocked before they become authoritative. Required links are confirmed before dependent actions proceed. Forbidden pairings are caught, not merely documented, and the distinction between a valid exception and an uncontrolled workaround becomes visible and reviewable.
Reach for this when you hear…¶
[database engineering] “The foreign key violation only showed up in production because we were checking individual rows, not whether the rows could legally reference each other.”
[hospital credentialing] “The attending and the reviewer were the same person on three charts — nobody flagged it because each credential individually passed, but the combination never should have been allowed.”
[supply chain] “We approved the PO locally, but the supplier relationship wasn't authorized for that product category, and we didn't find out until customs held the shipment.”
When This Archetype Applies¶
Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.
Diagnostic problem
A system allows relationships among entities, records, actors, roles, resources, processes, or artifacts that should not coexist, should not point in that direction, should not have that multiplicity, or should not be trusted as valid without additional checks.
What this problem means
The structural problem is not merely bad data, bad actors, or bad objects. It is a bad relational state. The system permits links that should not exist, omits links that must exist, reverses directionality, allows too many or too few instances of a relationship, or treats an unsupported pairing as legitimate.
This creates failures that are easy to miss because every individual entity may look valid. A record exists, but points to the wrong parent. A process step is completed, but by an actor who should not have that relationship to the decision. A dependency exists, but violates trust boundaries. A policy case is filed, but lacks required source, consent, or authority links. The inconsistency lives between entities.
The recurring tension is flexibility versus relational closure. Real systems need unusual relationships, migrations, exceptions, and emergency handling. But without constraints, the system drifts into states that cannot be trusted. The archetype preserves flexibility by making exceptions explicit rather than allowing invalid relationships to disappear into informal workarounds.
Show the applicability expression
Applicability expression4 distinct conditions
groundedpartly groundedopen
4 conditions, all required.
4Required in every casenumbered 1–4
These hold no matter which pattern applies.
Invalid entity relationships · open
Entities are individually valid but can be connected in invalid or harmful ways.
This creates failures that are easy to miss because every individual entity may look valid. The narrower requirement in this condition set is: Entities are individually valid but can be connected in invalid or harmful ways.
Relationship-dependent decisions · open
Downstream decisions depend on relationship validity, not just on the properties of individual items.
It is especially useful when downstream action depends on relationship validity. The narrower requirement in this condition set is: Downstream decisions depend on relationship validity, not just on the properties of individual items.
Broken relation structures · grounded
The system contains orphaned links, duplicate owners, contradictory assignments, invalid references, circular dependencies, or prohibited role combinations.
Typical triggers include orphaned records, duplicate owners, invalid dependencies, forbidden role combinations, unsupported approvals, missing required links, and relationships that are accepted before compatibility or authority is checked. The narrower requirement in this condition set is: The system contains orphaned links, duplicate owners, contradictory assignments, invalid references, circular dependencies, or prohibited role combinations.
Unchecked relationship changes · open
Failures arise when relationship changes are accepted before compatibility, cardinality, authority, or directionality has been checked.
Typical triggers include orphaned records, duplicate owners, invalid dependencies, forbidden role combinations, unsupported approvals, missing required links, and relationships that are accepted before compatibility or authority is checked. The narrower requirement in this condition set is: Failures arise when relationship changes are accepted before compatibility, cardinality, authority, or directionality has been checked.
Other requirements and context (1)
Why these sit outside the expression
Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.
Supporting contextManual judgment or informal convention is no longer enough to keep relations valid at scale.
If later processes, audits, safety checks, payments, access permissions, or decisions assume that a relation is valid, then invalid relations need to be stopped before they propagate. In this archetype, the relevant contextual consideration is: Manual judgment or informal convention is no longer enough to keep relations valid at scale. It helps interpret the situation or strengthens the practical case for examining the archetype.
Coverage
1 of 4 conditions grounded · 3 open.
Mechanisms / Implementations¶
- Foreign-Key Constraint: A declarative database rule that refuses any write which would leave a record pointing to a non-existent related record, guaranteeing referential existence at the storage layer.
- Graph Schema Validation: A conformance check that judges whether the nodes and edges of a graph satisfy a declared schema of allowed labels, edge types, directions, and structural rules.
- Role Compatibility Check: A pre-appointment screen that tests a proposed role assignment against the role's competence bar and against conflict and separation constraints, before the assignment is made.
- Conflict-of-Interest Check: This mechanism implements Relation Constraint Enforcement by blocks or escalates relationships that would place an actor in a compromised, self-dealing, or improperly dependent position.
- Policy Relation Rule: 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.
- Dependency Constraint Check: A design-time procedure that tests an artifact's dependency edges against architectural rules — no cycles, no forbidden cross-boundary or lower-tier edges — and prescribes fixes for edges that already violate them.
- Authorization Relationship Check: A runtime access control that validates whether the relationships among actor, resource, permission, and delegated authority authorize a requested action before it is allowed.
- Workflow Transition Guard: A gate on a process state transition that blocks the move unless the required relationships — approvals, handoffs, ownership, evidence links — are valid, holding or escalating the case when they are not.
- Relational Integrity Test Suite: A maintained set of assertions run on a schedule over live data to detect relational violations that already exist — orphans, duplicate owners, forbidden pairings — and route them for correction.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Closure: Ensures operations remain within a set.
- Constraint: Limits possibilities to guide outcomes.
- Relation: Describes associations or dependencies.
Also references 13 related abstractions
- Access Control: Restrict system access.
- Accountability: Responsibility for actions.
- Boundary: Defines system limits.
- Cardinality: Size of sets.
- Conflict of Interest: Competing incentives.
- Data Integrity: Accuracy and consistency preserved.
- Function (Mapping): Relates inputs to outputs.
- Invariance: Properties unchanged under transformation.
- Network: Models interactions between components.
- Role Conflict: Conflicting roles.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Referential Integrity Enforcement · domain variant · recognized
Enforce that references among records, objects, documents, or identifiers point only to valid related entities.
Cardinality Constraint Enforcement · subtype · recognized
Enforce how many instances of a relationship may or must exist for each entity, role, state, or case.
Compatibility Constraint Enforcement · subtype · recognized
Prevent relationships between entities, roles, states, interests, or artifacts that are structurally incompatible.
Dependency Constraint Enforcement · subtype · candidate
Constrain which dependencies may exist so designs, workflows, releases, or supply chains do not form unsupported or hazardous dependency structures.
Separation-of-Duties Enforcement · governance variant · recognized
Prevent a single actor or role from holding incompatible relationships to actions, approvals, assets, or records.
Editorial Notes¶
Problem Classification¶
Classification: Correctness, Conformance & Formal Validity Failure → Feasibility & Requirement Consistency
Problem kernel: invalid relational states violate cardinality or direction constraints
Rationale: Earliest causal condition: A system allows relationships among entities, records, actors, roles, resources, processes, or artifacts that should not coexist, should not point in that direction, should not have that multiplicity, or should not be trusted as valid without additional checks.
Independent corroboration: The earliest necessary condition in the frozen evidence is: A system allows relationships among entities, records, actors, roles, resources, processes, or artifacts that should not coexist, should not point in that direction, should not have that multiplicity, or should not be trusted as valid without additional checks. That is a feasibility requirement and invariant consistency problem because Required constraints, guarantees, relations, or necessary conditions are absent, mutually incompatible, intrinsically impossible, or unenforceable together within the stated scope.
Review outcome: Independent reviewer agreement; high confidence.