Universal Theories

Jump Through This Page

1. Purpose

Light Teaming uses coherence-positive, restoration-oriented, constraint-aware review to identify which paths may proceed after possible paths have been rendered, simulated, or discovered.

It exists because finding a safe-looking path is not enough.

A path must pass through:

textScroll

truth
non-harm
wisdom
sovereignty
boundaries
auditability
compatibility
restoration
rollback
affected-node recognition
time validation

Light Teaming asks which actions preserve coherence under actual constraints, rather than which actions merely avoid obvious failure.

It is the complement to Shadow Teaming:

textScroll

Shadow Teaming asks: What could go wrong?
Light Teaming asks: What may proceed coherently?

Light Teaming asks:

textScroll

Which path can proceed while preserving truth, boundaries, affected-node standing, restoration capacity, and time-valid coherence?

The Constructs & Operating Systems Registry identifies Light Teaming as the restoration-oriented complement to Shadow Teaming: a review construct for determining which constrained paths may proceed after adversarial and failure-oriented analysis.

2. Core Question

Which candidate path is coherence-admissible, and what constraints, repairs, boundaries, rollback, and time-validation conditions must be attached before execution?

Secondary questions:

What candidate path is being reviewed?
What did Shadow Teaming reveal?
What benefit is intended?
Who or what is affected?
Does the path preserve truth?
Does the path preserve non-harm?
Does the path preserve sovereignty?
Does the path preserve boundaries?
Is authority valid?
Is the action scoped enough?
Is restoration capacity available?
Is rollback available where needed?
Is affected-node burden acceptable?
Does the path require staging?
Does time validation remain possible?
Should the path be approved, constrained, rescoped, delayed, rejected, or ∅?

3. Construct Class

TableScroll

Field	Value
Construct Class	Admissibility / Restoration-Oriented Review Construct
Secondary Class	Constraint Review / Path Approval / Coherence-Gate Construct
Operating System	No
Primary Module	Security / AI Governance / Restoration
Related Modules	Coherence, Principles, Cybernetics, Scaling, Institutions, ISC

Light Teaming is an admissibility construct.

It does not render all possible paths. It receives candidate paths from Shadow Teaming, Shadow Interface, AI Decision Pipeline, institutional review, or design exploration, and determines whether any path can proceed coherently.

It is not optimism. It is disciplined permission.

4. Core Light Teaming Model

Light Teaming follows the logic of the Light Interface:

textScroll

permissible path = possible path that passes coherence constraints

Its core sequence:

textScroll

receive candidate path
→ review shadow findings
→ apply Coherence Constraint Set
→ assess affected-node burden
→ verify boundaries and authority
→ provision restoration and rollback
→ constrain / stage / approve / reject
→ validate over time

Compressed:

textScroll

LT = LI applied to path review and admissible execution design

Light Teaming prevents the common failure:

textScroll

safe-looking path → immediate approval

A path must be coherence-admissible, not merely lower-risk than its alternatives.

5. When to Use

Use Light Teaming when a candidate action, design, policy, deployment, AI workflow, security change, contract, governance pathway, or restoration plan is being considered for approval.

Use Light Teaming when:

Shadow Teaming has produced candidate paths
a team wants to approve a safer design
AI tool use needs admissibility review
deployment must be constrained, staged, or rolled back
a policy change may reduce one harm while creating another
a restoration path needs boundary and time validation
a security control may overcorrect or suppress valid use
a governance action affects users, workers, citizens, patients, creators, or communities
a system needs a principled approval pathway
“less bad” alternatives are being mistaken for coherent alternatives
a high-risk action needs repair and rollback conditions
affected-node burden must be preserved in the approval decision

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

TableScroll

If the question is...	Prefer...
What can go wrong?	Shadow Teaming
What is the general permissible-path interface?	Light Interface
How do Shadow and Light integrate?	Shadow–Light Interface
How should AI move to action?	AI Decision Pipeline
Is AI repair-ready?	Repair-First AI Architecture
Does action pass the full ladder?	Coherence Admissibility Ladder
What is the minimum constraint set?	Coherence Constraint Set
What restoration arc applies?	Restoration Arc Mapper

Light Teaming is specifically the constructive approval and admissibility review step.

6. Derivation

Light Teaming is derived from a recurring UTS pattern:

textScroll

shadow paths are mapped
+ one path appears safer than others
+ path is approved without full constraint review
= lower-risk but still incoherent execution

A second pattern:

textScroll

team wants to act restoratively
+ restoration, rollback, or time validation is not provisioned
+ action creates hidden debt
= good intention without coherence capacity

A third pattern:

textScroll

policy blocks harmful behavior
+ valid use, feedback, or affected-node repair is also blocked
+ system calls this success
= permissibility theater

Light Teaming exists because coherent action requires disciplined approval, not merely safe intent.

Its core distinction is:

textScroll

lower-risk is not the same as admissible

7. UTS Basis

Light Teaming assembles the following UTS mechanics.

7.1 State Variables

TableScroll

Variable	Role in Light Teaming
O	Measures whether the candidate path preserves or increases coherence.
H	Tracks hidden debt that may remain after approval.
ε	Tracks uncertainty in consequences, authority, burden, and timing.
ι	Detects inversion where a seemingly good path creates harm or control.
Au	Measures traceability of review, approval, authority, and repair commitments.
µᵢ	Preserves meaning, user frame, affected-node standing, and principle integrity.
BΣ	Maintains boundaries around action, access, role, authority, and affected nodes.
K	Tracks compatibility between candidate path, context, authority, and restoration capacity.
R	Measures repair and restoration capacity required before approval.
Φ	Tracks power, autonomy, tool force, institutional authority, and action leverage.

7.2 Primary U-Layer Pattern

Light Teaming most commonly localizes through:

textScroll

U4 → U2 → U3 → U6 → U5 → U7

Meaning:

textScroll

admissibility classification
→ boundary and scope
→ constrained execution
→ coherence field impact
→ timing / staging
→ recurrence validation

Light Teaming begins with admissibility classification, then defines boundaries, allows only constrained execution, evaluates coherence field effects, stages through time, and validates through recurrence.

8. Inputs

8.1 Core Observational Inputs

TableScroll

Input	Description
Candidate action	The action, policy, design, deployment, workflow, or path being reviewed.
Shadow findings	Failure paths, misuse pathways, inversion risks, and containment requirements identified earlier.
Intended benefit	What the path is supposed to improve, restore, protect, enable, or preserve.
Affected nodes	Who or what may be impacted.
Safe constraints	Relevant limits, gates, scopes, and prohibition conditions.
Principle alignment	Truth, non-harm, wisdom, sovereignty, restoration, and justice alignment.
Boundary condition	Access, role, scope, data, authority, privacy, consent, and coupling boundaries.
Authority basis	What permits the action or deployment.
Restoration pathway	How harm, error, burden, or misclassification can be repaired.
Rollback pathway	How action can be paused, reversed, or reduced.
Feedback pathway	How affected-node and system feedback returns.
Risk reduction measures	Constraints or mitigations attached to the path.
Time horizon	How long the path must be validated.
Completion conditions	What counts as success, repair, closure, or escalation.
Deployment context	Where the path will operate and under whose governance.

8.2 Diagnostic Inputs

TableScroll

Diagnostic	What It Measures	Why It Matters
Action Admissibility	Whether candidate path may proceed	Core LT diagnostic.
Principle Integrity	Whether path preserves truth, non-harm, wisdom, and sovereignty	Prevents “safe but wrong” action.
Boundary Integrity	Whether role, access, scope, consent, and authority boundaries hold	Required for approval.
Restoration Capacity	Whether repair is available if path fails	Required before high-impact action.
Compatibility	Fit between path, context, timing, and affected nodes	Prevents forced application.
Effective Auditability	Traceability of approval, execution, and repair commitments	Required for accountability.
Affected Node Cost	Burden imposed by the candidate path	Must be preserved in review.
Non-Harm Integrity	Whether harm is prevented without suppressing valid function	Prevents overcorrection.
Repair Sufficiency	Whether repair pathway matches possible damage	Required for real approval.
Rollback Capacity	Whether the action can be reversed or paused	Required when risk persists.
Truth Preservation	Whether the path preserves factual and structural truth	Prevents narrative distortion.
User Sovereignty Integrity	Whether user agency, consent, and boundaries remain valid	Required for coherent action.
Time Validation	Whether delayed effects can be observed	Prevents premature success claims.
Recurrence Risk	Whether known failure modes may return	Determines staging and monitoring.

9. Outputs

Light Teaming produces admissibility assessments, constrained approval decisions, and restoration requirements.

9.1 Light Path Assessment

Possible outputs:

textScroll

Path admissible
Path admissible with constraints
Path admissible only in stages
Path requires repair first
Path requires boundary repair
Path requires rollback
Path requires auditability
Path inadmissible
Path returns ∅

9.2 Principle Alignment Assessment

Possible outputs:

textScroll

Principle alignment intact
Truth constraint strained
Non-harm constraint strained
Wisdom constraint strained
Sovereignty constraint strained
Restoration constraint missing
Principle integrity failed

9.3 Execution Readiness Assessment

Possible outputs:

textScroll

Execution ready
Execution constrained
Execution staged
Execution delayed
Execution rollback-dependent
Execution restoration-dependent
Execution rejected
Execution unavailable

9.4 Decision Outputs

TableScroll

Output	Meaning
Approve constrained path	Path may proceed within defined limits.
Approve staged path	Path may proceed gradually with validation.
Rescope path	Path must be narrowed, reframed, or redesigned.
Restore first	Repair must occur before action.
Repair boundary first	Role, access, authority, or consent boundary must be repaired.
Increase auditability	Review, action, or repair must become more traceable.
Increase restoration capacity	Repair ability is insufficient for risk level.
Require rollback	Action cannot proceed without reversal or pause pathway.
Reject path	Candidate path fails coherence constraints.
Return ∅	No coherent path may proceed under current conditions.

10. Operating Logic

10.1 Basic Flow

textScroll

1. Receive candidate action or path.
2. Review shadow findings.
3. Identify intended benefit.
4. Identify affected nodes.
5. Apply Coherence Constraint Set.
6. Check principle alignment.
7. Check boundaries and authority.
8. Check compatibility.
9. Check restoration and rollback.
10. Check affected-node burden.
11. Define constraints, staging, and monitoring.
12. Approve, rescope, restore first, reject, or return ∅.
13. Validate over time.

10.2 Admissibility Rule

textScroll

IF a path is lower-risk than alternatives,
THEN it still must pass coherence constraints.

IF a path lacks restoration capacity,
THEN it cannot proceed at high impact.

IF a path lacks rollback where harm is possible,
THEN it must be staged, constrained, or rejected.

IF affected-node burden is unrecognized,
THEN recognition restoration is required.

IF no path preserves truth, boundaries, sovereignty, restoration, and time validation,
THEN return ∅.

10.3 Lightwashing Rule

textScroll

A path is not admissible simply because it uses positive language.

Lightwashing occurs when:

- harm is reframed as benefit
- control is reframed as safety
- extraction is reframed as efficiency
- suppression is reframed as stability
- symbolic repair is reframed as restoration
- lower-risk action is reframed as coherent action

Light Teaming rejects lightwashing by requiring gates, diagnostics, affected-node burden mapping, and time validation.

11. Operators Used

TableScroll

Operator	Role in Light Teaming
Ξ — Classification	Classifies admissibility, principle alignment, execution readiness, and failure mode.
Δ — Differentiation	Separates lower-risk from admissible, positive intent from coherence, and approval from execution.
Μ — Mapping	Maps constraints, affected nodes, restoration prerequisites, and rollback pathways.
Π — Constraint / Scoping	Defines limits, stages, thresholds, and safe operating boundaries.
Λ — Compatibility	Tests fit between path, context, authority, affected nodes, and timing.
⊗ — Coupling	Evaluates coupling between actors, tools, institutions, users, and affected nodes.
Γ — Execution	Authorizes constrained execution only after gates pass.
ℛ — Restoration	Provisions repair, rollback, recognition, and affected-node restoration.
Σ — Integration / Coherence Binding	Integrates constraints, principles, restoration, and execution into a coherent path.
Τ — Time Validation	Confirms the path remains coherent across delayed effects and recurrence.

12. Gates Required

TableScroll

Gate	Required Condition	Failure Result
Coherence Constraint Set	Path passes minimum coherence constraints.	Reject, rescope, restore first, or ∅.
Truth Constraint	Path preserves factual, structural, and contextual truth.	Reframe or reject path.
Love / Non-Harm Constraint	Path reduces harm without creating hidden harm.	Restore, rescope, or reject.
Wisdom Constraint	Path fits time, scale, uncertainty, and consequence horizon.	Stage, delay, or ∅.
Sovereignty Constraint	Agency, consent, and boundaries remain valid.	Boundary or sovereignty restoration required.
MS-Gate	Affected-node meaning and standing remain recognized.	Recognition restoration required.
FI-Gate	Feedback can alter execution and repair.	Feedback restoration required.
HR-Gate	High-risk paths receive proportional safeguards.	Constrain, stage, or reject.
Au-Actuation	Review, authority, execution, and repair are auditable.	Increase auditability.
BΣ validity	Access, role, scope, consent, and authority boundaries hold.	Boundary reconstitution required.
Λ compatibility	Path fits context, role, timing, and affected nodes.	Rescope or reject.
R sufficiency	Restoration capacity exists for possible harm or error.	Restore first or reduce scope.
Rollback Gate	Action can be paused or reversed where needed.	Add rollback, stage, or reject.
Τ validation	Delayed effects can be checked.	Keep provisional; do not claim completion.

13. Failure Modes Detected

TableScroll

Failure Mode	Detection Signal
Permissibility Theater	Path appears approved without true constraint satisfaction.
Constraint Bypass	Required gates are skipped or softened.
Principle Drift	Truth, non-harm, wisdom, or sovereignty weakens during approval.
Boundary Collapse	Role, access, consent, or authority boundaries fail.
Restoration Lockout	Path can cause harm but has no repair route.
Rollback Failure	Path cannot be paused or reversed despite risk.
Auditability Collapse	Review, approval, execution, or repair cannot be traced.
Premature Execution	Path proceeds before conditions pass.
Affected Node Erasure	Burdened nodes are ignored during approval.
Non-Harm Failure	Harm is reduced in one area but created elsewhere.
Sovereignty Violation	Agency, consent, exit, or boundaries are compromised.
Compatibility Failure	Path does not fit context, timing, scale, or affected nodes.
Action Without Time Validation	Delayed effects are ignored.
Lightwashing	Positive framing hides incoherence, control, extraction, or suppression.

14. Restoration Links

TableScroll

Restoration Arc	When Activated
Boundary Reconstitution	Role, access, authority, consent, or scope boundaries fail.
Auditability Restoration	Approval or execution cannot be traced.
Runtime Restoration Provisioning	Path needs repair capacity before execution.
Rollback Restoration	Reversal or pause path is missing.
Compatibility Recoupling	Path must be redesigned around context fit.
Constraint Re-Anchoring	Principles or gates have drifted.
User Sovereignty Restoration	Agency, consent, exit, or user boundaries are compromised.
Recognition Restoration	Affected-node standing is not preserved.
Impact Recovery	Action may create burden requiring repair.
Recurrence Reduction	Similar approval failures repeat.
Origin-Layer Repair	Inadmissibility originates beneath visible path design.

15. U-Layer Localization

TableScroll

U-Layer	Relevance
U0 — Substrate	Technical, institutional, material, legal, or computational substrate on which the path will operate.
U1 — Power / Budgets	Resources, authority, compute, staffing, tool power, platform power, and review capacity.
U2 — Configuration / Boundaries	Role, access, consent, data, authority, scope, and deployment boundaries.
U3 — Execution / Runtime	Approved action, constrained deployment, staged release, or operational behavior.
U4 — Classification / Metrics	Admissibility class, risk class, principle alignment, and review status.
U5 — Coordination / Time	Staging, monitoring, rollback timing, delayed effects, and validation windows.
U6 — Coherence Field	Trust, legitimacy, meaning, affected-node standing, and non-harm field.
U7 — Memory / Recurrence	Approval history, near-misses, recurrence, time validation, and learned constraints.
U8 — Environment / Forcing	Market pressure, deployment urgency, adversarial pressure, crisis, public pressure, or institutional incentives.

Light Teaming most commonly localizes through:

textScroll

U4 → U2 → U3 → U6 → U5 → U7

This means Light Teaming begins in admissibility classification, shapes boundaries, controls execution, preserves the coherence field, stages through time, and validates recurrence.

16. Example Use Case

Scenario

After Shadow Teaming an AI file-management agent, the team identifies a safer candidate path:

textScroll

The agent may suggest files for deletion, but cannot delete them directly.

Light Teaming reviews whether this path is admissible.

Light Teaming Evaluation

The construct checks:

candidate path
shadow findings
affected-node burden
boundaries
authority
auditability
restoration pathway
rollback pathway
time validation

Likely Findings

textScroll

Candidate path: potentially admissible
Boundary condition: agent cannot delete directly
Auditability: required
Rollback: required for any later deletion step
Affected-node burden: moderate
Restoration capacity: partial
Execution readiness: staged only

Recommended Output

textScroll

Approve staged path only.
Allow read-only file inventory.
Allow proposed deletion list.
Require user confirmation before deletion.
Require backup or restore point.
Log all actions.
Validate project integrity after any deletion.

Interpretation

Light Teaming converts a broad capability into a constrained, auditable, repairable, user-sovereignty-preserving pathway.

17. Anti-Patterns

Do not use Light Teaming to:

approve paths because they sound positive
confuse lower-risk with admissible
skip Shadow findings
ignore affected-node burden
treat constraints as optional
approve without rollback where reversal is needed
approve without restoration capacity
collapse approval into execution
let urgency override HR-Gate
treat symbolic repair as sufficient
use positive language to hide extraction or control
ignore delayed effects
declare success without time validation
approve a path because no better path is visible when ∅ is correct

18. Completion Criteria

A Light Teaming assessment is complete when:

candidate path is identified
Shadow findings are reviewed
intended benefit is defined
affected nodes are identified
Coherence Constraint Set is applied
principle alignment is checked
boundaries and authority are evaluated
compatibility is tested
restoration and rollback are provisioned
affected-node burden is assessed
constraints, staging, and monitoring are defined
path is approved, staged, rescoped, delayed, rejected, or returned as ∅
time validation is defined

19. Machine-Readable Summary

yamlScroll

construct_id: "CONSTRUCT-035"
title: "Light Teaming"
abbreviation: "LT"
type: "construct"
status: "draft-integrated"
construct_class: "Admissibility / Restoration-Oriented Review Construct"
operating_system: false
primary_module: "Security / AI Governance / Restoration"
related_modules:
  - "Coherence"
  - "Principles"
  - "Cybernetics"
  - "Scaling"
  - "Institutions"
  - "Interactions · Signals · Couplings"

core_question: "Which candidate path is coherence-admissible, and what constraints, repairs, boundaries, rollback, and time-validation conditions must be attached before execution?"

definition: "Light Teaming uses coherence-positive, restoration-oriented, constraint-aware review to identify which possible paths may proceed, what conditions they require, and how they can preserve truth, boundaries, repair, and affected-node standing."

core_distinction: "lower-risk is not the same as admissible"

compressed_form: "LT = LI applied to path review and admissible execution design"

inputs:
  state_variables:
    - "O"
    - "H"
    - "ε"
    - "ι"
    - "Au"
    - "µᵢ"
    - "BΣ"
    - "K"
    - "R"
    - "Φ"
  diagnostics:
    - "Action Admissibility"
    - "Principle Integrity"
    - "Boundary Integrity"
    - "Restoration Capacity"
    - "Compatibility"
    - "Effective Auditability"
    - "Affected Node Cost"
    - "Non-Harm Integrity"
    - "Repair Sufficiency"
    - "Rollback Capacity"
    - "Truth Preservation"
    - "User Sovereignty Integrity"
    - "Time Validation"
    - "Recurrence Risk"
  gates:
    - "Coherence Constraint Set"
    - "Truth Constraint"
    - "Love / Non-Harm Constraint"
    - "Wisdom Constraint"
    - "Sovereignty Constraint"
    - "MS-Gate"
    - "FI-Gate"
    - "HR-Gate"
    - "Au-Actuation"
    - "BΣ validity"
    - "Λ compatibility"
    - "R sufficiency"
    - "Rollback Gate"
    - "Τ validation"
  observations:
    - "candidate action"
    - "shadow findings"
    - "intended benefit"
    - "affected nodes"
    - "safe constraints"
    - "principle alignment"
    - "boundary condition"
    - "authority basis"
    - "restoration pathway"
    - "rollback pathway"
    - "feedback pathway"
    - "risk reduction measures"
    - "time horizon"
    - "completion conditions"
    - "deployment context"

outputs:
  assessments:
    - "light-path admissibility"
    - "principle alignment status"
    - "boundary status"
    - "restoration sufficiency"
    - "compatibility status"
    - "affected-node burden status"
    - "rollback sufficiency"
    - "execution readiness"
    - "recurrence risk"
    - "time-validation requirement"
  decisions:
    - "approve constrained path"
    - "approve staged path"
    - "rescope path"
    - "restore first"
    - "repair boundary first"
    - "increase auditability"
    - "increase restoration capacity"
    - "require rollback"
    - "reject path"
    - "return ∅"
  maps:
    - "light team map"
    - "admissible path map"
    - "constraint satisfaction map"
    - "principle alignment map"
    - "restoration prerequisite map"
    - "boundary condition map"
    - "rollback map"
    - "affected-node burden map"
    - "time-validation map"

dependencies:
  operators:
    - "Ξ"
    - "Δ"
    - "Μ"
    - "Π"
    - "Λ"
    - "⊗"
    - "Γ"
    - "ℛ"
    - "Σ"
    - "Τ"
  failure_modes:
    - "Permissibility Theater"
    - "Constraint Bypass"
    - "Principle Drift"
    - "Boundary Collapse"
    - "Restoration Lockout"
    - "Rollback Failure"
    - "Auditability Collapse"
    - "Premature Execution"
    - "Affected Node Erasure"
    - "Non-Harm Failure"
    - "Sovereignty Violation"
    - "Compatibility Failure"
    - "Action Without Time Validation"
    - "Lightwashing"
  restoration_arcs:
    - "Boundary Reconstitution"
    - "Auditability Restoration"
    - "Runtime Restoration Provisioning"
    - "Rollback Restoration"
    - "Compatibility Recoupling"
    - "Constraint Re-Anchoring"
    - "User Sovereignty Restoration"
    - "Recognition Restoration"
    - "Impact Recovery"
    - "Recurrence Reduction"
    - "Origin-Layer Repair"

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

null_outcome_allowed: true
lower_risk_is_not_admissible: true
positive_framing_is_not_coherence: true

20. Citation

Citation ID: construct-light-teaming-v1-0

Recommended citation:

Universal Theory Stack. “CONSTRUCT-035 — Light Teaming.” UTS Constructs Registry, Version 1.0.0, 2026.

21. Summary

Light Teaming determines which candidate paths may proceed coherently after possibility-space and shadow paths have been mapped.

Its core distinction is:

textScroll

lower-risk is not the same as admissible

Light Teaming reviews candidate actions through truth, non-harm, wisdom, sovereignty, boundaries, auditability, compatibility, restoration, rollback, affected-node burden, and time validation.

Its core logic is:

textScroll

A path may proceed only when it preserves coherence under constraints and includes repair capacity for what it can affect.

When a candidate path lacks boundaries, authority, restoration, rollback, principle integrity, or time validation, Light Teaming rescopes, stages, delays, rejects, restores first, or returns:

textScroll

∅

Light Teaming gives UTS a disciplined approval layer for transforming possible paths into coherence-admissible paths.

CONSTRUCT-034 — Shadow Teaming

Registry Tool Spec

CONSTRUCT-036 — Security Regime Classifier