Robustness Margin Design

batch: First Iteration/Batch 16

aliases:
robust margining
tolerance margin design
robust-by-design
defensive tolerance design
margin-based robustness

related_primes: tolerance variability uncertainty invariance threshold stress_and_rupture sensitivity_analysis optimization trade_offs

slug: tolerance

slug: variability

slug: invariance

components:
Stress Dimension
Operating Variation Envelope
Protected Invariant
Tolerance Margin
Safety Factor
Margin Budget
Robustness Test
Degradation Boundary
Margin Governance Owner
Uncertainty Model
Sensitivity Profile
Field Feedback Loop

mechanisms:
Safety Factor Application
Engineering Tolerance Specification
Tolerance Stack-Up Analysis
Stress Margin Simulation
Sensitivity Analysis Protocol
Defensive Design Review
Ruggedization Testing
Usability Tolerance Testing
Robust Statistics Method
Policy Slack Allowance

essence_one_line: Design extra tolerance into a system so it maintains function across expected variation, stress, or uncertainty.

compression_statement: When real-world variation can break a tightly optimized design, build robustness margins so core function survives variation at the cost of efficiency or resource overhead.

core_intuition: Real systems rarely operate at nominal conditions. Robustness margin design works by naming the dimensions that can vary, deciding what must remain true, placing deliberate distance between normal operation and failure, and testing that the margin survives plausible non-ideal conditions.

canonical_formula: stress dimensions + protected invariant + tolerance margin + robustness test + margin governance -> function preserved across variation

structural_problem: A system functions under nominal conditions but fails when inputs, environment, users, components, measurements, or demand vary within plausible ranges.

condition: Nominal-condition brittleness

description: The system performs well only when assumptions about load, timing, input quality, user behavior, environment, or component properties are almost exactly true.

condition: High consequence of small deviation

description: A modest change in a stress dimension can produce disproportionate failure, harm, invalidity, or loss of service.

condition: Uncertainty in operating conditions

description: The relevant future conditions are not known precisely enough to optimize tightly around one expected value.

condition: Efficiency pressure has eroded cushion

description: Cost, speed, weight, staffing, budget, or performance optimization has removed the distance between ordinary use and failure.

condition: Variation accumulates across interfaces

description: Small deviations in multiple parts, teams, rules, or assumptions combine into system-level failure even when each local part looks acceptable.

symptom: Frequent edge-case failures

meaning: The system works for the average case but repeatedly fails for plausible non-average users, inputs, environments, or demand levels.

symptom: Tight tolerances require constant rescue

meaning: Operators compensate for an over-optimized design by monitoring, expediting, correcting, or improvising around small deviations.

symptom: Failure appears surprising but was within plausible variation

meaning: The event was treated as exceptional even though it belonged to the expected range of real-world conditions.

symptom: Local optimization creates system fragility

meaning: Each part trims its own cushion, but the combined system no longer has enough margin to absorb variation.

symptom: Testing confirms nominal performance but not tolerance

meaning: Validation demonstrates that the design works under scripted conditions, but not under realistic variability, noise, or stress.

root_tension: The system must be efficient and precise enough to be viable, but not so tightly optimized that ordinary variation breaks its protected function.

case: The main problem is recovery from a major disruption after function is already lost

why_not: Use resilience capacity building or graceful recovery pathway when the central intervention is absorption, adaptation, recovery, and learning rather than margin under variation.

case: A failed component needs an alternate component to take over

why_not: Use redundant backup provisioning or failover when continuity depends on alternate capacity rather than tolerance inside the original design.

case: A variable must be continuously sensed and corrected within a target range

why_not: Use homeostatic regulation when the main intervention is an active feedback loop rather than static or predesigned tolerance.

case: The safe response is to stop operation when failure is detected

why_not: Use fail-safe default or protective shutdown when harmless stopping matters more than maintaining function under variation.

case: Extra resources exist without a named stress dimension or protected invariant

why_not: This is likely generic slack or capacity reservation, not robustness margin design.

structural_intervention: Identify stress dimensions, define tolerance margins, add design buffer, and test performance across variation while preserving a named invariant.

Name the stress dimensions

logic: Identify which variables, inputs, environments, behaviors, loads, assumptions, or component properties can vary and threaten function.

Define the protected invariant

logic: State what must remain true despite variation, such as safety, integrity, service level, validity, compatibility, fairness, or usability.

Set the operating variation envelope

logic: Describe the plausible range of conditions to tolerate, including expected variation, edge cases, uncertainty bands, and rare-but-credible stresses.

Allocate tolerance margin

logic: Add deliberate distance between nominal operation and failure through dimensions such as size, time, budget, strength, capacity, threshold, interface acceptance, or error allowance.

Test across variation

logic: Validate the design under non-nominal conditions, combinations of variation, and stress cases rather than only ideal operating assumptions.

Govern margin erosion

logic: Track how optimization, cost pressure, scope creep, standards drift, or environmental change can consume or misallocate margins over time.

rule: Margin must answer a named stress dimension

guidance: Do not add cushion indiscriminately. Specify what variation the margin is meant to tolerate and what invariant it protects.

rule: Use consequence and uncertainty to size margin

guidance: Increase margins when failure consequences are high, uncertainty is large, inspection is difficult, repair is slow, or correlated variation is likely.

rule: Test combinations, not just isolated extremes

guidance: Robustness can fail when several ordinary deviations align, even if each one is acceptable by itself.

rule: Do not treat margin as a substitute for understanding

guidance: If the stress dimension is unknown or the failure mechanism is opaque, use investigation, observability, or experimentation rather than simply adding more cushion.

rule: Review margins when conditions change

guidance: Margins should be revisited after incidents, field evidence, demand shifts, new materials, model changes, regulatory changes, or repeated near misses.

invariant: Protected function persists under variation

description: The system continues to deliver the function that matters across the defined operating variation envelope.

invariant: Distance from failure threshold remains visible

description: Decision makers can see how close the system is to unacceptable degradation or failure rather than unknowingly operating at the edge.

invariant: Margins are justified and testable

description: The margin can be connected to stress assumptions, consequences, evidence, and validation rather than tradition or vague caution.

invariant: Local margins do not create system-level fragility

description: Margins are coordinated so one part does not preserve itself by transferring variation, delay, cost, or risk to another part.

invariant: Efficiency tradeoffs remain explicit

description: The overhead of robustness is visible so the system does not silently overbuild or silently remove essential margin.

outcome: Fewer failures from ordinary variation

description: The system no longer breaks merely because real-world conditions differ from the nominal case.

outcome: Greater predictability under stress

description: Performance may decline, but it declines within known bounds rather than crossing abruptly into failure.

outcome: Reduced dependence on heroic correction

description: Operators spend less effort rescuing brittle designs from predictable variation.

outcome: Clearer design tradeoffs

description: Stakeholders can judge whether added tolerance is worth the cost, weight, time, complexity, or efficiency loss.

outcome: Better validation of non-ideal conditions

description: Testing covers the variation envelope instead of only confirming that the system works under ideal assumptions.

prose_essence:
Robustness Margin Design adds deliberate tolerance between normal operation and unacceptable failure. It is useful when a system works under ideal or average conditions but becomes brittle when real-world variation appears. The archetype asks: what can vary, what must remain true, how much margin is needed, and how will we prove that the margin works?

This is not just a slogan for being robust. It is a design intervention: define the stress dimensions, protect an invariant, set a variation envelope, allocate margin, validate it under non-ideal conditions, and prevent that margin from being silently consumed by optimization pressure.

prose_when_to_use:
Use this archetype when ordinary variation, uncertainty, or stress can break a system that appears functional under nominal assumptions. It fits systems that face varied users, uncertain loads, component variation, environmental stress, noisy data, policy edge cases, timing jitter, or imperfect inputs.

It is especially appropriate when small deviations have high consequences, when future operating conditions are uncertain but not completely unknowable, or when efficiency pressure has removed too much cushion. The archetype is weaker when the problem is a major shock requiring adaptation and recovery, a failed component requiring backup activation, or an active variable that must be continuously regulated by feedback.

prose_structural_problem:
The structural problem is brittle optimization around a narrow operating assumption. A design may work when demand is average, users behave as expected, components are within perfect fit, data are clean, staff are present, or the environment stays calm. But real systems rarely stay at the nominal point.

The brittle system has too little distance between ordinary operation and failure. It may pass ordinary tests while still failing at plausible edge cases. It may also hide fragility by relying on operators, users, or downstream systems to compensate whenever small deviations occur.

prose_intervention_logic:
The intervention begins by naming the stress dimensions. A vague instruction to “make it more robust” is not enough; the designer must identify whether the relevant variation is load, timing, temperature, user behavior, demand, measurement error, material property, policy ambiguity, or something else.

Next, the intervention defines the protected invariant. The invariant might be structural integrity, data validity, minimum service level, user completion, patient safety, policy fairness, or compatibility across interfaces. Margin is then placed between nominal operation and the point where that invariant fails.

The margin must be validated. Robustness Margin Design is incomplete until the system is tested across the intended variation envelope, including combinations of ordinary deviations. Finally, the margin needs governance because cost cutting, schedule compression, feature growth, or local optimization can consume it over time.

prose_key_components:
### Stress Dimension

A stress dimension identifies what can vary in a way that threatens function. Without it, margin design becomes arbitrary. Load, timing, input quality, human behavior, environmental conditions, and measurement noise require different forms of margin.

### Operating Variation Envelope

The operating variation envelope defines the range of conditions the system is expected to tolerate. It may include ordinary variation, edge cases, uncertainty bands, and rare but credible stress conditions. It keeps robustness grounded in expected reality rather than vague caution.

### Protected Invariant

The protected invariant states what must remain true despite variation. A system might preserve safety, service quality, valid records, fairness, structural integrity, or task completion. The invariant prevents robustness from becoming indiscriminate overbuilding.

### Tolerance Margin

The tolerance margin is the deliberate distance between nominal operation and failure. It can appear as extra strength, time, budget, interface acceptance, error allowance, capacity, threshold width, or procedural flexibility.

### Safety Factor

A safety factor is a common parameter for sizing a margin. It is useful when uncertainty or failure consequences justify conservative design. It is a mechanism inside the archetype, not the archetype itself.

### Margin Budget

A margin budget allocates margin across competing dimensions and parts of the system. It prevents every part from demanding unlimited cushion while also preventing efficiency pressure from removing essential tolerance invisibly.

### Robustness Test

A robustness test checks whether the margin actually works across the variation envelope. It may use stress testing, simulation, tolerance stack-up analysis, usability testing, sensitivity analysis, field pilots, or destructive testing.

### Degradation Boundary

The degradation boundary marks where acceptable decline ends and unacceptable failure begins. Robustness does not always mean perfect performance under stress; it means the protected function does not collapse or cross a critical boundary.

### Margin Governance Owner

The margin governance owner is accountable for defining, preserving, revising, and testing the margin. Margins are often eroded over time, so ownership makes margin loss visible and reviewable.

prose_common_mechanisms:
Mechanisms implement Robustness Margin Design; they should not be confused with the archetype itself. A mechanism only counts as an instance of this archetype when it protects a named invariant across a defined variation envelope.

### Safety Factor Application

Safety factor application uses a multiplier or allowance to set a conservative design requirement. It is common in engineering, finance, scheduling, and safety-sensitive operations, but it should be justified by uncertainty and consequences rather than habit.

### Engineering Tolerance Specification

Engineering tolerance specifications define acceptable ranges for dimensions, timing, material properties, interfaces, or quality attributes. They implement the archetype when they preserve system function despite component-level variation.

### Tolerance Stack-Up Analysis

Tolerance stack-up analysis examines how individually acceptable deviations can accumulate into system failure. This mechanism is important because robustness often fails at interfaces, not inside isolated parts.

### Stress Margin Simulation

Stress margin simulation varies load, environment, demand, timing, or inputs before real exposure. It helps test whether margin survives plausible combinations of non-ideal conditions.

### Sensitivity Analysis Protocol

Sensitivity analysis varies assumptions or parameters to reveal where the system is brittle. It helps place margins where they matter instead of overprotecting dimensions that have little effect.

### Defensive Design Review

A defensive design review looks for fragile assumptions, narrow tolerances, and hidden dependence on ideal behavior. It is a review mechanism for finding where margin should be added or preserved.

### Ruggedization Testing

Ruggedization testing exposes a product, process, or service to harsher-than-nominal conditions. It is a product-oriented mechanism for confirming tolerance under environmental or usage stress.

### Usability Tolerance Testing

Usability tolerance testing examines whether varied users, imperfect inputs, and distracting contexts can be absorbed without task failure. It implements robustness margin design in human-centered systems.

### Robust Statistics Method

Robust statistical methods preserve useful inference when data contain outliers, noise, missingness, or assumption violations. They are mechanisms for maintaining decision validity under data variation.

### Policy Slack Allowance

Policy slack allowances build tolerance into rules, budgets, schedules, or eligibility processes. They must be governed carefully so tolerance supports fairness rather than arbitrary discretion.

prose_failure_modes:
The first failure mode is over-margining. This happens when designers add cushion without linking it to consequences, uncertainty, or actual stress dimensions. The result is wasteful conservatism.

The second failure mode is under-margining from optimism. Designers may assume ideal users, clean data, stable demand, independent variation, or perfect maintenance. The mitigation is to test edge cases, field evidence, near misses, and combinations of ordinary deviations.

The third failure mode is margin erosion. Efficiency pressure, cost cutting, schedule compression, scope growth, and informal workarounds can silently consume the original margin. Explicit margin governance helps prevent this.

The fourth failure mode is protecting the wrong dimension. A design may add margin where variation is easy to measure while ignoring the dimension most likely to cause failure.

The fifth failure mode is tolerance stack-up. Several local deviations may be acceptable in isolation but combine into a system-level failure. End-to-end tests and interface analysis are essential.

prose_neighbor_distinctions:
Robustness Margin Design is distinct from Resilience Capacity Building. Resilience capacity building prepares shock absorption, adaptation, recovery resources, and learning loops. Robustness margin design preserves function across plausible variation before recovery becomes the central problem.

It is distinct from Margin of Safety as a standalone phrase. Margin of safety names a principle of distance from failure; Robustness Margin Design is the full intervention pattern for defining, allocating, testing, and governing that distance.

It is distinct from Capacity Reservation. Capacity reservation sets aside resources. Robustness margin design may use reserved capacity, but only as one way to protect a named invariant against a defined stress dimension.

It is distinct from Homeostatic Regulation. Homeostatic regulation senses deviation and actively corrects a variable within a range. Robustness margin design can be predesigned tolerance without continuous sensing and correction.

It is distinct from Fail-Safe Default. Fail-safe default moves the system to a harmless state when failure occurs. Robustness margin design aims to keep function from failing under expected variation.

prose_cross_domain_examples:
In infrastructure, a drainage system sized above average rainfall protects public function across rainfall variation. In software, an API that tolerates harmless request timing variation protects correctness under real client behavior.

In manufacturing, tolerance bands allow parts from different batches to assemble correctly. In analytics, robust estimators and sensitivity analysis preserve decision validity under noisy data or uncertain assumptions.

In public service design, a documented grace window can absorb predictable transport or paperwork delays while preserving fairness and auditability. In human-centered design, an intake form that accepts common formatting differences protects task completion without corrupting records.

prose_non_examples:
A disaster recovery plan is not Robustness Margin Design unless it specifically defines and tests margins against expected variation before failure. It is usually resilience capacity building or graceful recovery.

A backup supplier is not Robustness Margin Design when it simply replaces a failed supplier. That is redundant backup provisioning or failover.

A machine trip switch is not Robustness Margin Design when its core purpose is to stop dangerous operation. That is fail-safe default or protective shutdown.

Extra budget without a named stress dimension, protected invariant, and validation method is not Robustness Margin Design. It may be slack, contingency, or capacity reservation.

prose_tradeoffs:
Robustness margins trade efficiency for tolerance. They may increase cost, weight, complexity, staffing, budget, or time. A margin can also reduce precision if the system must accept broader variation.

There is also a learning tradeoff. Large margins can protect against known variation but may slow adaptation if the environment changes beyond the assumed envelope. A margin is not a substitute for monitoring, feedback, or redesign.

Finally, robustness can create false confidence. If the stress model is wrong or the margin has eroded, people may believe the system is safe precisely when it is operating near failure.

prose_invariants_to_preserve:
The core invariant is that the protected function persists across the intended variation envelope. A robust system can experience stress and still maintain the function that matters.

A second invariant is visibility of distance from failure. Stakeholders should know whether a system is comfortably inside its margin, approaching its degradation boundary, or operating at the edge.

A third invariant is that margins remain justified and testable. A margin should be connected to a stress dimension, consequence, uncertainty, and validation method.

A fourth invariant is system-level coherence. Local margins should not protect one part by shifting risk, delay, ambiguity, or burden to another part.

prose_target_outcomes:
Successful Robustness Margin Design reduces failures from ordinary variation. It gives the system more predictable behavior under stress, reduces dependence on heroic correction, and improves confidence that the design will work outside ideal conditions.

It also makes tradeoffs visible. Instead of hiding robustness inside vague caution, it lets stakeholders decide whether the extra cost, weight, complexity, time, or slack is worth the protection gained.

prose_parameter_dimensions:
The most important tuning dimension is margin size. Too little margin leaves the system brittle; too much margin wastes resources, reduces precision, or hides architectural problems.

The second dimension is the width of the variation envelope. A narrow envelope makes testing cheaper but may miss real-world conditions. A broad envelope improves tolerance but can make design expensive or vague.

The third dimension is invariant strictness. Some invariants are non-negotiable, such as safety or data integrity. Others can degrade within a defined boundary. The stricter the invariant, the more careful the margin and validation must be.

The fourth dimension is evidence quality. When field data, models, or measurements are weak, margins may need to be more conservative or paired with monitoring and learning.

The fifth dimension is margin distribution. Designers must decide whether margin belongs in components, interfaces, procedures, staffing, thresholds, schedules, budgets, or user-facing accommodations.

prose_variants_and_near_names:
Engineering tolerance band design is the technical variant that defines acceptable ranges for dimensions, interfaces, timing, materials, or quality attributes.

Usability tolerance design applies the same logic to human variation. It makes a process or interface robust to varied skills, devices, languages, attention, and common mistakes.

Statistical robustness margin applies the logic to inference and decision systems. It uses methods and thresholds that remain useful when data contain noise, outliers, or uncertain assumptions.

Policy slack margin applies the logic to rules, schedules, budgets, and administrative processes. It must be governed carefully because tolerance can become arbitrary discretion.

Near names include margin of safety, tolerance design, defensive design, ruggedization, and robustness testing. Safety factor is collapsed as a mechanism or parameter under this archetype, not a separate archetype.

Engineering Tolerance Band Design

short_definition: Defines acceptable technical ranges so components and interfaces still function despite manufacturing, environmental, or timing variation.

distinctive_feature: The margin is expressed as a technical tolerance band on a dimension, interface, material property, timing parameter, or quality attribute.

distinct_from_parent: The parent covers all robust margin design; this variant focuses on explicit tolerance bands and tolerance stack-up in engineered or procedural systems.

still_same_parent_because: It still uses the same logic of preserving an invariant across expected variation by adding tested margin.

use_when: Physical, digital, or procedural components vary within measurable ranges.

use_when: Several small deviations can combine into system-level failure.

use_when: Interfaces must remain compatible despite imperfect fit or timing.

example_domains:
manufacturing
civil engineering
software interface design
quality systems

concise_examples: A connector accepts small dimensional variation without losing electrical contact.

concise_examples: A service interface tolerates minor timing jitter without corrupting a transaction.

failure_modes: Tolerance bands are locally reasonable but accumulate into system-level misfit.

failure_modes: Margins are copied from precedent without checking actual stress conditions.

Usability Tolerance Design

short_definition: Designs processes or interfaces to tolerate variation in user ability, attention, interpretation, device, language, and input quality.

distinctive_feature: The variation envelope is human variation rather than only technical or environmental variation.

distinct_from_parent: The parent is general; this variant focuses on accommodating diverse users and imperfect interaction without immediate breakdown.

still_same_parent_because: The intervention still adds tolerance margin around a protected task or service invariant.

use_when: Users vary in skill, language, context, attention, or access needs.

use_when: Small user mistakes currently cause disproportionate task failure.

use_when: A process must work outside ideal training, environment, or device assumptions.

example_domains:
public services
software products
forms and intake workflows
education

concise_examples: A form accepts multiple date formats and prevents invalid submission rather than rejecting users silently.

concise_examples: A public process gives enough time and plain-language guidance for varied participants to complete it correctly.

failure_modes: Accommodation becomes so broad that data quality or fairness deteriorates.

failure_modes: Designers overfit to a narrow test group and call the result robust.

Statistical Robustness Margin

short_definition: Chooses analytic methods or decision thresholds that remain useful under outliers, measurement error, distributional shift, or assumption uncertainty.

distinctive_feature: The margin appears in inference, estimation, thresholds, or model assumptions rather than physical design.

distinct_from_parent: The parent covers robustness under variation generally; this variant applies the pattern to analytic and statistical decision systems.

still_same_parent_because: It still preserves a decision or validity invariant across plausible data variation and uncertainty.

use_when: Data are noisy, incomplete, heavy-tailed, or likely to contain outliers.

use_when: A decision would become brittle if it depended on a precise model assumption.

use_when: Uncertainty about parameters must be reflected in thresholds or confidence bounds.

example_domains:
statistics
machine learning
risk analysis
policy evaluation

concise_examples: A median-based summary is chosen because a few outliers should not distort the decision.

concise_examples: A policy threshold includes an uncertainty band rather than treating a point estimate as exact.

failure_modes: Conservatism hides useful signal and makes the system insensitive.

failure_modes: Robust methods are used as a substitute for understanding data-generating assumptions.

Policy Slack Margin

short_definition: Builds tolerance into policies, budgets, rules, or service processes so plausible variation does not immediately create exclusion, overload, or violation.

distinctive_feature: The margin is encoded in governance rules rather than hardware, software, or analytic assumptions.

distinct_from_parent: The parent is general; this variant applies margin logic to rules and administrative systems.

still_same_parent_because: It preserves a service, fairness, or compliance invariant across expected variation by adding tested tolerance.

use_when: Rigid rules fail under ordinary variation in timing, resources, need, or evidence quality.

use_when: Small deviations currently trigger disproportionate sanctions or administrative failure.

use_when: The process must remain fair and functional under noisy real-world conditions.

example_domains:
public administration
education policy
service design
operations management

concise_examples: A deadline policy includes documented grace conditions for predictable delays while protecting fairness.

concise_examples: A service budget includes a contingency allowance for seasonal demand variation.

failure_modes: Slack becomes arbitrary discretion and undermines procedural fairness.

failure_modes: Margin is captured by powerful users while less powerful users still absorb failure.

near_names:
Margin of Safety
Tolerance Design
Defensive Design
Ruggedization
Robustness Testing


Role Expectation Architecture

type: archetype

source: generated

batch: Batch 07

aliases:
Role Architecture
Role Design
Social Role Design
Position Expectation Design
Role Expectation Bundle Design
Role Boundary Governance
Role Interface Design
Role Occupancy Governance
Office and Mandate Design
Role Chartering

source_primes: role potential_occupancy_region interface decomposition interpretation transformation institution social_norms accountability delegation_of_authority agency coordination

slug: role

slug: interface

slug: decomposition

slug: interpretation

slug: transformation

slug: institution

slug: accountability

slug: agency

slug: coordination

slug: authority

slug: legitimacy

slug: boundary

slug: hierarchy

slug: substitutability

slug: representation

slug: specialization

components: Handoff, Substitution, and Succession Path

mechanisms:
Role Charter
Position Description or Office Mandate
RACI or Decision Participation Matrix
Role Card or Participation Card
Onboarding and Role Shadowing Runbook
Delegation Letter or Authority Envelope
Role Compatibility Check
Handoff Checklist
Role Rotation or Deputy Schedule
Conflict-of-Interest Disclosure
Role Review Retrospective
Swimlane or Service Blueprint

essence_one_line: When coordination depends on a recurring social position, design the role as a clear, occupiable bundle of expected behaviours, authority, obligations, interfaces, support, conflict guards, and handoff rules.

compression_statement: Role Expectation Architecture treats a role as a position-bound expectation bundle rather than a title, personality, job slot, or one-time task assignment. The archetype separates the role from its current holder, defines expected behaviors and permissions, maps interfaces with other roles, provides legitimacy and resources, manages conflicts of interest and role strain, and preserves continuity across entry, exit, rotation, substitution, and rechartering.

core_intuition: People coordinate better when they know what a role is for, who may occupy it, what the holder is expected to do and not do, what authority comes with it, what others can rely on, how to challenge misuse, and how the role changes hands. A role should be stable enough to be recognizable and transferable, but not so frozen that it ignores context, overload, or changing institutional needs.

canonical_formula: role_architecture = position_anchor + expectation_bundle + authority_scope + obligation_scope + interface_map + legitimacy_rule + support + accountability + conflict_guard + handoff_path + recharter_trigger

structural_problem: A group, institution, system, or workflow depends on recurring positions, but the expected behaviours attached to those positions are tacit, person-dependent, overbroad, under-resourced, conflicting, illegitimate, or hard to transfer. Participants cannot tell what a role-holder may decide, what others may expect, when the role is being misused, how the role interfaces with neighboring roles, or what happens when the holder leaves.

condition: A recurring position must be occupied by different actors across time.

notes: The role must persist beyond one incumbent.

condition: Others need reliable expectations about what the role-holder will do or refrain from doing.

notes: Predictability and reliance are central.

condition: A title, office, job, volunteer slot, ecological niche, or system function exists but its behavioral bundle is unclear.

notes: The name of the position is not enough.

condition: Authority, obligation, access, accountability, or support is attached to a position rather than only to a person.

notes: Position-bound powers and duties need boundaries.

condition: Multiple roles interact, overlap, conflict, or require handoffs.

notes: Role interfaces and role-conflict guards become necessary.

condition: Role performance depends on tacit norms, informal expectations, or local interpretation.

notes: Codification must preserve necessary judgment without leaving expectations invisible.

condition: Turnover, rotation, scaling, crisis, growth, automation, or cross-boundary work exposes that the role is not transferable.

notes: A role architecture problem appears when continuity fails.

symptoms: People treat the same title as carrying different obligations in different contexts.

symptoms: A role-holder is blamed for duties never stated, resourced, or authorized.

symptoms: Authority attaches to a charismatic incumbent rather than to a legitimate position.

symptoms: Neighbors do not know what to route to the role, what to keep local, or when to escalate.

symptoms: Role expectations expand silently until the holder burns out or becomes a bottleneck.

symptoms: Conflicts of interest are handled as personal virtue problems rather than role-architecture problems.

symptoms: New holders inherit records but not the tacit judgment needed to perform the role.

symptoms: A role continues after its purpose disappears because no sunset or recharter trigger exists.

symptoms: A role is over-specified into rigid procedure, leaving no room for legitimate interpretation.

symptoms: Multiple positions claim the same authority or assume someone else owns the same responsibility.

root_tension: Roles must be stable enough for others to rely on and transferable enough to survive holder changes, but flexible enough to adapt to context, capability, legitimacy, and changing institutional needs.

anti_signatures: Use responsibility_assignment_for_action when the issue is a one-time named owner for a specific action, not a durable role.

anti_signatures: Use decision_rights_clarification when only decision authority is unclear and the broader behavior expectation bundle is already settled.

anti_signatures: Use emergent_role_formation when the main work is discovering whether a repeated contribution pattern should become a role at all.

anti_signatures: Use institutional_rule_role_stabilization when the design object is the whole institution-level rule-role-expectation complex rather than a role or role family.

anti_signatures: Use functional_specification when defining the input-output behavior of a component, process, model, or policy is the main problem rather than position-bound social expectations.

anti_signatures: Use least_privilege_access_design when the only concern is technical or operational permission scope.

anti_signatures: Use role_scoped_disclosure_minimization when a role already exists and the question is how much information it should receive.

structural_intervention: Convert an ambiguous or person-dependent position into a role architecture: anchor the occupiable position, define its expectation bundle, set authority and obligation boundaries, map interfaces, define eligibility and legitimacy, provide resources, install conflict and accountability safeguards, document interpretation rules, and create continuity and recharter paths.

action: Name the position anchor and distinguish the role from the current holder.

reason: A role must be transferable and reviewable as a position-bound pattern.

action: Elicit actual expectations from incumbents, neighbors, affected parties, rules, norms, and observed practice.

reason: Hidden expectations are the main source of role confusion and unjust burden.

action: Sort expectations into required, permitted, discretionary, forbidden, obsolete, contested, and unsupported behaviours.

reason: The bundle needs internal structure, not a flat list of duties.

action: Attach authority, access, resources, and support to obligations.

reason: A role-holder should not be accountable for duties they cannot perform.

action: Map role interfaces, handoffs, escalation paths, and boundary crossings.

reason: Roles coordinate through predictable interfaces with other roles and systems.

action: Define eligibility, appointment, recognition, term, rotation, removal, and exit rules.

reason: Occupancy conditions protect legitimacy and continuity.

action: Install conflict-of-interest, role-conflict, overload, and capture safeguards.

reason: Role expectations can create conflicts and power concentrations.

action: Document the role at the right level of granularity and publish the parts neighbors must know.

reason: Visibility supports coordination while avoiding unnecessary disclosure.

action: Create handoff, memory, learning, and review loops.

reason: The role must survive turnover and adapt without silent drift.

action: Recharter, split, merge, rotate, automate, or sunset the role when the expectation bundle no longer fits.

reason: Roles should evolve as work, context, legitimacy, and risk change.

rule: If a role has obligations but no authority or resources, either narrow the obligations or provide capacity before assigning accountability.

rationale: Unfunded responsibility creates blame without control.

rule: If a role has authority but no accountability path, add review, challenge, appeal, or removal mechanisms before expanding the role.

rationale: Role power must remain attached to a legitimate position.

rule: If a role depends on a single incumbent, document tacit knowledge, create deputies, or redesign the role before turnover.

rationale: Person-dependence is a continuity risk.

rule: If two roles carry incompatible expectations, resolve the role architecture rather than moralizing the holder’s failure.

rationale: Role conflict is structural.

rule: If role boundaries are repeatedly contested, add interface maps and interpretation rules instead of adding more ad hoc tasks.

rationale: Repeated boundary disputes signal architectural ambiguity.

rule: If a role has become symbolic only, either restore function and accountability or sunset it.

rationale: Empty roles create false expectations and institutional clutter.

target_invariants: The role remains distinguishable from the person currently occupying it.

target_invariants: Expected behaviors are visible enough for coordination and review.

target_invariants: Authority, obligation, access, and accountability remain mutually aligned.

target_invariants: Neighboring roles know the role interface and escalation path.

target_invariants: Eligibility and appointment are legitimate for the consequences carried by the role.

target_invariants: Role conflicts, conflicts of interest, overload, and capture have explicit safeguards.

target_invariants: Handoffs preserve enough memory, context, and authority for continuity.

target_invariants: The role can be revised or sunset when its purpose, context, or legitimacy changes.

expected_outcomes: Reduced role ambiguity, hidden labor, and expectation conflict.

expected_outcomes: More reliable coordination across people, teams, offices, systems, or institutions.

expected_outcomes: Clearer authority boundaries and accountability paths.

expected_outcomes: Safer delegation, substitution, succession, and rotation.

expected_outcomes: Better integration between social expectations and technical or organizational interfaces.

expected_outcomes: Lower burnout and capture risk because roles are resourced and reviewable.

expected_outcomes: Improved institutional memory and newcomer onboarding.

expected_outcomes: Fairer treatment of role-holders and affected parties.

Formal Office Role Charter

short_definition: A formally recognized office or position with explicit mandate, authority, duties, term, accountability, and succession rules.

distinctive_feature: Role expectations are attached to an office that persists beyond the incumbent.

distinct_from_parent: It is the formalized office branch of the broader role-expectation architecture.

still_same_parent_because: It still governs the same position-bound expectation bundle.

source_primes: role institution authority accountability delegation_of_authority

use_when: A role exercises institutional power or represents a collective.

use_when: Legitimacy, term limits, appointment, or removal are central.

failure_modes: The office becomes title-only, captured by incumbents, or granted authority without accountability.

Emergent Contribution Role

short_definition: A role first recognized from repeated contributions, tacit expectation, or informal reliance before any formal charter exists.

distinctive_feature: Recognition and support must follow evidence of actual contribution patterns.

distinct_from_parent: It concerns the informal-to-role transition path.

still_same_parent_because: After recognition, the role still needs expectation, interface, resource, and accountability architecture.

use_when: A group already relies on a contribution pattern but lacks a legitimate role boundary.

use_when: Premature formalization would freeze a useful emergent pattern too early.

failure_modes: Informal reliance becomes invisible labor, status capture, or retroactive obligation without consent.

Boundary-Spanning Role

variant_type: subtype

short_definition: A role whose expected behaviors focus on translating, brokering, coordinating, or mediating across group, domain, system, or boundary interfaces.

distinctive_feature: The role exists primarily at an interface rather than inside one local workflow.

distinct_from_parent: It is the cross-boundary branch of role architecture.

still_same_parent_because: It still requires a position anchor, expectation bundle, legitimacy, authority limits, and conflict guards.

source_primes: role interface network_broker_role boundary coordination

use_when: Coordination fails because separate groups lack a trusted interface.

use_when: The role-holder must translate norms, language, evidence, requests, or constraints across boundaries.

failure_modes: The boundary spanner becomes a chokepoint, informal gatekeeper, or unaccountable broker.

Rotating Stewardship Role

short_definition: A role intentionally moved among qualified holders to distribute burden, prevent capture, preserve learning, and maintain continuity.

distinctive_feature: Role health depends on managed occupancy turnover.

distinct_from_parent: It is the rotation-and-substitution branch of role architecture.

still_same_parent_because: The same role expectation bundle persists while holders change.

source_primes: role accountability coordination substitutability collective_systemic_learning

use_when: A necessary role creates status monopoly, burnout, or single-holder dependency.

use_when: The role can be safely transferred with overlap, documentation, and competency controls.

failure_modes: Rotation destroys expertise or accountability if handoffs are shallow.

Role Conflict Resolution Branch

short_definition: A branch of role architecture focused on resolving incompatible expectations across one or more roles held by an actor or position.

distinctive_feature: The design problem is incompatibility among expectation bundles.

distinct_from_parent: It handles a failure mode produced by multiple or overloaded roles.

still_same_parent_because: The repair still depends on mapping role expectation bundles, boundaries, legitimacy, and accountability.

use_when: A holder is pulled by incompatible obligations, loyalties, norms, or performance criteria.

use_when: A role creates conflict of interest or expectation strain that cannot be solved by simple clarification.

failure_modes: Conflict is disclosed but not mitigated, or one role silently dominates another.

near_names:
Role Design
Social Role Design
Position Expectation Design
Role Chartering
Role Boundary Governance


batch: Batch 18

canonical_family: Finite Capacity & Contention

slug: allocation

slug: consent

slug: normativity

components: Role, Expectation, and Principal Inventory

components: Role Capacity, Authority, and Boundary Test

components: Redesign, Recusal, Delegation, and Substitution Plan

components: Protected Conflict Disclosure and Escalation Path

components: Role Transition and Residual-Strain Monitor

mechanisms: Simultaneous Feasibility and Capacity Test

essence_one_line: Make incompatible role expectations visible and govern which duty controls, what must be redesigned, and when a person needs recusal, substitution, support, sequencing, or release.

compression_statement: Roles carry expectations about action, availability, loyalty, confidentiality, care, impartiality, performance, and identity. A person or position may be unable to satisfy them simultaneously, or one role may contain contradictory demands from different principals. Role-Expectation Conflict Reconciliation inventories roles and expectation sources; maps time, authority, resource, loyalty, ethical, identity, and boundary conflicts; identifies affected parties and nonwaivable duties; distinguishes negotiable preference from legitimate obligation; chooses priority through declared rules; redesigns scope, sequence, staffing, delegation, recusal, information access, or handoff; protects people from retaliation for surfacing impossible demands; and monitors residual strain, hidden work, quality, safety, and recurrence.

core_intuition: Clarity is necessary but insufficient. Two perfectly clear expectations can still be impossible to satisfy together. The intervention must change priority, structure, resources, boundaries, or role occupancy rather than asking the person to absorb the contradiction privately.

canonical_formula: role_and_expectation_inventory + incompatibility_classification + affected_party_and_duty_map + capacity_and_boundary_evidence + legitimate_priority_rule + redesign_recusal_substitution_options + protected_escalation_and_transition + residual_strain_monitor -> governable_role_commitments

structural_problem: A person, team, office, or agent occupies multiple roles or receives incompatible expectations within one role. Satisfying one duty necessarily delays, compromises, conceals, or violates another. The contradiction is treated as an individual resilience or time-management failure, allowing principals to externalize impossible demands and obscuring who is harmed by the tradeoff.

trigger_conditions: Two roles require simultaneous use of the same time, attention, resource, authority, or presence.

trigger_conditions: Loyalty, confidentiality, impartiality, care, advocacy, enforcement, or reporting duties conflict.

trigger_conditions: Different principals issue incompatible expectations to the same role.

trigger_conditions: Performance targets conflict with safety, ethics, due process, or professional standards.

trigger_conditions: Informal identity or caregiving expectations collide with formal work or public roles.

trigger_conditions: Recusal, delegation, sequencing, substitution, or role redesign is possible.

symptoms: Chronic overload, hidden work, missed handoffs, inconsistent decisions, or moral distress.

symptoms: People satisfy the most powerful principal rather than the most legitimate duty.

symptoms: Conflict is disclosed only after harm because escalation invites retaliation.

symptoms: Role descriptions are clear but jointly impossible.

symptoms: Confidential information leaks across roles or necessary information is withheld.

symptoms: Temporary exception work becomes a permanent second job.

symptoms: Responsibility is assigned without matching authority, time, or resources.

root_tension: Multiple roles can improve integration, empathy, continuity, and efficiency, but they can also create incompatible loyalties, capacity overload, and self-review. Separation protects integrity but can fragment context and relationships. The design task is evidence-based compatibility, not universal role consolidation or separation.

anti_signatures: The only issue is ambiguity about who decides; Decision Rights Clarification is sufficient.

anti_signatures: Independent roles disagree but no person or position carries incompatible expectations; use dispute governance.

anti_signatures: The sole problem is personal benefit bias in a decision; use conflict-of-interest controls.

anti_signatures: The workload is high but every role expectation is compatible; use capacity or workload management.

structural_intervention: Create a protected role-conflict workflow that records roles and expectation sources, tests simultaneous feasibility and normative compatibility, assigns priority, changes structure or occupancy, documents residual obligations and affected-party protections, and verifies that the conflict does not recur as hidden strain.

action_logic: Inventory formal and informal roles, principals, beneficiaries, duties, authority, information access, time, and resources.

action_logic: Translate vague expectations into observable obligations, deadlines, quality, availability, confidentiality, and decision rights.

action_logic: Classify conflict as time, resource, authority, loyalty, interest, confidentiality, identity, ethical, care, or within-role principal conflict.

action_logic: Identify nonwaivable legal, safety, rights, professional, and care duties and people exposed by each tradeoff.

action_logic: Test whether sequencing, scope reduction, added capacity, delegation, interface design, or expectation negotiation restores compatibility.

action_logic: Where judgment integrity is compromised, require disclosure, recusal, independent review, or role separation.

action_logic: Where no combination is feasible, apply an authorized priority rule and explicitly release or transfer the displaced duty.

action_logic: Provide protected escalation, documentation, representation, and nonretaliation for people surfacing impossible expectations.

action_logic: Define handoff, information segregation, continuity, transition, and consent requirements for redesign or exit.

action_logic: Monitor workload, delay, quality, safety, moral distress, affected-party harm, workarounds, and conflict recurrence.

decision_rules: Nonwaivable safety, rights, legal, and professional duties outrank discretionary performance preferences.

decision_rules: Responsibility without adequate authority, time, information, and resources triggers redesign rather than blame.

decision_rules: Recuse or separate roles when impartial judgment cannot be credibly preserved through disclosure and review.

decision_rules: Delegate only with authority, competence, information, capacity, acceptance, and accountability transferred together.

decision_rules: Sequence compatible duties only when delay does not impose unacceptable harm or breach.

decision_rules: Do not solve conflict by silently dropping obligations owed to less powerful or less visible parties.

decision_rules: Use exit or role release when structural incompatibility persists after proportionate redesign.

target_invariants: Every material expectation has a source, beneficiary, authority basis, resource demand, and review path.

target_invariants: Nonwaivable duties and affected-party harms are visible before priorities are chosen.

target_invariants: People can disclose conflict without retaliation or automatic blame.

target_invariants: Priority decisions release, transfer, or compensate displaced obligations explicitly.

target_invariants: Delegation and substitution include authority, information, competence, capacity, and accountability.

target_invariants: Recusal and confidentiality boundaries preserve continuity and appropriate access.

target_invariants: Residual strain, hidden work, and recurrence remain monitored after redesign.

expected_outcomes: Fewer impossible or contradictory assignments and less hidden role strain.

expected_outcomes: Better protection of safety, rights, impartiality, confidentiality, care, and professional duties.

expected_outcomes: Clearer priorities, handoffs, delegation, recusal, and accountability.

expected_outcomes: Reduced burnout, moral distress, delay, quality loss, and retaliation.

expected_outcomes: More deliberate decisions about when multiple-role integration adds value or creates unacceptable risk.

prose_essence:
Role-Expectation Conflict Reconciliation governs incompatible demands carried by one person, position, team, or agent. It makes role sources, duties, authority, resources, loyalties, boundaries, and affected parties visible, then changes priority, structure, occupancy, support, or expectations so the contradiction is not privately absorbed.

Clarity alone is insufficient. Two expectations can be perfectly clear and still impossible or unethical to satisfy together.

The unit of intervention is the role–expectation system, not the supposedly deficient role-holder. Expectations are produced by laws, contracts, professional standards, managers, clients, communities, families, peers, metrics, identities, and informal norms. When these sources impose incompatible duties, exhorting the person to communicate better or become more resilient merely transfers the cost of organizational contradiction into private strain.

Reconciliation does not mean splitting every difference. Some duties are nonwaivable, some expectations lack legitimate authority, some conflicts can be sequenced, and some require recusal, substitution, boundary change, or release. The archetype makes that judgment explicit, contestable, and operational while preserving continuity for people who depend on the role.

prose_when_to_use:
Use it when roles compete for the same time or resources, demand incompatible loyalty or confidentiality, combine advocacy with impartial review, conflict across care and performance, or receive contradictory instructions from multiple principals. The conflict must have consequences beyond private preference and admit structural choices such as sequencing, delegation, recusal, substitution, added capacity, or role release.

If the only problem is unclear decision authority, use Decision Rights Clarification. If separate actors disagree, use dispute governance. If the sole concern is self-interest bias, use Conflict-of-Interest Management. High but compatible workload is ordinary capacity management.

### Strong application signals

Use the full pattern when a person can satisfy expectation A or B but not both within the relevant time, resources, authority, confidentiality, or ethical constraints; when satisfying one principal predictably harms another beneficiary; when a role-holder must advocate and judge the same matter; when formal work depends on invisible caregiving, emotional, or coordination labor; or when conflict is repeatedly surfaced only after errors, illness, exit, or retaliation.

The pattern applies even when nobody is openly arguing. Role conflict can remain intrapersonal or be normalized as dedication. A clinician may privately absorb incompatible care and throughput demands; a manager may hide compliance work to preserve delivery metrics; a community leader may be bound by confidentiality while expected to represent constituents publicly. Absence of a dispute is not evidence of compatibility.

Use a lighter clarification process when expectations are vague but become jointly feasible once specified. Use workload management when the duties are compatible and the only gap is volume. Escalate to this archetype when clarity exposes a structural contradiction or when capacity additions alone cannot resolve duty, loyalty, identity, confidentiality, or authority incompatibility.

prose_structural_problem:
Role conflict occurs when satisfying one legitimate expectation breaches, delays, or undermines another. Organizations often misdescribe it as resilience, productivity, or communication failure. That lets principals externalize impossible demands and makes the individual choose privately which beneficiary will be harmed.

The conflict can concern time, authority, loyalty, ethics, identity, care, information, impartiality, or responsibility without matching resources. It may occur across roles or inside one role with multiple principals.

### Map actors, roles, and expectation sources

Separate the **actor** from the **role** and the **role** from each **expectation**. One actor can occupy several roles; one role can be occupied by several actors; and one role can receive expectations from many sources. For every material expectation, record the source, claimed authority, beneficiary, required action or restraint, quality standard, timing, information boundary, resources, consequence of breach, and route for interpretation or appeal.

Include formal and informal sources. Statutes, professional codes, contracts, job descriptions, delegations, and policies may have explicit standing. Performance targets, team norms, cultural expectations, care relationships, identity commitments, and emergency practices may be less formal but still exert real force. Informality does not make an expectation unreal; it does mean legitimacy and enforceability require careful examination.

### Distinguish ambiguity, tension, overload, and conflict

**Ambiguity** means the expectation or authority is unclear. **Tension** means duties compete but can coexist with ordinary judgment. **Overload** means compatible duties exceed available capacity. **Conflict** means satisfying one material expectation necessarily violates, delays beyond tolerance, compromises, or conceals another under realistic conditions. These diagnoses can combine, but their remedies differ.

Test compatibility at peak conditions and across the complete duty cycle. Two roles may fit average hours yet collide at month-end, emergencies, court deadlines, school pickup, or recovery periods. A duty may be technically sequenced but not ethically sequenced if delay creates irreversible harm. A conflict may also be conditional: confidentiality and reporting are compatible until specified facts trigger a mandatory duty.

### Identify incompatible obligation types

Time and presence conflicts are only one class. Authority conflict assigns responsibility without decision power. Loyalty conflict binds the actor to principals with opposed interests. Confidentiality conflict pits information protection against disclosure or reporting. Impartiality conflict combines advocacy, benefit, or prior involvement with independent judgment. Care and performance conflict places relational duty against throughput. Identity conflict makes role performance demand denial or betrayal of a salient community or self commitment. Ethical conflict pits an instruction against law, safety, rights, or professional standards.

prose_intervention_logic:
Inventory roles, principals, duties, beneficiaries, authority, information, time, and resources. Translate vague expectations into observable obligations. Classify the incompatibility and identify nonwaivable duties and affected-party harms. Test simultaneous feasibility and structural options.

Where capacity, sequencing, scope, or interface changes solve the conflict, redesign them. Where judgment integrity is compromised, disclose, recuse, review independently, or separate roles. Where no feasible combination exists, apply an authorized priority rule and explicitly release, transfer, defer, or compensate displaced duties. Protect disclosure and monitor handoffs, retaliation, residual strain, and recurrence.

### 1. Construct the role–expectation map

Inventory actors, occupied roles, principals, beneficiaries, formal and informal expectations, authority bases, resources, information rights, temporal windows, and accountability. Translate abstractions such as “be supportive,” “deliver,” “remain neutral,” or “protect confidentiality” into observable obligations and tolerances. Record disputed interpretations rather than prematurely choosing one.

### 2. Test source legitimacy and precedence

Verify whether the source has authority over the role and the type of duty asserted. Distinguish law, rights, safety, professional duty, contract, delegated authority, policy, legitimate managerial direction, beneficiary expectation, custom, preference, and self-imposed norm. Precedence is contextual: a performance target does not override a statutory reporting duty; a manager cannot waive a professional obligation they do not own; and a family or community expectation may carry moral weight without automatically authorizing access to confidential information.

Build a reasoned priority order rather than a universal list. Consider legal force, rights and safety floors, professional independence, mandate scope, affected-party harm, reversibility, urgency, consent, and whether the source created the conflict. Make exceptions visible and reviewable.

### 3. Diagnose the incompatibility

Pair expectations and test simultaneous feasibility, sequencing, substitution, information separation, and conditional triggers. Estimate realistic time, attention, emotional labor, recovery, authority, competence, and resource requirements. Identify which assumption creates the collision and whether it is necessary. Capture the role-holder's evidence without requiring public disclosure of sensitive identity, health, family, or client information.

### 4. Generate reconciliation options

Start with expectation clarification and removal of illegitimate demands. Then consider scope reduction, resource addition, deadline or sequence change, interface redesign, joint ownership, delegation, substitute staffing, information segregation, independent review, recusal, role separation, boundary renegotiation, temporary relief, or exit. Options may combine: recusal without a qualified substitute protects integrity but abandons the beneficiary.

### 5. Negotiate where duties are waivable

When sources have legitimate but negotiable claims, convene an authority-linked negotiation. Make nonwaivable floors explicit first. Compare options by beneficiary harm, role-holder burden, continuity, privacy, reversibility, capacity, and accountability. An agreement must state revised expectations, resources, boundaries, decision rights, displaced duties, owners, dates, and review conditions. Consent obtained under retaliation risk is not reliable settlement.

### 6. Adjudicate when negotiation cannot resolve

Escalate unresolved precedence or rights conflicts to an authorized, sufficiently independent decision maker. Provide notice, relevant evidence, representation where stakes warrant, a record of reasons, conflict-of-interest controls, and appeal or review. Adjudication is not generic dispute settlement: its question is which role obligation governs and how the displaced obligation will be lawfully released, transferred, or remedied.

### 7. Transition roles and protect affected parties

Implement handoffs, successor access, confidentiality boundaries, knowledge transfer, consent, continuity coverage, compensation, and communication. Limit disclosure to what each party needs operationally. If the person exits or a role is separated, preserve records and services without carrying prohibited information across boundaries.

### 8. Monitor and prevent recurrence

Track workload, decision delay, quality, safety, ethical incidents, moral distress, absence, turnover, complaints, workarounds, handoff failure, retaliation, and the informal return of released duties. Feed findings into staffing, role design, source policy, escalation, and leadership review. A resolved case should reduce the structural source of future conflicts, not merely redistribute it to a quieter person.

prose_key_components:
The Role, Expectation, and Principal Inventory establishes the full demand set. The Incompatibility Classifier separates time, authority, loyalty, information, ethical, and identity conflicts. The Affected-Party and Nonwaivable-Duty Map protects less powerful beneficiaries. The Capacity, Authority, and Boundary Test distinguishes ambiguity from impossibility.

The Duty Priority and Release Rule prevents silent dropping. The Redesign, Recusal, Delegation, and Substitution Plan changes structure. Protected Disclosure and Escalation makes early reporting safe. The Transition and Residual-Strain Monitor ensures released work does not return informally.

### Role, expectation, and principal inventory

The inventory establishes who occupies which role, who asserts each expectation, who benefits, what authority is claimed, and what resources and information accompany the duty. It includes informal care, identity, and relational expectations only when relevant and with privacy safeguards. Without source mapping, the loudest instruction can masquerade as the legitimate one.

### Role-incompatibility classifier

The classifier distinguishes ambiguity, overload, conditional tension, and structural conflict, then tags time, resource, authority, loyalty, interest, confidentiality, identity, care, ethical, and multi-principal modes. Multiple tags are normal. Classification guides options: additional staff can solve capacity conflict but cannot make a conflicted adjudicator impartial.

### Affected-party and nonwaivable-duty map

This map prevents priority from becoming a contest among principals alone. It identifies people whose safety, rights, care, confidentiality, access, or livelihood depends on each duty, including parties absent from the meeting. It also names which obligations cannot be casually traded and who, if anyone, can interpret or waive them.

### Role capacity, authority, and boundary test

The test checks realistic time, peaks, attention, emotional labor, recovery, competence, decision power, information access, resources, and separation. It also tests boundary permeability: whether information, relationships, or authority from one role improperly crosses into another. A clear assignment fails if its enabling conditions do not travel with it.

### Role-duty priority and release rule

The rule records why one duty controls, which authority makes the decision, how harm and reversibility were considered, and what happens to displaced obligations. “Prioritize X” is incomplete unless Y is explicitly deferred, transferred, waived by a competent source, compensated, or ended.

### Redesign, recusal, delegation, and substitution plan

The plan turns a decision into a viable structure. Delegation transfers authority, information, resources, competence requirements, capacity, acceptance, and accountability together. Recusal identifies the scope and duration of withdrawal, independent successor, information firewall, handoff, and continuity. Boundary redesign states what the role will no longer own.

### Protected conflict disclosure and escalation path

The path offers confidential intake, need-to-know handling, representation, interim protection, nonretaliation, independent routing, response time, and escalation to an authority capable of changing expectations. A complaint channel that forwards the disclosure to the source of retaliation without protection is not a safe path.

### Role transition and residual-strain monitor

The monitor observes whether the designed arrangement holds. It compares formal assignments with actual work, samples handoffs and exceptions, and looks for retaliation, moral distress, delay, quality loss, confidentiality leakage, successor overload, and hidden return. Findings trigger redesign rather than renewed blame.

prose_common_mechanisms:
A role-expectation conflict matrix reveals incompatible pairs. Simultaneous feasibility tests compare capacity and timing under peaks. Duty-priority and harm comparison makes displaced obligations visible. Recusal, delegation, or separation gates test continuity and successor capacity. Protected conflict conferences revise expectations through real authority. Recurrence audits test whether hidden strain returns.

Each mechanism is partial. A matrix can document impossibility without changing it, and a meeting without authority can pressure the role-holder to accept the same conflict again.

Use mechanisms in a sequence appropriate to the conflict. A matrix and feasibility test can establish the collision. Source review and harm comparison can narrow legitimate options. A protected conference can negotiate waivable expectations. An independent gate can require recusal, delegation, or separation. A recurrence audit can reveal that the formal resolution never changed actual work.

Mechanisms must be privacy-bounded. Evidence may include client confidences, health information, family circumstances, protected reports, or identity commitments. Use functional descriptions and minimal disclosure where possible; separate the operational fact that a duty cannot be performed from details that are unnecessary to the decision. Restrict records, set retention, and disclose conflicts only to those able to act or provide required oversight.

Power affects mechanism validity. A conference is not genuinely participatory if a supervisor controls pay, scheduling, evaluation, or future opportunity and no nonretaliation control exists. A recusal decision is not independent if the replacement answers to the conflicted principal. Match procedural safeguards to stakes and power asymmetry.

prose_failure_modes:
Clarity without feasibility documents impossible work. Powerful principals crowd out less visible beneficiaries. Hollow delegation transfers blame rather than capability. Retaliation silences conflict. Recusal without continuity abandons service. Hidden recurrence returns released duties informally. Feasibility tests, duty floors, transfer gates, nonretaliation, substitute plans, and recurrence audits address these failures.

### Ambiguity misclassified as conflict

Detect this when parties attach different meanings, scopes, or deadlines to the same expectation and compatibility returns after authoritative clarification. Clarify before structural separation, but do not let repeated “clarification” become a way to deny an established contradiction.

### Conflict misclassified as overload

Adding hours or staff cannot reconcile duties that require both advocacy and impartial judgment, confidentiality and unauthorized disclosure, or incompatible loyalties. Detect when more capacity leaves the normative collision intact. Use source precedence, boundary redesign, independent review, recusal, or separation.

### Power-weighted priority

The highest-status or most proximate principal may win even when its demand is discretionary and another party's right or safety is nonwaivable. Detect repeated sacrifice of invisible beneficiaries and decisions without reasons. Require affected-party mapping, subject-matter authority, recorded priority logic, and review.

### Retaliation and privacy breach

Disclosure may trigger poor assignments, exclusion, evaluation harm, gossip, credential threats, or pressure to reveal more than necessary. Detect adverse changes after reporting and access beyond need-to-know. Provide interim protection, independent intake, representation, audit trails, remedial authority, and sanctions for retaliation.

### Hollow remedy and failed recovery

A decision may order delegation without successor capacity, recusal without continuity, or boundary change without removing old metrics. Detect missed handoffs, repeated exceptions, successor overload, confidentiality gaps, and work returning informally. Reopen the transition, resource the substitute, repair affected-party harm, and correct the source policy.

### Recurrence through system design

Conflict often returns because incentives, staffing, escalation, job architecture, or principal behavior remain unchanged. Aggregate recurring cases by source and conflict mode, then redesign upstream mandates, reporting lines, role combinations, staffing ratios, and policy language. Do not treat each recurrence as a unique personality problem.

prose_neighbor_distinctions:
Decision Rights Clarification resolves who decides. Alignment Governance resolves disagreement among actors. Conflict-of-Interest Management protects judgment from divided interest. Decision Load Management reduces cognitive burden. Authority Rotation limits tenure. Role conflict uniquely reconciles incompatible expectations carried by one role-holder or position.

Responsibility assignment creates ownership and accountability for work. It is a component of role design, but assigning responsibility cannot resolve two incompatible obligations and may worsen conflict when authority or resources do not accompany it. This archetype decides which duty remains, which moves, and what conditions make the assignment viable.

Distributed Authority Checks and Balances designs institutions so multiple centers constrain one another. It intentionally separates powers at system level. Role reconciliation may use separation or independent review, but its trigger is incompatible expectations concentrated in an actor or position, including informal and capacity conflicts that are not constitutional checks.

Procedural Fairness governs how decisions are made through notice, voice, reasons, impartiality, and appeal. Those safeguards may be required when adjudicating a role conflict, especially under power asymmetry. The parent archetype additionally diagnoses role-source incompatibility, tests feasibility, and redesigns occupancy, boundaries, resources, or duties.

Generic conflict resolution mediates incompatible interests or perceptions among parties. Role conflict can exist without interpersonal disagreement and may not be negotiable when law, rights, safety, confidentiality, or professional duties set floors. Reconciliation therefore combines negotiation with source legitimacy, precedence, structural remedy, and explicit release.

prose_cross_domain_examples:
A clinician should not combine confidential treatment with punitive evaluation without separation. A manager responsible for delivery, employee advocacy, compliance, and budget reduction needs priority and redesign, not generic resilience training. A public official with a loyalty conflict may require disclosure, recusal, substitution, and continuity.

### Healthcare

A clinician is asked to provide confidential treatment and certify facts for a punitive employment action. The map separates care, confidentiality, reporting, employer, and patient expectations; identifies nonwaivable professional duties; and tests whether limited consent resolves the collision. Where impartial punitive evaluation remains incompatible, an independent evaluator receives only authorized information, the treating relationship continues, and the transition is audited for privacy and care disruption.

### Matrix organization

A security lead reports to a product executive on delivery and to a risk executive on release assurance. Both issue mandatory deadlines that cannot coexist. The system verifies authority scopes, quantifies feasibility, protects escalation, adjudicates the release gate, revises shared metrics, assigns capacity, and records which delivery commitment is released. Follow-up checks whether the product leader reintroduces the rejected demand informally.

### Education

A teacher is expected to advocate for a student, grade impartially, maintain confidentiality, report specified risks, support family engagement, and meet class-wide workload targets. Conditional triggers and information boundaries are clarified; reporting duties are separated from discretionary disclosure; additional support and independent review handle high-stakes cases; and family communication does not expose protected student information.

### Caregiving and employment

An employee with predictable elder-care duties is assigned an on-call role whose peak demands collide with nontransferable care windows. The organization does not demand private clinical detail. It tests schedules, backup, role rotation, compensation, and scope; negotiates a bounded arrangement; transfers specified on-call periods with authority and pay; and monitors team burden and retaliation.

### Research and public service

A researcher is principal investigator, supervisor, data custodian, and adjudicator of a complaint involving their own program. The design protects disclosure, moves fact finding and adjudication to independent roles, preserves necessary data access controls, maintains project continuity, and prevents the investigator from evaluating complainants through another role.

prose_non_examples:
Clarifying one uncontested decision owner is not role-conflict reconciliation. Mediating separate teams is dispute resolution. Reducing a compatible task list is workload management. Asking someone to work harder leaves structural incompatibility intact.

Nor is every uncomfortable decision a role conflict. Ordinary professional judgment can require choosing among compatible priorities within delegated discretion. Personal dislike of a legitimate expectation is not structural incompatibility. The archetype applies when evidence shows simultaneous infeasibility, prohibited boundary crossing, compromised judgment, or unavoidable breach of another material duty.

A disclosure form without independent review and remedy is not reconciliation. Reassigning a person while retaining the same metrics and informal requests is not boundary change. Telling a caregiver to use leave without examining role design may simply privatize the conflict. Creating a committee to discuss the problem without authority to release expectations is procedural theater.

prose_tradeoffs:
Role integration conflicts with independence, continuity with recusal, flexibility with bounded responsibility, and resolution evidence with privacy. These tensions require case-specific structural decisions rather than universal separation or consolidation.

Integrated roles can provide context, trust, speed, and relational continuity, yet the same integration can enable self-review, confidentiality leakage, divided loyalty, or chronic overload. Separate only the functions necessary to protect integrity and feasibility, while designing interfaces that preserve legitimate knowledge and service continuity.

Flexible roles allow adaptation when conditions change, but vague flexibility can become unlimited obligation. Bound flexibility with capacity, authority, duration, review, and explicit release. Temporary exceptions need sunset or incorporation into staffing; otherwise exceptional work becomes an invisible permanent role.

Conflict visibility enables legitimate priority decisions but may expose identity, health, family, client, or protected-report information. Use the least revealing evidence capable of supporting the decision. Independent reviewers can sometimes evaluate sensitive facts and provide an operational conclusion without broad disclosure.

Fast recusal can protect integrity but disrupt care or service. Delay for handoff can preserve continuity but extend compromised judgment. Establish interim restrictions, qualified substitutes, emergency coverage, and a time-bounded transition rather than choosing between instant abandonment and indefinite conflict.

prose_invariants_to_preserve:
- Every material expectation has a source, beneficiary, authority, resource demand, and review path.
- Nonwaivable duties and affected-party harms precede priority selection.
- Conflict disclosure is protected from retaliation.
- Displaced duties are released, transferred, deferred, or compensated explicitly.
- Delegation includes authority, competence, information, capacity, acceptance, and accountability.
- Recusal preserves continuity and lawful confidentiality.
- Hidden work and residual strain remain monitored.

The role-holder retains standing and dignity. They must be able to describe incompatibility, challenge source legitimacy, decline an unsafe or unethical instruction, and contest a redesign that removes opportunity or identity without necessity. Participation does not give them unilateral authority over duties owed to others, but neither are they merely the object of assignment.

Privacy is preserved through purpose limitation, minimal disclosure, access control, and separation of sensitive facts from operational instructions. Informal care or identity roles should not become an invitation for organizational intrusion. The system needs enough evidence to govern the conflict, not a complete account of private life.

Affected parties and less powerful beneficiaries remain visible. A resolution that protects the role-holder by abandoning patients, students, clients, constituents, family members, or junior staff is incomplete. Continuity, remedy, and explicit transfer are part of reconciliation.

prose_target_outcomes:
The pattern should reduce impossible assignments, hidden work, burnout, moral distress, delay, and quality loss while improving duty protection, priority clarity, recusal, delegation, continuity, and accountability.

Measure structural outcomes, not the disappearance of complaints. Useful indicators include incompatible assignment frequency, time to protected review, percentage resolved by source correction or redesign, displaced-duty disposition, handoff quality, confidentiality incidents, retaliation reports, hidden overtime, missed care or service, moral distress, successor overload, recurrence, and whether affected parties received remedy.

Silence after intervention can mean resolution or fear. Pair administrative metrics with confidential follow-up and evidence from actual work. A strong result makes ordinary priority judgments easier while making serious conflicts safer to surface.

prose_parameter_dimensions:
Tune role granularity, time horizon, severity thresholds, authority for priority decisions, strength of nonwaivable-duty floors, disclosure confidentiality, recusal threshold, delegation requirements, transition duration, and recurrence-monitoring cadence.

### Role and expectation granularity

Too coarse a role label hides incompatible functions; too fine a decomposition creates administrative noise. Split roles where authority, beneficiary, information boundary, ethical standard, or accountability differs. Specify expectations to the level needed for feasibility and priority without micromanaging legitimate professional judgment.

### Conflict and escalation thresholds

Tune which tensions remain with ordinary judgment and which require protected review. Consider severity, frequency, irreversibility, safety, rights, confidentiality, affected-party dependence, and retaliation risk. A low-frequency conflict can merit immediate escalation if consequences are grave; a recurring minor collision may warrant systemic redesign because cumulative strain is high.

### Priority and waiver authority

Define who can interpret, modify, waive, or transfer each duty. Authority should follow the source and subject matter, not merely organizational rank. Require independent adjudication where the decision maker benefits from one priority outcome or where professional, legal, or rights duties constrain managerial discretion.

### Recusal, delegation, and separation depth

Tune the scope, duration, information firewall, successor independence, handoff, and review of structural remedies. Overbroad recusal can unnecessarily exclude expertise or relationships; narrow recusal can leave the decisive conflict intact. Delegation depth must match the transferred responsibility.

### Protection and monitoring cadence

Set confidentiality, interim measures, response deadlines, nonretaliation checks, retention, appeal, and follow-up according to risk. Monitor early after transition, at known peak periods, and after leadership, policy, staffing, or workload changes. Avoid surveillance of the role-holder; measure the role system and consequences.

prose_variants_and_near_names:
Interrole Capacity and Time Conflict concerns incompatible presence or attention. Divided Loyalty and Professional-Duty Conflict concerns advocacy, confidentiality, impartiality, reporting, care, and ethics. Intra-Role Multi-Principal Conflict concerns contradictory direction inside one role. The queue aliases route to these variants or the parent according to conflict mode.

The capacity variant emphasizes peaks, recovery, care dependencies, scheduling, and hidden work; it remains distinct from ordinary workload because obligations arise from different roles and priority or release must be governed. The professional-duty variant raises nonwaivable floors, confidentiality, consent, independent review, and recusal. The multi-principal variant concentrates on mandate scope, authority reconciliation, escalation, and preventing principals from reissuing displaced demands informally.

“Role strain” is a near name only when the strain comes from incompatible expectations. Burnout, role ambiguity, decision fatigue, and excessive workload can exist without conflict and should route elsewhere. A conflict matrix, recusal form, conference, delegation memo, or ethics hotline is a mechanism, not a parent archetype.

Interrole Capacity and Time Conflict

short_definition: Reconciles legitimate roles that require incompatible presence, timing, attention, emotional labor, recovery, or resource use under realistic peak conditions.

distinctive_feature: Peak timing, physical presence, switching, recovery, hidden work, care dependency, and the legitimacy of formal versus informal commitments dominate.

distinct_from_parent: The primary incompatibility is resource and temporal feasibility rather than divided judgment, confidentiality, or contradictory authority mandates.

still_same_parent_because: It uses expectation inventory, source legitimacy, simultaneous-feasibility tests, priority, redesign, explicit release, protected escalation, transition, and recurrence monitoring.

source_primes: role_conflict role allocation

use_when: Multiple roles collide at specific deadlines, emergencies, care windows, or peak periods.

use_when: Average workload appears feasible while simultaneity or recovery makes it impossible.

use_when: Informal care, volunteer, identity, or continuity duties materially constrain scheduling.

use_when: Sequencing, added capacity, substitution, scope change, or release may restore feasibility.

example: Reassigns defined on-call windows with authority, pay, backup, and team-burden monitoring without demanding unnecessary private medical information.

example: Separates command presence from recovery and family-contact duties through qualified rotation and handoff rather than relying on continuous heroic availability.

failure_modes: Average-hours analysis hides deadline and presence collisions.

failure_modes: Recovery and switching costs are excluded from capacity.

failure_modes: Informal care or community duties are dismissed without legitimacy review.

failure_modes: Temporary coverage becomes hidden unpaid permanent work.

failure_modes: Schedule accommodation reduces opportunity or evaluation parity.

name: Divided Loyalty and Professional-Duty Conflict

short_definition: Reconciles loyalty, advocacy, confidentiality, impartiality, reporting, care, consent, fiduciary, and professional obligations owed to parties whose interests conflict.

distinctive_feature: Nonwaivable duties, professional independence, confidentiality, informed consent, recusal, information separation, independent review, and continuity dominate.

distinct_from_parent: The conflict turns on normative and fiduciary integrity rather than only capacity; some compromises are prohibited and structural independence may be mandatory.

still_same_parent_because: It uses duty-source mapping, affected-party analysis, precedence, recusal or separation, explicit transfer, protected escalation, transition, and monitoring.

use_when: One person is expected to advocate and independently judge the same matter.

use_when: Confidentiality and a reporting or disclosure duty may collide.

use_when: Professional or legal duties constrain what principals may negotiate or waive.

use_when: Disclosure alone cannot preserve credible judgment or public trust.

example_domains: healthcare law research public_service journalism fiduciary_governance

domain: healthcare

example: Separates confidential treatment from punitive evaluation, limits information transfer to authorized facts, appoints an independent evaluator, and preserves care continuity.

domain: research

example: Moves complaint fact finding and adjudication away from a principal investigator who supervises the parties and controls the relevant data and opportunities.

failure_modes: Disclosure is treated as sufficient though judgment remains compromised.

failure_modes: Confidential information crosses roles without consent or authority.

failure_modes: Loyalty to a powerful principal overrides rights or professional duty.

failure_modes: Recusal removes the actor but abandons service or remedy.

failure_modes: The replacement is formally separate but operationally controlled by the conflicted principal.

Intra-Role Multi-Principal Conflict

short_definition: Resolves incompatible expectations issued to one role by multiple authorized principals, mandates, beneficiaries, or governance channels.

distinctive_feature: Principal legitimacy, mandate scope, precedence, escalation, joint authority, expectation release, accountability, and prevention of informal reissue dominate.

distinct_from_parent: The conflict occurs inside one named role and concentrates on competing authority sources rather than the actor's separate professional, care, or identity roles.

still_same_parent_because: The role-holder still carries incompatible obligations requiring source mapping, feasibility, priority, expectation revision, explicit release, transition, and monitoring.

use_when: A matrixed or joint role has several principals with overlapping direction rights.

use_when: Authority hierarchy, mandate scope, or conflict-reconciliation rules are incomplete.

use_when: The role-holder is accountable for outcomes controlled by different principals.

use_when: Released expectations repeatedly return through informal instructions or metrics.

example: Adjudicates incompatible delivery and security gates, revises shared metrics, transfers resources, and records which commitment is released.

example: Reconciles statutory, ministerial, and local-service mandates through defined subject-matter precedence and a protected route for frontline escalation.

failure_modes: Highest-status principal wins without subject-matter authority review.

failure_modes: Accountability remains with the role-holder while decision power is fragmented.

failure_modes: Escalation loops among principals without a final authorized forum.

failure_modes: A rejected demand returns informally through performance evaluation.

failure_modes: Joint ownership produces no owner for the displaced beneficiary or handoff.

near_names:
Incompatible Role Expectations
Multi-Role Strain
Inter-Role Conflict
Intra-Role Conflict