0. Registry Classification

1. Purpose

1.1 What This Arc Repairs

Basin-Aware Security Restoration repairs security systems that repeatedly fail because they treat incidents, attackers, users, vulnerabilities, institutions, tools, incentives, or field conditions as isolated events rather than attractor-bound patterns.

It applies when security interventions address symptoms while the basin that keeps producing the failure remains intact.

This arc repairs basin-blind security by:

• mapping the attractor basin that regenerates the security failure;
• identifying incentives, affordances, dependencies, and recurrence geometry;
• distinguishing incident response from basin repair;
• restoring observability across field, attacker, user, interface, and institutional conditions;
• reducing the basin pull toward repeated compromise or harmful control;
• correcting feedback loops that strengthen the failure attractor;
• repairing security posture at the structural layer that sustains recurrence;
• validating that the same threat, control failure, or exposure pattern does not regenerate over time.

Basin-Aware Security Restoration is the canonical arc for repairing security failures that recur because the surrounding geometry keeps making them likely.

1.2 Core Restoration Function

This arc restores security by shifting from incident-only response to basin-aware repair: mapping the attractor geometry, reducing recurrence forces, repairing feedback and boundary pathways, and validating that the failure basin loses pull over time.

Basin-Aware Security Restoration prevents systems from treating repeated security failures as separate anomalies.

2. Use Conditions

2.1 When to Apply

Use this arc when:

• the same security failure type keeps recurring;
• incident response succeeds locally but recurrence persists;
• controls reduce one attack path while the attractor produces another;
• users, attackers, or systems are repeatedly pulled into the same unsafe pattern;
• incentives reward insecure behavior or security theater;
• emergency controls become normalized because the basin is never repaired;
• AI classifiers, policies, or evaluators repeatedly misclassify because field geometry is unchanged;
• platform or institutional design keeps regenerating exposure;
• security posture improves visibly while the deeper attractor remains active;
• the system needs to change the conditions that make failure likely, not only respond to the failure.

Examples:

• phishing training repeats while workflow pressure and interface design keep producing credential exposure;
• AI safety policies patch outputs while the evaluator basin keeps rewarding over-compression or false refusal;
• a security team fixes incidents while incentives keep expanding attack surface;
• a platform blocks abuse patterns while recommendation, engagement, or monetization basins regenerate them;
• an institution disciplines individuals while process geometry keeps producing the same failure;
• an economy adds fraud controls while scarcity and dependency continue generating exploitability.

2.2 When Not to Apply

Do not apply this arc when:

• active harm is still cascading and emergency stabilization must occur first;
• the issue is a one-off incident with no recurrence or attractor evidence;
• observability is too low to map basin geometry;
• boundary containment is urgently needed before basin analysis;
• basin language is being used to avoid immediate remediation;
• the system refuses to alter incentives, affordances, or structural conditions;
• the correct move is full supersession because the basin cannot be safely repaired;
• basin mapping would expose affected nodes or sensitive security posture without protection.

Basin-Aware Security Restoration must not become analysis paralysis or basin-label 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 return to emergency stabilization, observability restoration, audit surface expansion, boundary reconstitution, or stability / damping restoration.

3. Failure / Damage Signature

3.1 Pre-State Across S

3.2 Primary Failure Links

3.3 Origin-Layer Localization

Canon rule:

Security restoration is incomplete when the basin that regenerates the failure remains intact.

4. Restoration Objective

4.1 Canonical Objective

Restore security by mapping the basin geometry that regenerates failure, reducing attractor pull, repairing boundary and feedback loops, and validating recurrence reduction across time.

Formal objective:

basin geometry visible
basin_pull ↓
basin_depth ↓ where harmful
recurrence ↓
attack_surface ↓ or bounded
FI_security ↑
BΣ ↑
H_security ↓
R_structural ↑
Φ/O divergence ↓

Expanded objective:

Convert recurring incident repair into structural security restoration by changing the conditions that make the failure likely.

4.2 Non-Goals

This arc does not aim to:

• replace urgent containment;
• analyze forever without repair;
• blame users for basin-generated behavior;
• treat every incident as evidence of a basin;
• remove all friction regardless of security need;
• preserve insecure incentives while adding training;
• optimize posture scores without reducing recurrence;
• treat basin language as proof of sophistication;
• ignore adversarial adaptation;
• claim success after one quiet interval.

5. Operator Sequence

5.1 Minimal Operator Scaffold

Μ basin / recurrence map → Au incident-to-basin trace → Π boundary / exposure containment → FI recurrence feedback repair → Θ attractor-gain reduction → Λ control-fit test → ℛ basin repair → Σ anti-recurrence lock → Τ basin-pull validation

Universal grammar alignment:

Σ + Θ → Π → Au↑ → FI↑ → ℛ(basin force layer) → Τ → Temporal Proof

Basin-Aware Security Restoration may route into Basin Geometry Mapping, Basin Shallowing, Attractor Weakening, Parallel Attractor Seeding, Observability Restoration, or Security Theater Correction.

5.2 Operator Step Table

5.3 Sequence Notes

This arc is recurrence-gated and basin-gated.

Security posture is not restored simply because an incident is closed. If the basin remains, recurrence is expected.

The sequence must distinguish:

incident
pattern
recurrence
basin
attractor
structural repair
posture theater

The following steps cannot be skipped:

recurrence mapping
incident-to-basin trace
active exposure containment
feedback repair
attractor-gain reduction
structural repair
temporal validation

If security control treats the symptom but strengthens the basin, the arc has inverted.

If recurrence returns under a new label, the arc is incomplete.

6. Restoration Phases

Phase 0 — Identify Recurrence Pattern

Purpose: Determine whether repeated failure indicates basin geometry.

Actions:

• identify repeated incidents;
• identify near-misses;
• identify recurring bypass paths;
• identify repeated user behavior shaped by system design;
• identify repeated attacker adaptation;
• identify repeated policy failure;
• identify repeated burden export.

Validation:

recurrence pattern visible
incident-only framing insufficient
candidate basin suspected

Phase 1 — Map Basin Forces

Purpose: Identify what makes the security failure likely.

Actions:

• map incentives;
• map affordances;
• map workload and capacity;
• map interface design;
• map access paths;
• map attacker rewards;
• map institutional incentives;
• map policy feedback and enforcement loops;
• map economic or social pressures.

Validation:

basin geometry visible
basin_pull factors named
structural recurrence path traceable

Phase 2 — Contain Active Exposure

Purpose: Prevent basin analysis from delaying immediate protection.

Actions:

• bound active attack surface;
• repair obvious boundary leaks;
• reduce privileged access drift;
• isolate repeated exploit pathways;
• preserve evidence;
• prevent emergency controls from becoming permanent without review.

Validation:

attack_surface bounded
BΣ stable or ↑
containment does not replace basin repair

Phase 3 — Restore Recurrence Feedback

Purpose: Make basin pull measurable.

Actions:

• track recurrence by geometry, not just label;
• track near-misses;
• track bypass attempts;
• track field harm;
• track user burden and operator burden;
• track attacker adaptation;
• track whether controls displace or reduce risk.

Validation:

FI_security ↑
recurrence observable across variants
security metrics no longer label-bound

Phase 4 — Reduce Attractor Gain

Purpose: Make the harmful basin less attractive or less easy to fall into.

Actions:

• reduce convenience of insecure path;
• reduce reward for exploit or abuse;
• reduce pressure that causes risky behavior;
• reduce control loopholes;
• reduce dependency on brittle human vigilance;
• reduce institutional incentive to preserve theater;
• reduce urgency that causes bypass.

Validation:

basin_pull ↓
exploitability ↓
unsafe path less attractive or less available

Phase 5 — Repair Structural Security Geometry

Purpose: Change the system conditions that regenerate failure.

Actions:

• redesign access paths;
• repair interface geometry;
• revise policy;
• adjust incentives;
• strengthen real boundaries;
• repair classifier or evaluator logic;
• redesign workflow;
• route hidden debt into repair;
• remove controls that reinforce the basin.

Validation:

R_structural ↑
H_security ↓
failure no longer generated by same geometry

Phase 6 — Seed Safer Attractor

Purpose: Provide a better default path.

Actions:

• make secure path easier than insecure path;
• create safe defaults;
• create lower-burden reporting;
• create reversible and appealable controls;
• support operator and user capacity;
• align incentives with security function;
• build alternative basin where secure behavior is natural.

Validation:

safe attractor visible
secure behavior becomes lower-friction
old basin pull decreases

Phase 7 — Temporal Proof

Purpose: Confirm basin repair holds over time.

Actions:

• monitor recurrence;
• monitor variants;
• monitor attack surface;
• monitor user burden;
• monitor false assurance;
• monitor basin pull indicators;
• validate that safer attractor remains preferred.

Validation:

recurrence ↓
basin_pull(t+n) ≤ basin_pull(t)
attack_surface bounded
Φ/O divergence ↓

7. Gates

7.1 Required Gates

7.2 Gate Failure Rule

If any required gate fails:

∅ — Basin-Aware Security Restoration cannot validly proceed in that form.

The system must either:

• restore observability;
• expand auditability;
• contain active exposure;
• repair feedback;
• reduce theater;
• reroute to basin mapping;
• withdraw incident-closure claims.

8. Diagnostics

8.1 Required Diagnostic Trends

8.2 Arc-Specific Diagnostic Thresholds

Suggested thresholds:

basin geometry visible
basin_pull ↓
recurrence ↓ across variants
attack_surface ↓ or bounded
FI_security ↑
Au_basin ↑
BΣ stable or ↑
H_security ↓
R_structural ↑
Φ/O divergence ↓

Basin-Aware Security Restoration is not complete if:

incidents close but recurrence persists
security metrics remain label-bound
basin forces remain unaltered
controls displace risk rather than reduce it
users remain blamed for basin-generated behavior
attack surface drifts back open
same failure returns under new variant

9. Anti-Patterns / False Restorations

9.1 Common False Versions

This arc is being simulated, not executed, if:

• each incident is treated as isolated despite recurrence;
• users or operators are blamed for predictable basin behavior;
• controls harden the same attractor they claim to fix;
• metrics track labels rather than recurrence geometry;
• training is used instead of incentive or interface repair;
• attack surface shifts but does not shrink;
• compliance increases while exploitability remains;
• basin mapping is performed but no structural changes occur;
• the system adds emergency controls rather than changing the basin;
• recurrence is renamed as a new incident class.

9.2 Named Anti-Pattern Links

10. Completion Criteria

10.1 Post-State Signature

10.2 Temporal Proof

Basin-Aware Security Restoration cannot be declared complete until recurrence and basin pull decline over time.

Template:

Completion requires basin_pull(t+n) ≤ basin_pull(t),
recurrence decreasing across variants,
BΣ(t+n) ≥ BΣ(t),
H_security(t+n) ≤ H_security(t),
and Φ/O divergence decreasing across U7.

Minimum temporal proof:

• same security failure does not recur under simple variants;
• attack surface remains bounded;
• secure path remains lower-friction or better supported;
• hidden debt does not re-accumulate through incident churn;
• field feedback continues to detect basin pull;
• posture metrics remain subordinate to recurrence proof.

10.3 Completion Statement

Canonical format:

This arc is complete only when the basin that regenerated the security failure has lost pull, recurrence decreases across variants, boundary integrity is stronger, hidden debt is lower, and security posture is validated by field proof rather than incident closure alone.

11. Cross-Links

11.1 Related Restoration Arcs

11.2 Related Failure Modes

11.3 Related Diagnostics

basin_depth, basin_pull, recurrence, τ_m, H, Au, FI, BΣ, O, R, K, σ(t), attack_surface, Φ/O divergence, field proof

11.4 Related Laws / Invariants

INV — Recurrence indicates unresolved geometry until proven otherwise.
INV — Security restoration must reduce basin pull, not only close incidents.
INV — Controls must not strengthen the basin they claim to repair.
INV — Fitness proxy is not coherence.
LAW — Incident closure without basin repair produces recurrence.
LAW — Adversarial systems adapt to unchanged affordance geometry.
LAW — Security theater thrives when posture metrics replace field proof.
LAW — Φ improvement is not O restoration.

12. Domain Notes

12.1 AI / Cognitive Infrastructure

Check:

• evaluator basins;
• refusal / over-compliance recurrence;
• classifier reward geometry;
• policy overfitting;
• benchmark basin effects;
• user interaction patterns created by interface design;
• adversarial prompt basins;
• hidden model incentives;
• moderation recurrence across variants.

AI basin-aware security restoration repairs the conditions that make the same model, evaluator, policy, or interface failure recur across prompt variants and deployment contexts.

12.2 Justice / Governance / Legitimacy

Check:

• recurring complaints;
• grievance basin;
• institutional incentive to suppress signal;
• process geometry that regenerates harm;
• repeated scapegoating;
• legitimacy-preserving incident closure;
• reform cycles that return to the same basin.

JGL basin-aware security restoration changes the conditions that repeatedly generate institutional harm rather than closing each case as isolated.

12.3 Biology / Medicine

Conceptual systems mapping only.

Basin-Aware Security Restoration in biological or medical-adjacent systems means identifying recurrence-supporting conditions, exposure patterns, timing windows, capacity limits, or feedback loops that keep pulling the system toward the same instability.

Not diagnosis.

Not treatment.

Not medical advice.

12.4 Economy

Check:

• recurring fraud patterns;
• debt traps;
• exploitative default paths;
• survival-edge participation;
• platform incentive basins;
• compliance burden that favors larger actors;
• externality patterns that return after each fix.

Economic basin-aware security restoration repairs the incentive and access geometry that repeatedly produces exploitation or exposure.

12.5 CMS / Meaning / Archetypes

Check:

• recurring taboo cycles;
• repeated scapegoat basin;
• symbolic security theater;
• group identity pull toward suppression;
• repeated “purity” or “threat” framing;
• archetypal capture that regenerates the same conflict.

Meaning systems require basin-aware security restoration when protective narratives repeatedly recreate the threat pattern they claim to contain.

13. Machine-Readable Metadata

id: "RA-031"
title: "Basin-Aware Security Restoration"
aliases:
  - "Basin Security Repair"
family_primary: "Security"
families_secondary:
  - "Core"
  - "Basin"
  - "Cybernetics"
  - "Scaling"
  - "Auditability"
  - "AI Governance"
  - "Justice / Governance / Legitimacy"
  - "Economy"
  - "Institutional Design"
treatment: "Specialized Grammar"
status: "Canon-Ready"
scope:
  - "Local"
  - "Institutional"
  - "AI"
  - "Security"
  - "Economic"
  - "Civilizational"
  - "Cross-Domain"
u_layers:
  failure_origin:
    - "often U1 capacity / incentive / workload"
    - "often U2 boundary / access / interface"
    - "often U3 control / security architecture"
    - "often U4 security narrative / policy"
  symptom_visible:
    - "U6 recurring field incidents"
    - "U4 incident narratives"
    - "Φ closure / compliance / posture metrics"
  repair_required:
    - "same or lower than basin force generating recurrence"
  validation:
    - "U5"
    - "U6"
    - "U7"
operators:
  scaffold: "Μ basin / recurrence map → Au incident-to-basin trace → Π boundary / exposure containment → FI recurrence feedback repair → Θ attractor-gain reduction → Λ control-fit test → ℛ basin repair → Σ anti-recurrence lock → Τ basin-pull validation"
  sequence:
    - "Μ"
    - "Au"
    - "Π"
    - "FI"
    - "Θ"
    - "Λ"
    - "ℛ"
    - "Σ"
    - "Τ"
state_variables:
  primary:
    - "H"
    - "Au"
    - "FI"
    - "BΣ"
    - "O"
    - "R"
  secondary:
    - "K"
    - "Φ"
diagnostics:
  - "basin_depth"
  - "basin_pull"
  - "recurrence"
  - "τ_m"
  - "attack_surface"
  - "σ(t)"
  - "Φ/O divergence"
  - "field proof"
gates_required:
  - "FI-Gate"
  - "HR-Gate"
  - "MS-Gate"
  - "Au-Actuation"
  - "BΣ-Gate"
  - "Λ-Gate"
  - "☷ᵢ"
linked_failure_modes:
  - "Basin-Blind Security"
  - "Incident-Only Security"
  - "Attractor Reinforcement"
  - "Threat Recurrence"
  - "Attack Surface Drift"
  - "Security Theater"
  - "Policy Overfitting"
  - "False Assurance"
  - "Adversarial Adaptation"
  - "Emergency Normalization"
  - "Restoration Bypass"
  - "Recurrence Renaming"
linked_restoration_arcs:
  - "RA-008"
  - "RA-012"
  - "RA-014"
  - "RA-017"
  - "RA-025"
  - "RA-026"
  - "RA-028"
  - "RA-029"
  - "RA-058"
  - "RA-075"
  - "RA-076"
  - "RA-077"
  - "RA-078"
anti_patterns:
  - "Incident-Only Repair"
  - "Basin-Label Theater"
  - "User-Blame Basin Preservation"
  - "Control-as-Attractor"
  - "Recurrence Renaming"
  - "Training-as-Substitute"
  - "Variant Whack-a-Mole"
completion_tests:
  - "basin geometry visible"
  - "basin_pull decreases"
  - "recurrence decreases across variants"
  - "attack_surface decreases or becomes bounded"
  - "FI_security increases"
  - "Au_basin increases"
  - "BΣ stable or increases"
  - "H_security decreases"
  - "R_structural increases"
  - "Φ/O divergence decreases"
summary: "Basin-Aware Security Restoration repairs systems whose security posture fails because it treats incidents, controls, threats, users, attackers, or institutions as isolated events rather than attractor-bound patterns shaped by basin geometry, recurrence, incentives, and field conditions."

Final Calibration Rule

Basin-Aware Security Restoration answers six questions:

What hidden debt is being generated by incident-only or basin-blind security?
What boundary, incentive, interface, control, or attractor pathway must be repaired?
What auditability proves the incident pattern is traceable to basin geometry?
What posture metric, incident closure, training ritual, or control patch must remain provisional until recurrence reduction is proven?
What trajectory becomes viable once the harmful security basin loses pull?
How is restoration proven over time through lower basin pull, reduced recurrence, bounded attack surface, and stronger field proof?