0. Registry Classification

1. Purpose

1.1 What This Arc Repairs

Repair-First Intake repairs the first contact layer of a restoration, complaint, appeal, incident, grievance, harm report, support, mediation, safety, security, or accountability process.

It applies when intake systems classify, compress, extract, redirect, mediate, defend, or close cases before identifying what repair is actually needed.

This arc repairs intake failure by:

• centering harm, boundary, consent, safety, burden, and repair needs at first contact;
• preventing testimony extraction and procedural burden;
• preserving affected-node agency and refusal;
• distinguishing intake from investigation, mediation, reconciliation, or closure;
• restoring auditability around routing and classification;
• identifying immediate safety and boundary needs;
• routing responsibility and repair obligations early;
• preventing institutional legitimacy management from replacing repair;
• validating that intake improves repair alignment instead of producing procedural churn.

Repair-First Intake is the canonical arc for ensuring the first system response to harm is repair-oriented rather than process-oriented.

1.2 Core Restoration Function

This arc restores the intake layer by making first contact boundary-safe, consent-valid, auditably routed, and repair-oriented before classification, mediation, reconciliation, reputation management, or closure logic can dominate.

Repair-First Intake prevents the first act of restoration from becoming a second extraction.

2. Use Conditions

2.1 When to Apply

Use this arc when:

• people, users, affected nodes, operators, or witnesses report harm but the intake process converts the report into a narrow category before repair is identified;
• testimony is repeatedly requested without material change;
• intake forms are optimized for institutional routing rather than affected-node needs;
• support, complaint, safety, moderation, HR, governance, platform, or AI appeal systems create burden without repair;
• the first response prioritizes risk containment, reputation, legal defense, mediation, or classification;
• intake routes harmed nodes toward reconciliation or explanation before boundary and repair needs are protected;
• users cannot tell what happens after reporting;
• evidence submission increases exposure, burden, or retaliation risk;
• AI systems misclassify user reports, user intent, or harm context at the first step;
• intake becomes a dead end or legitimacy artifact.

Examples:

• a platform harm report becomes a generic support ticket without repair routing;
• an AI appeal process asks for repeated context while the classifier error persists;
• a workplace complaint intake routes immediately to mediation without safety or boundary review;
• a governance process asks affected people to summarize harm into a form that loses causality;
• a security incident intake captures logs but ignores affected-node burden;
• an institution creates a listening channel that cannot trigger repair obligations.

2.2 When Not to Apply

Do not apply this arc when:

• active harm is still cascading and emergency stabilization must occur first;
• intake is already repair-oriented and the issue lies in downstream governance;
• harm facts are too unclear and truth clarification must precede repair routing;
• the interface itself is illegitimate and must be repaired first;
• intake would expose affected nodes without consent or protection;
• the system refuses to act on intake outcomes;
• the correct move is immediate safe decoupling, boundary reconstitution, or emergency containment.

Repair-First Intake must not become intake 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, boundary reconstitution, observability restoration, interface re-legitimation, truth clarification, or victim-centered restoration.

3. Failure / Damage Signature

3.1 Pre-State Across S

3.2 Primary Failure Links

3.3 Origin-Layer Localization

Canon rule:

Intake is valid only when it preserves boundary, consent, truth, and repair routing before system classification or closure logic dominates.

4. Restoration Objective

4.1 Canonical Objective

Restore intake as a repair-oriented first-contact layer by protecting affected-node boundaries, preserving signal fidelity, increasing routing auditability, and connecting reports to actual repair obligations.

Formal objective:

BΣ_intake ↑
intake_fidelity ↑
routing_accuracy ↑
Au_intake ↑
burden_transfer ↓
repair_alignment ↑
H_intake ↓
R_repair-directed ↑
Φ/O divergence ↓
recurrence ↓

Expanded objective:

Convert intake from a procedural sorting surface into a boundary-safe, signal-preserving, repair-triggering interface between harm and restoration.

4.2 Non-Goals

This arc does not aim to:

• maximize report volume;
• increase form completion;
• convert testimony into institutional data;
• classify before repair need is understood;
• use intake to gather legitimacy evidence;
• force harmed nodes into process;
• replace repair with case management;
• make intake visually friendly while routing remains dead;
• require affected nodes to diagnose the system;
• treat closure time as restoration proof.

5. Operator Sequence

5.1 Minimal Operator Scaffold

Π intake boundary protection → Σ repair-first invariant → Au intake routing trace → FI affected-signal correction → Θ burden / urgency damping → Μ harm / repair need map → ℛ repair routing → Λ intake-fit test → Τ repair / recurrence validation

Universal grammar alignment:

Σ + Θ → Π → Au↑ → FI↑ → Μ map → ℛ(repair routing) → Λ → Τ → Temporal Proof

Repair-First Intake may route into Victim-Centered Restoration, Responsibility Gradient Mapping, Interface Re-Legitimation, Translation Layer Reset, AI Classifier / Evaluator Restoration, or Future-Compatible Accountability.

5.2 Operator Step Table

5.3 Sequence Notes

This arc is first-contact-gated, boundary-gated, and repair-gated.

Repair-First Intake is not “better intake” in an administrative sense. It is repair geometry at the point of first contact.

The sequence must distinguish:

intake
classification
triage
testimony
evidence
appeal
repair routing
case closure
legitimacy management

The following steps cannot be skipped:

intake surface identification
boundary and consent protection
routing trace
affected-signal correction
harm / repair need map
repair routing
temporal validation

If intake becomes smoother but repair alignment does not improve, the arc has failed.

If reporting creates additional burden without repair, the arc has inverted.

6. Restoration Phases

Phase 0 — Identify Intake Surface

Purpose: Name the first-contact pathway that must be repaired.

Actions:

• identify form, portal, report path, appeal path, support ticket, complaint channel, classifier, mediator, intake worker, or interface;
• identify what it claims to receive;
• identify what it actually routes;
• identify who controls it;
• identify who is affected by it.

Validation:

intake surface named
routing authority visible
affected nodes identified

Phase 1 — Protect Boundary and Consent

Purpose: Make first contact safe enough to be valid.

Actions:

• limit required disclosure;
• protect privacy;
• allow refusal and exit;
• avoid forced contact with responsible node;
• define evidence scope;
• make follow-up consent-valid;
• prevent repeated proof demands where avoidable.

Validation:

BΣ_intake ↑
participation consent-valid
unsafe exposure reduced

Phase 2 — Preserve Signal Fidelity

Purpose: Prevent the report from being flattened into the wrong category.

Actions:

• preserve affected-node wording where possible;
• separate observation from classification;
• mark uncertainty;
• identify boundary, safety, consent, and repair needs before case category;
• preserve context and timing;
• avoid premature mediation or reconciliation labels.

Validation:

intake_fidelity ↑
testimony compression ↓
repair needs visible before closure logic

Phase 3 — Trace Routing and Ownership

Purpose: Make the process accountable.

Actions:

• identify case owner;
• identify decision path;
• identify escalation path;
• identify repair path;
• identify appeal path;
• identify what happens if routing fails;
• identify how affected-node signal can correct the path.

Validation:

Au_intake ↑
routing path traceable
dead-end appeal risk ↓

Phase 4 — Map Repair Need Before Classification Closure

Purpose: Ensure repair is not lost to category.

Actions:

• identify immediate safety needs;
• identify boundary needs;
• identify consent needs;
• identify material repair needs;
• identify record correction needs;
• identify responsibility mapping needs;
• identify prevention needs.

Validation:

repair need map complete enough for routing
classification no longer dominates repair
R_repair-directed ↑

Phase 5 — Route to Repair / Protection / Escalation

Purpose: Convert intake into action.

Actions:

• route to emergency stabilization if acute;
• route to boundary repair;
• route to consent repair;
• route to responsibility mapping;
• route to compensation or correction;
• route to technical / policy repair;
• route to prevention and monitoring.

Validation:

repair_alignment ↑
routing_accuracy ↑
intake triggers action

Phase 6 — Reduce Intake Burden

Purpose: Prevent the process from extracting from affected nodes.

Actions:

• reduce repeated testimony;
• reduce redundant forms;
• reduce proof burden;
• reduce navigation burden;
• provide status visibility;
• provide support without requiring exposure;
• stop using reporting as legitimacy data unless consent-valid and repair-linked.

Validation:

burden_transfer ↓
K / σ ↑
H_intake ↓

Phase 7 — Temporal Proof

Purpose: Confirm intake improves restoration over time.

Actions:

• monitor routing accuracy;
• monitor repair completion;
• monitor repeated reports;
• monitor abandoned reports;
• monitor affected-node burden;
• monitor recurrence of intake capture.

Validation:

routing_accuracy(t+n) ≥ routing_accuracy(t)
repair_alignment(t+n) ≥ repair_alignment(t)
H_intake(t+n) ≤ H_intake(t)
recurrence ↓

7. Gates

7.1 Required Gates

7.2 Gate Failure Rule

If any required gate fails:

∅ — Repair-First Intake cannot validly proceed in that form.

The system must either:

• reduce intake scope;
• restore boundary protection;
• increase auditability;
• reroute to victim-centered restoration;
• repair the interface;
• repair translation layer;
• block classification, mediation, or closure until repair need is mapped.

8. Diagnostics

8.1 Required Diagnostic Trends

8.2 Arc-Specific Diagnostic Thresholds

Suggested thresholds:

BΣ_intake ↑
intake_fidelity ↑
routing_accuracy ↑
Au_intake ↑
burden_transfer ↓
repair_alignment ↑
H_intake ↓
R_repair-directed ↑
recurrence ↓ across U7

Repair-First Intake is not complete if:

case closure improves but repair does not
intake extracts repeated testimony
classification still precedes repair need
affected-node signal cannot correct routing
appeal path remains dead
routing remains opaque
intake data supports legitimacy more than repair

9. Anti-Patterns / False Restorations

9.1 Common False Versions

This arc is being simulated, not executed, if:

• intake forms are redesigned but routing remains unchanged;
• response time improves while repair alignment does not;
• reports are collected but no owner can act;
• testimony is compressed into a category before repair needs are mapped;
• affected nodes must repeat harm to each new handler;
• closure metrics improve because cases are misclassified or abandoned;
• intake becomes a legitimacy dashboard;
• evidence submission increases exposure without protection;
• mediation is routed before boundary and responsibility review;
• AI classifiers turn harm reports into generic support or safety categories.

9.2 Named Anti-Pattern Links

10. Completion Criteria

10.1 Post-State Signature

10.2 Temporal Proof

Repair-First Intake cannot be declared complete until intake reliably routes to repair and reduces burden over time.

Template:

Completion requires intake_fidelity(t+n) ≥ intake_fidelity(t),
routing_accuracy(t+n) ≥ routing_accuracy(t),
repair_alignment(t+n) ≥ repair_alignment(t),
H_intake(t+n) ≤ H_intake(t),
and recurrence decreasing across U7.

Minimum temporal proof:

• reports reach the correct repair path;
• affected-node burden decreases;
• routing errors become correctable;
• case closure no longer outruns repair;
• appeal paths can change outcomes;
• intake capture does not return under new forms or categories.

10.3 Completion Statement

Canonical format:

This arc is complete only when first contact preserves affected-node boundary and signal, identifies repair needs before closure logic, routes responsibility and repair obligations accurately, and proves over time that intake reduces burden instead of extracting testimony or producing procedural churn.

11. Cross-Links

11.1 Related Restoration Arcs

11.2 Related Failure Modes

11.3 Related Diagnostics

BΣ, BΣ_intake, Au, Au_intake, H, H_intake, R, FI, K, σ(t), O, µᵢ, burden_transfer, repair_alignment, intake_fidelity, routing_accuracy, Φ/O divergence, recurrence

11.4 Related Laws / Invariants

INV — Intake must preserve boundary and consent before classification.
INV — Repair need precedes closure logic.
INV — Affected-node signal must remain correctable without forced participation.
INV — Case closure is not repair proof.
LAW — Procedural extraction accumulates hidden debt.
LAW — Classification before repair misroutes restoration capacity.
LAW — Dead-end appeal preserves harm geometry.
LAW — Φ improvement is not O restoration.

12. Domain Notes

12.1 AI / Cognitive Infrastructure

Check:

• user report intake;
• model appeal forms;
• classifier triage;
• safety escalation;
• memory correction intake;
• user feedback routing;
• harm report summarization;
• whether user reports become training data without consent or repair.

AI repair-first intake requires user harm, boundary, consent, memory, tool, and appeal reports to be routed to actual correction rather than generic support, safety category, or product telemetry.

12.2 Justice / Governance / Legitimacy

Check:

• complaint intake;
• testimony channels;
• public grievance processes;
• HR / institutional reports;
• mediation referrals;
• appeal portals;
• whether process reduces harm or captures legitimacy.

JGL repair-first intake prevents the first procedural contact from extracting testimony or pushing reconciliation before responsibility and repair.

12.3 Biology / Medicine

Conceptual systems mapping only.

Repair-First Intake in biological or medical-adjacent systems means intake preserves lived signal, timing, boundary, agency, and repair needs rather than flattening experience prematurely into rigid categories.

Not diagnosis.

Not treatment.

Not medical advice.

12.4 Economy

Check:

• dispute intake;
• refund or remediation process;
• worker grievance channels;
• debt hardship intake;
• benefit access forms;
• platform support tickets;
• whether intake reduces burden or creates procedural attrition.

Economic repair-first intake routes economic harm toward correction, compensation, portability, relief, or prevention rather than complaint churn.

12.5 CMS / Meaning / Archetypes

Check:

• confession intake;
• healing circles;
• community grievance;
• spiritual harm reports;
• symbolic testimony;
• initiation or reconciliation processes;
• whether meaning systems ask for vulnerable disclosure before boundary and repair are protected.

Meaning systems require repair-first intake when testimony, harm, or symbolic disclosure risks becoming legitimacy, healing, or reconciliation material before repair.

13. Machine-Readable Metadata

id: "RA-042"
title: "Repair-First Intake"
aliases:
  - "Repair Intake"
family_primary: "Justice / Governance / Legitimacy"
families_secondary:
  - "Core"
  - "Boundary"
  - "Consent"
  - "Auditability"
  - "Interface"
  - "Institutional Design"
  - "AI Governance"
  - "Security"
  - "Economy"
  - "CMS"
treatment: "Canon Parent Arc"
status: "Canon-Ready"
scope:
  - "Relational"
  - "Institutional"
  - "AI"
  - "Security"
  - "Economic"
  - "Civilizational"
  - "Cross-Domain"
u_layers:
  failure_origin:
    - "usually U2 boundary / disclosure / consent"
    - "often U3 intake routing / classifier / process"
    - "often U4 institutional narrative / category language"
  symptom_visible:
    - "U4 case category / support response / procedure language"
    - "Φ ticket / response / closure metrics"
  repair_required:
    - "same or lower than layer where first contact misroutes or extracts from the affected node"
  validation:
    - "U5"
    - "U6"
    - "U7"
operators:
  scaffold: "Π intake boundary protection → Σ repair-first invariant → Au intake routing trace → FI affected-signal correction → Θ burden / urgency damping → Μ harm / repair need map → ℛ repair routing → Λ intake-fit test → Τ repair / recurrence validation"
  sequence:
    - "Π"
    - "Σ"
    - "Au"
    - "FI"
    - "Θ"
    - "Μ"
    - "ℛ"
    - "Λ"
    - "Τ"
state_variables:
  primary:
    - "BΣ"
    - "Au"
    - "H"
    - "R"
    - "FI"
  secondary:
    - "K"
    - "O"
    - "µᵢ"
    - "Φ"
diagnostics:
  - "BΣ_intake"
  - "Au_intake"
  - "H_intake"
  - "burden_transfer"
  - "repair_alignment"
  - "intake_fidelity"
  - "routing_accuracy"
  - "Φ/O divergence"
  - "recurrence"
gates_required:
  - "FI-Gate"
  - "HR-Gate"
  - "MS-Gate"
  - "Au-Actuation"
  - "BΣ-Gate"
  - "Λ-Gate"
  - "☷ᵢ"
linked_failure_modes:
  - "Intake Capture"
  - "Procedural Extraction"
  - "Classification Before Repair"
  - "Testimony Compression"
  - "Dead-End Appeal"
  - "Legitimacy-First Intake"
  - "Victim Burden Transfer"
  - "Consent Theater"
  - "Repair Burden Inversion"
  - "False Reconciliation"
  - "Interface Misrepresentation"
  - "Restoration Bypass"
linked_restoration_arcs:
  - "RA-001"
  - "RA-002"
  - "RA-004"
  - "RA-005"
  - "RA-018"
  - "RA-030"
  - "RA-039"
  - "RA-040"
  - "RA-041"
  - "RA-043"
  - "RA-044"
  - "RA-046"
  - "RA-058"
anti_patterns:
  - "Intake Theater"
  - "Classification Capture"
  - "Procedural Extraction"
  - "Dead-End Appeal"
  - "Ticket Closure Substitution"
  - "Legitimacy Dashboarding"
  - "Mediation Premature Routing"
completion_tests:
  - "BΣ_intake increases"
  - "intake_fidelity increases"
  - "routing_accuracy increases"
  - "Au_intake increases"
  - "burden_transfer decreases"
  - "repair_alignment increases"
  - "H_intake decreases"
  - "R_repair-directed increases"
  - "recurrence decreases across U7"
summary: "Repair-First Intake restores the first contact layer of a restoration process so intake captures harm, boundary, consent, safety, burden, responsibility, and repair needs before classification, mediation, reconciliation, legitimacy management, or procedural closure."

Final Calibration Rule

Repair-First Intake answers six questions:

What hidden debt is being generated by intake capture, testimony extraction, or misrouting?
What boundary, consent, disclosure, routing, or repair-need path must be restored at first contact?
What auditability proves intake preserves source signal and routes to actual repair?
What ticket, case category, form, appeal path, response metric, or closure signal must remain provisional until repair alignment is proven?
What trajectory becomes viable once intake becomes boundary-safe and repair-first?
How is intake repair proven over time without procedural extraction, classification capture, dead-end appeal, ticket-closure substitution, or legitimacy dashboarding?