1) Diagnostic Identity

Diagnostic Name: Repair Burden Distribution

Short Name / Symbol: repair_burden_distribution

Diagnostic Class: Restoration / Burden Allocation / Coupling Justice / Repair Symmetry / Legitimacy

Primary Function: Estimate how repair responsibility, labor, cost, attention, time, risk, emotional load, technical correction, acknowledgment, memory correction, and restoration effort are distributed across nodes, roles, systems, institutions, or subfields.

Primary Use: Determine whether the burden of restoration is being carried by the correct layer, cause-bearing node, authority position, repair-capable node, or affected node — and whether that distribution is coherent, symmetrical, and sustainable.

Core Risk if Ignored: The system may claim repair while shifting the actual restoration burden onto affected, lower-resource, lower-authority, or lower-visibility nodes, producing hidden debt, recurrence, legitimacy loss, and extraction dynamics.

Core Risk if Overtrusted: Any unequal repair distribution may be treated as incoherent, even when specialized skill, stewardship role, voluntary contribution, or capacity-aware support legitimately assigns more repair work to some nodes.

2) Mechanical Definition

repair_burden_distribution measures who is actually carrying the work, cost, risk, responsibility, and memory load of restoration.

repair_burden_distribution answers:

Who is doing the repairing, who caused the repair need, who benefits from the repair, and who carries the cost if repair fails?

Repair burden includes more than technical fixing.

It may include:

diagnosing
naming
acknowledging
tracking
explaining
absorbing delay
providing resources
changing behavior
restoring boundaries
correcting memory
appealing
documenting
teaching
holding continuity
absorbing recurrence
rebuilding trust
validating repair

A system can have visible repair activity while the burden is distributed incoherently.

Common failure pattern:

cause-bearing node creates damage
affected node must name, prove, explain, track, and absorb repair
authority node claims closure
system memory stores repair as complete

Healthy repair burden distribution does not require identical effort. It requires coherent alignment between cause, authority, capacity, benefit, harm, and restoration obligation.

3) What the Diagnostic Measures

Direct Measurement Target

repair_burden_distribution measures:

• who supplies repair labor
• who pays repair cost
• who performs diagnosis
• who provides evidence
• who carries proof burden
• who supplies acknowledgment
• who performs behavior change
• who corrects memory
• who validates repair
• who absorbs recurrence
• who funds restoration
• who carries delay cost
• who absorbs emotional, social, technical, or institutional load
• who has authority to repair the cause
• who benefits from repair
• who bears cost if repair fails
• whether repair burden matches cause, authority, capacity, and harm

Indirect / Proxy Signals

repair_burden_distribution can be estimated from:

• affected nodes repeatedly explaining the same issue
• repair labor concentrated in low-power nodes
• harmed nodes required to prove harm repeatedly
• authority nodes approving closure without carrying repair
• technical teams patching policy-origin failures
• frontline nodes absorbing upstream design failures
• lower-resource nodes carrying documentation burden
• one node doing most recurrence tracking
• repair being delayed until affected nodes escalate
• acknowledgment burden placed on those harmed
• memory correction performed by those misclassified
• repair work invisible in official records
• repair cost not matching cause or benefit
• repair responsibility assigned to nodes without authority
• cause-bearing layer not participating in restoration
• repair outcome evaluated without affected-node validation

What It Does Not Measure

repair_burden_distribution does not directly measure:

• whether repair is complete
• whether all repair burden should be equal
• whether affected nodes should never participate in repair
• whether specialized repair roles are incoherent
• whether high-capacity nodes must do all repair
• whether cause is fully known
• whether harm was intentional
• whether repair work is voluntary or coerced
• whether repair is effective by itself
• whether burden distribution is illegitimate simply because uneven

High asymmetry in repair burden means restoration labor or cost is unevenly distributed.

It does not automatically mean incoherence if the distribution is voluntary, capacity-aligned, cause-aware, supported, and acknowledged.

Low asymmetry means burden is more evenly distributed.

It does not automatically mean repair is coherent if no one with true authority is repairing the origin.

4) Canonical State Variables Involved

Canonical state vector:

S = {O, H, ε, ι, Au, µᵢ, BΣ, K, R, Φ}

Primary Variables

• R: repair burden distribution determines whether restoration capacity is actually available where needed
• H: hidden debt rises when repair cost is exported, denied, or unacknowledged
• BΣ: boundary integrity is damaged when affected nodes must carry disproportionate restoration burden
• µᵢ: integrity depends on aligning action, consequence, responsibility, and repair
• O: coherence depends on repair burden matching real causal and restoration structure
• Au: repair burden must be visible enough to audit who is repairing what

Secondary Variables

• ε: visible errors may be reduced while repair burden remains distorted
• ι: pseudo-repair appears when repair is claimed but burden is exported
• K: compatibility degrades when one node repeatedly supplies restoration for both
• Φ: repair metrics may improve while actual burden falls on hidden nodes

Variables Commonly Confused With repair_burden_distribution

5) Localization Signature

Primary Legibility Layers

• U1 — Power / Budgets: money, time, labor, staffing, compute, energy, attention, material resources required for repair
• U2 — Configuration / Boundaries: who is assigned repair authority, obligation, access, and permission
• U3 — Execution: who actually performs repair actions
• U4 — Classification / Metrics / Narratives: how repair responsibility is named, justified, minimized, or misassigned
• U5 — Coordination / Time: who tracks, escalates, sequences, and follows up repair over time
• U7 — Memory / Recurrence: who maintains repair memory, recurrence tracking, and correction history

Primary Leverage Layers

• U1: allocate repair resources to the correct node/layer
• U2: redesign repair authority and responsibility
• U3: move repair execution to the cause-bearing or capable layer
• U4: correct narratives that misassign repair responsibility
• U5: reduce coordination burden on affected nodes
• U7: preserve repair burden history and prevent false closure

Verification Layers

• U1: who has resources to repair?
• U2: who has authority to repair?
• U3: who is doing repair?
• U4: who is named as responsible?
• U5: who tracks repair over time?
• U7: whose repair burden is remembered?

Common Mislocalizations

• Treating affected-node explanation as repair participation
• Treating proof burden as neutral process
• Treating apology as repair transfer
• Treating technical team patching as full repair when origin is policy
• Treating frontline service as cause-bearing repair
• Treating harmed-node patience as recovery capacity
• Treating unpaid coordination as invisible
• Treating repair tracking as administrative detail
• Treating lower-resource repair labor as willingness
• Treating authority approval as repair execution
• Treating closure documentation as burden resolution
• Treating restoration fatigue as resistance

6) Input Requirements

Required Inputs

To estimate repair_burden_distribution, the system needs:

• failure, harm, breach, or repair target
• cause-bearing layer or node estimate
• affected nodes
• repair-capable nodes
• authority-bearing nodes
• resource-bearing nodes
• actual repair actions
• who performs each repair action
• affected variables in S
• repair costs by node
• repair time by node
• repair authority by node
• proof burden
• acknowledgment burden
• memory correction burden
• recurrence tracking burden
• affected-node validation

Optional Inputs

These improve precision:

• repair logs
• incident timeline
• cost estimates
• labor/time records
• escalation records
• proof/documentation records
• appeal records
• resource allocation data
• authority map
• dependency map
• recurrence history
• repair outcome validation
• trust recovery data
• hidden labor reports
• contribution records
• public/private repair narrative
• MS symmetry review
• external audit
• post-repair stress test

Missing Input Behavior

If repair_burden_distribution inputs are missing:

• If cause-bearing node is unknown, avoid assigning repair burden definitively
• If repair labor is untracked, hidden burden may be high
• If affected-node effort is missing, repair may be over-credited to authority
• If authority map is missing, repair may be assigned to nodes unable to fix cause
• If resource map is missing, burden may exceed capacity
• If recurrence tracking is missing, repair durability is unverified
• If memory correction burden is missing, U7 repair may be incomplete
• If affected-node validation is missing, burden resolution is unverified

Default missing-input posture:

map repair tasks → identify who carries each task → compare cause/authority/capacity → redistribute burden before closure

7) Diagnostic States / Ranges

These ranges are qualitative and should be domain-calibrated.

Healthy / Coherence-Supporting Range

Repair burden is distributed according to cause, authority, capacity, benefit, harm, and restoration need.

Signals:

• cause-bearing layer participates in repair
• authority-bearing nodes carry proportional repair responsibility
• affected nodes are not forced to carry proof and restoration alone
• repair resources match repair demand
• hidden labor is acknowledged
• memory correction is assigned
• recurrence tracking is not externalized unfairly
• repair burden is visible and auditable
• repair outcome is validated by affected nodes
• burden distribution improves O and BΣ

Recommended posture:

continue ℛ
track burden distribution
validate recurrence
store repair responsibility in U7

Watch Range

Repair burden is partially coherent, but some cost, proof, tracking, or coordination is drifting toward affected or lower-capacity nodes.

Signals:

• affected nodes must explain repeatedly
• repair resources are thin
• authority supports repair symbolically but not operationally
• repair tracking depends on one node
• repair work is under-acknowledged
• memory correction is incomplete
• proof burden is rising
• recurrence is being tracked informally
• repair is happening but burden is uneven

Recommended posture:

make burden visible
increase repair resources
shift authority-linked burden upward
protect affected-node capacity
repair U7 memory

Degraded Range

Repair burden is misassigned or exported in a way that undermines restoration.

Signals:

• affected nodes must prove, explain, track, and absorb repair
• lower-resource nodes carry most restoration
• authority nodes claim closure without doing repair
• repair occurs at symptom layer
• cause-bearing nodes avoid repair obligation
• recurrence continues because repair burden lacks authority
• hidden labor sustains the system
• repair fatigue appears
• apology or acknowledgment substitutes for burden transfer
• repair metrics improve while affected nodes remain depleted

Recommended posture:

activate MS review
pause closure
redistribute repair burden
resource origin-layer repair
restore affected-node capacity
correct repair narrative

Contraindicated:

declaring repair complete
demanding trust
deep recoupling
scaling repaired narrative
punishing repeated feedback
continuing burden export

Critical / Collapse-Prone Range

Repair burden distribution becomes extractive, coercive, or structurally impossible.

Signals:

• harmed nodes carry most restoration
• repair burden exceeds capacity
• affected nodes exit or collapse
• cause-bearing authority remains untouched
• hidden repair labor becomes infrastructure
• repair legitimacy collapses
• recurrence normalizes
• system depends on the depleted node to keep repairing
• repair burden is denied or moralized
• outside intervention is required to redistribute burden

Recommended posture:

stop closure and expansion
triage affected-node burden
restore resources
reassign repair to authority/cause layer
repair hidden debt
correct official memory
validate restoration over time

False Positive Risk

repair_burden_distribution may appear incoherent when:

• specialized repair role legitimately carries more repair work
• affected nodes choose to participate and are supported
• high-capacity nodes voluntarily carry extra repair
• temporary repair concentration is necessary
• repair burden is unequal but acknowledged and resourced
• a steward role exists with clear authority and restoration capacity
• transitional repair requires uneven effort before rebalancing

False Negative Risk

repair_burden_distribution may appear healthy when:

• hidden labor is untracked
• affected nodes stop reporting
• authority claims repair while others execute it
• proof burden is invisible
• emotional or memory labor is omitted
• unpaid coordination sustains repair
• repair metrics count closure rather than burden
• lower-resource nodes normalize repair load
• public repair narrative hides actual labor distribution

8) Leading Indicators

repair_burden_distribution degradation appears early as:

• affected nodes repeat the same explanation
• repair tracking falls to the harmed node
• proof burden increases
• authority asks for more evidence but provides little repair
• repair depends on heroic labor
• same node coordinates every repair cycle
• acknowledgment arrives without resource transfer
• repair meetings multiply without burden shift
• recurrence is tracked informally
• lower-capacity nodes absorb delay
• cause-bearing nodes become less visible
• repair fatigue appears
• memory correction is left to those misremembered
• “we fixed it” appears before burden is redistributed

9) Lagging Indicators

repair_burden_distribution failure has already accumulated debt when:

• affected nodes exit or disengage
• trust in repair collapses
• recurrence persists despite repair claims
• hidden labor becomes visible after breakdown
• repair systems are viewed as theater
• authority must be externally pressured to repair
• repair backlog exceeds available capacity
• memory records falsely credit repair
• restoration requires major redistribution
• system cannot repair without those harmed continuing to help
• repair cost exceeds the capacity of assigned nodes
• legitimacy shock follows exposure of burden export

10) Interpretation Rules

How to Read repair_burden_distribution

repair_burden_distribution should be read as:

context-specific allocation of restoration work, cost, authority, and memory responsibility

It is not a demand for equal repair work.

A system may have:

• unequal repair burden and high coherence if capacity/authority/role justify it
• equal repair burden and low coherence if cause and capacity differ
• high affected-node participation and healthy repair if voluntary, supported, and not proof-burdened
• high authority participation and low repair if authority only performs symbolic action
• strong technical repair and weak memory/acknowledgment repair
• visible resource allocation but hidden coordination burden

What Changes Its Meaning

repair_burden_distribution changes meaning under:

• high resource_asymmetry
• high dependency_load
• high exit_cost
• low R_eff
• low Au_eff
• low EB
• weak FI_integrity
• high affected_node_cost
• high AP(t)
• high AckDebt
• low M_int(t)
• high recovery_asymmetry
• high boundary_strain
• high immunity_index
• low MS_symmetry_index
• high Φ pressure

Context Modifiers

High resource_asymmetry: repair burden may become unfair even if formally equal.

High dependency_load: dependent nodes may be forced to repair coupling.

High exit_cost: affected nodes may repair because leaving is unavailable.

Low R_eff: burden may be assigned where capacity is insufficient.

Low Au_eff: actual repair labor may be hidden.

Low EB: burdened nodes may not express depletion.

High AckDebt: repair may not land without recognition.

High immunity_index: cause-bearing nodes may avoid repair.

High recovery_asymmetry: burden may grow faster than repair lands.

Domain Calibration Notes

repair_burden_distribution should be calibrated by domain:

• in engineering: who diagnoses, fixes, tests, documents, owns postmortems, and carries on-call recurrence
• in AI: who corrects model/tool/memory failures, users versus system, evaluation versus product, policy versus engineering
• in institutions: who proves harm, who funds remedy, who changes policy, who validates repair
• in governance: who bears remedy cost, proof burden, legal burden, administrative burden, and reform labor
• in relationships: who names issues, tracks recurrence, changes behavior, validates repair, and rebuilds trust
• in archives: who updates glossary, cross-links, canon status, version history, source lineage, and correction records

11) Operator Sequencing Implications

If repair_burden_distribution Is Healthy

Allowed with ordinary gate checks:

• ℛ can proceed with legitimate burden alignment
• Γ can select repair roles and priorities
• Π can define repair responsibilities
• MS-Gate can pass with monitoring
• U7 memory can store repair responsibility
• Λ / ⊗ recoupling may be considered after validation
• Δ retesting can proceed if repair capacity remains sufficient

Recommended:

damage map → burden map → Γ repair role selection → ℛ origin-layer repair → affected-node validation → U7 update

If repair_burden_distribution Is Degraded

Recommended:

pause closure → map actual repair labor → identify burden export → activate MS review → redistribute repair to cause/authority/capacity layers

Or:

restore affected-node capacity → resource repair → correct memory → validate recurrence

Avoid or delay:

• repair-complete claims
• demanding trust
• deep ⊗ re-coupling
• scaling repair narrative
• assigning more proof burden to affected nodes
• punitive response to repeated signal
• using acknowledgment as repair transfer
• closing before burden is redistributed

Operators Recommended Under Degraded Burden Distribution

• Au: reveal actual repair labor and cost
• MS-Gate: review burden symmetry
• ℛ: repair at cause-bearing layer
• Π: assign repair obligation and protect affected nodes
• Γ: select repair roles based on cause, authority, and capacity
• Ψ: attend to hidden affected-node burden
• Ξ: detect repair theater and burden export
• Θ: damp closure pressure

Operators Contraindicated Under Degraded Burden Distribution

• Γ closure selection: may declare repair complete while burden persists
• Π equal burden rule: may worsen asymmetry under unequal capacity
• ⊗ deep coupling: continues burden export
• ⊕ composition: embeds unfair repair structure
• Τ acceleration: outruns restoration redistribution
• Σ escalation: may moralize unequal repair
• ✕ force: shifts burden coercively and creates hidden debt

12) Gate Implications

Gates Strengthened By Reliable repair_burden_distribution

• MS-Gate: checks whether restoration burden is proportional and symmetrical
• Au-Actuation: repair burden and cost are traceable
• FI-Gate: affected-node feedback can reveal incomplete or exported repair
• High Risk Gate: prevents high-risk closure or binding when repair burden is misassigned
• ☷ᵢ: ensures principles are not invoked while repair burden is exported

Gates Weakened If repair_burden_distribution Is Poorly Known

If repair burden distribution is unknown:

• MS may falsely pass symbolic repair
• Au may miss hidden repair labor
• FI may not hear burdened nodes
• High Risk Gate may allow repair-complete binding too early
• ☷ᵢ may validate repair language without restoration
• Π may assign burden to the wrong node
• Γ may select repair path without capacity
• ℛ may repair symptoms while burden remains displaced

Gate Outcomes Affected

Degraded repair_burden_distribution should push gates toward:

• Pause closure
• Require repair burden map
• Require affected-node validation
• Require cause/authority/capacity alignment
• Require resource allocation
• Require memory correction
• Deny repair-complete claims
• Deny re-coupling under exported burden
• ∅ for high-impact transition where repair burden remains misassigned

13) Scaling Behavior

repair_burden_distribution becomes more difficult under scale because repair labor becomes distributed, invisible, specialized, outsourced, or shifted downward.

As systems scale:

• repair work fragments
• diagnosis separates from authority
• affected-node proof burden grows
• hidden labor increases
• repair becomes proceduralized
• authority claims closure while local nodes repair
• recurrence tracking becomes diffuse
• lower-resource nodes absorb unresolved debt
• memory correction lags
• technical repair and trust repair separate
• repair metrics track closure rather than burden
• public repair narrative hides actual labor
• cause-bearing layers become harder to reach

Scaling Risks

• repair theater
• burden export
• affected-node depletion
• hidden labor infrastructure
• proof-burden overload
• restoration debt
• repair backlog collapse
• authority/repair separation
• memory correction failure
• recurrence normalization
• legitimacy shock
• extraction regime
• crisis loop
• repair fatigue
• pseudo-recovery

Scaling Requirements

To scale repair coherently, systems need:

• repair labor tracking
• proof burden tracking
• affected-node validation
• resource allocation
• cause/authority/capacity maps
• repair-burden symmetry review
• recurrence tracking
• memory correction ownership
• acknowledgment ownership
• repair backlog visibility
• hidden labor detection
• restoration role clarity
• external audit triggers
• repair-complete criteria
• post-repair stress testing
• burden redistribution mechanisms

Scaling Rule

Repair burden must scale with cause-bearing authority, resource capacity, affected-node cost, and restoration need.

Sanity constraint:

repair_burden_on_affected_node ↑ + affected_node_cost ↑ ⇒ restoration legitimacy ↓

If affected nodes carry both harm and repair, restoration legitimacy declines.

Second constraint:

repair_burden_distribution misaligned with cause_layer ⇒ recurrence risk ↑

If repair burden is not assigned to the cause-bearing layer, recurrence remains likely.

Third constraint:

repair_claims ↑ + hidden_repair_labor ↑ ⇒ repair theater risk ↑

If repair claims grow while hidden labor grows, repair theater risk rises.

14) Interaction / Coupling Behavior

repair_burden_distribution reveals whether a relation, institution, AI system, archive, or interface can repair without exporting restoration labor to the wrong node.

What It Reveals About Coupling

• whether one node repeatedly repairs both sides
• whether cause-bearing node participates in repair
• whether affected node must prove, explain, and validate
• whether repair burden follows authority
• whether support becomes repair obligation
• whether recurrence tracking is one-sided
• whether trust repair is shared or externalized
• whether re-coupling is premature

What It Reveals About Boundary Integrity

Boundary repair requires correct burden distribution.

When repair burden is misassigned:

• boundary holder may have to prove boundary strain
• boundary breach may be repaired by the harmed node
• refusal may require repeated explanation
• BΣ repair may not land
• old breaches remain active in memory
• boundary repair becomes exhaustion rather than restoration

What It Reveals About Compatibility

Compatibility requires sustainable repair burden.

A coupling may be unsafe if:

one node causes damage and the other carries repair

or:

the relation remains stable only because one node continuously restores it

Healthy compatibility requires repair labor to be acknowledged, supported, and distributed according to cause, capacity, and authority.

Relevant Interface Acts

• ↺ Reflection: identify who is carrying repair
• ⇩ Relaxation: reduce pressure on overburdened repair node
• ⊘ Attenuation: reduce coupling while repair burden is redistributed
• ⊙ Alignment: take responsibility for one’s own repair obligations
• →? Invitation: invite shared repair without shifting burden
• ⚕︎ Restorative Override: requires explicit post-action repair burden allocation
• ✕ Force: usually exports repair burden and creates restoration debt

15) Failure Modes Detected

Primary Failure Modes

repair_burden_distribution detects or predicts:

• repair burden export
• affected-node proof burden
• repair theater
• hidden restoration labor
• authority/repair separation
• repair fatigue
• recurrence from misassigned repair
• boundary repair failure
• trust recovery failure
• memory correction burden
• lower-resource repair overload
• restoration debt
• extraction regime
• symbolic repair
• closure without burden redistribution
• cause-layer nonparticipation
• legitimacy loss

Composite Regimes Where repair_burden_distribution Matters

• Extraction Regime: repair cost is exported to affected or lower-resource nodes
• Repair Theater: visible repair claims hide burden displacement
• Crisis Loop: recurrence persists because repair burden is misassigned
• Coercive Fusion: one node must repair the coupling to remain connected
• Goodhart Collapse: repair metrics improve while real burden grows
• Pseudo-Coherent Basin: stability is maintained by hidden repair labor
• LOS: latent repair work sustains formal structure
• Mission Lock: repair burden is deferred to preserve trajectory
• Compression Collapse: repair burden compresses onto the nearest available node

16) Accountability & Reintegration Implications

If repair_burden_distribution Was Ignored

Likely consequences:

• harmed nodes carried restoration
• authority claimed repair without performing it
• repair fatigue accumulated
• hidden labor sustained the system
• recurrence persisted
• repair legitimacy declined
• memory credited the wrong nodes
• proof burden was externalized
• boundary repair failed
• trust did not recover
• lower-capacity nodes depleted

Accountability questions:

• Who caused the repair need?
• Who had authority to repair?
• Who actually repaired?
• Who paid repair cost?
• Who tracked recurrence?
• Who corrected memory?
• Who validated repair?
• Who benefited from repair?
• Who carried cost if repair failed?
• Was affected-node burden reduced or increased?
• Did repair burden match cause and capacity?
• Did official memory credit repair accurately?

If repair_burden_distribution Was Misread

Possible misread forms:

• voluntary repair support mistaken for burden export
• specialized repair role mistaken for exploitation
• affected-node participation mistaken for proof burden
• resource transfer mistaken for repair completion
• apology mistaken for burden redistribution
• authority approval mistaken for repair labor
• equal repair work mistaken for fairness
• unequal repair work mistaken for unfairness despite role/capacity fit
• hidden repair labor missed because closure metrics improved

Required Restoration

When repair_burden_distribution failure is found:

map actual repair labor
→ identify cause-bearing layer
→ identify authority/capacity mismatch
→ relieve affected-node proof and repair burden
→ resource origin-layer repair
→ correct repair narrative and memory
→ validate recurrence and affected-node recovery

If repair burden was asymmetric, MS-Gate should review cause, authority, capacity, harm, benefit, and consequence distribution.

17) Cross-Domain Examples

Technical / Engineering

A frontline team keeps patching symptoms caused by an upstream architecture decision they cannot change.

Diagnostic implication: repair burden is assigned below the cause-bearing layer.

Operator sequence: origin-layer audit → architecture ownership repair → resource frontline relief → U7 incident correction.

Institutional / Governance

A harmed group must repeatedly document, explain, appeal, and track the repair process while the institution claims reform.

Diagnostic implication: proof and repair burden remain on affected nodes.

Operator sequence: affected-node burden audit → repair resource transfer → policy correction → memory update → recurrence validation.

AI / Algorithmic

Users must repeatedly correct the same AI memory or classification error, while the system does not reduce future correction burden.

Diagnostic implication: repair burden is shifted onto the user.

Operator sequence: memory correction pathway → user burden reduction → HR/Au gate repair → U7 correction propagation.

Interaction / Relational

One person repeatedly names the pattern, tracks recurrence, initiates repair, and validates whether change occurred.

Diagnostic implication: relational repair burden is one-sided.

Operator sequence: ↺ repair-burden reflection → redistribute behavior change/tracking → boundary repair → Λ re-test.

Archive / Framework Design

A glossary drift is detected by readers, but no archive-maintenance process exists, so users must repeatedly interpret or correct terms themselves.

Diagnostic implication: archive repair burden is exported to readers.

Operator sequence: repair glossary ownership → cross-link update process → issue tracking → U7 version memory.

18) Test Protocols

1. Repair Task Map Test

What tasks are required for repair, and who performs each?

Failure signal: repair labor is invisible or concentrated in affected nodes.

2. Cause / Repair Alignment Test

Does the cause-bearing layer participate in repair?

Failure signal: symptoms are repaired below the origin layer.

3. Authority / Repair Alignment Test

Do those with authority carry repair responsibility?

Failure signal: nodes without authority must repair causes they cannot change.

4. Capacity Test

Does assigned repair burden match resource capacity?

Failure signal: lower-capacity nodes carry higher restoration load.

5. Proof Burden Test

Who must prove that repair is needed?

Failure signal: harmed nodes must repeatedly prove obvious or recurring harm.

6. Memory Correction Test

Who updates U7 memory?

Failure signal: misclassified or affected nodes must correct the record alone.

7. Recurrence Tracking Test

Who monitors whether repair holds?

Failure signal: affected nodes carry long-term recurrence tracking.

8. Validation Test

Who decides repair is complete?

Failure signal: authority declares closure without affected-node validation.

9. Benefit / Burden Test

Who benefits from repair, and who pays for it?

Failure signal: beneficiaries do not carry proportional repair cost.

10. Symmetry Test

Are comparable nodes expected to carry comparable repair burden?

Failure signal: repair burden follows rank, dependency, or visibility rather than cause/capacity.

19) Anti-Patterns

• Harmed node as repair engine
• Proof burden on affected node
• Authority claims closure, others repair
• Apology as burden transfer
• Acknowledgment as restoration
• Technical patch for governance failure
• Frontline repair of upstream cause
• Hidden labor as normal operation
• Repair tracking as affected-node duty
• Memory correction by misclassified node
• Equal burden despite unequal capacity
• Resource transfer as full repair
• Repair metrics without labor accounting
• Closure before burden redistribution
• Recurrence blamed on those still repairing
• Repair fatigue as resistance
• Cause layer absent from repair
• Benefit without burden
• Public reform, private repair burden
• Repair theater through visible process

20) Spec Validation Check

• Is this truly a diagnostic, not an operator? Yes.
• Does it measure state, capacity, risk, or response rather than act directly? Yes.
• Does it map to S? Yes.
• Are U-layers specified? Yes.
• Are leading and lagging indicators separated? Yes.
• Are interpretation risks defined? Yes.
• Are operator sequencing implications clear? Yes.
• Are gate implications clear? Yes.
• Are scaling risks included? Yes.
• Are interaction implications included? Yes.
• Does it avoid new primitives? Yes.

Condensed Archive Summary

repair_burden_distribution is the diagnostic estimate of how repair responsibility, labor, cost, time, proof burden, acknowledgment, memory correction, recurrence tracking, and restoration effort are distributed across nodes, roles, systems, or subfields. It does not require equal repair work; it requires coherent alignment between cause, authority, capacity, harm, benefit, and restoration obligation. Degraded repair burden distribution indicates risk of repair burden export, affected-node proof burden, hidden restoration labor, authority/repair separation, repair theater, recurrence, boundary repair failure, trust depletion, and legitimacy loss. Under degraded repair burden distribution, the system should pause closure, map actual repair labor, identify cause-bearing and authority-bearing layers, relieve affected-node burden, resource origin-layer repair, correct repair memory, and validate recurrence before repair-complete claims, re-coupling, scaling, or success narratives.