1. Purpose

The Restorative Interaction Template defines the canonical sequence for an interaction that intends to repair, clarify, recouple, reintegrate, or restore coherence after strain, rupture, harm, misclassification, or boundary failure.

It exists because an interaction can be well-intended while still becoming extractive, premature, coercive, or incomplete.

RIT prevents a system from jumping directly from recognition to action, from apology to closure, from strategy to repair, or from repair intent to recoupling.

Its core purpose is to sequence interaction through the right membranes:

EI → SI → LI → ℛ → Τ

Meaning:

Empathy Interface
→ Shadow Interface
→ Light Interface
→ Restoration
→ Time Validation

The Constructs & Operating Systems Registry identifies the Restorative Interaction Template as a workflow that sequences interaction through empathy, simulation, authorization, restoration, and validation.

2. Core Question

Can this interaction proceed restoratively without extraction, projection, premature recoupling, boundary collapse, or false completion?

Secondary questions:

• Has the affected node been recognized?
• Are boundaries intact before interaction proceeds?
• Is the interaction asking too much from the harmed or burdened node?
• Have possible strategies been separated from permissible actions?
• Has the proposed action passed coherence constraints?
• Does restoration capacity exist?
• Is recoupling premature?
• What would count as completion?
• Can repair be validated across time?
• Is ∅ more coherent than forcing interaction?

3. Construct Class

RIT is a workflow because it defines a sequence.

It is not merely a principle and not merely a restoration arc. It is an interaction template that tells a system how to move through recognition, strategy, authorization, repair, and validation without collapsing steps into each other.

4. When to Use

Use the Restorative Interaction Template when an interaction is intended to restore coherence after strain, rupture, conflict, misclassification, harm, or failed coupling.

Use RIT when:

• a repair conversation needs structure
• a harmed or affected node needs recognition before action
• an institution wants to correct a failure without re-burdening affected nodes
• an AI system needs an interaction pattern after misclassification or failed response
• a team needs to recouple after conflict or breakdown
• a governance process needs to sequence repair before enforcement or closure
• restoration risks becoming symbolic rather than completed
• apology, explanation, or policy change is being mistaken for repair
• boundaries must be restored before further interaction
• recoupling is desired but not yet validated
• time validation is required to prove the repair holds

Do not use RIT as the primary construct when the central question is:

RIT coordinates several of these constructs into an interaction sequence.

5. Derivation

The Restorative Interaction Template is derived from a recurring UTS pattern:

rupture or harm occurs
+ the system wants repair
+ recognition, strategy, action, and closure collapse into one step
+ affected-node burden rises
= restoration theater or premature recoupling

A second failure pattern:

repair intent exists
+ boundaries remain unclear
+ restoration capacity is insufficient
+ time validation is skipped
= false completion

RIT exists to prevent “repair” from becoming another form of burden transfer.

It requires the system to move in order:

recognize
→ model possibilities
→ authorize only coherent action
→ restore
→ validate over time

This keeps restoration from collapsing into performance, pressure, or premature closure.

6. Canon Sequence

The canonical RIT sequence is:

EI → SI → LI → ℛ → Τ

Expanded:

RIT does not allow the system to skip from EI to closure, SI to execution, or ℛ to completion without Τ.

7. UTS Basis

RIT assembles the following UTS mechanics.

7.1 State Variables

7.2 Primary U-Layer Pattern

RIT most commonly localizes through:

U6 → U2 → U3 → U5 → U7

Meaning:

recognition and coherence field
→ boundaries and configuration
→ interaction/action
→ timing and sequencing
→ recurrence and validation

Restorative interaction often begins in the coherence field, requires boundary repair, moves into action, must be sequenced correctly, and only completes through recurrence validation.

8. Inputs

8.1 Core Observational Inputs

8.2 Diagnostic Inputs

9. Outputs

RIT produces interaction readiness, restoration sequence, and validation requirements.

9.1 Interaction Readiness Assessment

Possible outputs:

Interaction ready
Interaction not ready
Recognition incomplete
Boundary repair required
Restoration capacity insufficient
Power asymmetry requires safeguards
Affected-node burden too high
Time validation required

9.2 Restoration Sequence Assessment

Possible outputs:

Proceed through EI
Proceed to SI mapping
Proceed to LI review
Proceed to restoration
Delay recoupling
Repair boundary first
Increase support first
Return ∅

9.3 Completion Assessment

Possible outputs:

Repair incomplete
Repair partial
Repair symbolic
Repair active
Repair time-validation pending
Repair recurrence-reduced
Repair complete provisionally
Completion invalid

9.4 Decision Outputs

10. Operating Logic

10.1 Basic Flow

1. Identify affected node and initiating node.
2. Define interaction purpose.
3. Activate Empathy Interface.
4. Model affected-node state, burden, and recognition need.
5. Check boundaries and non-extraction conditions.
6. Activate Shadow Interface if multiple responses are possible.
7. Map possible responses without execution.
8. Activate Light Interface.
9. Filter responses through CCS and CAL as needed.
10. Select admissible restorative action.
11. Perform restoration.
12. Define recurrence and completion criteria.
13. Validate repair over time.
14. Recouple only if validation supports it.

10.2 Restorative Sequence Rule

IF affected-node recognition is incomplete,
THEN do not proceed to closure.

IF boundaries are unclear,
THEN repair boundaries before deeper interaction.

IF possible actions include coercive or extractive pathways,
THEN map them in Shadow but do not execute them.

IF an action has not passed Light review,
THEN it cannot be used as restoration.

IF repair cannot be validated over time,
THEN completion cannot be claimed.

IF recoupling restores the old failure pathway,
THEN delay recoupling or return ∅.

10.3 Completion Rule

Restoration is not complete when an apology is made,
a policy is changed,
a conversation ends,
or a system reports closure.

Restoration is complete only when the relevant burden is reduced,
boundaries are restored,
recurrence risk is lowered,
affected-node reality is recognized,
and the result holds across time.

11. Operators Used

12. Gates Required

13. Failure Modes Detected

14. Restoration Links

15. U-Layer Localization

RIT most commonly localizes through:

U6 → U2 → U3 → U5 → U7

This means restorative interaction begins with recognition, depends on boundaries, moves into action, must be sequenced over time, and completes only through recurrence-aware memory.

16. Example Use Case

Scenario

A team member was repeatedly assigned urgent cleanup work after project failures. The team lead wants to “repair the relationship” by having a conversation and thanking the person for their resilience.

The affected person is tired, under-supported, and concerned that the same pattern will repeat.

RIT Evaluation

The construct checks:

• affected-node burden
• recognition status
• boundary condition
• restoration capacity
• possible responses
• admissible repair actions
• recurrence risk
• completion criteria

Likely Findings

Recognition: partial
Boundary integrity: strained
Restoration capacity: insufficient
Burden transfer risk: high
Recurrence risk: active
Completion status: not available yet

Recommended Output

Do not treat appreciation as repair.
Acknowledge the burden directly.
Remove recurring cleanup load.
Clarify role boundaries.
Add support before future cycles.
Create recurrence checkpoints.
Validate over multiple project cycles before claiming restoration.

Interpretation

The interaction can become restorative only if it reduces the actual burden and changes the recurrence pattern.

Gratitude alone may recognize effort, but it does not restore coherence.

17. Anti-Patterns

Do not use RIT to:

• treat apology as restoration
• treat conversation as completion
• ask harmed nodes to carry the repair
• skip affected-node recognition
• bypass boundary repair
• move directly from strategy to action without Light review
• force recoupling before validation
• use restoration language to preserve the old structure
• treat symbolic repair as burden reduction
• treat closure as recurrence reduction
• ignore power asymmetry
• require repeated disclosure for recognition
• treat silence as restored trust
• claim completion without time validation

18. Completion Criteria

An RIT assessment is complete when:

• affected and initiating nodes are identified
• interaction purpose is defined
• affected-node state is modeled without extraction
• boundaries are checked
• possible responses are mapped
• candidate actions are filtered through Light Interface
• restoration capacity is verified
• repair action is selected or rejected
• affected-node burden is reduced or explicitly addressed
• recurrence risk is monitored
• recoupling conditions are defined
• time validation is established
• completion is not claimed prematurely
• ∅ is returned if no coherent restorative interaction is available

19. Machine-Readable Summary

construct_id: "CONSTRUCT-011"
title: "Restorative Interaction Template"
abbreviation: "RIT"
type: "construct"
status: "draft-integrated"
construct_class: "Restoration Workflow / Interaction Template"
operating_system: false
primary_module: "Restoration"
related_modules:
  - "Principles"
  - "Coherence"
  - "Justice · Governance · Legitimacy"
  - "AI Governance"
  - "Interactions · Signals · Couplings"
  - "Security"

core_question: "Can this interaction proceed restoratively without extraction, projection, premature recoupling, boundary collapse, or false completion?"

definition: "The Restorative Interaction Template sequences interaction through affected-node recognition, strategy-space awareness, coherence-constrained action, restoration, and time validation."

canon_sequence: "EI → SI → LI → ℛ → Τ"

inputs:
  state_variables:
    - "O"
    - "H"
    - "ε"
    - "ι"
    - "Au"
    - "µᵢ"
    - "BΣ"
    - "K"
    - "R"
    - "Φ"
  diagnostics:
    - "Affected Node Cost"
    - "Boundary Integrity"
    - "Recognition Integrity"
    - "Restoration Capacity"
    - "Effective Auditability"
    - "Feedback Integrity"
    - "Hidden Debt"
    - "Power Asymmetry"
    - "Compatibility"
    - "Recurrence"
    - "Time Validation"
    - "Completion Integrity"
  gates:
    - "MS-Gate"
    - "FI-Gate"
    - "BΣ validity"
    - "Λ compatibility"
    - "R sufficiency"
    - "Au-Traceability"
    - "Sovereignty constraint"
    - "Non-Extraction Boundary"
    - "Τ validation"
  observations:
    - "affected-node state"
    - "initiating node"
    - "interaction purpose"
    - "harm or rupture context"
    - "boundary condition"
    - "available restoration capacity"
    - "power asymmetry"
    - "repair need"
    - "possible strategies"
    - "admissible actions"
    - "feedback pathway"
    - "completion criteria"
    - "recurrence risk"

outputs:
  assessments:
    - "interaction readiness"
    - "affected-node recognition status"
    - "boundary status"
    - "restoration sufficiency"
    - "admissibility status"
    - "repair pathway status"
    - "recurrence risk"
    - "completion status"
  decisions:
    - "proceed restoratively"
    - "pause for recognition"
    - "repair boundary first"
    - "increase restoration capacity"
    - "rescope interaction"
    - "reroute through Light Interface"
    - "delay recoupling"
    - "return ∅"
  maps:
    - "restorative interaction sequence"
    - "affected-node burden map"
    - "boundary repair map"
    - "admissible action map"
    - "restoration path map"
    - "time-validation map"
    - "recurrence monitoring map"

dependencies:
  operators:
    - "Ξ"
    - "Δ"
    - "Μ"
    - "Π"
    - "Λ"
    - "⊗"
    - "ℛ"
    - "Σ"
    - "Τ"
  failure_modes:
    - "Premature Recoupling"
    - "Restoration Theater"
    - "Boundary Collapse"
    - "Recognition Failure"
    - "Burden Transfer"
    - "Capacity-Inverting Restoration"
    - "Consent Theater"
    - "Forced Coupling"
    - "Restoration Lockout"
    - "Completion Theater"
    - "Recurrence Blindness"
    - "Repair Without Validation"
  restoration_arcs:
    - "Recognition Restoration"
    - "Boundary Reconstitution"
    - "Justice-Aligned Repair"
    - "Compatibility Recoupling"
    - "Slack Regeneration"
    - "Auditability Restoration"
    - "Conditional Reintegration"
    - "Recurrence Reduction"
    - "Origin-Layer Repair"

u_layers:
  primary:
    - "U2"
    - "U3"
    - "U5"
    - "U6"
    - "U7"
  secondary:
    - "U0"
    - "U1"
    - "U4"
    - "U8"

null_outcome_allowed: true
completion_requires_time_validation: true

20. Citation

Citation ID: construct-restorative-interaction-template-v1-0

Recommended citation:

Universal Theory Stack. “CONSTRUCT-011 — Restorative Interaction Template.” UTS Constructs Registry, Version 1.0.0, 2026.

21. Summary

The Restorative Interaction Template gives UTS a canonical sequence for repair-oriented interaction.

Its core distinction is:

repair is not closure

RIT ensures that interaction moves through recognition, bounded strategy mapping, coherence-constrained action, actual restoration, and time validation.

Its core logic is:

Restorative interaction must reduce burden, repair boundaries, preserve affected-node standing, and hold across recurrence.

When interaction would re-burden the affected node, bypass boundaries, skip admissibility, force recoupling, or claim completion without validation, RIT pauses, rescopes, restores first, delays recoupling, or returns:

∅

The Restorative Interaction Template gives UTS a clean repair sequence before interaction becomes another failure path.