0. Registry Classification

1. Purpose

1.1 What This Arc Repairs

Circulation Repair repairs systems where value, resources, goods, services, information, repair access, returns, claims, payments, obligations, signals, or burden cannot move through the system at the right layer, direction, pace, or interface.

It applies when the system is not primarily failing because there is no resource, but because circulation is blocked, delayed, misrouted, one-way, poorly timed, unevenly distributed, or unable to clear.

This arc repairs circulation failure by:

• identifying the circulation layer that failed;
• repairing delivery;
• repairing return;
• repairing clearance;
• repairing exchange interfaces;
• repairing timing;
• restoring distributed repair access;
• improving throughput;
• reducing response latency;
• increasing distribution quality;
• preventing growth from amplifying bottlenecks;
• ensuring flows support repair rather than extraction, stasis, or backlog.

Circulation Repair is the canonical arc for restoring movement, return, clearance, and repair access in economic and cross-domain systems.

1.2 Core Restoration Function

This arc restores circulation by repairing delivery, return, clearance, exchange interfaces, timing, and distributed repair access so throughput improves without increasing hidden debt or burden displacement.

Circulation Repair prevents systems from mistaking accumulation for health.

2. Use Conditions

2.1 When to Apply

Use this arc when:

• goods, resources, money, information, decisions, repairs, claims, returns, or signals are stuck;
• delivery occurs but return, repair, appeal, or clearance fails;
• flows move one way and create backlog elsewhere;
• exchange interfaces are broken, costly, opaque, or exclusionary;
• timing mismatch creates waste, scarcity, delay, or instability;
• repair is centralized and inaccessible to distributed nodes;
• resources exist but cannot reach the right node;
• claims, refunds, maintenance, support, or appeals accumulate in queues;
• platforms, institutions, markets, or supply chains generate throughput in one layer while causing stasis in another;
• growth is being attempted before circulation and clearance are repaired.

Examples:

• a platform pays creators slowly while collecting revenue quickly;
• an institution receives claims but cannot process returns, appeals, or repair requests;
• a supply chain delivers goods but cannot handle returns, repair, reuse, or waste clearance;
• a governance system collects reports but cannot route them to action;
• an AI platform receives user feedback but cannot circulate it to evaluator, memory, or policy repair;
• an economy produces output while maintenance, repair, and clearance backlogs grow;
• a security team receives alerts faster than it can triage, remediate, or close loops.

2.2 When Not to Apply

Do not apply this arc when:

• the issue is hidden economic structure and RA-061 must occur first;
• the issue is unresolved burden requiring RA-063 before circulation can resume;
• the issue is survival-edge slack collapse requiring RA-062 first;
• the problem is invalid coupling and recoupling should not occur;
• circulation increase would amplify extraction, harm, or externality export;
• the system needs to slow down, not increase throughput;
• delivery is intentionally blocked for safety, consent, legal, or boundary reasons;
• repair access would expose protected nodes or violate boundaries;
• circulation repair is being used to justify growth before hidden debt is cleared.

Circulation Repair must not become throughput theater.

2.3 Required Preconditions

Before this arc begins, the following must be true:

If required preconditions fail:

Arc cannot validly begin.

The system must route to Economic Legibility, Observability Restoration, Economic Clearance, Economic Slack Regeneration, Responsibility Gradient Mapping, Consent-Valid Economic Recoupling, or Governance-Level Restoration.

3. Failure / Damage Signature

3.1 Pre-State Across S

3.2 Primary Failure Links

3.3 Origin-Layer Localization

Canon rule:

Circulation is not restored by increasing outbound throughput while return, clearance, repair, or timing remains broken.

4. Restoration Objective

4.1 Canonical Objective

Restore circulation by repairing delivery, return, clearance, exchange interfaces, timing, and distributed repair access.

Formal objective:

throughput ↑
clearance ↑
τ_resp ↓
𝓓 ↑
delivery_integrity ↑
return_integrity ↑
exchange_interface_integrity ↑
timing_alignment ↑
repair_access_distribution ↑
circulation_blockage ↓
H ↓
Φ/O divergence ↓

Expanded objective:

Convert stuck or one-way flow into healthy circulation with delivery, return, clearance, timing, and distributed repair pathways.

4.2 Non-Goals

This arc does not aim to:

• maximize throughput at all costs;
• increase circulation through invalid or harmful couplings;
• clear queues by denial or deletion;
• accelerate delivery while return and clearance remain broken;
• treat output as circulation;
• force flow through nodes that need rest, slack, repair, or protection;
• make repair access dependent on excessive surveillance;
• reduce latency by suppressing complexity;
• treat growth as proof of circulation health;
• route burden faster without reducing it.

5. Operator Sequence

5.1 Minimal Operator Scaffold

Au circulation layer / blockage trace → Π flow and repair-access boundary → Σ bidirectional circulation invariant → FI return / field / backlog feedback → Θ throughput-pressure damping → ℛ delivery / return / clearance / exchange / timing routing → Λ circulation-fit test → Τ throughput-clearance proof

Reference sequence from the registry:

identify circulation layer failure
→ repair delivery
→ repair return
→ repair clearance
→ repair exchange interfaces
→ repair timing
→ restore distributed repair

Universal grammar alignment:

Au + Π → Σ → FI → Θ → ℛ → Λ → Τ

Circulation Repair may route into Economic Legibility, Economic Clearance, Economic Slack Regeneration, Consent-Valid Economic Recoupling, Repair-First Growth, Circulation Clearance Restoration, Timing Window Repair, or Governance-Level Restoration.

5.2 Operator Step Table

5.3 Sequence Notes

This arc is flow-gated, return-gated, clearance-gated, timing-gated, and repair-access-gated.

The sequence must distinguish:

delivery
return
clearance
exchange
timing
throughput
distribution
repair access
circulation
growth

The following steps cannot be skipped:

circulation layer identification
blockage mapping
delivery repair
return repair
clearance repair
exchange interface repair
timing alignment
distributed repair access
temporal proof

If delivery improves while return and clearance remain blocked, the arc is incomplete.

If queues shrink by denying unresolved claims, the arc fails.

If repair is available only at central nodes while distributed nodes remain unable to access it, circulation is still weak.

6. Restoration Phases

Phase 0 — Identify Circulation Layer Failure

Purpose: Name where circulation broke.

Actions:

• identify what is supposed to move;
• identify source, destination, intermediary, and affected nodes;
• identify whether failure is delivery, return, clearance, exchange, timing, repair access, or distribution;
• identify where backlog, waste, delay, stasis, or dead inventory accumulates;
• identify whether throughput is one-way.

Validation:

circulation layer failure named
blockage visible
return / clearance status known

Phase 1 — Repair Delivery

Purpose: Ensure needed flows reach the right place.

Actions:

• repair access path;
• repair logistics path;
• repair payment path;
• repair information path;
• repair service path;
• repair claim routing;
• repair eligibility and routing errors;
• ensure delivery does not bypass boundary or consent.

Validation:

delivery_integrity ↑
throughput ↑ where appropriate
misdelivery ↓

Phase 2 — Repair Return

Purpose: Restore bidirectionality.

Actions:

• create or repair return channels;
• repair refunds, appeals, feedback, exchange, reuse, repair, support, and reversal pathways;
• ensure return signal reaches decision and repair layers;
• distinguish valid return from abuse or unsafe reversal;
• reduce friction that traps burden downstream.

Validation:

return_integrity ↑
FI ↑
one-way flow ↓

Phase 3 — Repair Clearance

Purpose: Process accumulated load.

Actions:

• identify backlog;
• identify waste;
• identify unresolved claims;
• identify delayed maintenance;
• identify dead inventory or stuck obligations;
• process, route, retire, repair, compensate, or internalize load;
• avoid denial-as-clearance.

Validation:

clearance ↑
backlog_load ↓
H ↓

Phase 4 — Repair Exchange Interfaces

Purpose: Improve the interfaces where value, goods, information, obligations, repair, or return cross boundaries.

Actions:

• repair pricing, payment, claim, appeal, delivery, return, intake, support, and review interfaces;
• reduce friction where it blocks valid flow;
• add friction where boundary or safety requires it;
• improve interoperability;
• clarify roles and obligations;
• protect vulnerable nodes from extraction at the interface.

Validation:

exchange_interface_integrity ↑
BΣ stable or ↑
transaction failure ↓

Phase 5 — Repair Timing

Purpose: Align flow with capacity and repair windows.

Actions:

• identify timing mismatch;
• reduce response latency;
• repair payout timing;
• repair delivery timing;
• repair review timing;
• repair replenishment and maintenance windows;
• sequence clearance before growth;
• prevent urgency from overwhelming repair capacity.

Validation:

timing_alignment ↑
τ_resp ↓
overload risk ↓

Phase 6 — Restore Distributed Repair

Purpose: Ensure repair reaches where failures occur.

Actions:

• distribute repair access;
• localize support where appropriate;
• decentralize triage where safe;
• create escalation paths;
• provide repair capacity to affected nodes;
• ensure feedback loops return to governance and allocation;
• avoid central bottleneck dependence.

Validation:

repair_access_distribution ↑
R ↑
distributed resilience ↑

Phase 7 — Temporal Circulation Proof

Purpose: Confirm circulation remains healthy under real conditions.

Actions:

• monitor throughput;
• monitor clearance;
• monitor response latency;
• monitor backlog recurrence;
• monitor delivery and return quality;
• monitor exchange interface failures;
• monitor distributed repair access;
• monitor hidden debt produced by faster flow.

Validation:

throughput ↑ where appropriate
clearance ↑
τ_resp ↓
𝓓 ↑
circulation_blockage ↓
recurrence ↓

7. Gates

7.1 Required Gates

7.2 Gate Failure Rule

If any required gate fails:

∅ — Circulation Repair cannot validly proceed in that form.

The system must either:

• map hidden blockage;
• repair delivery;
• restore return;
• clear backlog;
• repair exchange interfaces;
• align timing;
• distribute repair access;
• reduce throughput until clearance catches up;
• route to economic clearance, slack regeneration, consent-valid recoupling, timing window repair, or governance-level restoration;
• withhold growth claims until circulation is proven.

8. Diagnostics

8.1 Required Diagnostic Trends

8.2 Arc-Specific Diagnostic Thresholds

Suggested thresholds:

throughput ↑
clearance ↑
τ_resp ↓
𝓓 ↑
delivery_integrity ↑
return_integrity ↑
exchange_interface_integrity ↑
timing_alignment ↑
repair_access_distribution ↑
circulation_blockage ↓
H ↓
Φ/O divergence ↓

Circulation Repair is not complete if:

delivery improves but return remains broken
throughput rises while clearance falls
queues shrink through denial rather than resolution
timing mismatch continues
repair access remains centralized and inaccessible
exchange interfaces remain opaque or exclusionary
backlog regenerates immediately
flow improvement increases hidden debt
growth is resumed before circulation stabilizes

9. Anti-Patterns / False Restorations

9.1 Common False Versions

This arc is being simulated, not executed, if:

• outbound throughput rises while return paths remain blocked;
• queue closure is counted as repair;
• delivery volume replaces circulation health;
• returns are discouraged through friction;
• repair is available only to high-status nodes;
• backlog is moved to another department or queue;
• timing failures are renamed as user delay;
• exchange interfaces improve for profitable flows but not repair flows;
• faster flow increases hidden debt;
• growth resumes before clearance and repair access stabilize.

9.2 Named Anti-Pattern Links

10. Completion Criteria

10.1 Post-State Signature

10.2 Temporal Proof

Circulation Repair cannot be certified by one throughput improvement. It requires persistent alignment between throughput, return, clearance, timing, and distributed repair.

Template:

Completion requires throughput ↑,
clearance ↑,
τ_resp ↓,
𝓓 ↑,
delivery_integrity ↑,
return_integrity ↑,
exchange_interface_integrity ↑,
timing_alignment ↑,
repair_access_distribution ↑,
circulation_blockage ↓,
H ↓,
and recurrence of bottlenecks decreasing across U7.

Minimum temporal proof:

• delivery reaches intended nodes;
• return and appeal paths are usable;
• backlog and waste decrease;
• clearance rises with throughput;
• timing matches capacity;
• repair access is distributed enough to reach affected nodes;
• faster flow does not increase hidden debt;
• circulation remains stable under perturbation.

10.3 Completion Statement

Canonical format:

This arc is complete only when delivery, return, clearance, exchange interfaces, timing, and distributed repair access are functioning together, with throughput and clearance rising, response latency falling, hidden debt decreasing, and circulation blockage recurring less over time.

11. Cross-Links

11.1 Related Restoration Arcs

11.2 Related Failure Modes

11.3 Related Diagnostics

Au, H, O, BΣ, K, R, FI, 𝓓, τ_resp, throughput, clearance, delivery_integrity, return_integrity, exchange_interface_integrity, timing_alignment, repair_access_distribution, circulation_blockage, Φ/O divergence

11.4 Related Laws / Invariants

INV — Throughput without clearance is not circulation.
INV — Delivery without return creates hidden debt.
INV — Repair access must circulate to affected nodes.
INV — Timing is part of flow integrity.
LAW — One-way flow accumulates backlog.
LAW — Queue closure is not repair unless burden decreases.
LAW — Growth before circulation repair amplifies blockage.
LAW — Φ output volume is not O restoration.

12. Domain Notes

12.1 Economy

Check:

• delivery;
• payment flow;
• return flow;
• refund flow;
• exchange interfaces;
• inventory;
• backlog;
• maintenance;
• repair access;
• timing;
• clearance.

Economic circulation is healthy only when outbound delivery, return, repair, and clearance all work together.

12.2 Platform Governance

Check:

• payout timing;
• creator support;
• appeal queues;
• refund systems;
• moderation review;
• account recovery;
• user reports;
• policy feedback;
• escalation paths.

Platforms often show strong delivery or engagement while return and repair paths are weak. Circulation repair must include appeals, refunds, support, and governance feedback.

12.3 AI / Cognitive Infrastructure

Check:

• user feedback routing;
• evaluator updates;
• memory correction;
• appeal handling;
• incident reports;
• tool rollback;
• model update feedback;
• support channels;
• policy correction loops.

AI systems fail circulation when user signal enters the system but cannot return to memory, evaluator, policy, boundary, or governance repair.

12.4 Security

Check:

• alert triage;
• incident response;
• patch flow;
• remediation backlog;
• vulnerability reporting;
• return of findings to engineering;
• detection-rule updates;
• response latency;
• maintenance windows.

Security circulation fails when alerts, reports, incidents, and vulnerabilities enter faster than they can be triaged, remediated, cleared, and learned from.

12.5 Justice / Governance / Legitimacy

Check:

• claim intake;
• appeal route;
• decision return;
• repair access;
• compensation flow;
• review timing;
• backlog transparency;
• escalation.

Governance legitimacy requires that reports, claims, appeals, and remedies circulate rather than accumulate in opaque queues.

12.6 CMS / Meaning / Archetypes

Check:

• giving and return;
• recognition flow;
• repair access;
• apology and response;
• communal backlog;
• unresolved obligations;
• timing of repair;
• distributed capacity.

Meaning systems require circulation when recognition, care, repair, and return are blocked or made one-way.

13. Machine-Readable Metadata

id: "RA-066"
title: "Circulation Repair"
aliases:
  - "Circulation Repair"
family_primary: "Economy / Circulation / Throughput"
families_secondary:
  - "Core"
  - "Economy"
  - "Governance"
  - "Coherence"
  - "Distribution"
  - "Clearance"
  - "Timing"
  - "Exchange"
  - "Boundary"
  - "Dependency"
  - "Restoration Capacity"
  - "Institutional Design"
  - "Scaling"
treatment: "Canon Parent Arc"
status: "Canon-Ready"
scope:
  - "Economic"
  - "Institutional"
  - "Platform"
  - "Governance"
  - "Community"
  - "Civilizational"
  - "AI"
  - "Security"
  - "Cross-Domain"
u_layers:
  failure_origin:
    - "often U2 interface / delivery / return boundary"
    - "often U3 allocation / logistics / platform governance"
    - "often U5 timing / backlog / clearance layer"
  symptom_visible:
    - "U4 delayed payment / stuck queue / support backlog / delivery failure / return failure / appeal delay / waste accumulation / unavailable repair"
  repair_required:
    - "same or lower than the layer where delivery, return, clearance, exchange, or timing failed"
  validation:
    - "U6"
    - "U7"
operators:
  scaffold: "Au circulation layer / blockage trace → Π flow and repair-access boundary → Σ bidirectional circulation invariant → FI return / field / backlog feedback → Θ throughput-pressure damping → ℛ delivery / return / clearance / exchange / timing routing → Λ circulation-fit test → Τ throughput-clearance proof"
  sequence:
    - "Au"
    - "Π"
    - "Σ"
    - "FI"
    - "Θ"
    - "ℛ"
    - "Λ"
    - "Τ"
state_variables:
  primary:
    - "Au"
    - "H"
    - "O"
    - "BΣ"
    - "K"
    - "R"
    - "FI"
  secondary:
    - "𝓓"
    - "τ_resp"
    - "Φ"
diagnostics:
  - "throughput"
  - "clearance"
  - "delivery_integrity"
  - "return_integrity"
  - "exchange_interface_integrity"
  - "timing_alignment"
  - "repair_access_distribution"
  - "circulation_blockage"
  - "Φ/O divergence"
gates_required:
  - "FI-Gate"
  - "HR-Gate"
  - "MS-Gate"
  - "Au-Actuation"
  - "BΣ-Gate"
  - "Λ-Gate"
  - "☷ᵢ"
linked_failure_modes:
  - "Delivery Failure"
  - "Return Failure"
  - "Clearance Failure"
  - "Exchange Interface Failure"
  - "Timing Failure"
  - "Repair-Access Failure"
  - "Circulation Bottleneck"
  - "Stuck Flow"
  - "Dead Inventory"
  - "Backlog Accumulation"
  - "Queue Collapse"
  - "Distributed Repair Failure"
  - "Latency Accumulation"
  - "Economic Stasis"
  - "Throughput Theater"
linked_restoration_arcs:
  - "RA-004"
  - "RA-006"
  - "RA-012"
  - "RA-014"
  - "RA-025"
  - "RA-026"
  - "RA-040"
  - "RA-046"
  - "RA-054"
  - "RA-061"
  - "RA-062"
  - "RA-063"
  - "RA-064"
  - "RA-065"
  - "RA-067"
  - "RA-071"
  - "RA-072"
anti_patterns:
  - "Throughput Theater"
  - "One-Way Flow"
  - "Queue Closure Theater"
  - "Return Friction"
  - "Central Repair Bottleneck"
  - "Backlog Relocation"
  - "Timing Denial"
  - "Profitable Interface Bias"
  - "Growth Before Clearance"
completion_tests:
  - "throughput increases"
  - "clearance increases"
  - "response latency decreases"
  - "distribution / damping capacity increases"
  - "delivery integrity increases"
  - "return integrity increases"
  - "exchange interface integrity increases"
  - "timing alignment increases"
  - "repair access distribution increases"
  - "circulation blockage decreases"
  - "hidden debt decreases"
  - "Φ/O divergence decreases"
summary: "Circulation Repair restores economic, institutional, platform, and cross-domain circulation by identifying circulation-layer failure, repairing delivery, return, clearance, exchange interfaces, timing, and distributed repair pathways so throughput, clearance, response latency, and distribution improve."

Final Calibration Rule

Circulation Repair answers six questions:

What flow, return path, clearance path, exchange interface, timing window, or repair access pathway is blocked?
Where are backlog, waste, latency, dead load, or stuck obligations accumulating?
What delivery, return, clearance, exchange, and timing repairs restore bidirectional circulation?
How does repair access reach distributed affected nodes instead of remaining centralized?
How does throughput rise without increasing hidden debt?
How is circulation proven over time without throughput theater, one-way flow, queue closure theater, or growth before clearance?