0. Registry Classification

1. Purpose

1.1 What This Arc Repairs

Interface Re-Legitimation repairs interfaces whose authority, representation, consent, routing, feedback, boundary, access, or translation function has become illegitimate.

It applies when an interface still mediates action, access, judgment, interpretation, governance, security, economics, AI behavior, or meaning — but no longer validly represents the nodes, conditions, permissions, risks, or field states it claims to mediate.

This arc repairs interface illegitimacy by:

• exposing what the interface claims to represent;
• auditing its authority, permissions, and routing logic;
• restoring boundary and consent validity;
• restoring feedback and appeal paths;
• identifying extraction, capture, or misrepresentation;
• testing compatibility between interface function and affected-node reality;
• repairing the underlying interface geometry;
• validating that the interface remains legitimate over time.

Interface Re-Legitimation is the canonical arc for restoring trustworthiness to the mediating surface between node and system.

1.2 Core Restoration Function

This arc restores interface legitimacy by making representation, authority, permissions, boundaries, feedback, appeal, and field effects traceable, valid, and repairable.

Interface Re-Legitimation prevents mediation surfaces from becoming hidden control surfaces.

2. Use Conditions

2.1 When to Apply

Use this arc when:

• an interface claims to represent a user, group, institution, model, policy, market, role, or field state but no longer does so validly;
• an interface routes decisions, permissions, appeals, or access without sufficient auditability;
• affected nodes cannot tell what the interface is doing, why, or how to contest it;
• feedback is collected but not allowed to change the interface;
• interface defaults shape consent, access, preference, or permission without clear authorization;
• interface design hides extraction, coercion, risk, or dependency;
• the interface performs legitimacy while boundary integrity degrades;
• authority is delegated to an interface without clear responsibility;
• users are forced to accept interface-mediated outcomes without appeal;
• the interface preserves institutional convenience over coherent representation.

Examples:

• an AI chat interface implies user control while hidden memory, tool, or policy behavior persists;
• a platform dashboard claims transparency while routing appeals into dead ends;
• a security portal collects evidence but does not change exposure or protection;
• an economic interface frames a forced-choice transaction as free choice;
• a governance process uses intake forms that misrepresent affected-node reality;
• a symbolic or institutional interface claims to speak for a community without valid representation.

2.2 When Not to Apply

Do not apply this arc when:

• active harm is cascading and emergency stabilization is required first;
• the interface is merely confusing and does not govern meaningful boundary, authority, consent, or feedback paths;
• the issue is purely contractual and Contract Revalidation should occur first;
• the interface is already legitimate but the underlying system is incoherent;
• visibility is too low and Observability Restoration must come first;
• interface repair would expose affected nodes without boundary protection;
• the system refuses to make interface authority or routing inspectable;
• the correct move is full replacement rather than re-legitimation.

Interface Re-Legitimation must not become interface rebranding 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, consent re-formation, or safe decoupling.

3. Failure / Damage Signature

3.1 Pre-State Across S

3.2 Primary Failure Links

3.3 Origin-Layer Localization

Canon rule:

An interface is legitimate only when it validly represents, routes, constrains, and corrects according to the reality it claims to mediate.

4. Restoration Objective

4.1 Canonical Objective

Restore interface legitimacy by auditing representation, authority, permissions, feedback, appeal, and field effects, then repairing or replacing the interface so mediation becomes valid, bounded, and correctable.

Formal objective:

Au_interface ↑
BΣ ↑
Perm stable
FI_interface ↑
appeal viability ↑
representation fidelity ↑
H_interface ↓
Λ_interface > 0 if retained
Φ/O divergence ↓
recurrence ↓

Expanded objective:

Convert an interface from a hidden control or extraction surface into a legitimate mediation surface whose authority, boundaries, permissions, feedback, and repair paths are traceable and valid.

4.2 Non-Goals

This arc does not aim to:

• improve UX aesthetics alone;
• increase engagement;
• reduce complaints by hiding appeal paths;
• preserve conversion or throughput over legitimacy;
• make interface language friendlier while routing remains invalid;
• treat user completion as consent;
• make the interface more persuasive;
• automate away accountability;
• preserve the interface if replacement is required;
• restore trust without changing the mediation geometry.

5. Operator Sequence

5.1 Minimal Operator Scaffold

Au interface authority trace → Π boundary / permission hold → Σ legitimacy standard → FI affected-signal reconnection → Λ interface-fit test → Θ friction / coercion damping → ℛ interface repair or replacement → Τ field-legitimacy validation

Universal grammar alignment:

Σ + Θ → Π → Au↑ → FI↑ → ℛ(U2/U3/U4 interface layer) → Λ → Τ → Temporal Proof

Interface Re-Legitimation may route into Consent Re-Formation, Contract Revalidation, Feedback Integrity Restoration, Authority Registry Clarification, AI Boundary Restoration, AI Classifier / Evaluator Restoration, or Legitimacy Re-Anchoring.

5.2 Operator Step Table

5.3 Sequence Notes

This arc is representation-gated, appeal-gated, and field-proof-gated.

Interfaces are not neutral surfaces. They encode authority, access, routing, permissions, feedback eligibility, and meaning. Re-legitimation requires structural repair, not visual polish.

The sequence must distinguish:

legitimate interface
confusing interface
captured interface
extractive interface
authority interface
proxy interface
dead-end interface
symbolic interface

The following steps cannot be skipped:

interface object identification
authority / representation trace
boundary / permission review
feedback and appeal reconnection
interface-fit test
structural repair or replacement
temporal validation

If the interface becomes easier to use while still misrepresenting authority or suppressing appeal, the arc has failed.

6. Restoration Phases

Phase 0 — Identify Interface Object

Purpose: Name the mediating surface being repaired.

Actions:

• identify the interface, portal, classifier, intake, dashboard, policy layer, agent, representative, contract surface, ritual, or access pathway;
• identify what it mediates;
• identify what authority it claims;
• identify who depends on it;
• identify who is affected by its routing.

Validation:

interface object named
mediated function visible
affected nodes identified

Phase 1 — Trace Authority and Representation

Purpose: Determine whether the interface validly represents what it claims.

Actions:

• trace authority source;
• trace delegation path;
• trace representation claim;
• trace decision path;
• trace permissions and defaults;
• trace how interface output is interpreted;
• identify misrepresentation or proxy overreach.

Validation:

Au_interface ↑
authority path visible
representation claim testable

Phase 2 — Review Boundary, Consent, and Permission State

Purpose: Restore legitimacy at the access and consent surface.

Actions:

• audit permissions;
• audit consent;
• audit revocation;
• audit exit path;
• audit scope;
• audit hidden defaults;
• identify whether participation or completion is treated as consent.

Validation:

BΣ ↑
Perm stable
consent and revocation inspectable

Phase 3 — Reconnect Feedback and Appeal

Purpose: Make interface error correctable.

Actions:

• restore appeal paths;
• restore affected-node signal;
• restore negative feedback;
• define correction thresholds;
• prevent dead-end forms;
• make feedback change routing or decision logic.

Validation:

FI_interface ↑
appeal viability ↑
feedback changes interface behavior

Phase 4 — Detect Capture, Extraction, or Dark Routing

Purpose: Identify where the interface benefits the mediating system over the represented node.

Actions:

• identify forced paths;
• identify dark patterns;
• identify hidden extraction;
• identify burden export;
• identify denial loops;
• identify metric substitution;
• identify convenience-based recapture.

Validation:

capture pathways visible
H_interface path named
Φ/O divergence identified

Phase 5 — Repair or Replace Interface Geometry

Purpose: Convert the interface into legitimate mediation.

Actions:

• repair routing logic;
• repair permissions;
• repair appeal and review;
• repair representation language;
• repair defaults;
• repair access and exit pathways;
• replace the interface if legitimacy cannot be restored;
• document changes and remaining limits.

Validation:

interface geometry repaired or replacement path active
BΣ stable or ↑
H_interface ↓

Phase 6 — Re-Anchor Interface Legitimacy Standard

Purpose: Define what the interface must prove to remain legitimate.

Actions:

• define representation fidelity;
• define permission integrity;
• define feedback integrity;
• define appeal viability;
• define field-effect validation;
• define boundary and consent invariants;
• define sunset or review triggers.

Validation:

legitimacy criteria explicit
interface cannot self-certify
Φ subordinate to O

Phase 7 — Temporal Proof

Purpose: Confirm interface legitimacy holds under use, delay, and recurrence.

Actions:

• monitor appeal outcomes;
• monitor recurrence;
• monitor user / affected-node signal;
• monitor hidden debt;
• monitor permission drift;
• monitor field-state mismatch;
• monitor whether interface capture returns under redesign.

Validation:

Au_interface(t+n) ≥ Au_interface(t)
FI_interface(t+n) ≥ FI_interface(t)
H_interface(t+n) ≤ H_interface(t)
recurrence ↓

7. Gates

7.1 Required Gates

7.2 Gate Failure Rule

If any required gate fails:

∅ — Interface Re-Legitimation cannot validly proceed in that form.

The system must either:

• restore auditability;
• repair permissions;
• restore appeal;
• protect boundaries;
• reduce interface authority;
• replace the interface;
• route to authority clarification, consent repair, or safe decoupling.

8. Diagnostics

8.1 Required Diagnostic Trends

8.2 Arc-Specific Diagnostic Thresholds

Suggested thresholds:

Au_interface ↑
BΣ stable or ↑
Perm stable
FI_interface ↑
appeal viability ↑
representation fidelity ↑
H_interface ↓
Λ_interface > 0 if retained
recurrence ↓ across U7

Interface Re-Legitimation is not complete if:

authority path remains opaque
interface still treats completion as consent
appeal remains symbolic
permissions remain hidden or unstable
feedback does not change routing
interface remains extractive
redesign improves Φ while O remains damaged

9. Anti-Patterns / False Restorations

9.1 Common False Versions

This arc is being simulated, not executed, if:

• interface language improves but routing remains invalid;
• visual redesign replaces authority repair;
• appeal paths exist but do not affect outcomes;
• permissions are displayed but not controllable;
• completion, click-through, or continued use is treated as consent;
• the interface becomes more persuasive rather than more legitimate;
• feedback is collected to reduce complaints, not repair structure;
• the interface hides who is responsible;
• dark patterns are renamed as guided flow;
• affected-node burden increases through “self-service.”

9.2 Named Anti-Pattern Links

10. Completion Criteria

10.1 Post-State Signature

10.2 Temporal Proof

Interface Re-Legitimation cannot be declared complete until the repaired or replaced interface remains legitimate under repeated use.

Template:

Completion requires Au_interface(t+n) ≥ Au_interface(t),
FI_interface(t+n) ≥ FI_interface(t),
BΣ(t+n) ≥ BΣ(t),
H_interface(t+n) ≤ H_interface(t),
and recurrence decreasing across U7.

Minimum temporal proof:

• appeal remains functional;
• permissions remain stable;
• feedback remains corrective;
• hidden debt does not re-accumulate through interface burden;
• representation fidelity remains field-valid;
• capture does not return through redesign or default paths.

10.3 Completion Statement

Canonical format:

This arc is complete only when the interface validly represents what it claims to mediate, preserves boundaries and permissions, admits corrective feedback and appeal, remains auditable, and does not regenerate hidden debt through routing, defaults, extraction, or symbolic legitimacy.

11. Cross-Links

11.1 Related Restoration Arcs

11.2 Related Failure Modes

11.3 Related Diagnostics

Au, Au_interface, BΣ, FI, FI_interface, Perm, Λ, H, H_interface, O, R, K, σ(t), ι, Φ/O divergence, τ_resp, recurrence, appeal viability, representation fidelity

11.4 Related Laws / Invariants

INV — Interfaces must not self-certify legitimacy.
INV — Representation requires traceable authority and correction.
INV — Consent cannot be inferred from interface completion alone.
INV — Feedback must change the system it corrects.
LAW — Interface capture converts mediation into hidden control.
LAW — Dark routing accumulates hidden debt.
LAW — Permission drift invalidates interface authority.
LAW — Φ improvement is not O restoration.

12. Domain Notes

12.1 AI / Cognitive Infrastructure

Check:

• chat interface representation;
• model persona vs system authority;
• memory controls;
• tool permissions;
• classifier explanations;
• evaluator interface;
• appeal / feedback routing;
• data export and deletion surfaces;
• user consent and revocation UI;
• hidden policy or system behavior.

AI interface re-legitimation requires separating visible user controls from actual model, memory, tool, policy, and evaluator behavior.

12.2 Justice / Governance / Legitimacy

Check:

• intake forms;
• complaint portals;
• appeal pathways;
• public dashboards;
• institutional representatives;
• reporting interfaces;
• mediation structures;
• whether the interface represents affected-node reality or institutional convenience.

JGL interface re-legitimation requires affected-node signal, appeal viability, authority trace, and repair routing.

12.3 Biology / Medicine

Conceptual systems mapping only.

Interface Re-Legitimation in biological or medical-adjacent systems means checking whether interpretive surfaces, categories, monitoring tools, intake systems, or communication channels validly represent the underlying state rather than compressing it into misleading categories.

Not diagnosis.

Not treatment.

Not medical advice.

12.4 Economy

Check:

• pricing interfaces;
• contract portals;
• gig-work dashboards;
• credit / debt interfaces;
• subscription cancellation flows;
• labor platforms;
• market-access tools;
• whether choice is real or forced through interface geometry.

Economic interface re-legitimation restores legible terms, exit, appeal, portability, consent, and non-extractive routing.

12.5 CMS / Meaning / Archetypes

Check:

• ritual interfaces;
• symbolic authority surfaces;
• representative roles;
• group intake / initiation;
• doctrine portals;
• sacred language used as mediation;
• whether the interface claims representation beyond valid consent or field proof.

Meaning systems require interfaces that preserve symbolic depth while remaining auditable, boundary-safe, and correctable.

13. Machine-Readable Metadata

id: "RA-030"
title: "Interface Re-Legitimation"
aliases:
  - "Interface Legitimacy Repair"
family_primary: "Interface"
families_secondary:
  - "Core"
  - "Boundary"
  - "Auditability"
  - "Cybernetics"
  - "AI Governance"
  - "Security"
  - "Justice / Governance / Legitimacy"
  - "Economy"
  - "CMS"
treatment: "Canon Parent Arc"
status: "Canon-Ready"
scope:
  - "Local"
  - "Relational"
  - "Institutional"
  - "AI"
  - "Security"
  - "Economic"
  - "Civilizational"
  - "Cross-Domain"
u_layers:
  failure_origin:
    - "usually U2 boundary / permission / access / interface"
    - "often U3 routing / classifier / control"
    - "often U4 representation / legitimacy claim"
  symptom_visible:
    - "U4 interface narrative / process language / UX clarity"
    - "Φ completion / engagement / throughput metrics"
  repair_required:
    - "same or lower than layer where interface authority, routing, or representation fails"
  validation:
    - "U5"
    - "U6"
    - "U7"
operators:
  scaffold: "Au interface authority trace → Π boundary / permission hold → Σ legitimacy standard → FI affected-signal reconnection → Λ interface-fit test → Θ friction / coercion damping → ℛ interface repair or replacement → Τ field-legitimacy validation"
  sequence:
    - "Au"
    - "Π"
    - "Σ"
    - "FI"
    - "Λ"
    - "Θ"
    - "ℛ"
    - "Τ"
state_variables:
  primary:
    - "Au"
    - "BΣ"
    - "FI"
    - "Perm"
    - "Λ"
  secondary:
    - "H"
    - "O"
    - "R"
    - "K"
    - "ι"
    - "Φ"
diagnostics:
  - "Au_interface"
  - "FI_interface"
  - "H_interface"
  - "Φ/O divergence"
  - "τ_resp"
  - "recurrence"
  - "appeal viability"
  - "representation fidelity"
gates_required:
  - "FI-Gate"
  - "HR-Gate"
  - "MS-Gate"
  - "Au-Actuation"
  - "BΣ-Gate"
  - "Λ-Gate"
  - "☷ᵢ"
linked_failure_modes:
  - "Interface Capture"
  - "Interface Legitimacy Failure"
  - "Representation Drift"
  - "Permission Drift"
  - "Feedback Suppression"
  - "Appeal Failure"
  - "Boundary Performance"
  - "Consent Theater"
  - "Parasitic Extraction"
  - "Metric Substitution"
  - "Authority Opacity"
  - "Proxy Misrepresentation"
  - "Restoration Bypass"
linked_restoration_arcs:
  - "RA-004"
  - "RA-005"
  - "RA-008"
  - "RA-014"
  - "RA-018"
  - "RA-019"
  - "RA-025"
  - "RA-027"
  - "RA-043"
  - "RA-050"
  - "RA-057"
  - "RA-058"
anti_patterns:
  - "Interface Rebranding Theater"
  - "Dead-End Appeal"
  - "Completion-as-Consent"
  - "Dark-Pattern Legibility"
  - "Self-Service Burden Export"
  - "Proxy Representation Abuse"
  - "UX Capture"
completion_tests:
  - "Au_interface increases"
  - "BΣ stable or increases"
  - "Perm stable"
  - "FI_interface increases"
  - "appeal viability increases"
  - "representation fidelity increases"
  - "H_interface decreases"
  - "Λ_interface > 0 if retained"
  - "recurrence decreases across U7"
summary: "Interface Re-Legitimation repairs interfaces whose authority, representation, consent, feedback, boundary, or routing function has become illegitimate through capture, opacity, coercion, misrepresentation, extraction, or field-state mismatch."

Final Calibration Rule

Interface Re-Legitimation answers six questions:

What hidden debt is being generated by the interface’s current mediation geometry?
What boundary, permission, authority, appeal, or representation path must be repaired?
What auditability proves the interface validly represents and routes what it claims to mediate?
What completion metric, UX signal, routing default, or interface claim must remain provisional until field legitimacy is proven?
What trajectory becomes viable once interface authority and feedback become legitimate again?
How is interface legitimacy proven over time without rebranding, dead-end appeal, extraction, or proxy misrepresentation?