0. Registry Classification

1. Purpose

1.1 What This Arc Repairs

Authority Registry Clarification repairs systems where decisions, permissions, constraints, overrides, policies, enforcement actions, resources, or governance powers exist without a visible responsible authority.

It applies when power acts, but no one can clearly answer:

Who can decide?
Who did decide?
What is their scope?
Who is accountable?
Who can review or reverse it?
When must authority be revalidated?

This arc repairs authority opacity by:

• identifying decision authorities;
• defining authority scope;
• distinguishing formal authority from operational authority;
• distinguishing advisory influence from binding decision power;
• publishing or internally auditing an authority registry;
• attaching responsibility to each authority path;
• linking decisions to review, escalation, appeal, and rollback paths;
• preventing power from becoming orphaned, unowned, or unreviewable;
• ensuring authority remains valid across personnel, model, vendor, policy, interface, or institutional change.

Authority Registry Clarification is the canonical arc for repairing orphaned power.

1.2 Core Restoration Function

This arc restores authority traceability by making decision power visible, scoped, owned, reviewable, and attached to responsibility over time.

Authority Registry Clarification prevents governance systems from acting through unnamed power.

2. Use Conditions

2.1 When to Apply

Use this arc when:

• a decision was made but no accountable decision authority is visible;
• policy exists without an owner;
• enforcement occurs without clear review authority;
• AI behavior changes but ownership of the change is unclear;
• model, interface, or platform constraints shift without named authority;
• a vendor, automated system, policy team, safety team, executive layer, or governance body influences outcomes without responsibility attachment;
• escalation paths are unclear;
• affected nodes cannot identify who can reverse, review, repair, or explain a decision;
• public authority differs from operational authority;
• multiple teams can act, but no one is accountable;
• power persists after its mandate, scope, or review window has expired.

Examples:

• a platform bans users through an automated process whose policy owner is unclear;
• a model behavior changes after an evaluator update but no decision owner is visible;
• a security exception is granted by an informal channel;
• a governance committee recommends action while another group implements it without trace;
• a contract gives one actor control, but operational decisions are made elsewhere;
• an institution claims “the process decided” when actual authority can be mapped.

2.2 When Not to Apply

Do not apply this arc when:

• active harm requires emergency stabilization first;
• authority is already clear and the issue is misuse, not opacity;
• the primary repair is victim-centered restoration, not authority mapping;
• publication of authority would expose protected personnel, affected nodes, or security controls;
• the system refuses to preserve decision or authority records;
• responsibility gradient mapping is not yet possible;
• authority clarification is being used to delay repair;
• the correct immediate move is signed decision provenance for a specific decision.

Authority Registry Clarification must not become bureaucratic delay 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 stabilization, audit surface expansion, responsibility gradient mapping, signed decision provenance, tamper-evident audit restoration, 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:

Power is not legitimate merely because it operates. Authority must be scoped, traceable, reviewable, and attached to responsibility.

4. Restoration Objective

4.1 Canonical Objective

Restore authority clarity by identifying decision authorities, defining scope, making the registry auditable, attaching responsibility, and establishing review cadence.

Formal objective:

authority_traceability ↑
scope_clarity ↑
responsibility_attachment ↑
decision_ownership ↑
review_cadence_integrity ↑
escalation_clarity ↑
orphaned_power ↓
H ↓
Au ↑
Φ/O divergence ↓

Expanded objective:

Convert hidden, diffused, or orphaned authority into visible, scoped, accountable, reviewable governance structure.

4.2 Non-Goals

This arc does not aim to:

• centralize authority unnecessarily;
• expose protected operational details where disclosure creates risk;
• publish names when role-level accountability is safer and sufficient;
• use authority mapping to delay affected-node repair;
• replace responsibility with a registry artifact;
• create rigid bureaucracy where lightweight ownership would suffice;
• treat formal authority as the only authority that matters;
• erase informal, delegated, automated, or vendor-mediated authority;
• certify legitimacy without review or rollback capacity;
• attach blame where responsibility mapping is still incomplete.

5. Operator Sequence

5.1 Minimal Operator Scaffold

Au authority trace → Π scope / disclosure boundary → Σ responsibility-attachment invariant → FI review / appeal / field signal → Θ diffusion and evasion damping → ℛ registry / owner / cadence routing → Λ authority-fit test → Τ review cadence proof

Reference sequence from the registry:

identify decision authorities
→ define scope
→ publish or audit registry
→ attach responsibility
→ review cadence

Universal grammar alignment:

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

Authority Registry Clarification may route into Signed Decision Provenance, Tamper-Evident Audit Restoration, Governance-Level Restoration, Constraint Recalibration Under Φ Growth, or Sovereignty Safeguard Restoration.

5.2 Operator Step Table

5.3 Sequence Notes

This arc is authority-gated, scope-gated, and review-gated.

The sequence must distinguish:

formal authority
operational authority
delegated authority
automated authority
advisory influence
override power
review authority
repair authority

The following steps cannot be skipped:

authority identification
scope definition
responsibility attachment
registry or audit record
review / appeal path
review cadence
successor continuity

If authority is identified but scope is undefined, the arc is incomplete.

If authority is scoped but no responsibility attaches, the arc fails.

If responsibility attaches but no review cadence exists, orphaned power can return.

6. Restoration Phases

Phase 0 — Identify Authority Object

Purpose: Name what authority must be clarified.

Actions:

• identify decision, policy, permission, constraint, override, resource, enforcement action, or governance function;
• identify where the authority acted;
• identify affected nodes;
• identify formal and operational authority candidates;
• identify whether authority is human, institutional, automated, vendor-mediated, or hybrid.

Validation:

authority object named
decision path visible enough to map
affected-node recourse relevance visible

Phase 1 — Map Decision Authorities

Purpose: Identify who or what can decide.

Actions:

• map formal decision authority;
• map operational authority;
• map delegated authority;
• map automated system authority;
• map advisory influence that effectively controls outcomes;
• map override authority;
• map appeal and reversal authority;
• map repair authority.

Validation:

authority_traceability ↑
decision_ownership candidates visible
shadow authority decreases

Phase 2 — Define Scope

Purpose: Clarify what each authority can and cannot do.

Actions:

• define domain of authority;
• define limits;
• define affected-node boundaries;
• define data, tool, access, or enforcement scope;
• define emergency scope if applicable;
• define expiration, review, or renewal conditions;
• define escalation thresholds.

Validation:

scope_clarity ↑
BΣ stable or ↑
scope drift risk ↓

Phase 3 — Publish or Audit Registry

Purpose: Preserve authority record in a usable form.

Actions:

• create registry entry;
• identify authority owner by role, body, system, or accountable actor;
• distinguish public registry from protected internal registry;
• record scope, decision class, review authority, appeal path, and rollback path;
• record relevant dependencies;
• preserve uncertainty where authority is still being investigated.

Validation:

Au ↑
authority registry active
future auditability ↑

Phase 4 — Attach Responsibility

Purpose: Prevent power from remaining orphaned.

Actions:

• assign responsibility to authority owner;
• identify benefit, capacity, and repair obligation;
• attach accountability to decisions made under the authority;
• identify who must respond to appeals;
• identify who must repair error;
• identify who can revoke, suspend, or constrain the authority.

Validation:

responsibility_attachment ↑
orphaned_power ↓
repair route visible

Phase 5 — Define Review Cadence

Purpose: Ensure authority remains valid across time.

Actions:

• define review interval;
• define review trigger;
• define escalation path;
• define audit criteria;
• define expiration or renewal rules;
• define successor handoff requirements;
• define drift monitoring.

Validation:

review_cadence_integrity ↑
successor continuity ↑
authority drift ↓

Phase 6 — Test Authority Fit

Purpose: Confirm the authority remains legitimate and compatible.

Actions:

• test authority against stated scope;
• test against competence and capacity;
• test against affected-node boundary;
• test against escalation and appeal needs;
• test against future conditions;
• test whether authority can be safely relied upon;
• test whether authority must be reduced, split, constrained, or revoked.

Validation:

Λ > 0
authority fit confirmed
invalid authority constrained

Phase 7 — Temporal Review

Purpose: Validate that authority stays clear and accountable.

Actions:

• monitor authority drift;
• monitor appeals and reversals;
• monitor hidden override;
• monitor owner changes;
• monitor policy changes;
• monitor recurrence of unowned decisions;
• monitor whether the registry remains current.

Validation:

authority_traceability(t+n) ≥ authority_traceability(t)
orphaned_power(t+n) ≤ orphaned_power(t)
review_cadence_integrity stable or ↑

7. Gates

7.1 Required Gates

7.2 Gate Failure Rule

If any required gate fails:

∅ — Authority Registry Clarification cannot validly proceed in that form.

The system must either:

• restore auditability;
• protect disclosure boundaries;
• map responsibility gradient;
• define authority scope;
• attach responsibility;
• assign review or appeal path;
• route to signed decision provenance;
• route to tamper-evident audit restoration;
• suspend or constrain authority until reviewability exists.

8. Diagnostics

8.1 Required Diagnostic Trends

8.2 Arc-Specific Diagnostic Thresholds

Suggested thresholds:

authority_traceability ↑
scope_clarity ↑
responsibility_attachment ↑
decision_ownership ↑
review_cadence_integrity ↑
escalation_clarity ↑
orphaned_power ↓
H ↓
Au ↑
Φ/O divergence ↓

Authority Registry Clarification is not complete if:

authority is named but scope remains unclear
scope is defined but responsibility is not attached
registry exists but review cadence is absent
authority can act without appeal or escalation path
operational authority differs from formal registry
high-status actors remain outside the registry
protected disclosure boundaries are violated
affected nodes still cannot identify recourse

9. Anti-Patterns / False Restorations

9.1 Common False Versions

This arc is being simulated, not executed, if:

• a registry lists roles but no responsibilities;
• formal authority is named while operational authority remains hidden;
• authority scope is vague;
• review cadence is not assigned;
• appeal paths are unavailable;
• high-status actors are exempt;
• automated authority is treated as ownerless;
• vendor-mediated authority is omitted;
• authority is published in a way affected nodes cannot use;
• registry maintenance is unowned.

9.2 Named Anti-Pattern Links

10. Completion Criteria

10.1 Post-State Signature

10.2 Temporal Proof

Authority Registry Clarification cannot be certified by one-time mapping. It requires authority to remain current, reviewable, and attached to responsibility over time.

Template:

Completion requires authority_traceability ↑,
scope_clarity ↑,
responsibility_attachment ↑,
decision_ownership ↑,
review_cadence_integrity ↑,
orphaned_power ↓,
and authority remaining current across review cycles.

Minimum temporal proof:

• decision authorities remain identifiable;
• scope remains clear;
• responsibility remains attached;
• affected nodes can identify recourse;
• review cadence occurs;
• successor owners inherit accountability;
• hidden override and orphaned power decrease.

10.3 Completion Statement

Canonical format:

This arc is complete only when decision authority is identifiable, scoped, auditable, attached to responsibility, connected to appeal and review paths, and revalidated over time so power cannot remain orphaned.

11. Cross-Links

11.1 Related Restoration Arcs

11.2 Related Failure Modes

11.3 Related Diagnostics

Au, H, O, R, BΣ, K, FI, authority_traceability, scope_clarity, responsibility_attachment, orphaned_power, decision_ownership, review_cadence_integrity, escalation_clarity, Φ/O divergence

11.4 Related Laws / Invariants

INV — Power without responsibility is not legitimate authority.
INV — Authority must be scoped to be auditable.
INV — Decision power must attach to review and repair.
INV — Formal authority does not erase operational authority.
LAW — Orphaned power accumulates hidden governance debt.
LAW — Responsibility diffusion regenerates accountability failure.
LAW — Reviewless authority drifts toward opacity.
LAW — Φ throughput is not O restoration.

12. Domain Notes

12.1 AI / Cognitive Infrastructure

Check:

• model behavior authority;
• policy owner;
• evaluator owner;
• override authority;
• deployment authority;
• tool-access authority;
• memory authority;
• appeal authority;
• rollback authority;
• vendor-mediated authority.

AI authority registry clarification requires that automated behavior is not treated as ownerless. Every model, policy, evaluator, deployment, tool, and memory decision path must attach to a responsible authority layer.

12.2 Platform Governance

Check:

• enforcement owner;
• moderation policy owner;
• appeal owner;
• account action authority;
• automated enforcement authority;
• escalation path;
• reversal authority;
• public-policy owner;
• authority changes after policy updates.

Platform users cannot meaningfully appeal or trust governance when authority is invisible or diffused across teams and systems.

12.3 Security

Check:

• exception authority;
• incident commander;
• change approval owner;
• privileged access owner;
• override path;
• emergency authority;
• rollback authority;
• post-incident review owner;
• third-party or vendor authority.

Security systems require authority clarity because hidden override and informal exception paths become attack surfaces.

12.4 Justice / Governance / Legitimacy

Check:

• who can decide;
• who can review;
• who can reverse;
• who can repair;
• who benefits;
• who is responsible;
• whether rank affects review;
• whether affected nodes can identify recourse.

Legitimacy requires authority to be legible enough for responsibility to attach.

12.5 Economy

Check:

• contract authority;
• pricing authority;
• debt authority;
• account access authority;
• labor policy authority;
• compliance authority;
• settlement authority;
• resource allocation authority.

Economic authority clarification prevents hidden decision power from shaping dependency, debt, access, or burden without responsibility.

12.6 CMS / Meaning / Archetypes

Check:

• symbolic authority;
• interpretive authority;
• ritual authority;
• community decision power;
• taboo enforcement;
• role legitimacy;
• review and appeal paths;
• whether authority is inherited, projected, or earned.

Meaning systems require authority to be clarified when symbolic power shapes interpretation, belonging, exclusion, or legitimacy.

13. Machine-Readable Metadata

id: "RA-050"
title: "Authority Registry Clarification"
aliases:
  - "Authority Registry"
family_primary: "Governance / Authority / Accountability"
families_secondary:
  - "Core"
  - "AI Governance"
  - "Justice / Governance / Legitimacy"
  - "Auditability"
  - "Institutional Design"
  - "Security"
  - "Platform Governance"
  - "Boundary"
  - "Coherence"
  - "Scaling"
  - "Decision Provenance"
treatment: "Canon Parent Arc"
status: "Canon-Ready"
scope:
  - "Institutional"
  - "AI"
  - "Security"
  - "Platform"
  - "Economic"
  - "Governance"
  - "Civilizational"
  - "Cross-Domain"
u_layers:
  failure_origin:
    - "often U3 authority / governance structure"
    - "often U4 policy language"
    - "often U5 delegation / review / memory layer"
  symptom_visible:
    - "U4 decision / enforcement / denial / policy change / override / resource allocation / appeal failure"
  repair_required:
    - "same or lower than layer where authority became unowned, hidden, or detached from responsibility"
  validation:
    - "U6"
    - "U7"
operators:
  scaffold: "Au authority trace → Π scope / disclosure boundary → Σ responsibility-attachment invariant → FI review / appeal / field signal → Θ diffusion and evasion damping → ℛ registry / owner / cadence routing → Λ authority-fit test → Τ review cadence proof"
  sequence:
    - "Au"
    - "Π"
    - "Σ"
    - "FI"
    - "Θ"
    - "ℛ"
    - "Λ"
    - "Τ"
state_variables:
  primary:
    - "Au"
    - "H"
    - "O"
    - "R"
    - "BΣ"
  secondary:
    - "K"
    - "FI"
    - "µᵢ"
    - "Φ"
diagnostics:
  - "authority_traceability"
  - "scope_clarity"
  - "responsibility_attachment"
  - "orphaned_power"
  - "decision_ownership"
  - "review_cadence_integrity"
  - "escalation_clarity"
  - "Φ/O divergence"
gates_required:
  - "FI-Gate"
  - "HR-Gate"
  - "MS-Gate"
  - "Au-Actuation"
  - "BΣ-Gate"
  - "Λ-Gate"
  - "☷ᵢ"
linked_failure_modes:
  - "Responsibility Diffusion"
  - "Orphaned Power"
  - "Authority Opacity"
  - "Unowned Decision Path"
  - "Accountability Evasion"
  - "Shadow Governance"
  - "Policy Without Owner"
  - "Hidden Override"
  - "Scope Drift"
  - "Escalation Failure"
  - "Institutional Forgetting"
  - "Governance Failure"
linked_restoration_arcs:
  - "RA-004"
  - "RA-012"
  - "RA-040"
  - "RA-043"
  - "RA-044"
  - "RA-046"
  - "RA-049"
  - "RA-051"
  - "RA-052"
  - "RA-053"
  - "RA-055"
  - "RA-056"
  - "RA-060"
anti_patterns:
  - "Role List Without Responsibility"
  - "Formalism Mask"
  - "Ownerless Automation"
  - "Vendor Shadow Authority"
  - "Scope Fog"
  - "Reviewless Mandate"
  - "Appeal Dead-End"
  - "High-Status Exemption"
  - "Registry Decay"
completion_tests:
  - "authority_traceability increases"
  - "scope_clarity increases"
  - "responsibility_attachment increases"
  - "decision_ownership increases"
  - "review_cadence_integrity increases"
  - "escalation_clarity increases"
  - "orphaned_power decreases"
  - "hidden debt decreases"
  - "auditability increases"
  - "Φ/O divergence decreases"
summary: "Authority Registry Clarification repairs responsibility diffusion and orphaned power by identifying decision authorities, defining scope, publishing or auditing the authority registry, attaching responsibility, and establishing review cadence."

Final Calibration Rule

Authority Registry Clarification answers six questions:

Who or what has decision authority?
What is the scope and limit of that authority?
What record, registry, or audit path makes the authority traceable?
What responsibility, review, appeal, rollback, or repair obligation attaches to it?
How often must the authority be revalidated?
How is orphaned power prevented from returning through drift, delegation, automation, vendor authority, or institutional forgetting?