schema_version: "1.0"

id: "FM-R-006"

title: "FM-R-006 — Repair as Compliance"

slug: "fm-r-006-repair-as-compliance"

type: "failure_mode"

status: "draft"

version: "0.1.0"

last_updated: "2026-06-19"

summary: "Repair as Compliance occurs when a system treats completion of required steps, mandated procedures, policy updates, training, forms, reports, checklists, audits, settlements, or regulatory obligations as sufficient restoration, even though the affected state, hidden debt, burden, trust, capacity, or local coherence remains unrepaired."

canonical_url: "/archive/failure-modes/registry/false-repair/fm-r-006-repair-as-compliance"

citation_id: "FM-R-006-v0-1-0"

canon:

tier: "registry"

state: "draft"

source: "UTS — Failure Modes Registry"

source_id: "FM-R-006"

classification:

family: "failure-modes"

module: "false-repair"

module_group: "restoration"

density: "advanced-reference"

audience:

• "UTS readers"
• "restoration researchers"
• "justice researchers"
• "compliance researchers"
• "cybernetics researchers"
• "security researchers"
• "AI governance researchers"
• "organizational systems researchers"
• "coherence researchers"
• "machine readers"

tags:

• "failure-modes"
• "false-repair"
• "repair-as-compliance"
• "fm-r-006-repair-as-compliance"
• "compliance"
• "procedural-theater"
• "restoration"
• "audit"
• "policy"
• "hidden-debt"
• "coherence"

aliases:

• "Repair as Compliance"
• "Compliance as Repair"
• "Checklist Repair"
• "Mandated Repair Theater"
• "Regulatory Restoration"
• "Compliance-Only Repair"
• "Policy Completion as Repair"
• "Audit Completion as Restoration"
• "Formal Compliance Repair"
• "Compliance Closure"

related:

laws:

• "Procedural Theater"
• "Pseudo-Restoration"
• "Process Inflation"
• "Cosmetic Restoration"
• "U4 Truth Substitution"
• "Success Proxy Substitution"
• "Auditability Collapse"
• "Hidden Debt Accumulation"
• "Repair Suppression via Efficiency"
• "Under-Resourced Justice"
• "Security Theater"
• "Template Capture"

invariants:

• "Compliance Is Not Restoration"
• "Policy Completion Must Not Replace Affected-State Repair"
• "Checklist Completion Must Remain Outcome-Answerable"
• "Audit Closure Must Preserve Hidden Debt"
• "Mandated Action Must Reduce Burden"
• "Formal Correctness Must Preserve Local Coherence"
• "Repair Must Be Validated by the Affected State"

operators:

• "R — Restoration Capacity"
• "Au — Auditability"
• "O — Coherence"
• "H — Hidden Debt"
• "Ψ — Observation / Interface"
• "Γ — Selection"
• "K — Constraint / Load"
• "Φ — Flow / Resource Movement"
• "BΣ — Boundary Integrity"
• "Λ — Compatibility"
• "D — Damping"
• "G — Gain"
• "Τ — Trajectory / Time"

gates:

• "Compliance / Restoration Gate"
• "Affected-State Gate"
• "Burden Reduction Gate"
• "Auditability Gate"
• "Hidden Debt Gate"
• "Outcome Gate"
• "Accountability Gate"
• "Local Coherence Gate"
• "Closure Gate"

diagnostics:

• "Compliance / Repair Delta"
• "Affected-State Change"
• "Burden Reduction"
• "Hidden Debt"
• "Audit Closure Integrity"
• "Policy Effectiveness"
• "Outcome Validity"
• "Accountability Continuity"
• "Auditability"
• "Local Coherence"

failure_modes:

• "FM-R-001 — Cosmetic Restoration"
• "FM-R-002 — Process Inflation"
• "FM-R-003 — Insight Without Load Reduction"
• "FM-R-004 — Repair Burden Externalization"
• "FM-R-005 — Stabilization Freeze"
• "FM-R-007 — Repair Suppression via Efficiency"
• "FM-R-008 — Audit Evasion in Repair"
• "FM-R-010 — Infinite Repair Loop"
• "FM-JC-001 — Procedural Theater"
• "FM-SEC-001 — Security Theater / Φ Substitution"
• "FM-AIX-006 — Template Capture"
• "FM-CORE-003 — Success Proxy Substitution"

restoration_arcs:

• "Compliance / Restoration Audit"
• "Affected-State Recheck"
• "Checklist Outcome Validation"
• "Hidden Debt Accounting"
• "Policy Effectiveness Review"
• "Audit Closure Reopening"
• "Accountability Reattachment"
• "Material Repair Activation"
• "Local Coherence Validation"
• "False Compliance Repair Dissolution"

modules:

• "False Repair"
• "Restoration"
• "Justice"
• "Compliance"
• "Cybernetics"
• "Security"
• "AI Governance"
• "Interfaces"
• "Diagnostics"
• "Coherence"

navigation:

order: 1406

parent: "failure-modes"

visible: true

provenance:

created_from: "failure-mode-registry-production"

source_thread: "UTS Failure Modes Registry production"

source_file: "content/archive/failure-modes/registry/false-repair/fm-r-006-repair-as-compliance.md"

notes: "Expanded from False Repair family index entry and aligned to normalized metadata structure. Standalone false repair entry focused on compliance steps, checklists, policy updates, mandated training, reports, audits, regulatory actions, settlements, or formal closure being treated as repair despite insufficient affected-state change or burden reduction."

entry:

failure_mode_id: "FM-R-006"

failure_family: "False Repair"

production_treatment: "Standalone Entry"

parent_modes:

• "FM-JC-001 — Procedural Theater"
• "FM-RX-001 — Pseudo-Restoration"
• "FM-CORE-003 — Success Proxy Substitution"
• "FM-CORE-006 — U4 Truth Substitution"
• "FM-AIX-006 — Template Capture"

first_gate_failure: "Compliance / Restoration Gate"

primary_hidden_debt: "Hidden debt accumulates when formal obligations are completed but the actual burden, harm, capacity gap, affected-node state, or repair debt remains unresolved."

primary_inversion: "Compliance becomes restoration; the system treats completion of required steps as proof that repair has occurred."

primary_boundary_pattern: "The boundary between formal requirement and restorative outcome collapses; procedural correctness is allowed to occupy the role of affected-state repair."

primary_signature: "Required steps are completed; compliance status improves; closure pressure rises; affected-state change remains weak or absent; hidden debt persists beneath formal correctness."

FM-R-006 — Repair as Compliance

Status: Draft

Archive Type: Failure Mode

System: Universal Theory Stack

Parent: Failure Modes

Canon Tier: Registry

Registry: Failure Modes Registry

Entry ID: FM-R-006

Family: False Repair

Production Treatment: Standalone Entry

Parent Modes: FM-JC-001 — Procedural Theater; FM-RX-001 — Pseudo-Restoration; FM-CORE-003 — Success Proxy Substitution; FM-CORE-006 — U4 Truth Substitution; FM-AIX-006 — Template Capture

0. False Repair Scope Note

This entry is conceptual and systems-oriented.

It does not treat compliance, policy updates, audits, checklists, mandated training, documentation, reporting, certification, legal settlement, regulatory response, or formal requirements as inherently failed.

Compliance can support repair.

Formal requirements can preserve coherence when they:

• clarify obligation
• preserve auditability
• prevent recurrence
• create enforceable standards
• trigger material repair
• assign responsibility
• protect affected nodes
• expose hidden debt
• validate outcomes
• remain answerable to local coherence
• reduce burden
• do not substitute for restoration

The failure begins when compliance becomes the repair.

The issue is not formal requirement.

The issue is formal completion being treated as sufficient restoration.

Repair as Compliance occurs when the system satisfies the form of repair without restoring the condition that made repair necessary.

1. Definition

Repair as Compliance occurs when a system treats completion of required steps, mandated procedures, policy updates, training, forms, reports, checklists, audits, settlements, or regulatory obligations as sufficient restoration, even though the affected state, hidden debt, burden, trust, capacity, or local coherence remains unrepaired.

The compliance act may include:

• checklist completion
• mandatory training
• policy revision
• report filing
• audit response
• regulatory submission
• legal settlement
• certification
• internal control update
• incident closure
• corrective-action plan
• remediation ticket
• consent form
• risk acceptance document
• new governance template
• committee approval
• compliance dashboard
• public accountability statement
• required disclosure
• mandated consultation
• formal apology
• process redesign
• safety review
• AI evaluation report

The core failure is:

compliance completed
repair assumed
affected-state change unverified
hidden debt remains
H↑

Repair as Compliance is not failed paperwork.

It is paperwork promoted into restoration.

2. Core Pattern

The core pattern is:

1. A harm, defect, burden, incident, breach, injustice, or restoration need appears.
2. The system identifies required compliance steps.
3. The steps are completed.
4. Completion creates evidence of responsiveness.
5. The system treats formal completion as closure.
6. Affected nodes remain burdened or unrepaired.
7. Hidden debt is excluded because the formal requirement is satisfied.
8. Accountability narrows to whether steps were completed.
9. Real restoration is delayed, diluted, or abandoned.
10. The system learns to satisfy repair requirements through procedural completion.

This failure often appears as:

we completed the required remediation

while the hidden truth may be:

the required remediation did not repair the affected state

or:

we are compliant now

while the overlooked condition is:

compliance does not prove restoration

The restorative question is:

what changed beyond the compliance record?

Repair as Compliance turns formal closure into repair theater.

3. Failure Signature

Typical signature:

compliance status↑
required steps complete
affected-state change↓
burden reduction↓
audit closure↑
H↑

Extended signature:

training completed while behavior remains unchanged
policy updated while enforcement is absent
audit finding closed while root cause remains
settlement signed while affected nodes remain unrepaired
risk accepted while exposure persists
incident closed while users still carry harm
dashboard green while repair backlog remains

Common forms include:

an organization completes mandatory training after harm but does not change workload, power, or repair pathways
a company closes audit findings with documentation but does not correct underlying control failure
a platform updates policy language while appeals remain unusable
a security team marks remediation complete after a checklist while the vulnerable architecture persists
an AI system passes an eval while user redress and correction remain absent
a justice process closes a case after formal procedure while remedy is unfunded
a regulator receives reports while affected communities remain unrepaired
a workplace creates compliance forms while employees still carry the same burden

The defining condition is not that compliance is performed.

The defining condition is that compliance is counted as repair without validating repair.

4. Primary U-Layer Origin

Common origin layers:

• U1 — Power / Budgets: compliance is cheaper, safer, and more defensible than full restoration.
• U2 — Configuration / Boundaries: repair obligations are narrowed to formal requirements.
• U3 — Execution / Runtime: teams complete steps rather than repair conditions.
• U4 — Information / Truth: compliance status substitutes for restoration truth.
• U5 — Coordination / Time: closure is allowed after steps are complete, regardless of repair timing.
• U6 — Coherence Field: compliance creates legitimacy aura.
• U7 — Memory / Recurrence: repeated compliance-based repair becomes institutional habit.
• U8 — Environment / Field: legal, regulatory, market, or reputational pressure rewards formal correctness.

Common manifestation layers:

• U2 — Boundaries: repair scope narrows to obligation scope.
• U3 — Execution: teams perform required actions.
• U4 — Truth: completion records become proof.
• U5 — Time: closure precedes state validation.
• U6 — Field: compliance calm replaces restoration.
• U7 — Memory: compliance becomes the repair template.

Repair as Compliance is primarily a U4 truth-substitution and U2 obligation-boundary failure.

The system reduces restoration to what can be formally satisfied.

5. Typical Development Sequence

A common development sequence is:

1. A failure or harm becomes visible.
2. The system identifies required remediation, policy, audit, training, or reporting steps.
3. The requirements are translated into a checklist.
4. Teams execute the checklist.
5. Completion is documented.
6. Compliance status improves.
7. The system closes the issue.
8. Affected nodes remain burdened.
9. Further repair requests are treated as outside scope because compliance was achieved.
10. Hidden debt remains.
11. Future repair is designed around what can be documented, not what reduces burden.

The loop often looks like:

harm → compliance requirement → checklist completion → closure → burden remains

Another common loop is:

affected state unchanged → more compliance required → more steps complete → state still unchanged

Repair as Compliance becomes self-reinforcing when compliance records become more authoritative than affected-state evidence.

6. Diagnostic Markers

Diagnostic markers include:

• The system can prove compliance but cannot prove affected-state repair.
• Checklists are complete while burden persists.
• Training completion is used as evidence of behavioral change.
• Policy revision is counted as implementation.
• Audit closure happens before root-cause repair.
• Settlement or documentation closes responsibility.
• The compliance function defines success more than affected nodes do.
• Metrics track completion, not relief.
• Repair requests after compliance are treated as redundant or out of scope.
• Compliance artifacts are easier to produce than restoration evidence.
• The system asks “did we complete the requirement?” before “did the burden change?”
• Restoration improves when compliance is made outcome-answerable.

Useful diagnostics:

• Compliance / Repair Delta: Compares formal completion with actual repair.
• Affected-State Change: Tests whether affected nodes improved.
• Burden Reduction: Measures whether load, harm, or constraint decreased.
• Hidden Debt: Tracks unresolved burden after compliance.
• Audit Closure Integrity: Tests whether closure reflects real correction.
• Policy Effectiveness: Determines whether policy changed practice.
• Outcome Validity: Checks whether compliance outcomes match restoration outcomes.
• Accountability Continuity: Tests whether responsibility remains after closure.
• Auditability: Traces required steps to real effect.
• Local Coherence: Tests whether formal repair improves actual coherence.

7. Related Gates

Relevant gates include:

• Compliance / Restoration Gate: Fails when formal completion is accepted as repair.
• Affected-State Gate: Fails when affected nodes remain unchanged.
• Burden Reduction Gate: Fails when compliance does not reduce load.
• Auditability Gate: Fails when compliance cannot be traced to repair.
• Hidden Debt Gate: Fails when unresolved burden is excluded after closure.
• Outcome Gate: Fails when completion metrics replace restoration outcomes.
• Accountability Gate: Fails when responsibility ends at formal compliance.
• Local Coherence Gate: Fails when compliance does not improve actual conditions.
• Closure Gate: Fails when closure follows procedure rather than repair.

The first common gate failure is usually the Compliance / Restoration Gate.

The system accepts formal satisfaction before testing restorative effect.

8. Related Operators

Relevant operators include:

• R — Restoration Capacity: Must convert compliance into actual repair.
• Au — Auditability: Should trace compliance to outcome, not only completion.
• O — Coherence: May appear high through formal correctness.
• H — Hidden Debt: Persists when compliance does not repair burden.
• Ψ — Observation / Interface: Determines what compliance makes visible.
• Γ — Selection: Selects formal steps over material repair.
• K — Constraint / Load: Remains in affected nodes if repair is absent.
• Φ — Flow / Resource Movement: Must move resources beyond the checklist.
• BΣ — Boundary Integrity: Prevents responsibility from ending at form completion.
• Λ — Compatibility: Tests whether compliance action fits actual repair need.
• D — Damping: Can slow overreaction, but may over-damp action.
• G — Gain: Incentivizes minimal formal satisfaction.
• Τ — Trajectory / Time: Tracks whether compliance leads to lasting repair.

Common operator pattern:

harm appears
Γ selects required compliance path
Ψ surfaces completion artifacts
O appears improved
Au tracks step completion
Φ repair resources remain limited
K remains on affected nodes
H persists
closure is claimed

The core operator inversion is:

compliant → repaired

instead of:

compliant + affected-state repair + burden reduction + hidden-debt accounting → repaired

Repair as Compliance turns formal correctness into restoration proxy.

9. Related Laws and Invariants

Related Laws

• Procedural Theater: formal process substitutes for repair.
• Pseudo-Restoration: appearance of restoration replaces restoration.
• Process Inflation: compliance process grows faster than burden reduction.
• Cosmetic Restoration: visible corrective action hides material non-repair.
• U4 Truth Substitution: compliance record replaces truth of affected state.
• Success Proxy Substitution: completion metrics replace repair outcomes.
• Auditability Collapse: audit tracks steps, not effects.
• Hidden Debt Accumulation: burden persists after closure.
• Repair Suppression via Efficiency: formal minimum is used to avoid full repair.
• Under-Resourced Justice: remedy remains unfunded after process.
• Security Theater: security compliance replaces security repair.
• Template Capture: templates replace situated restoration.

Related Invariants

• Compliance Is Not Restoration: formal satisfaction does not prove repair.
• Policy Completion Must Not Replace Affected-State Repair: policy must change conditions.
• Checklist Completion Must Remain Outcome-Answerable: steps must be tied to effects.
• Audit Closure Must Preserve Hidden Debt: closure cannot erase unresolved burden.
• Mandated Action Must Reduce Burden: required steps must be evaluated by repair.
• Formal Correctness Must Preserve Local Coherence: compliance must improve actual conditions.
• Repair Must Be Validated by the Affected State: affected nodes bound the truth of restoration.

10. Common False Positives

Not every compliance-based repair is Repair as Compliance.

Common false positives include:

• Compliance steps that materially reduce burden.
• Mandatory training paired with behavioral enforcement and affected-state improvement.
• Audit closure after root-cause correction.
• Policy updates that change practice and are validated.
• Regulatory response that funds repair.
• Checklist completion linked to verified outcomes.
• Settlement that includes actual remedy and hidden-debt accounting.
• Incident closure after affected nodes confirm restoration.
• Certification that reflects tested resilience.
• Compliance that triggers repair resources.
• Documentation that preserves accountability and prevents recurrence.
• Formal process that remains subordinate to affected-state validation.

Clarifying rule:

This is not Repair as Compliance unless completion of formal requirements, policies, checklists, audits, reports, training, settlements, or mandated steps is treated as restoration while actual affected-state repair, burden reduction, or hidden-debt resolution remains insufficient.

11. Common False Repairs

Common false repairs include:

• adding more checklist items
• creating stricter compliance language
• requiring annual retraining
• producing more detailed reports
• closing audit findings with new templates
• adding certification without testing conditions
• creating policy updates without enforcement capacity
• mandating documentation from affected nodes
• moving issues into compliance ownership without repair authority
• increasing reporting frequency
• adding attestations or signatures
• using legal settlement as closure without repair validation
• changing terminology in policy documents
• treating repeated compliance failure as need for more compliance
• making compliance dashboards more visible

False repair often produces the loop:

compliance fails to repair → more compliance added → restoration still absent

Another common loop is:

affected burden persists → system cites completed requirements → affected burden becomes out of scope

The repair fails because it deepens formal correctness while leaving affected-state repair unvalidated.

12. Restoration Direction

Restoration requires making compliance outcome-answerable, reopening closure where burden remains, attaching formal steps to material repair, and validating affected-state change.

Primary restoration direction:

separate compliance from repair,
validate affected-state change,
account hidden debt,
and make formal action outcome-bound

A fuller restoration path includes:

1. Name the compliance action. Identify the checklist, training, policy, audit, report, settlement, certification, or required step.
2. Name the repair burden. Identify the harm, debt, constraint, risk, capacity gap, or affected-node state requiring restoration.
3. Test compliance / repair delta. Compare formal completion to actual state change.
4. Audit hidden debt. Identify what remains unrepaired after compliance.
5. Reopen closure where needed. Reverse issue closure if affected-state repair is incomplete.
6. Attach outcomes to requirements. Define what burden reduction each step must produce.
7. Move resources beyond compliance. Fund the material work required.
8. Validate policy effectiveness. Confirm policy changes practice.
9. Validate with affected nodes. Confirm restoration from the receiving side.
10. Preserve accountability. Ensure responsibility does not end at formal completion.
11. Revise audits. Track repair effects, not only artifacts.
12. Remove non-repair steps. Eliminate compliance work that does not support restoration.
13. Install compliance/restoration gates. Prevent closure without affected-state validation.
14. Monitor recurrence. Confirm the repair holds over time.

A valid restoration path should reduce:

compliance / repair gap
unrepaired burden
formal closure error
checklist substitution
policy non-effect
hidden debt
affected-node incoherence
H

Repair as Compliance is not repaired by becoming more compliant.

It is repaired by making compliance answerable to restoration.

13. Cross-Module Links

• False Repair: Core failure where formal completion substitutes for restoration.
• Restoration: Repair requires affected-state change and hidden-debt reduction.
• Justice: Legal or procedural satisfaction cannot replace remedy.
• Compliance: Compliance systems must remain outcome-bound.
• Cybernetics: Formal controls can become Goodhart targets and feedback suppressors.
• Security: Security compliance can hide unresolved vulnerabilities.
• AI Governance: AI evals, policy checklists, safety reports, and model cards can become compliance repair when redress, correction, and affected-user restoration remain absent.
• Interfaces: Consent flows, required notices, and checkboxes can produce formal compliance without real agency.
• Diagnostics: Requires compliance/repair delta, outcome validity, affected-state, and hidden-debt diagnostics.
• Coherence: Coherence requires formal correctness to serve real restoration.

14. Relationship to Parent / Child Modes

Production treatment: Standalone Entry

This mode maps upward to:

• FM-JC-001 — Procedural Theater
• FM-RX-001 — Pseudo-Restoration
• FM-CORE-003 — Success Proxy Substitution
• FM-CORE-006 — U4 Truth Substitution
• FM-AIX-006 — Template Capture

Sibling or related False Repair modes include:

• FM-R-001 — Cosmetic Restoration
• FM-R-002 — Process Inflation
• FM-R-003 — Insight Without Load Reduction
• FM-R-004 — Repair Burden Externalization
• FM-R-005 — Stabilization Freeze
• FM-R-007 — Repair Suppression via Efficiency
• FM-R-008 — Audit Evasion in Repair
• FM-R-009 — Therapeutic Capture
• FM-R-010 — Infinite Repair Loop

Related cross-family modes include:

• FM-JC-001 — Procedural Theater
• FM-JC-004 — Under-Resourced Justice
• FM-SEC-001 — Security Theater / Φ Substitution
• FM-SEC-004 — Consent Theater / Invalid Authorization
• FM-AIX-006 — Template Capture
• FM-AIX-012 — Guardrail Meaning Compression
• FM-CORE-003 — Success Proxy Substitution
• FM-CORE-006 — U4 Truth Substitution
• FM-C-018 — Goodhart Collapse
• FM-C-020 — Measurement Back-Action Loop
• FM-RX-009 — Repair Through Suppressed Auditability
• FM-ECO-020 — Risk Model Theater

Aliases preserved from source material:

• Repair as Compliance
• Compliance as Repair
• Checklist Repair
• Mandated Repair Theater
• Regulatory Restoration
• Compliance-Only Repair
• Policy Completion as Repair
• Audit Completion as Restoration
• Formal Compliance Repair
• Compliance Closure

15. Minimal Entry Version

Definition: Repair as Compliance occurs when a system treats completion of required steps, mandated procedures, policy updates, training, forms, reports, checklists, audits, settlements, or regulatory obligations as sufficient restoration, even though the affected state, hidden debt, burden, trust, capacity, or local coherence remains unrepaired.

Signature:

compliance status↑
required steps complete
affected-state change↓
burden reduction↓
audit closure↑
H↑

Restoration direction:

• name the compliance action
• name the repair burden
• test compliance / repair delta
• audit hidden debt
• reopen closure where needed
• attach outcomes to requirements
• move resources beyond compliance
• validate policy effectiveness
• validate with affected nodes
• preserve accountability
• revise audits
• remove non-repair steps
• install compliance/restoration gates
• monitor recurrence

16. Machine-Readable Summary

failure_mode:
  id: "FM-R-006"
  name: "Repair as Compliance"
  family: "False Repair"
  production_treatment: "Standalone Entry"
  parent_modes:
    - "FM-JC-001 — Procedural Theater"
    - "FM-RX-001 — Pseudo-Restoration"
    - "FM-CORE-003 — Success Proxy Substitution"
    - "FM-CORE-006 — U4 Truth Substitution"
    - "FM-AIX-006 — Template Capture"
  primary_failure: "Completion of formal requirements, policies, checklists, audits, reports, training, settlements, or mandated steps is treated as restoration while actual affected-state repair, burden reduction, or hidden-debt resolution remains insufficient."
  source: "UTS — Failure Modes Registry"
  source_id: "FM-R-006"
  scope_note: "Conceptual and systems-oriented; does not treat compliance, policy updates, audits, checklists, mandated training, documentation, reporting, certification, legal settlement, regulatory response, or formal requirements as inherently failed."
  aliases:
    - "Repair as Compliance"
    - "Compliance as Repair"
    - "Checklist Repair"
    - "Mandated Repair Theater"
    - "Regulatory Restoration"
    - "Compliance-Only Repair"
    - "Policy Completion as Repair"
    - "Audit Completion as Restoration"
    - "Formal Compliance Repair"
    - "Compliance Closure"
  signature:
    - "compliance status↑"
    - "required steps complete"
    - "affected-state change↓"
    - "burden reduction↓"
    - "audit closure↑"
    - "H↑"
  primary_layers:
    origin:
      - "U1 — Power / Budgets"
      - "U2 — Configuration / Boundaries"
      - "U3 — Execution / Runtime"
      - "U4 — Information / Truth"
      - "U5 — Coordination / Time"
      - "U6 — Coherence Field"
      - "U7 — Memory / Recurrence"
      - "U8 — Environment / Field"
    manifestation:
      - "U2 — Boundaries"
      - "U3 — Execution"
      - "U4 — Truth"
      - "U5 — Time"
      - "U6 — Field"
      - "U7 — Memory"
  state_variables:
    - "R"
    - "Au"
    - "O"
    - "H"
    - "Ψ"
    - "Γ"
    - "K"
    - "Φ"
    - "BΣ"
    - "Λ"
    - "D"
    - "G"
    - "Τ"
  first_gate_failure: "Compliance / Restoration Gate"
  restoration:
    - "Compliance / Restoration Audit"
    - "Affected-State Recheck"
    - "Checklist Outcome Validation"
    - "Hidden Debt Accounting"
    - "Policy Effectiveness Review"
    - "Audit Closure Reopening"
    - "Accountability Reattachment"
    - "Material Repair Activation"
    - "Local Coherence Validation"
    - "False Compliance Repair Dissolution"