Relation Constraint Enforcement

batch: First Iteration/Batch 08

aliases:
Relationship Constraint Enforcement
Relational Integrity Enforcement
Relationship Validation and Enforcement
Relation Guardrail

source_primes: relation constraint closure

slug: relation

slug: constraint

slug: closure

slug: cardinality

slug: boundary

slug: accountability

slug: versioning

slug: schema

slug: function

slug: network

components:
Relation Schema
Cardinality Rule
Compatibility Rule
Directionality Rule
Validation Rule
Enforcement Point
Safe Rejection or Deferral Path
Exception Rule
Audit Trail
Override Authority
Remediation Path
Monitoring Signal
Relation Owner

mechanisms:
Foreign-Key Constraint
Graph Schema Validation
Role Compatibility Check
Conflict-of-Interest Check
Policy Relation Rule
Dependency Constraint Check
Authorization Relationship Check
Workflow Transition Guard
Relational Integrity Test Suite

essence_one_line: Define and enforce which relationships are valid so the system cannot enter inconsistent, unsafe, or contradictory relational states.

compression_statement: When entities can form invalid, contradictory, unsafe, or unsupported relationships, specify the valid relation structure and enforce it at the point where relationships are created, changed, approved, synchronized, or relied upon.

core_intuition: Many failures do not come from bad entities in isolation; they come from impossible, forbidden, stale, or ambiguous relationships among otherwise valid entities. Relation Constraint Enforcement works by making the relationship itself a governed object with validity conditions, checks, and consequences.

canonical_formula: entities + relation_schema + relation_constraints + enforcement_point → valid_relational_state

structural_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.

trigger_conditions: Entities are individually valid but can be connected in invalid or harmful ways.

trigger_conditions: Downstream decisions depend on relationship validity, not just on the properties of individual items.

trigger_conditions: The system contains orphaned links, duplicate owners, contradictory assignments, invalid references, circular dependencies, or prohibited role combinations.

trigger_conditions: Manual judgment or informal convention is no longer enough to keep relations valid at scale.

trigger_conditions: Failures arise when relationship changes are accepted before compatibility, cardinality, authority, or directionality has been checked.

symptoms: A record points to a missing, obsolete, unauthorized, or incompatible record.

symptoms: Two actors are assigned relationships that create conflict of interest, role conflict, or unchecked authority.

symptoms: A workflow advances even though required approvals, dependencies, ownership links, or evidence links are missing.

symptoms: Teams discover too late that a dependency, handoff, reporting line, or ownership relation is impossible or unsupported.

symptoms: Data, policy, or operational states appear valid locally while being inconsistent relationally.

symptoms: Exceptions accumulate without visibility, creating a shadow relation structure that contradicts the official one.

root_tension: Systems need flexible relationship formation to adapt to real cases, but they also need relational closure: changes should remain inside the set of valid relationship structures. If all relationships are allowed, the system becomes inconsistent; if constraints are too rigid, legitimate edge cases are blocked or driven underground.

anti_signatures: The problem is mainly that relationships are unknown or implicit; use relation_mapping or dependency_exposure first.

anti_signatures: The relation is valid but poorly documented for audit or change propagation; use traceability_linking.

anti_signatures: The issue is choosing an authoritative record among conflicting representations; use source_of_truth_assignment.

anti_signatures: The problem is general state invariance rather than validity of relationships among entities; compare invariant_guarding or closure_preserving_operation.

anti_signatures: The relation is merely inconvenient or inefficient, not invalid, unsafe, contradictory, or unsupported.

structural_intervention: Define the allowed, required, forbidden, cardinality, directionality, compatibility, dependency, or authority constraints on relationships and enforce those constraints wherever relationship state is created, modified, approved, synchronized, interpreted, or acted upon.

action_logic: Identify the relation-bearing entities and the relationship types whose validity matters.

action_logic: Define valid relational structure: allowed participants, direction, multiplicity, required links, forbidden pairings, lifecycle states, and contextual exceptions.

action_logic: Translate the validity definition into concrete validation rules, schemas, policies, gates, tests, or review criteria.

action_logic: Place enforcement at the earliest reliable point before an invalid relationship becomes authoritative state or triggers downstream action.

action_logic: Provide safe rejection, correction, deferral, escalation, or quarantine paths for invalid or uncertain relationships.

action_logic: Record violations, overrides, exceptions, and remediation outcomes so constraints can be audited and improved.

action_logic: Monitor drift and update constraints when legitimate relationship patterns change.

decision_rules: Enforce only relationships whose invalidity would materially affect integrity, safety, accountability, fairness, reliability, or interoperability.

decision_rules: Prefer clear rejection when a proposed relation violates a hard safety or integrity constraint.

decision_rules: Prefer deferral or escalation when the evidence needed to judge relation validity is incomplete.

decision_rules: Allow exceptions only when the exception owner, duration, justification, impact, and review path are explicit.

decision_rules: Avoid making a mechanism such as a foreign key, checklist, or schema validator the entire archetype; it is an implementation of the broader enforcement logic.

decision_rules: Revisit constraints when rejection rates rise, workarounds spread, or legitimate cases repeatedly need overrides.

target_invariants: Only valid relationships may become authoritative system state.

target_invariants: Required relationships are present before dependent actions proceed.

target_invariants: Forbidden relationships are blocked, quarantined, escalated, or removed.

target_invariants: Relationship direction, multiplicity, and compatibility remain interpretable and testable.

target_invariants: Exceptions remain visible, bounded, justified, and reviewable.

target_invariants: Invalid relations discovered after the fact have a remediation path rather than being normalized silently.

expected_outcomes: Fewer inconsistent, orphaned, contradictory, or unsafe relationship states.

expected_outcomes: Higher data integrity, workflow integrity, policy compliance, and accountability.

expected_outcomes: Earlier detection of impossible assignments, invalid dependencies, incompatible roles, and prohibited associations.

expected_outcomes: More reliable downstream reasoning because relation validity is preserved at the point of use.

expected_outcomes: Clearer distinction between valid exceptions and uncontrolled workarounds.

prose_essence:
Relation Constraint Enforcement is the archetype for making relationships safe, valid, and governable. It applies when the entities in a system may each be acceptable on their own, but the relationship among them can be invalid, contradictory, unsafe, unsupported, or unauthorized.

The central move is to treat the relationship itself as a state that must satisfy rules. A customer can exist and an order can exist, but the order must point to a valid customer. A clinician can exist and a medication can exist, but the medication order must be linked to the right patient, prescriber, indication, and contraindication review. A role can exist and an employee can exist, but assigning the employee to two incompatible duties may create a conflict. The archetype prevents these invalid relationships from quietly becoming trusted system state.

prose_when_to_use:
Use this archetype when hidden or weakly enforced relationship rules are allowing relational corruption. 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.

It is especially useful when downstream action depends on relationship validity. 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.

Do not use this as the first move when relationships are simply unknown. In that case, Relation Mapping or Dependency Exposure comes first. Relation Constraint Enforcement becomes relevant when the valid relationship structure can be stated and the system needs to prevent invalid relationships from entering, remaining in, or being treated as authoritative state.

prose_structural_problem:
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.

prose_intervention_logic:
The intervention starts by identifying the relation types that matter: ownership, reference, approval, dependency, reporting, membership, custody, eligibility, delegation, causation, traceability, or any other relation that downstream processes rely on.

Next, it defines valid relational structure. The structure may include allowed participants, required links, forbidden pairings, directionality, lifecycle state, cardinality, compatibility, authority, and exception conditions. The definition must be specific enough to test, but not so rigid that all edge cases become failures.

Then the relation rules are placed at enforcement points. The best enforcement point is usually close to the moment when relationship state becomes authoritative: a database write, workflow transition, release approval, identity delegation, contract execution, policy decision, or synchronization event. Later auditing may still be needed, but late discovery is usually more expensive than early prevention.

Finally, the system needs governed handling for violations. A failed relation can be rejected, quarantined, corrected, deferred, escalated, or granted a documented exception. This is where the archetype avoids brittleness: invalid relations are not silently accepted, but uncertain or legitimate edge cases are not forced into shadow channels.

prose_key_components:
### Relation Schema

Defines the allowed relation types, participating entity kinds, permitted directions, and required attributes before enforcement begins. The schema makes the relational state inspectable. Without it, enforcement becomes ad hoc approval rather than a governed relation structure.

### Cardinality Rule

Specifies how many relationships of a given type may or must exist, such as one-to-one, one-to-many, many-to-many, exactly one, or at most one. Cardinality is often where relational corruption appears: duplicate owners, orphaned records, impossible pairings, or missing required links.

### Compatibility Rule

States which entity kinds, roles, statuses, identities, or conditions are allowed to relate to each other. Compatibility rules prevent structurally wrong associations, such as assigning a person to mutually exclusive roles or linking an artifact to an unsupported parent.

### Directionality Rule

Clarifies whether a relationship is directional, symmetric, reciprocal, hierarchical, dependent, or ordered. Directionality prevents inversion errors where “approves,” “depends on,” “owns,” “reports to,” or “causes” is mistakenly treated as interchangeable with its reverse.

### Validation Rule

Checks whether a proposed, existing, or changed relationship satisfies the relation schema and its cardinality, compatibility, and directionality constraints. Validation turns the intended relation structure into a testable condition that can be applied manually, procedurally, or automatically.

### Enforcement Point

Locates where the system intercepts invalid relational changes before they become authoritative state or harmful action. The enforcement point may be a database write, workflow transition, policy approval, identity-management step, contract review, or model update gate.

### Safe Rejection or Deferral Path

Defines what happens when a relationship fails validation: reject, quarantine, request correction, escalate, or defer until evidence is available. This component prevents invalid relations from silently entering the system while also avoiding brittle failure when a case is uncertain or exceptional.

### Exception Rule

Defines when an otherwise invalid or unusual relationship may be permitted, by whom, for how long, and with what documentation. Exception handling preserves necessary flexibility without turning enforcement into unreviewable override culture.

Optional components extend the enforcement loop when risk, scale, or governance complexity increases.

### Audit Trail

Records relation changes, validation outcomes, rejected attempts, exceptions, and override decisions. Auditability is especially important when constraints govern money, safety, rights, access, accountability, or evidence chains.

### Override Authority

Identifies who may authorize constrained exceptions or emergency relation changes. An override authority should be bounded by scope, reason codes, review cadence, and conflict-of-interest safeguards.

### Remediation Path

Guides correction when invalid relationships are discovered after they have already entered the system. Remediation matters because many relational errors are inherited from legacy records, manual workarounds, migrations, or prior policy gaps.

### Monitoring Signal

Detects drift, repeated rejections, suspicious overrides, missing links, orphan records, or emerging constraint mismatch. Monitoring distinguishes healthy enforcement from brittle constraint accumulation that no longer matches operational reality.

### Relation Owner

Assigns accountability for maintaining a relation type, reviewing exceptions, and updating constraints when the system changes. Without ownership, constraints tend to decay into stale rules that block valid work or fail to stop invalid states.

prose_common_mechanisms:
Mechanisms implement the archetype in specific domains. They should not be confused with the archetype itself. A foreign key, policy rule, workflow gate, graph validator, or checklist is only a mechanism if it helps define, test, enforce, repair, or audit valid relationship state.

### Foreign-Key Constraint

This mechanism implements Relation Constraint Enforcement by enforces referential integrity by preventing records from pointing to non-existent, invalid, or unsupported related records. It is a software or tool mechanism, not the whole archetype.

### Graph Schema Validation

This mechanism implements Relation Constraint Enforcement by checks whether nodes and edges in a graph satisfy allowed labels, directions, cardinalities, and attribute requirements. It is a test or assessment mechanism, not the whole archetype.

### Role Compatibility Check

This mechanism implements Relation Constraint Enforcement by prevents incompatible role assignments, reporting lines, permissions, duties, or responsibilities from coexisting. It is a procedure mechanism, not the whole archetype.

### 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. It is a checklist mechanism, not the whole archetype.

### Policy Relation Rule

This mechanism implements Relation Constraint Enforcement by states allowed, required, or forbidden relationships in governance, eligibility, safety, contracting, or compliance contexts. It is a document mechanism, not the whole archetype.

### Dependency Constraint Check

This mechanism implements Relation Constraint Enforcement by prevents unsupported, circular, missing, or prohibited dependencies from entering a design, workflow, supply chain, or release plan. It is a procedure mechanism, not the whole archetype.

### Authorization Relationship Check

This mechanism implements Relation Constraint Enforcement by ensures that access, delegation, ownership, or approval relationships match the governing identity and permission model. It is a software or tool mechanism, not the whole archetype.

### Workflow Transition Guard

This mechanism implements Relation Constraint Enforcement by prevents a process from moving to a new state unless required relationships, approvals, handoffs, or dependencies are valid. It is a workflow mechanism, not the whole archetype.

### Relational Integrity Test Suite

This mechanism implements Relation Constraint Enforcement by runs recurring checks for orphaned links, duplicate owners, forbidden pairings, missing mandatory relations, or directionality errors. It is a test or assessment mechanism, not the whole archetype.

prose_failure_modes:
Overconstraint occurs when the rule blocks valid relationships because the schema is too narrow or outdated. The mitigation is to review repeated rejections and create bounded exceptions or revised constraints.

Underenforcement occurs when the rule exists but is not applied where relationship state becomes authoritative. The mitigation is to move enforcement closer to creation, approval, synchronization, or state transition.

Stale relation schemas occur when roles, lifecycle states, dependencies, or policies change but constraints remain fixed. The mitigation is to assign relation ownership and monitor override patterns, rejection rates, and invalid relation incidents.

Hidden override culture appears when users bypass constraints through informal records, shared accounts, manual side channels, or unlogged exceptions. The mitigation is to make legitimate exception paths visible and safer than shadow workarounds.

Context-blind validation occurs when a rule checks a simple entity type or count but ignores lifecycle, consent, authority, conflict, safety, or fairness context. The mitigation is to include the context needed for validity or escalate cases where the context cannot be evaluated automatically.

prose_neighbor_distinctions:
Relation Mapping makes relationships visible; Relation Constraint Enforcement decides which of those relationships are valid and prevents invalid ones from becoming trusted state.

Dependency Exposure reveals hidden dependencies; Dependency Constraint Enforcement, as a variant of this archetype, blocks or remediates dependency edges that violate allowed structure.

Traceability Linking creates links that support audit and change propagation; Relation Constraint Enforcement governs whether such links are valid, required, forbidden, complete, or strong enough for downstream use.

Closure-Preserving Operation keeps transformation outputs within a valid domain. Relation Constraint Enforcement is a relational specialization: it keeps relationship states inside the valid relational structure.

Invariant Guarding protects any condition that must remain true. Relation Constraint Enforcement protects invariants expressed as valid, required, or forbidden relationships.

Access Control governs who may access or act on resources. Relation Constraint Enforcement may support access control when the central question is whether actor-resource-permission-delegation relationships are valid.

prose_cross_domain_examples:
In database design, a purchase-order line may reference only an existing order and active product record. The constraint prevents orphaned or stale references from corrupting downstream fulfillment and accounting.

In finance controls, the same employee may not both create a vendor and approve payment to that vendor. The constrained relation is not a data link alone; it is a governance relation among actor, vendor, action, and approval authority.

In software architecture, a production service may be prevented from depending on packages in lower trust tiers or deprecated lifecycle states. The dependency edge itself becomes constrained relation state.

In clinical operations, a medication order may require valid links among patient, prescriber, medication, indication, allergy review, and administration authority. The rule prevents unsafe relation combinations rather than merely validating each entity separately.

In ontology or knowledge-graph governance, a subclass edge may be rejected if it creates a cycle or violates type constraints. The relation must remain valid for inference to remain trustworthy.

prose_non_examples:
A stakeholder map is not Relation Constraint Enforcement unless it is used to define and enforce allowed, required, or forbidden stakeholder relationships.

A dependency inventory is not this archetype unless dependency edges are checked against constraints and invalid dependencies are blocked, escalated, or remediated.

A foreign key by itself is not the archetype. It is one mechanism for referential integrity, and it can fail if lifecycle state, exception handling, authority, or remediation is ignored.

A policy statement saying that conflicts of interest are prohibited is not enough. The archetype requires a way to detect, reject, escalate, document, and review relationships that violate the prohibition.

prose_tradeoffs:
The main tradeoff is integrity versus flexibility. The stronger the constraint, the harder it is for invalid relations to enter the system, but the more likely it becomes that legitimate edge cases need a special path.

Another tradeoff is automation versus judgment. Automated enforcement can be consistent and scalable, but it may encode blind spots. Human review can handle context, but it may introduce inconsistency, delay, bias, or political pressure.

A third tradeoff is explicit exception handling versus administrative overhead. Documented exceptions improve accountability, but excessive exception paperwork can create incentives for informal workarounds.

prose_invariants_to_preserve:
The key invariant is that trusted relationship state remains valid. More specifically, required relations should exist before dependent action proceeds; forbidden relations should not become authoritative; directionality and multiplicity should remain interpretable; and exceptions should remain visible and bounded.

The archetype also preserves accountability. Someone should be able to explain why a relationship was allowed, rejected, corrected, or excepted. If no one can reconstruct that decision, the relation constraint may function operationally but not governably.

Finally, the archetype preserves repairability. Invalid relationships discovered after the fact should be correctable without destroying history or making downstream artifacts incoherent.

prose_target_outcomes:
Successful Relation Constraint Enforcement reduces orphaned records, invalid references, duplicate owners, incompatible role assignments, prohibited approvals, unsafe dependency edges, and missing required links. It improves data integrity, governance reliability, workflow safety, compliance, and downstream reasoning.

A good implementation also makes relational assumptions explicit. People no longer need to guess whether a relationship is allowed, required, or forbidden; the system either enforces the rule directly or makes review and exception handling visible.

prose_parameter_dimensions:
Important tuning dimensions include strictness, enforcement timing, exception tolerance, automation level, relation granularity, context sensitivity, and remediation depth.

Strictness controls how much evidence is required before a relationship is accepted. Higher strictness is useful in safety-critical, financial, legal, medical, or access-control settings, but it can increase false rejection.

Enforcement timing controls whether invalid relations are blocked at creation, detected at synchronization, audited after the fact, or remediated during periodic review. Earlier enforcement reduces propagation; later enforcement may be more flexible but allows more damage.

Exception tolerance controls whether unusual cases are impossible, escalated, time-bound, manually approved, or freely overridden. Mature implementations preserve exception paths without turning exceptions into normal bypasses.

Automation level controls whether rules are checked by software, workflow logic, policy review, human judgment, or mixed systems. Automation is valuable for clear relational rules; human review remains important when context, ethics, fairness, or incomplete evidence affects validity.

Relation granularity controls whether constraints apply to individual records, actor-role relationships, resource permissions, dependency edges, process handoffs, organizational units, ontology edges, or entire subgraphs. Granularity should match the harm being prevented.

prose_variants_and_near_names:
Referential Integrity Enforcement focuses on valid references among records, artifacts, identifiers, or objects. Foreign-key constraints are a familiar mechanism here, but the variant is broader than databases.

Cardinality Constraint Enforcement focuses on how many relationship instances may or must exist. Examples include exactly one owner, at most one active assignment, or at least one approval link.

Compatibility Constraint Enforcement focuses on whether two entities, roles, statuses, interests, or artifacts may be related under the current context. Conflict-of-interest checks and role compatibility checks often implement this variant.

Dependency Constraint Enforcement focuses on dependency edges: whether they are circular, unsupported, prohibited, missing, or incompatible with trust or lifecycle rules.

Separation-of-Duties Enforcement is a governance variant that prevents a single actor from occupying incompatible relationships to actions, approvals, assets, or records. It may deserve later promotion if its cross-domain governance logic proves distinct enough.

Near names include relationship validation, relational integrity enforcement, relation guardrail, association constraint, graph constraint validation, and foreign-key constraint. Most of these should collapse into the parent or into a variant unless they add a distinct intervention pattern.

Referential Integrity Enforcement

short_definition: Enforce that references among records, objects, documents, or identifiers point only to valid related entities.

distinctive_feature: The constrained relationship is a reference relation: one record or artifact asserts a link to another.

distinct_from_parent: It is narrower than the parent because it focuses on validity of references rather than all relation types.

still_same_parent_because: The intervention still defines and enforces valid relationships, usually through schema, validation, rejection, and repair.

source_primes: relation constraint data_integrity

use_when: Records can point to missing, deleted, duplicate, deprecated, or unsupported targets.

use_when: Downstream reasoning depends on references remaining valid over time.

use_when: Invalid references would create orphaned records, evidence gaps, billing errors, or broken workflows.

example: A customer order cannot reference a customer record that does not exist.

example: A case file cannot cite a withdrawn evidence item as active without an exception record.

failure_modes: Soft-deleted targets appear valid unless lifecycle state is included.

failure_modes: Automated repair rewires links without preserving history.

Cardinality Constraint Enforcement

short_definition: Enforce how many instances of a relationship may or must exist for each entity, role, state, or case.

distinctive_feature: The key constraint is the count or multiplicity of a relation rather than the identity of the related entities alone.

distinct_from_parent: It is a subtype focused on relation quantity and requiredness.

still_same_parent_because: It uses the parent pattern of defining valid relation structure and enforcing it before invalid states become authoritative.

source_primes: relation constraint cardinality

use_when: A relation must be exactly one, at most one, at least one, one-to-many, or many-to-many.

use_when: Invalid multiplicity causes duplicate authority, orphaned responsibility, over-assignment, or missing required links.

use_when: The risk is not merely whether a relation is allowed, but whether too many or too few instances exist.

example: Every critical process must have exactly one accountable owner.

example: A medication order must be linked to one prescribing clinician and one patient.

failure_modes: Rigid cardinality can block legitimate temporary shared ownership.

failure_modes: Counting rules can hide quality problems in the relationship itself.

Compatibility Constraint Enforcement

short_definition: Prevent relationships between entities, roles, states, interests, or artifacts that are structurally incompatible.

distinctive_feature: The relation is governed by pairwise or contextual compatibility rather than by existence or count alone.

distinct_from_parent: It focuses on whether this entity may relate to that entity under the current context.

still_same_parent_because: The core intervention still defines valid relation structure and uses enforcement to block invalid associations.

source_primes: relation constraint role_conflict

use_when: The relation may be invalid even if both entities are individually valid.

use_when: Role combinations, statuses, attributes, interests, or lifecycle states make the pairing unsafe or contradictory.

use_when: Invalid pairings create conflicts of interest, safety hazards, data corruption, or accountability ambiguity.

domain: governance

example: A reviewer cannot approve a grant application where they have a financial interest.

example: A temporary contractor may not be made owner of a permanent privileged account.

failure_modes: Compatibility criteria become opaque or biased.

failure_modes: Rules freeze a past state and block legitimate role evolution.

Dependency Constraint Enforcement

short_definition: Constrain which dependencies may exist so designs, workflows, releases, or supply chains do not form unsupported or hazardous dependency structures.

distinctive_feature: The constrained relation is dependency, with special attention to direction, criticality, circularity, and allowable coupling.

distinct_from_parent: It narrows enforcement to dependency relations and often interacts with dependency exposure or dependency ordering.

still_same_parent_because: The dependency rule is still a relation constraint applied at an enforcement point.

source_primes: relation constraint coupling

use_when: Dependency relationships can become circular, unsupported, missing, over-coupled, or incompatible with policy.

use_when: Hidden or invalid dependencies would undermine resilience, release safety, resource planning, or accountability.

use_when: The system needs to block bad dependency edges rather than merely expose or map them.

example: A module cannot depend on a deprecated package or on a package in a lower trust zone.

example: A milestone cannot be marked ready while depending on an unresolved upstream decision.

failure_modes: The rule focuses on visible dependencies and misses informal workarounds.

failure_modes: Circular dependencies are allowed by exception until they become normal.

Separation-of-Duties Enforcement

short_definition: Prevent a single actor or role from holding incompatible relationships to actions, approvals, assets, or records.

distinctive_feature: It constrains relationships among actors, permissions, assets, and duties to preserve checks and balances.

distinct_from_parent: It is a governance/security variant focused on incompatible duty relationships.

still_same_parent_because: It still implements the parent logic by defining forbidden relation combinations and enforcing them at approval or access points.

use_when: Fraud, error, capture, or unchecked authority would be enabled by combining certain roles or permissions.

use_when: The critical constraint is relational: the same actor may not be linked to both initiating and approving, custody and reconciliation, or request and authorization.

use_when: Governance requires a visible exception and audit path when separation cannot be maintained.

example: The same employee cannot both create a vendor and approve payment to that vendor.

example: A principal investigator cannot be the sole approver of a conflict disclosure involving their own financial interest.

failure_modes: Rules are bypassed through shared accounts or informal delegation.

failure_modes: Over-separation slows work without reducing meaningful risk.

near_names:
Relationship Validation
Relational Integrity Enforcement
Graph Constraint Validation
Foreign Key Constraint
Relation Guardrail
Association Constraint


Relation Mapping

type: archetype

source: generated

Relationship Mapping

notes: Common-language synonym when relation semantics are explicit and action-relevant.

Association Mapping

notes: Near-name that may be weaker if it only records association without direction, strength, consequence, or governance use.

Network Mapping

notes: Often overlaps, but topology-centered network analysis may require graph/network-specific archetypes.

source_primes: relation network observability

related_primes: graph_network coupling data_integrity accountability boundary constraint transparency stakeholder_analysis topology

slug: observability

slug: coupling

slug: transparency

slug: topology

components:
Entity Inventory
Relation Type Catalog
Relation Instance Link
Directionality and Cardinality
Relation Strength Indicator
Evidence and Source Basis
Scope Boundary
Validation and Update Loop
Ownership Annotation
Consequence Annotation
Temporal Validity Window
Visualization Layer
Access and Privacy Policy

mechanisms:
Dependency Map
Stakeholder Map
Data Lineage Map
Relationship Graph
Ownership Map
Causal Map
Adjacency Matrix
RACI Matrix
Service Dependency Inventory
Knowledge Graph

essence_one_line: Make important associations or dependencies explicit so they can be reasoned about, governed, repaired, or redesigned.

compression_statement: When hidden or implicit relationships shape outcomes, map the entities, relation types, directionality, strength, constraints, evidence basis, and consequences of those relations so actors can coordinate, govern, repair, or redesign the system with fewer blind spots.

core_intuition: Systems often fail not because the entities are unknown, but because the relations among them are invisible or mislabeled. A relation map turns a fog of informal ties, assumptions, dependencies, obligations, and influence paths into a shared object of reasoning. Once the relation is explicit, people can ask whether it is valid, too strong, missing, outdated, harmful, or assigned to the wrong owner.

canonical_formula: relation_mapping = entity_inventory + relation_type_catalog + labeled_edges + directionality/cardinality + evidence_basis + validation/update_loop

structural_problem: Important associations, dependencies, ownership links, influence paths, obligations, constraints, or data relationships exist but are not explicit enough to guide action.

description: Actors believe elements are independent until a change, failure, or decision reveals an unseen relation.

description: People know that entities are somehow related, but cannot say what kind of relation exists, in which direction, or with what consequence.

description: Work crosses teams, roles, systems, or institutions, but handoffs and mutual reliance are not visible enough to manage.

description: Outcomes depend on relations among owners, authorities, contributors, or custodians, yet those relations are too implicit to assign responsibility.

description: A proposed change may affect connected entities, but the relation structure is not explicit enough to predict or govern impact.

description: Entities are documented separately, causing decision makers to miss the relation pattern that actually drives behavior.

symptom: A local change repeatedly causes surprising downstream effects.

interpretation: The relation structure is operating, but it has not been made visible or validated.

symptom: Different teams maintain incompatible mental maps of who depends on whom.

interpretation: Relations exist socially or technically, but there is no shared representation.

symptom: A diagram exists but no one agrees what the lines mean.

interpretation: The artifact lacks relation semantics, evidence basis, or decision rules.

symptom: Ownership, influence, or obligation is contested after failure.

interpretation: The relevant accountability relations were not explicit before action was needed.

symptom: Risk reviews focus on individual components while relational failure modes are missed.

interpretation: The system is being understood as a set of parts rather than as a set of consequential relations.

root_tension: Relation mapping must make enough structure explicit to support action without pretending that all relations are stable, measurable, objective, or ethically safe to expose.

case: A static inventory of entities is enough.

why_not: Use a list, registry, or catalog when no consequential relation semantics need to be represented.

case: The central need is to define input-output behavior of one element.

why_not: Use functional_specification when behavior of a component, process, role, model, or policy is the main object.

case: The central need is to order work once dependencies are already known.

why_not: Use dependency_ordering when the relation structure is already explicit and the intervention is sequencing or scheduling.

case: The central need is preserving audit continuity from origin to outcome.

why_not: Use traceability_linking when source-to-consequence chains, evidence continuity, or change propagation are decisive.

case: A visual graph is produced for communication only and does not affect decisions.

why_not: A diagram may be a communication artifact, but relation mapping as an archetype requires reasoning, governance, repair, or redesign use.

structural_intervention: Create and maintain an explicit representation of consequential relations among entities, including relation types, directionality, strength or criticality, constraints, evidence, and intended decision use.

logic: State what decision, risk, governance, repair, design, or coordination problem the relation map must support.

logic: Choose the system boundary, entity classes, time horizon, and relation types worth representing.

logic: List the actors, components, records, variables, processes, resources, obligations, or artifacts that can participate in the relevant relations.

logic: Name the kinds of relations to be mapped, such as dependency, ownership, influence, membership, obligation, transformation, compatibility, or conflict.

logic: Record directionality, cardinality, strength, confidence, temporal validity, constraint status, and consequences where they matter.

logic: Record how each relation is known, who can verify it, and who maintains the relation record.

logic: Check the map against observations, records, domain experts, affected actors, and counterexamples.

logic: Use the map to assign governance, redesign flows, run impact analysis, plan engagement, monitor risks, or repair broken relations.

logic: Update relation records as entities, dependencies, roles, or evidence change; version maps that guide consequential decisions.

description: Include a relation because it changes reasoning, coordination, governance, risk, or redesign, not merely because it can be drawn.

description: Every line, link, or edge should say what relation it represents; unlabeled edges invite false inference.

description: Mark whether a relation is directly observed, analytically inferred, socially reported, legally mandated, or desired by design.

description: A depends-on, reports-to, funds, influences, transforms, or owns relation cannot be safely treated as symmetric unless it truly is symmetric.

description: A weak link and a critical link may both exist, but they should not receive equal visual or governance weight.

description: Maps of social, political, security, health, or commercial relations can create harm if overexposed or misused.

description: A relation map that informs action becomes dangerous when it drifts from the current relation structure.

description: Mapped nodes or entities remain identifiable enough that relation records are not attached to the wrong thing.

description: Each relation type has a clear meaning, and different relation types are not silently conflated.

description: Directional, reciprocal, one-to-one, one-to-many, many-to-one, and many-to-many relations are represented accurately where they matter.

description: Important relation claims retain enough source or validation information to be challenged, updated, or audited.

description: The level of detail and abstraction remains appropriate to the decisions the map is meant to support.

description: Users can tell whether a relation is current, historical, provisional, seasonal, or expected to change.

description: Sensitive relations are exposed only to the degree needed for legitimate use and with appropriate access controls.

description: Actors can see consequential connections that were previously implicit, fragmented, or hidden.

description: Teams, systems, or institutions can coordinate because dependencies, handoffs, obligations, and influence paths are explicit.

description: Decision makers can anticipate what a change may affect before it causes unexpected disruption.

description: Broken, missing, overloaded, invalid, or harmful relations can be identified and redesigned.

description: Ownership, responsibility, authority, and custody relations can be discussed before failures occur.

description: A validated relation map becomes a common reference for governance, audit, design, risk, or learning conversations.

prose_essence:
Relation Mapping is the archetype for making consequential relationships explicit. It is not merely drawing a network diagram. The intervention works when the system’s behavior depends on links among entities that people currently hold in separate, partial, or conflicting mental models.

The key move is to turn an implicit relation into a named, inspectable, and maintainable object: this entity depends on that one; this role owns that obligation; this dataset feeds that model; this actor influences that decision; this process constrains that downstream process. Once the relation is explicit, it can be validated, governed, repaired, strengthened, weakened, monitored, or redesigned.

Use this archetype when knowing the parts is not enough. The pattern that matters is between the parts.

prose_when_to_use:
Use Relation Mapping when relations materially shape outcomes but are not visible enough to guide action. This often appears when a local change creates surprising downstream consequences, teams disagree about dependencies, responsibilities are contested, or a diagram exists but no one agrees what the lines mean.

The archetype is especially useful when a decision depends on questions such as: who depends on whom, what flows through which path, who owns which obligation, which actor influences which outcome, which record feeds which report, which components are coupled, or which relations are valid enough to rely on.

Do not use it just because a graph could be drawn. A useful relation map is purpose-bound. It should support a concrete use such as change impact analysis, governance, accountability, repair, redesign, risk review, engagement planning, or coordination.

prose_structural_problem:
The structural problem is hidden relational structure. Entities are known, but the consequential links among them are implicit, scattered, outdated, disputed, or mislabeled. A system can look like a collection of parts while actually behaving like a web of dependencies, obligations, influence paths, constraints, and feedback effects.

This creates a characteristic failure: people optimize, govern, or change one entity at a time while the relation pattern determines the real outcome. A software team changes a service without knowing which reports depend on it. A policy team changes a rule without seeing the agencies and obligations connected to it. A manager assigns responsibility without seeing informal handoffs. A data team updates a field without seeing downstream models.

The root tension is that relations need enough explicitness to support action, but not every relation can or should be exposed. Some relations are unstable, uncertain, political, confidential, or ethically sensitive. The map must be useful without becoming falsely authoritative or harmful.

prose_intervention_logic:
Relation Mapping begins by defining the purpose of the map. A dependency map for migration planning, a stakeholder relation map for public engagement, and a data lineage map for auditability require different relation types and levels of detail.

Next, the mapper sets a scope boundary. The boundary answers: which entities count, which relation types matter, what time horizon applies, and what decisions the map will support. Without this boundary, maps either sprawl endlessly or hide exclusions as if they were facts.

The central step is relation semantics. Lines, arrows, links, or edges must mean something specific. A line can mean depends-on, funds, reports-to, transforms, owns, constrains, influences, conflicts-with, duplicates, verifies, or is-compatible-with. These meanings are not interchangeable. The map should also indicate directionality, cardinality, strength, confidence, and evidence when those properties affect action.

Finally, the map must be validated and connected to action. A relation map that is never used is a diagram. A relation map that informs governance, redesign, monitoring, or repair becomes a working abstraction.

prose_key_components:
### Entity Inventory

The entity inventory names the things that can participate in mapped relations. Entities may be people, roles, teams, services, datasets, documents, requirements, processes, resources, obligations, variables, or artifacts. The inventory must be clear enough that a relation is not attached to the wrong thing.

### Relation Type Catalog

The relation type catalog defines what each relation means. This is the heart of the archetype. Without a relation type catalog, a map can show connectedness while hiding whether the connection is dependency, authority, influence, ownership, conflict, transformation, evidence, or constraint.

### Relation Instance Link

A relation instance link records a specific relation between particular entities. It is the atomic record of the map: entity A has relation R to entity B under these conditions. A good relation instance can be validated, challenged, updated, or used in a decision.

### Directionality and Cardinality

Directionality and cardinality specify whether a relation is one-way, reciprocal, one-to-one, one-to-many, many-to-one, or many-to-many. These properties matter because many relation errors come from treating asymmetric relations as symmetric. “A depends on B” is not the same as “B depends on A.”

### Relation Strength Indicator

The relation strength indicator marks criticality, weight, frequency, confidence, influence, intensity, or risk. Two relations can both exist while differing radically in importance. A weak informational link should not be read like a critical operational dependency.

### Evidence and Source Basis

The evidence and source basis records how a relation is known. It may come from observation, system logs, documents, interviews, legal rules, data flow, expert judgment, or inference. This component prevents a visually polished map from laundering assumptions into apparent facts.

### Scope Boundary

The scope boundary states what is included and excluded. It defines entity classes, relation types, time horizon, and granularity. This protects the map from becoming either limitless or deceptively incomplete.

### Validation and Update Loop

Relations change. A validation and update loop checks the map against reality and revises it as systems, roles, obligations, dependencies, and evidence change. A relation map that guides action needs ownership and maintenance, not only initial creation.

prose_common_mechanisms:
A **dependency map** implements Relation Mapping by showing reliance relations among components, teams, suppliers, services, tasks, or assumptions. It is useful when changes or failures propagate through dependence.

A **stakeholder map** implements Relation Mapping by showing actor relations such as influence, obligation, trust, conflict, interest, or communication. It is useful for governance and engagement, but it can become ethically sensitive when used to expose or manipulate social relations.

A **data lineage map** implements Relation Mapping by showing how data sources, transformations, stores, models, reports, and decisions relate. It is useful for auditability and change impact, though it may overlap with Traceability Linking when evidence-chain continuity is central.

A **relationship graph** uses graph notation to represent entities as nodes and relation instances as edges. The graph notation is a mechanism, not the archetype. A graph becomes Relation Mapping only when relation semantics, evidence, validation, and use are explicit.

An **ownership map** implements Relation Mapping by showing responsibility, custody, authority, or approval relations. It supports governance and escalation, but should not be confused with Source-of-Truth Assignment unless it designates authoritative records.

A **causal map** implements a causal variant of Relation Mapping. It requires extra discipline because causal edges should not be inferred from correlation, sequence, or narrative plausibility alone.

A **RACI matrix** implements a narrow ownership or responsibility relation map. It can clarify who is responsible, accountable, consulted, and informed, but it can also oversimplify real authority and capacity.

A **knowledge graph** implements Relation Mapping as a queryable data structure. It can support discovery and inference, but the same cautions apply: relation types, evidence, and maintenance determine whether it is trustworthy.

prose_failure_modes:
The most common failure mode is ambiguous edges. A map with unlabeled arrows often produces more confidence than understanding. The mitigation is to require relation types and edge labels.

A second failure mode is stale mapping. Relation maps degrade as roles, systems, obligations, and dependencies change. The mitigation is maintenance ownership, versioning, and review triggers.

A third failure mode is false authority. A precise-looking map may rest on weak evidence. The mitigation is to label confidence, source, validation status, and uncertainty.

A fourth failure mode is visual clutter. Too many relations at one level can make the map unusable. The mitigation is layering by relation type, criticality, audience, or decision use.

A fifth failure mode is relation laundering. Representing a harmful or contested relation neutrally can make it appear natural or legitimate. The mitigation is to distinguish descriptive relations from normative or desired relations and to provide review paths for affected actors.

A sixth failure mode is privacy or power harm. Sensitive social relation maps can be used to surveil, rank, pressure, or manipulate people. The mitigation is minimization, access control, consent where appropriate, and explicit ethical review.

prose_neighbor_distinctions:
Relation Mapping differs from **Functional Specification** because it maps links among entities rather than specifying the expected input-output behavior of one entity.

It differs from **Dependency Exposure** because Dependency Exposure focuses specifically on hidden reliance, fragility, criticality, ownership, monitoring, and contingency action. Relation Mapping may include dependencies but is broader.

It differs from **Traceability Linking** because Traceability Linking preserves source-to-consequence continuity for audit, evidence, requirements, decisions, tests, or change propagation. Relation Mapping may show links without creating a full traceability chain.

It differs from **Dependency Ordering** because ordering uses known dependencies to sequence work. Relation Mapping discovers or clarifies the dependency structure first.

It differs from **Whole System Impact Mapping** because impact mapping anticipates consequence cascades from a change. Relation Mapping exposes the relation structure that can support that analysis.

It differs from **Relation Constraint Enforcement** because constraint enforcement prevents invalid relations. Relation Mapping can reveal relations and relation types, but enforcement is an additional intervention.

It differs from **Source-of-Truth Assignment** because assigning authority resolves conflicts among representations. Relation Mapping may reveal conflicting representations, but it does not choose the authoritative one.

prose_cross_domain_examples:
In software architecture, a team preparing to retire an API maps upstream callers, downstream consumers, shared databases, caches, reports, owners, and criticality. The resulting map guides migration sequencing and communication.

In public policy, an agency maps service providers, legal obligations, residents, courts, funding streams, and enforcement bodies before changing a housing program. The map helps reveal coordination points and accountability gaps.

In supply chain operations, a manufacturer maps supplier, material, certification, shipping, substitution, and quality-control relations. The map reveals where an apparently minor vendor dependency could disrupt a major product line.

In data governance, a data team maps source systems, transformations, feature tables, dashboards, and model outputs before changing a field definition. The map reveals downstream effects that a table inventory alone would miss.

In organizational design, leaders map formal reporting lines, informal influence paths, handoffs, shared tools, and overloaded coordination links before merging teams. The map prevents a reorganization from preserving hidden bottlenecks.

In education, a curriculum team maps prerequisite relations among concepts, assignments, and assessments. The map reveals that students are failing a later task because a supporting concept was never connected to the learning sequence.

prose_non_examples:
A decorative diagram with unlabeled arrows is not Relation Mapping. It may communicate that things are connected, but it does not define relation semantics or support governance.

A simple inventory of systems, roles, or stakeholders is not Relation Mapping until the relations among them are represented.

A functional contract for one service is not Relation Mapping unless the central work is mapping the service’s relations with other entities.

A schedule based on already-known prerequisites is not Relation Mapping. The active intervention is ordering, not relation discovery.

A social graph used for manipulation, surveillance, or coercion is not a legitimate use of this archetype. It is a misuse of relation visibility.

prose_tradeoffs:
Relation Mapping adds overhead. Discovering, validating, updating, and explaining relations takes time. The effort is justified when relational blind spots create real risk or coordination cost.

It also creates a simplification tradeoff. A useful map abstracts. It cannot include every relation. The danger is that omitted relations become invisible to decision makers.

There is a transparency tradeoff. Making relations visible can support accountability, but can also expose sensitive social, commercial, clinical, security, or political information.

There is an authority tradeoff. A map can become the shared reference for a group, but it may also privilege the perspective of the mapmaker or the most powerful participants.

Finally, relation mapping can delay action. Mapping is valuable when it changes decisions; it becomes wasteful when it becomes a ritual substitute for decisions.

prose_invariants_to_preserve:
Relation semantics must remain clear. A map loses value when the same line means several things or when different relation types are visually indistinguishable.

Entity identity must remain stable enough for use. If a node changes meaning across contexts, relation records become unreliable.

Directionality and cardinality must be preserved where action depends on them. Asymmetric relations should not be casually treated as reciprocal.

Evidence traceability must remain available for consequential relation claims. Users should know whether a relation is observed, inferred, reported, legally mandated, or hypothesized.

Decision alignment must be preserved. The map should be detailed enough for its intended use and not burdened with relations irrelevant to that use.

Temporal validity must be visible. A relation that used to hold, may hold, or holds only under certain conditions should not appear identical to a current stable relation.

Ethical visibility boundaries must be protected. Sensitive relation information should not be exposed simply because it can be mapped.

prose_target_outcomes:
The primary outcome is visible relation structure. Actors can see the dependencies, obligations, ownership paths, influence links, constraints, or data flows that shape outcomes.

A second outcome is better coordination. When handoffs and dependencies are explicit, teams can plan around them instead of discovering them through failure.

A third outcome is improved change-impact awareness. Relation maps help decision makers ask what else will be affected before changing a component, rule, role, record, or process.

A fourth outcome is repairability. Once a relation is visible, it can be strengthened, weakened, removed, rerouted, governed, or validated.

A fifth outcome is clearer accountability. Ownership, authority, custody, and obligation relations can be discussed before failures force blame-oriented reconstruction.

prose_parameter_dimensions:
**Granularity** determines whether the map represents high-level domains, teams, systems, functions, records, tasks, or individual interactions. Coarse maps aid strategy; fine maps aid operations and debugging.

**Relation-type breadth** determines whether the map focuses on one relation type, such as dependency, or multiple relation types, such as ownership, influence, data flow, and obligation. Broader maps explain more but become harder to read.

**Directionality discipline** determines whether arrows and asymmetric edges are required. Some social or conceptual associations are symmetric; dependencies, authority, data flow, and causality usually are not.

**Strength or confidence scale** determines whether relation intensity is binary, ordinal, quantitative, probabilistic, or qualitative. The scale should match the evidence and decision use.

**Temporal scope** determines whether the map represents current, historical, future, seasonal, episodic, or conditional relations. Dynamic systems often need versioned or layered maps.

**Evidence threshold** determines which relations are included. A low threshold supports exploration; a high threshold supports audit or governance. Mixing them without labels creates false authority.

**Visibility and access** determine who can view, edit, export, or act on the map. Sensitive relation maps may require role-based access, aggregation, consent, redaction, or review.

prose_variants_and_near_names:
**Dependency Mapping** is a relation mapping variant focused on reliance. It is useful when the relation of interest is “depends on,” “requires,” “blocks,” or “is affected by.” Keep it distinct from the later **Dependency Exposure** archetype when the main intervention is hidden fragility and contingency planning.

**Stakeholder Relation Mapping** maps actors and relations such as influence, obligation, conflict, trust, interest, and responsibility. It is a useful variant but needs ethical caution because social relation visibility can be used well or badly.

**Data Lineage Mapping** maps how data sources, transformations, records, reports, models, and decisions relate. It is a variant of Relation Mapping unless the core intervention is auditable source-to-consequence traceability.

**Ownership Relation Mapping** maps custody, responsibility, authority, and accountability relations. It is useful for governance but should not be confused with designating a source of truth.

**Causal Relation Mapping** maps hypothesized causal edges. It needs evidence discipline because relation visibility can be mistaken for causal proof.

Near names include relationship mapping, association mapping, network mapping, dependency graph, stakeholder map, relationship graph, ownership map, and data lineage diagram. Most of these are aliases, variants, or mechanisms rather than separate archetypes.

Dependency Mapping

variant_type: subtype

short_definition: Maps which entities rely on which other entities, resources, assumptions, or services.

distinctive_feature: Edges are dependency relations with direction, criticality, and possible failure consequences.

distinct_from_parent: The parent maps any action-relevant relation; this variant restricts relation semantics to dependence or reliance.

still_same_parent_because: It still performs the same core move: making hidden or implicit relations explicit for reasoning and governance.

source_primes: relation network coupling

use_when: The relation of interest is reliance rather than mere association.

use_when: Failure, delay, or change in one entity can affect another through a dependency edge.

use_when: The map is needed before sequencing, risk analysis, contingency planning, or redesign.

Entity Inventory

role: Identifies the dependent and depended-upon elements.

Directionality and Cardinality

role: Clarifies who depends on whom and whether one-to-one or many-to-many reliance exists.

Relation Strength Indicator

role: Marks dependency criticality or substitutability.

Dependency Map

mechanism_type: artifact

role: Visualizes dependency edges for review or redesign.

Service Dependency Inventory

mechanism_type: document

role: Records technical or operational service dependencies.

example: A team maps which services call, cache, or depend on which other services before a migration.

example: A manufacturer maps supplier, material, and logistics dependencies across product lines.

failure_modes: Mistaking dependency listing for dependency exposure; the latter must connect hidden dependencies to risk, ownership, or mitigation.

failure_modes: Representing every weak reliance equally, causing critical dependencies to disappear in visual clutter.

Stakeholder Relation Mapping

short_definition: Maps actors and their interests, influence, dependencies, obligations, conflicts, or communication relations.

distinctive_feature: The entities are actors or actor groups, and relation semantics include influence, interest, responsibility, trust, or obligation.

distinct_from_parent: The parent can map any relation among any entities; this variant focuses on social and institutional actors.

still_same_parent_because: The intervention still depends on explicit relation semantics and map validation rather than on the engagement plan itself.

source_primes: relation stakeholder_analysis network

use_when: Coordination or legitimacy depends on knowing how actors relate to one another.

use_when: Influence, obligation, conflict, or accountability paths are socially distributed.

use_when: The map will guide engagement, escalation, governance, or communication choices.

Entity Inventory

role: Identifies actors, groups, institutions, or roles to map.

Relation Type Catalog

role: Separates influence, obligation, dependency, trust, conflict, and communication relations.

Access and Privacy Policy

role: Protects sensitive social information from misuse.

Stakeholder Map

role: Represents actor relations for planning and engagement.

Influence–Interest Grid

mechanism_type: template

role: Simplifies actor relations into engagement categories.

example: A city maps resident groups, agencies, advocacy organizations, and statutory obligations before redesigning a service.

example: A change team maps sponsors, blockers, implementers, and impacted teams before altering a workflow.

failure_modes: Treating people as static nodes rather than actors whose roles, incentives, and relationships change.

failure_modes: Using a stakeholder map as covert surveillance or manipulation rather than legitimate coordination and accountability support.

Data Lineage Mapping

short_definition: Maps how data elements move, transform, and depend on upstream sources across systems or processes.

distinctive_feature: Relations connect data sources, transformations, stores, and consumers rather than generic entities.

distinct_from_parent: The parent maps relations generally; this variant uses relation mapping to preserve data integrity and interpret downstream outputs.

still_same_parent_because: It remains a relation map unless it specifically creates auditable source-to-consequence trace links, in which case traceability_linking is the closer archetype.

source_primes: relation data_integrity transparency

use_when: Data quality, auditability, model reliability, or privacy obligations depend on source and transformation relations.

use_when: Downstream decisions depend on upstream records whose provenance or transformation path is unclear.

use_when: A change in one data source could silently affect reports, models, or operations elsewhere.

Entity Inventory

role: Identifies data sources, tables, models, reports, or consumers.

Relation Instance Link

role: Records transformations, reads, writes, joins, or dependencies.

Evidence and Source Basis

role: Records how each lineage relation was established.

Data Lineage Map

role: Shows data flow and transformation relations.

Metadata Catalog

role: Maintains relation records across datasets and systems.

example: A model team maps training-data sources, feature transformations, and production consumers.

example: An accounting team maps which source ledgers feed each consolidated report.

failure_modes: Omitting transformation semantics, so the lineage graph shows movement but not how values change.

failure_modes: Letting the map drift after pipeline changes, causing false confidence in auditability.

Ownership Relation Mapping

short_definition: Maps responsibility, authority, custody, or ownership relations so accountability paths become explicit.

distinctive_feature: Relations encode responsibility, custody, authority, or duty rather than only dependency or association.

distinct_from_parent: The parent makes relations explicit in general; this variant focuses on accountability-relevant ownership semantics.

still_same_parent_because: It is still a relation map unless it designates a single authoritative record, which belongs closer to source_of_truth_assignment.

use_when: Assets, decisions, processes, risks, or obligations lack clear accountable owners.

use_when: Multiple actors can act on an object, but rights, duties, and escalation paths are ambiguous.

use_when: The map will guide governance, handoff, escalation, or audit decisions.

Ownership Annotation

role: Marks responsible, consulted, approving, or custodial actors.

Relation Type Catalog

role: Distinguishes ownership from authority, responsibility, custody, and support.

Validation and Update Loop

role: Keeps ownership relations current when roles or systems change.

Ownership Map

role: Displays ownership or responsibility relations.

RACI Matrix

role: Maps responsible, accountable, consulted, and informed roles.

example: A governance team maps dataset owners, stewards, approvers, and downstream consumers.

example: A risk office maps which teams own each control, exception, and remediation obligation.

failure_modes: Naming nominal owners without authority or capacity to act.

failure_modes: Conflating ownership with source-of-truth authority or decision rights.

Causal Relation Mapping

variant_type: other

short_definition: Maps hypothesized causal relations among variables, events, actors, or system states.

distinctive_feature: Edges assert or hypothesize cause-effect relations and should include evidence strength or uncertainty.

distinct_from_parent: The parent does not require causal semantics; this variant does, and therefore demands stronger evidence discipline.

still_same_parent_because: It remains relation mapping when the goal is to expose and reason over causal links rather than perform formal causal inference or model validation.

source_primes: relation causality network

use_when: Intervention choices depend on understanding which relations are causal rather than merely associative.

use_when: The map will support hypothesis generation, impact anticipation, or causal validation.

use_when: Feedback, mediation, or confounding may change how apparent relations should be interpreted.

Evidence and Source Basis

role: Marks whether a causal edge is observed, inferred, hypothesized, or validated.

Relation Strength Indicator

role: Captures confidence, effect size, or relevance of causal edges.

Validation and Update Loop

role: Revises the map as evidence changes.

Causal Map

role: Represents hypothesized causal relations.

Influence Diagram

role: Shows influence paths among decisions, uncertainties, and outcomes.

example: A team maps social, behavioral, clinical, and environmental relations behind a health outcome.

example: A leader maps how incentives, communication bottlenecks, and workload pressure reinforce delay.

failure_modes: Treating correlation, sequence, or narrative plausibility as proven causation.

failure_modes: Leaving uncertainty unlabeled, causing decision makers to overtrust speculative edges.

near_names:
Relationship Mapping
Association Mapping
Network Mapping
Dependency Graph
Stakeholder Map
Relationship Graph
Ownership Map
Data Lineage Diagram
Traceability Matrix


Relation Rewiring

batch: First Iteration/Batch 08/Wave 2

Network Realignment

notes: Useful when the relation changes are discussed in network terms, but too broad if it only means generic topology redesign.

Relationship Restructuring

notes: Plain-language near name for changing social, organizational, institutional, or technical relationships.

Stakeholder Realignment

notes: Often a participatory or governance implementation of relation rewiring, especially when obligations and influence paths must shift.

Workflow Rerouting

notes: A common mechanism for relation rewiring in operations and service design, not the archetype itself.

source_primes: relation graph_network feedback

related_primes: coupling flow causality leverage_points boundary delegation_of_authority accountability incentive_compatibility observability resilience interoperability topology

slug: feedback

slug: flow

slug: causality

slug: resilience

slug: interoperability

components:
Baseline Relation Map
Rewiring Objective
Edge Change Set
Relation Change Authority
Transition and Continuity Plan
Post-Rewiring Monitoring
Externality and Harm Check
Mediating Relation
Bypass Path Closure
Coupling Strength Rule
Role or Accountability Update
Rollback or Reversal Path

mechanisms: Dependency Injection or Adapter Substitution

essence_one_line: Change the relationships among entities to alter information flow, incentives, dependencies, responsibility, or influence patterns.

compression_statement: When existing relationships among actors, systems, resources, or roles sustain harmful dependency, influence, conflict, bottleneck, or coordination patterns, deliberately add, remove, redirect, mediate, strengthen, or weaken those relations so system behavior changes while preserving critical continuity and accountability.

core_intuition: Many failures persist because the wrong entities are connected, disconnected, overconnected, or connected through the wrong path. Relation Rewiring treats the relationship pattern itself as the intervention surface: change who depends on whom, who informs whom, who approves whom, or who routes to whom, and the behavior of the system can change without replacing every entity inside it.

canonical_formula: relation_rewiring = baseline_relation_map + rewiring_objective + edge_change_set + authority_boundary + transition_plan + post_rewiring_feedback

structural_problem: Existing relationships among entities create harmful dependency, influence, coordination, incentive, accountability, access, or flow patterns, and those harms persist even when the individual entities are competent or well-defined.

description: A unit, actor, component, vendor, agency, or workflow depends on another relation in a way that creates fragility, lock-in, bottleneck, or capture.

description: Information, cases, resources, approvals, or decisions flow through a path that causes delay, distortion, overload, leakage, or lost context.

description: The entities that shape behavior are connected in ways that amplify the wrong pressures or isolate the actors who need influence.

description: Responsibility, authority, escalation, or oversight relations are connected to the wrong actors or missing at the point of consequence.

description: Actors that should coordinate lack a usable relationship, or actors that need autonomy are coupled too tightly.

symptom: Work repeatedly stalls at the same handoff or approval point.

interpretation: The current relation path is producing a bottleneck, not merely poor effort.

symptom: Problems recur after training, documentation, or clearer responsibility labels.

interpretation: The relationship pattern may still route influence, information, or dependency through the wrong edges.

symptom: A supposedly independent unit is effectively controlled by an informal dependency or influence path.

interpretation: Hidden or informal relations may override the intended structure.

symptom: Removing one actor or vendor causes disproportionate disruption.

interpretation: The relation topology concentrates dependency and needs redesign rather than just monitoring.

symptom: People create unofficial workarounds to get information, decisions, or support.

interpretation: The formal relation pattern does not match operational needs.

root_tension: The system needs enough connection for coordination, flow, support, and accountability, but too much, too little, or wrongly routed connection creates fragility, conflict, delay, capture, or unintended influence.

case: The relationships are unclear but not yet known to be harmful or misrouted.

why_not: Use relation_mapping first when the immediate need is to make associations visible before choosing an intervention.

case: The issue is hidden dependency risk rather than a chosen structural change.

why_not: Use dependency_exposure when the main intervention is surfacing dependencies and assigning risk actions.

case: The central issue is invalid, forbidden, or contradictory relationships.

why_not: Use relation_constraint_enforcement when the needed move is to define and enforce valid relation structure.

case: The relation change is only a generic network diagram or topology exercise.

why_not: This archetype requires a practical relation-level intervention tied to flow, influence, dependency, responsibility, or coordination.

case: The only change is a new label, org chart, or tool with no actual shift in obligations, access, dependency, or flow.

why_not: Treat that as documentation or implementation noise, not relation rewiring.

structural_intervention: Identify the relation pattern that sustains the problem, define the desired relation pattern, then add, remove, redirect, mediate, strengthen, or weaken specific relationships while preserving continuity, legitimacy, and accountability.

logic: Identify entities, relation types, directionality, strength, formal and informal paths, constraints, and affected parties.

logic: Determine how the current relation pattern creates the unwanted dependency, influence, bottleneck, conflict, delay, exclusion, or accountability failure.

logic: Specify what should flow, stop, be mediated, be strengthened, be weakened, or become accountable after the intervention.

logic: Choose the minimal sufficient set of relation additions, removals, redirections, mediations, or strength changes.

logic: Clarify who can change the relation, who is affected, what must be communicated, and how continuity is protected during transition.

logic: Apply the relation change, observe whether intended behavior changes, and watch for bypass paths, new bottlenecks, orphaned responsibilities, or externalized harm.

logic: Tune, extend, rollback, or replace the rewiring when evidence shows unintended consequences or insufficient behavioral change.

guidance: Do not rewire a system merely because a relation map exists; the relationship pattern must be a credible cause of the problem.

guidance: Before removing or redirecting an edge, identify what support, information, authority, or service that edge currently carries.

guidance: Change the smallest set of relations likely to alter behavior, then monitor, rather than creating broad network churn.

guidance: An org chart, schema, or routing rule counts only if real access, obligation, dependency, or flow changes.

guidance: Rewiring should not remove necessary voice, appeal, safety review, or accountability simply to reduce friction.

description: Essential service, safety, decision, support, or information functions remain available during and after relation change.

description: It remains possible to tell who is responsible for decisions, handoffs, consequences, and exceptions after the relation pattern changes.

description: No critical actor, component, case, or obligation loses its only viable support path unless a safe replacement exists.

description: Affected parties, legal obligations, contractual constraints, and consent boundaries are not bypassed by the rewiring.

description: The system remains observable enough to detect whether the rewired relations are producing intended or harmful effects.

description: Fragile, captured, overloaded, or risky dependencies are reduced, diversified, mediated, or redirected.

description: Information, work, resources, approvals, or support reach the right actors through more effective paths.

description: Authority, ownership, escalation, and responsibility relations become better aligned with consequences.

description: Influence patterns that sustained dysfunction are interrupted, mediated, or redirected toward desired behavior.

description: The system is less vulnerable to single-edge failure, informal bypass, overcentralization, or unsupported handoffs.

prose_essence:
Relation Rewiring is the intervention to use when the **pattern of relationships** is part of the problem. It does not merely describe who is connected to whom. It changes the relationship pattern so dependency, influence, information, authority, support, or work flows differently.

The archetype is especially useful when capable parts of a system still produce bad outcomes because they are connected in the wrong way. A team may report to the wrong authority. A service may depend directly on a brittle downstream component. Cases may route through a queue that strips context. A public program may require agencies to coordinate through a path that no one can actually use. The intervention surface is the relation itself.

prose_when_to_use:
Use Relation Rewiring when the current relation pattern creates or sustains harm: a dependency is too concentrated, a flow path is too slow, an influence channel is misaligned, a coordination relation is missing, or an accountability path routes consequences away from responsible actors.

It is a good fit when you can say: “The entities are not the only problem; the way they are connected is the problem.” It is weaker when the system simply needs a clearer map, a stricter validity rule, a better specification, or a source-of-truth decision.

prose_structural_problem:
The structural problem is a misaligned relation topology at the practical level of actors, systems, roles, resources, or decisions. Existing edges may carry the wrong flow, concentrate fragility, route influence through conflicted actors, create unnecessary coupling, or leave crucial actors disconnected.

A recurring sign is that local fixes do not stick. Training, documentation, or role labels improve understanding, but the same handoff fails because the old relation path still routes work through the bottleneck. Risk remains because one supplier, actor, system, or approval path still carries too much critical dependency. Informal bypasses continue because the formal relation pattern does not match operational needs.

prose_intervention_logic:
The intervention begins by mapping the current relation pattern, then diagnosing how that pattern produces the observed problem. The designer then defines the desired relation behavior: which flows should be redirected, which dependencies should be reduced, which relations should be mediated, which authority paths should move, and which missing connections should be added.

The core move is the **edge change set**. Relations can be added, removed, redirected, mediated, strengthened, or weakened. The change should be minimal enough to avoid needless churn, but real enough to alter access, dependency, information, authority, or responsibility. After implementation, monitoring is essential because new relations can create new bottlenecks, hidden dependencies, or externalized burdens.

prose_key_components:
- **Baseline Relation Map** (`baseline_relation_map`): establishes the current pattern of association, dependency, influence, authority, responsibility, or flow. It is the diagnostic substrate, not the intervention itself.
- **Rewiring Objective** (`rewiring_objective`): states what the new relation pattern is supposed to improve, such as resilience, accountability, coordination, access, or flow.
- **Edge Change Set** (`edge_change_set`): names the actual relation changes: additions, removals, redirections, mediations, or strength adjustments. This is the structural core of the archetype.
- **Relation Change Authority** (`relation_change_authority`): clarifies who can change the relationships and who must consent, approve, or be informed.
- **Transition and Continuity Plan** (`transition_and_continuity_plan`): protects service, trust, responsibility, and context while old relations are retired and new ones become operational.
- **Post-Rewiring Monitoring** (`post_rewiring_monitoring`): watches for intended behavior change and for unintended bottlenecks, bypasses, or orphaned responsibilities.
- **Externality and Harm Check** (`externality_and_harm_check`): tests whether the change shifts burden, surveillance, exclusion, or risk onto parties who were not represented in the design.

Optional components include a mediating relation, bypass-path closure, coupling-strength rules, role/accountability updates, and rollback paths.

prose_common_mechanisms:
Common mechanisms implement the archetype but should not be confused with it.

**Organizational redesign** changes reporting lines, decision rights, team boundaries, or escalation relations. It implements Relation Rewiring only when real authority, responsibility, access, or coordination changes.

**Workflow rerouting** changes the path that work, cases, approvals, or information follow. It is a mechanism for flow-focused rewiring, not a standalone archetype.

**Stakeholder realignment workshops** help actors negotiate new relationships, obligations, or coordination patterns. A workshop is not rewiring unless the agreed relation changes are implemented.

**Communication channel redesign** changes who can communicate with whom, how often, through which medium, and with what visibility or escalation. It can strengthen, weaken, or mediate relations.

**Partnership restructuring** changes institutional, vendor, jurisdictional, or contractual relationships so obligations and dependencies are redistributed.

**Dependency injection or adapter substitution** implements relation rewiring in technical systems by changing how components depend on or invoke one another.

**Routing table or rule updates** implement relation rewiring in configured systems by changing the relation between incoming cases, destinations, and decision paths.

**Network intervention pilots** test relation changes on a limited scale before a full rollout.

prose_failure_modes:
Common failure modes include unintended dependency creation, authority confusion, shadow-network reassertion, overcentralized bottlenecks, loss of context or trust, externalized burden, and churn without behavior change.

A frequent failure is mistaking formal change for real relation change. If an org chart, routing rule, or interface is updated but people still use the same old influence, escalation, or dependency paths, the system has not truly been rewired.

prose_neighbor_distinctions:
**Relation Mapping** makes relationships explicit; Relation Rewiring changes them.

**Dependency Exposure** reveals hidden dependency and fragility; Relation Rewiring changes dependency paths.

**Relation Constraint Enforcement** defines valid and invalid relationships; Relation Rewiring changes valid relationships to alter behavior.

**Bridge Insertion** is a specific additive relation intervention; Relation Rewiring is broader.

**Feedback Loop Redirection** focuses on how outputs influence future behavior; Relation Rewiring includes feedback paths but also covers authority, workflow, supply, access, and dependency relations.

**Topology Reconfiguration** can be broad graph redesign; Relation Rewiring stays anchored in practical relation changes and their behavioral consequences.

prose_cross_domain_examples:
In organizational governance, moving safety escalation from delivery teams to an independent risk office rewires authority and accountability relations.

In software architecture, replacing direct calls to a fragile component with an adapter and fallback path rewires dependency relations.

In public services, creating direct referral paths between crisis responders and follow-up providers rewires service-network relations.

In operations, routing high-risk cases to specialist triage rewires workflow relations.

In supply chains, replacing a single-source dependency with a managed multi-supplier structure rewires dependency and monitoring relations.

prose_non_examples:
A stakeholder map without implemented relation changes is Relation Mapping, not Relation Rewiring.

A dependency registry without changes to ownership, fallback, routing, or coupling is Dependency Exposure, not Relation Rewiring.

A foreign-key constraint is Relation Constraint Enforcement, not Relation Rewiring.

A new org chart that leaves real authority, information flow, and informal escalation unchanged is not Relation Rewiring.

prose_tradeoffs:
Relation Rewiring trades stability for structural change. It can improve coordination but disrupt routines. It can reduce a fragile dependency but add overhead. It can clarify accountability but reduce local flexibility. It can remove harmful ties but also lose weak ties that carried trust, context, or redundancy.

The design challenge is to change enough of the relation pattern to alter behavior without creating excessive churn, bottlenecks, exclusion, or power concentration.

prose_invariants_to_preserve:
The main invariants are critical continuity, accountability traceability, no orphaned dependency, legitimate authority and consent boundaries, and post-change observability.

A relation change should not strand people, cases, obligations, or systems that depended on the old relation. It should not erase accountability, remove legitimate access, or make consequences harder to trace. It should leave enough observability to detect whether the new relation pattern is working.

prose_target_outcomes:
Successful Relation Rewiring reduces harmful dependencies, improves coordination and flow, clarifies accountability, redirects influence or incentives, and creates a more resilient relation structure.

The strongest sign of success is not that the diagram looks cleaner. It is that the changed relation pattern produces different behavior: fewer bottlenecks, less fragility, clearer authority, better support, or safer flow.

prose_parameter_dimensions:
Important tuning dimensions include relation type, directionality, strength, exclusivity, mediation depth, reversibility, rollout pace, authority level, and monitoring intensity.

A relation can be formal or informal, mandatory or optional, direct or mediated, one-way or reciprocal, weak or strong, local or system-wide. The right setting depends on the problem: reducing harmful coupling may require weakening a relation, while fixing coordination failure may require strengthening or adding one.

prose_variants_and_near_names:
Recognized variants include edge addition rewiring, edge removal rewiring, flow rerouting, mediation insertion, relation strength adjustment, and authority relation reassignment.

Near names include network realignment, relationship restructuring, stakeholder realignment, workflow rerouting, and reporting-line change. Most of these are aliases, variants, or mechanisms rather than separate archetypes.

Graph pruning remains a promotion candidate for later review because removal-focused rewiring may have enough distinct structure to become its own archetype in the network/topology family.

raw_bundle_path: solution_archetypes/_Batches/First Iteration/Batch 08/Wave 2/relation_rewiring_solution_archetype_output_bundle.zip

Edge Addition Rewiring

short_definition: Adds a new relationship so previously disconnected actors, systems, roles, or domains can coordinate, exchange, oversee, or support one another.

distinctive_feature: The decisive move is creating a new relation rather than changing only the attributes of an existing one.

distinct_from_parent: The parent includes any deliberate relation change; this variant names the additive form.

still_same_parent_because: Its logic is still to change system behavior by altering relations among entities.

use_when: A missing relationship creates coordination gaps, duplicated work, stranded responsibility, or lack of mutual visibility.

use_when: The system needs a new path for access, review, support, information, or obligation.

role: Specifies the relation to add.

role: Authorizes the new connection.

role: Creates a new communication path.

role: Creates new institutional obligations.

domain: healthcare

example: Create a referral relation between emergency departments and community follow-up clinics.

domain: software

example: Add a service adapter so a component can request data through a stable interface.

failure_modes:
unfunded coordination burden
new bottleneck
unclear accountability

Edge Removal Rewiring

short_definition: Removes or blocks a relationship that transmits harm, dependency, conflict, overload, contagion, or inappropriate influence.

distinctive_feature: The decisive move is subtractive: it changes behavior by removing a relation or preventing its use.

distinct_from_parent: The parent covers addition, removal, redirection, mediation, and strength adjustment; this variant names the removal form.

still_same_parent_because: The logic remains relation change, not generic deletion or boundary setting.

source_primes: relation boundary

use_when: An existing relationship creates fragility, conflict, capture, overload, leakage, or unsafe dependency.

use_when: The relation is no longer justified by its benefits or can be replaced by a safer path.

role: Prevents old harmful paths from reappearing.

role: Avoids orphaning work or support.

role: Removes inappropriate access relations.

role: Moves work away from a harmful path.

example: Remove a conflict-prone approval relation and route review to an independent body.

example: Remove direct connectivity between sensitive services and untrusted clients.

failure_modes:
loss of useful weak tie
shadow workaround
support gap

Flow Rerouting

short_definition: Redirects information, materials, cases, requests, approvals, or resources through different relationship paths.

distinctive_feature: The named distinction is the movement path rather than the existence of the relation itself.

distinct_from_parent: The parent is any relation change; this variant focuses on routing flows through relations.

still_same_parent_because: Rerouting only works by changing which relationships carry the flow.

source_primes: relation flow

use_when: The current route creates delay, overload, leakage, inequity, or poor decision context.

use_when: The underlying entities remain mostly the same, but the path among them needs to change.

role: Shows the current path.

role: Specifies the new route.

role: Changes operational handoffs.

role: Changes configured routing behavior.

example_domains: operations software_services logistics

example: Route high-risk cases directly to specialist review rather than through a general queue.

failure_modes:
new bottleneck
lost context during handoff
invisible exception path

Mediation Insertion

short_definition: Changes a direct relation into an indirect relation mediated by a person, role, interface, institution, or protocol.

distinctive_feature: The relation is rewired by adding an intermediary, not merely by adding or removing a direct edge.

distinct_from_parent: The parent includes many relation changes; this variant emphasizes indirection and mediation.

still_same_parent_because: The intervention still changes behavior by altering who relates to whom and through what path.

source_primes: relation indirection

use_when: Direct interaction is too conflict-prone, unsafe, ambiguous, asymmetric, or costly.

use_when: A trusted or specialized intermediary can translate, authorize, sequence, buffer, or arbitrate interaction.

role: Creates the intermediate connection.

role: Defines authority of the mediator.

role: Negotiates intermediary roles.

role: Creates a mediating team, role, or board.

example: Replace direct escalation fights with mediated negotiation through a joint committee.

failure_modes:
mediator capture
latency
loss of direct trust

Relation Strength Adjustment

short_definition: Strengthens, weakens, makes optional, makes mandatory, or changes the frequency/intensity of an existing relation.

distinctive_feature: The entities remain connected, but the intensity or coupling parameter changes.

distinct_from_parent: The parent covers structural edge changes; this variant names parameter-level relation change.

still_same_parent_because: Changing relation strength still changes the system by altering the relation pattern.

source_primes: relation coupling

use_when: The relationship is directionally correct but too strong, too weak, too frequent, too sparse, or too exclusive.

use_when: The problem is miscalibrated coupling rather than a missing or invalid relation.

role: Defines desired intensity.

role: Detects over- or under-correction.

role: Adjusts cadence or visibility.

role: Tests coupling changes.

domain: management

example: Reduce mandatory status meetings but strengthen exception escalation.

failure_modes:
overcoupling
undercoupling
false precision in relation weights

Authority Relation Reassignment

short_definition: Reassigns reporting, approval, ownership, escalation, or decision relations so authority and accountability flow through a different structure.

distinctive_feature: The changed relation specifically concerns authority, responsibility, approval, or accountability.

distinct_from_parent: The parent can rewire any relation type; this variant focuses on governance and authority relations.

still_same_parent_because: Authority reassignment still operates by changing relations among actors, roles, and decisions.

use_when: Current authority relations create delay, capture, role conflict, duplicated approval, or unclear accountability.

use_when: The central relation to rewire is decision authority rather than information, material, or dependency flow.

role: Updates responsibility after the relation change.

role: Defines who can alter authority links.

role: Changes reporting or approval structures.

role: Redistributes authority across institutions.

example_domains: governance management compliance

example: Move final safety sign-off from project delivery to an independent review office.

failure_modes:
authority ambiguity
accountability gap
informal power bypass

near_names:
Network Realignment
Relationship Restructuring
Workflow Rerouting
Reporting-Line Change
Stakeholder Realignment