INT-016 - Support

Open archive search
Archive registry entry

INT-016 - Support

Intention registry entry INT-016 - Support, defining support as a bounded intention within the UTS interaction architecture.

draftid: intention-int-016-supportversion: 1.0.0updated: 2026-07-17
Archive Progress

This section can be read now; registry depth and cross-references are still being strengthened.

Foundation
Online

The section has a stable overview route and basic reader context.

Technical Layer
Online

A deeper technical overview is available.

Registry
Current

24 registry entries are available.

Cross-links
Curating

Related concepts are being connected conservatively for accuracy.

Jump Through This Page

Intention Registry Entry v1.0

Registry ID: INT-016

Title: Support

Family: Relational

Status: Draft

Version: 1.0.0

Primary function: Increase another system’s capacity, stability, access, resilience, or restoration potential without replacing its authorship, creating unnecessary dependency, or converting assistance into control.


0. Canonical Definition

Support is the intention to increase another system’s capacity to remain coherent, act, recover, learn, choose, participate, or develop without replacing its identity, agency, responsibility, or authorship.

Support adds capacity around a system without becoming the system.

It may provide:

  • information
  • resources
  • time
  • protection
  • access
  • companionship
  • technical assistance
  • emotional presence
  • physical aid
  • financial capacity
  • training
  • infrastructure
  • advocacy
  • translation
  • restoration resources
  • coordination
  • temporary substitution for unavailable function

Support becomes coherent when the receiving system becomes more able to:

  • understand
  • choose
  • act
  • recover
  • participate
  • refuse
  • connect
  • create
  • sustain itself
  • access alternatives
  • restore lost function
  • retain responsibility appropriate to its capacity

Support is not measured only by how much is given.

Its deeper measure is whether the supported system gains usable capacity without losing sovereignty.


1. Foundational Principle

Support strengthens another system’s capacity without becoming the author of its life, identity, choices, or trajectory.

Support requires relation, but not possession.

It requires responsiveness, but not total substitution.

It may temporarily carry load, but should not silently convert temporary assistance into permanent authority.

The basic movement of Support is:

textScroll
insufficient available capacity
→ offered or requested assistance
→ increased usable capacity
→ restored or expanded authorship
→ reduced unnecessary dependency

Support protects the distinction between:

textScroll
helping

and:

textScroll
taking over

between:

textScroll
carrying temporary load

and:

textScroll
owning future direction

and between:

textScroll
meeting need

and:

textScroll
creating dependence so the need remains

Coherent Support does not require the receiving system to become fully independent in every dimension.

Interdependence may be valid, durable, and desirable.

The relevant question is whether the relationship remains:

  • consent-valid
  • identity-preserving
  • transparent
  • proportionate
  • non-extractive
  • revisable
  • compatible with meaningful choice

2. Directional Function

Starting condition

Support commonly arises when:

  • a system lacks sufficient resources
  • capacity has been reduced
  • restoration requires assistance
  • a system is learning
  • a temporary burden exceeds available bandwidth
  • access barriers block participation
  • a vulnerable system faces preventable harm
  • knowledge exists but cannot be used without translation
  • technical function requires maintenance
  • a relationship needs additional care
  • a community lacks infrastructure
  • an individual or institution requests help
  • an emergency creates temporary dependency
  • a system possesses potential but lacks enabling conditions
  • coordination requires distributed assistance
  • a system needs accompaniment rather than replacement

Intended direction

Support seeks movement from:

textScroll
insufficient capacity
→ increased capacity
textScroll
isolation under burden
→ shared burden
textScroll
blocked access
→ usable access
textScroll
reduced restoration potential
→ increased restoration potential
textScroll
fragility
→ greater resilience
textScroll
dependency on one pathway
→ broader available pathways
textScroll
external assistance
→ increased self-authored function

Support does not seek:

textScroll
maximum assistance

It seeks:

textScroll
the form and degree of assistance that most coherently increases usable capacity while preserving identity and authorship

Intended outcome region

A coherent Support intention seeks an outcome region in which:

  • the supported system can function more effectively
  • restoration becomes more possible
  • immediate burden decreases
  • access improves
  • agency is preserved or restored
  • choices expand
  • the supported system can communicate changing needs
  • assistance remains transparent
  • dependency does not become coercive
  • responsibility remains appropriate to capacity
  • support can reduce, transform, or continue by mutual agreement
  • the supporting system does not become the sole owner of future possibility

Protected invariants

Support should preserve:

  • identity
  • authorship
  • consent
  • dignity
  • responsibility
  • boundaries
  • choice
  • reciprocity where relevant
  • truthfulness
  • proportionality
  • valid interdependence
  • meaningful exit
  • the distinction between support and substitution
  • the distinction between assistance and control
  • the distinction between dependency and relational reliance

3. Active Intention Profile

yamlScroll
aim: "Increase another system’s usable capacity, stability, access, resilience, participation, or restoration potential without replacing its authorship."

target: "A person, relationship, team, institution, community, technical system, process, body, project, or restoration pathway."

scope: "Limited to the resources, functions, barriers, or burdens relevant to the identified need and agreed purpose."

horizon: "Active until the supported system reaches the intended capacity threshold, the need changes, support transitions into stable interdependence, or the relationship ends."

priority: "May follow Witness, Invite, Connect, Clarify, Verify, Protect, Stabilize, or Restore and may precede Learn, Coordinate, Preserve, Integrate, Create, or Liberate."

forbidden_outcomes:
  - "dependency creation"
  - "authorship replacement"
  - "coercive assistance"
  - "identity override"
  - "resource leverage"
  - "support used to demand access or loyalty"
  - "concealed extraction"
  - "withdrawal designed to punish"

completion_condition: "The supported system gains sufficient usable capacity, access, stability, or restoration potential for the intended function while retaining or regaining meaningful authorship."

confidence_requirements: "The form and intensity of support must remain responsive to expressed need, observed outcomes, compatibility, and changing capacity."

reversibility_requirements: "Support should remain adjustable, transferable, reducible, or terminable without punitive consequence as needs and conditions change."

4. Admissibility

Preconditions

Support is admissible when:

  • a meaningful need, barrier, or capacity gap exists
  • assistance can plausibly improve the condition
  • the supported system consents or legitimate emergency standing exists
  • the supporter has relevant capacity
  • the proposed assistance is proportionate
  • the support does not require identity replacement
  • the supported system can participate in defining the need where possible
  • foreseeable dependency risks have been considered
  • support will not conceal the source of systemic harm
  • the supporter can remain accountable
  • exit, transfer, or review conditions can be defined

Supporting evidence

Support may be justified by:

  • explicit request
  • reduced capacity
  • observable overload
  • verified access barrier
  • restoration need
  • technical failure
  • loss of resources
  • temporary incapacity
  • environmental hazard
  • demonstrated exclusion
  • learning need
  • caregiving requirement
  • crisis
  • asymmetric burden
  • lack of safe alternatives
  • recurring failure caused by absent infrastructure
  • evidence that modest assistance would materially increase function

Consent is generally required before support alters another system’s:

  • body
  • environment
  • data
  • finances
  • relationships
  • decision process
  • workload
  • identity
  • technical systems
  • private information
  • public representation

Consent should include:

  • what support is offered
  • what conditions apply
  • what access is required
  • what data is collected
  • what obligations remain
  • how support can change
  • how it can end
  • what happens if need increases or decreases

Support may occur without prior consent only in narrowly bounded conditions such as:

  • immediate prevention of severe harm
  • temporary incapacity
  • dependent-system care
  • emergency technical intervention
  • public duty

Even then, the support should restore consent and decision authority as soon as possible.

Boundary conditions

Support must distinguish:

textScroll
increasing capacity

from:

textScroll
assuming ownership of decisions

and:

textScroll
sharing burden

from:

textScroll
making the supported system permanently indebted

Support should preserve:

  • privacy
  • self-description
  • refusal
  • partial acceptance
  • independent relationships
  • access to alternatives
  • role clarity
  • right to revise need
  • right to outgrow the support
  • right to continue valid interdependence without subordination

Capacity conditions

A system enacting Support should possess sufficient capacity to:

  • understand the need
  • listen to the supported system
  • provide relevant assistance
  • avoid overpromising
  • maintain boundaries
  • monitor outcome
  • accept feedback
  • avoid making itself indispensable
  • protect privacy
  • coordinate with other support systems
  • transfer responsibility appropriately
  • reduce support without punitive withdrawal
  • repair harm caused by incorrect assistance

Scale conditions

Support should scale according to:

  • severity of need
  • duration
  • number of affected systems
  • dependency
  • available alternatives
  • resource cost
  • urgency
  • power asymmetry
  • restoration capacity
  • consequence of withdrawal

A personal support relationship may require presence, resources, or practical help.

An institutional support system may require funding, infrastructure, rights, staffing, maintenance, and public accountability.

The larger the support system, the stronger the need for:

  • eligibility transparency
  • non-discrimination
  • appeal
  • continuity
  • distributed access
  • review
  • transition planning
  • protection against gatekeeper capture

Null conditions

textScroll
Support returns ∅ when:
  • no meaningful need or capacity gap exists
  • the supported system has declined the assistance
  • the offer primarily serves the supporter’s need for control or validation
  • assistance would reduce the recipient’s authorship
  • the supporter lacks relevant capacity
  • support would conceal or preserve the source of harm
  • a less invasive pathway is sufficient
  • the relationship depends on forced loyalty
  • the support requires unnecessary access
  • the offer creates more dependency than capacity
  • aid is conditioned upon identity change
  • the intervention would knowingly export greater harm
  • immediate protection, containment, or professional intervention is required instead
  • the support has completed and continued assistance would become overreach

5. Intention Provenance

Common sources

Support may emerge from:

  • care
  • solidarity
  • kinship
  • friendship
  • stewardship
  • professional duty
  • mutual aid
  • public responsibility
  • restoration
  • collaboration
  • mentorship
  • community
  • technical maintenance
  • accessibility
  • caregiving
  • interdependence
  • shared purpose
  • recognition of unequal burden

Legitimate provenance

Support may be coherently:

  • invited by the system requesting help
  • self-authored by a system offering available capacity
  • mutually authored through a support agreement
  • role-derived through legitimate care, maintenance, education, or public service
  • condition-derived under temporary overload or crisis
  • restoration-derived where recovery requires additional capacity
  • rights-derived where access or accommodation is owed
  • community-derived through mutual aid
  • interdependence-derived where systems validly rely upon one another

High-risk provenance

Support becomes high-risk when driven by:

  • ownership
  • savior identity
  • desire for dependence
  • status
  • guilt
  • surveillance
  • institutional reputation
  • commercial extraction
  • ideological conversion
  • fear of being unnecessary
  • desire for access
  • paternalism
  • control
  • expectation of loyalty
  • avoidance of root-cause repair

Capture vectors

Dependency capture

Support is structured so the receiving system cannot leave or develop alternatives.

Paternalistic capture

The supporter decides what the recipient needs without meaningful participation.

Savior capture

The supporter’s identity depends on remaining indispensable.

Commercial capture

Assistance becomes a pathway to profit, data, market control, or lock-in.

Institutional capture

Support preserves the institution’s authority while limiting recipient self-determination.

Resource capture

Access to essential resources is conditioned upon compliance.

Narrative capture

The supporter becomes the public author of the recipient’s recovery.

Crisis capture

Temporary assistance becomes permanent authority after the emergency ends.


6. Interaction Profile

Common interactions

Support commonly travels through:

  • assistance
  • accompaniment
  • resource provision
  • advocacy
  • translation
  • maintenance
  • mentoring
  • caregiving
  • funding
  • access provision
  • accommodation
  • technical help
  • load sharing
  • guidance
  • transportation
  • protection
  • infrastructure
  • encouragement
  • referral
  • facilitation

Supporting interactions

Support is often supported by:

  • Witness
  • Invite
  • Connect
  • Clarify
  • Verify
  • Protect
  • Coordinate
  • Stabilize
  • Restore
  • Learn
  • Preserve
  • Integrate

High-risk interactions

Support becomes high-risk when paired with:

  • unilateral decision-making
  • compulsory disclosure
  • surveillance
  • financial leverage
  • forced dependence
  • identity labeling
  • public storytelling
  • exclusive access
  • hidden data collection
  • conditional care
  • moral debt
  • abrupt withdrawal

Incompatible interactions

Support is incompatible with:

  • coerced assistance
  • deliberate dependency creation
  • punishment for refusal
  • identity replacement
  • concealed extraction
  • abandonment after induced reliance
  • denial of alternatives
  • support conditioned on loyalty
  • exploitation of vulnerability
  • taking credit for another system’s authorship
  • assistance that cannot be questioned or revised

7. Operator Profile

Primary operators

⊗ — Coupling

Creates the relational channel through which assistance can move.

Λ — Compatibility

Tests whether the support fits the receiving system and context.

ℛ — Restoration

Directs assistance toward recovery of coherent function and capacity.

K — Relational Coherence

Tracks trust, responsiveness, reciprocity, and workable support relation.

R — Restoration Capacity

Measures whether support increases the system’s ability to recover and continue.

Supporting operators

Ψ — Presence

Keeps support responsive to actual state.

Μ — Sensemaking

Interprets need, capacity, feedback, and changing conditions.

Γ — Selection

Chooses the minimum sufficient and most relevant form of assistance.

Θ — Humility

Prevents the supporter from presuming superior knowledge or ownership.

Π — Boundary

Defines access, role, scope, duration, and privacy.

Σ — Invariant Preservation

Protects identity, consent, dignity, authorship, and responsibility.

Au — Auditability

Makes resource flows, conditions, decisions, and outcomes visible.

Conditional operators

Protect

May shield the supported system while capacity is low.

Contain

May prevent support pathways from spreading harm or compromise.

Amplification

May increase access to resources, voice, or opportunity.

Attenuation

May reduce load, stimulation, demand, or pressure.

Substitution

May temporarily replace unavailable function, but must include return-of-authorship conditions.

Excluded uses

Support must not be implemented through operators used to:

  • override identity
  • remove refusal
  • create permanent indebtedness
  • preserve institutional authority over recipient needs
  • force disclosure
  • make the supporter indispensable
  • withhold alternatives
  • conceal extraction
  • define the recipient solely through need
  • convert temporary substitution into permanent control

8. Expected State Effects

TableScroll
VariableExpected directionNotes
OIncreaseAdditional capacity should improve organization and available action.
HDecreaseBurden, instability, or preventable harm should decline.
εDecrease or become manageableSupport may reduce uncertainty by adding information and options.
ιPreserve or strengthenIdentity should remain intact as capacity increases.
AuPreserve or increaseSupport terms, resource flows, and outcomes should remain visible.
µᵢPreserve or increaseMeaning integrity rises when assistance matches stated care and actual effect.
PreserveSupport must not collapse boundaries.
KIncreaseTrust and relational coherence may deepen through reliable assistance.
RIncreaseRestoration capacity is a primary target.
ΦContext-dependentSupport may amplify capacity, but can also amplify dependency if poorly structured.

State-effect caution

Support may temporarily reduce visible independence.

A system receiving assistance may:

  • rely on others
  • require accommodation
  • transfer some tasks
  • accept temporary substitution
  • use external resources

This does not automatically indicate unhealthy dependency.

The relevant questions are:

  • Does authorship remain?
  • Does capacity increase?
  • Are alternatives preserved?
  • Can terms be revised?
  • Is the reliance transparent and consent-valid?
  • Does the support relation remain compatible with dignity and exit?

9. Intention Across Time

Immediate — I₀

Immediate Support responds to a present need.

Examples:

  • providing information
  • carrying temporary load
  • offering transportation
  • repairing a tool
  • supplying resources
  • assisting with access
  • staying present during difficulty
  • translating instructions

Tactical — I₁

Tactical Support sustains capacity across a recovery, project, or transition.

Examples:

  • mentoring
  • caregiving
  • funding a workstream
  • providing accommodations
  • maintaining infrastructure
  • supporting a restoration plan
  • distributing workload
  • providing recurring technical assistance
  • coordinating community aid

Strategic — I₂

Strategic Support creates durable capacity architecture.

Examples:

  • public infrastructure
  • social safety systems
  • accessibility standards
  • mutual-aid networks
  • healthcare systems
  • educational support
  • open-source maintenance
  • public-interest funding
  • resilient supply networks
  • community institutions
  • technical support ecosystems
  • rights-backed accommodation
  • long-term caregiving systems

Identity-trajectory conflict

Support conflicts with identity trajectory when it becomes:

  • permanent helplessness
  • savior identity
  • inability to let others grow
  • dependency
  • identity built around need
  • inability to refuse assistance
  • resource control
  • loss of responsibility
  • substitution for self-authorship
  • fear of becoming unnecessary

The trajectory conflict is:

textScroll
Support as expanded capacity
⊥
Support as preserved dependency

10. Completion and Exit

Completion condition

Support is complete when:

  • the identified need is sufficiently met
  • usable capacity increases
  • the supported system can perform the intended function
  • restoration reaches the relevant threshold
  • access barriers decrease
  • support terms remain understood
  • authorship remains or returns
  • continued assistance is no longer necessary in its current form
  • stable interdependence or an alternative support pathway exists

Exit condition

Active support should end, reduce, or transition when:

  • the capacity threshold is reached
  • the supported system requests change or closure
  • assistance no longer improves outcomes
  • the supporter lacks capacity to continue
  • another pathway becomes more appropriate
  • continued help begins replacing authorship
  • the support relationship becomes coercive
  • the remaining need belongs to Learn, Coordinate, Preserve, Restore, or independent action

Common transition

Support commonly transitions into:

textScroll
Support → Learn
Support → Coordinate
Support → Preserve
Support → Restore
Support → Stabilize
Support → Integrate
Support → Create
Support → Liberate
Support → Release
Support → Connect

Recurrence condition

Support may be reactivated when:

  • capacity declines
  • conditions change
  • new barriers emerge
  • restoration regresses
  • infrastructure fails
  • a new developmental stage requires different aid
  • the supported system requests renewed help
  • environmental demand exceeds available capacity
  • prior support ended before durable alternatives formed

Non-completion warning

Support without a sufficiency threshold, transfer pathway, or authorship return can become dependency, substitution, or permanent authority.


11. Polarity Architecture

Coherent Form — Capacity Increase

The coherent form of Support:

  • responds to real need
  • preserves consent
  • increases usable capacity
  • maintains dignity
  • remains proportionate
  • protects authorship
  • supports alternatives
  • adapts through feedback
  • permits continued valid interdependence
  • reduces when its current form is no longer needed

Coherent Support leaves the receiving system more able to choose and act.

Deficit Form — Neglect or Unsupported Burden

Too little Support produces:

  • preventable failure
  • overload
  • isolation
  • inaccessible systems
  • stalled restoration
  • avoidable dependency on crisis pathways
  • unequal participation
  • loss of capacity
  • abandonment
  • burnout
  • infrastructure decay
  • exclusion through unmet need

Excess Form — Oversupport or Substitution

Too much Support produces:

  • reduced self-authorship
  • learned dependency
  • loss of confidence
  • unnecessary intervention
  • blocked skill development
  • role confusion
  • supporter exhaustion
  • recipient surveillance
  • excessive accommodation detached from current need
  • inability to transition
  • hidden control
  • narrowed alternatives

Shadow Inversion — Dependency Creation

Support inverts when assistance is structured so the receiving system becomes less able to function, refuse, or leave without the supporter.

Examples:

  • withholding knowledge required for independence
  • solving every problem instead of transferring capacity
  • controlling resources
  • isolating the recipient from alternative support
  • framing self-directed action as ingratitude
  • making access contingent on loyalty
  • maintaining crisis conditions to remain needed
  • discouraging learning
  • replacing the recipient’s voice
  • escalating assistance beyond request

Dependency creation preserves need while claiming to meet it.

Captured Form — Paternalistic Control

Captured Support grants the supporter authority to define:

  • what the supported system needs
  • which choices are acceptable
  • what progress means
  • when support may end
  • who may participate
  • what identity the recipient should adopt
  • which alternatives are permitted

Examples include:

  • aid systems without recipient governance
  • guardianship that never returns authority
  • institutional care that suppresses self-direction
  • platforms deciding what users need while hiding incentives
  • development programs imposed without local authorship
  • support conditional on cultural conformity

False Form — Support Theater

False Support creates the appearance of assistance without materially increasing capacity.

Examples:

  • resource lists without access
  • symbolic funding without operational support
  • encouragement without removing barriers
  • hotlines without staffing
  • public commitments without delivery
  • training without tools
  • accessibility claims without usable design
  • “supportive” language paired with unchanged workload
  • institutional programs designed mainly for reputation

False Support displays care while preserving the original burden.


12. Failure Modes

Formation Failure

  • The supporter assumes need without asking.
  • The desire to help is driven by status.
  • The supported system is treated as incapable.
  • The supporter mistakes discomfort for need.
  • Aid is designed around the supporter’s convenience.
  • The need is defined by an institution rather than those affected.
  • Temporary vulnerability becomes permanent identity.
  • Assistance is offered to avoid structural repair.

Scope Failure

  • Support expands beyond the identified need.
  • Access to one domain becomes access to the whole system.
  • Temporary assistance becomes permanent involvement.
  • The supporter speaks for the recipient publicly.
  • One support role becomes total relational authority.
  • Resources are conditioned upon unrelated behavior.
  • Support data is reused outside scope.

Selection Failure

  • Support is used when Protect is required.
  • Help is imposed where Witness is needed.
  • assistance replaces Learn.
  • support continues where Release is needed.
  • an individual is supported around a system that should be repaired.
  • resources are offered where decision rights are the true barrier.
  • Support is selected when the recipient has already refused.

Operator Failure

  • Compatibility is not tested.
  • boundaries are unclear.
  • resource flow is opaque.
  • assistance is unreliable.
  • feedback cannot change the method.
  • substitution lacks a return condition.
  • support increases load through coordination burden.
  • alternatives are not provided.
  • the supporter cannot recognize completion.

Boundary Failure

  • Consent is absent.
  • privacy is invaded.
  • the supported system is required to disclose more than necessary.
  • gratitude is demanded.
  • refusal triggers withdrawal of unrelated resources.
  • support becomes exclusive.
  • the recipient cannot correct public narratives.
  • personal access is treated as part of assistance.

Completion Failure

  • No capacity threshold exists.
  • support cannot reduce.
  • the supporter fears becoming unnecessary.
  • the recipient is never considered ready.
  • every improvement generates new intervention.
  • stable interdependence is mislabeled as failure.
  • temporary substitution becomes permanent authority.
  • the relationship remains organized around need after the need changes.

Validation Failure

  • Amount spent is treated as capacity gained.
  • services offered are treated as services accessed.
  • recipient gratitude is treated as successful support.
  • dependency is interpreted as proof of usefulness.
  • program participation is treated as improved outcome.
  • the supporter’s effort is measured instead of recipient capacity.
  • institutional metrics exclude burden imposed by the support system.
  • no one tests whether alternatives increased.

Attribution Failure

  • Receiving support is treated as incapacity.
  • declining help is treated as irrationality.
  • continued need is treated as unwillingness.
  • independence is treated as rejection.
  • gratitude is treated as consent to deeper access.
  • difficulty using support is blamed on the recipient.
  • reliance is automatically treated as unhealthy dependency.
  • support failure is attributed to the individual rather than the design.

13. Forbidden Outcomes

Support must not produce:

  • dependency creation
  • authorship replacement
  • coercive assistance
  • identity override
  • resource leverage
  • forced gratitude
  • loyalty demands
  • surveillance
  • concealed extraction
  • isolation from alternative support
  • punishment through withdrawal
  • paternalistic control
  • permanent substitution
  • support theater
  • assistance used to preserve structural harm

14. Declared, Operational, and Inferred Intention

Declared Signals

Declared Support commonly appears through statements such as:

  • “How can I help?”
  • “This resource is available.”
  • “I can carry part of this.”
  • “You do not have to do this alone.”
  • “What would increase your capacity?”
  • “We can make this more accessible.”
  • “I can support the process without taking it over.”
  • “The goal is for you to retain control.”

Declared supportive language does not itself prove that usable capacity will increase.

Operational Signals

Support is operationally present when:

  • relevant resources are delivered
  • barriers decrease
  • consent is respected
  • the recipient can shape the support
  • alternatives remain available
  • the supporter accepts correction
  • capacity increases
  • privacy remains intact
  • conditions are transparent
  • assistance can be reduced
  • authorship remains with the supported system
  • the recipient is not required to perform gratitude or loyalty

Outcome Signals

Support has produced a coherent outcome when:

  • usable capacity rises
  • restoration becomes more durable
  • participation improves
  • burden becomes manageable
  • choices expand
  • dependency does not become coercive
  • the supported system can increasingly direct the process
  • alternatives increase
  • support can transition without collapse
  • relational trust improves
  • the system is not reduced to its need
  • future action becomes more self-authored

Common Misattributions

  • Assuming help is coherent because it is well intended.
  • Treating resource delivery as capacity increase.
  • Assuming refusal means support is unnecessary.
  • Treating need as total identity.
  • Assuming dependence is always harmful.
  • Treating gratitude as permanent consent.
  • Assuming more assistance is always better.
  • Treating institutional support as neutral.
  • Assuming the supporter understands the need better.
  • Treating independence as the only valid completion.

15. Responsibility Profile

Responsibility analysis for Support should ask:

  • What need was identified?
  • Who defined it?
  • Was support requested or consented to?
  • Did the supporter have relevant capacity?
  • Were terms transparent?
  • Did assistance increase usable capacity?
  • Did it preserve identity and authorship?
  • Were alternatives available?
  • Did dependency increase?
  • Did the supporter gain disproportionate access or control?
  • Were resource flows auditable?
  • Could the recipient revise or end the support?
  • Was support used instead of structural repair?
  • Did withdrawal create avoidable harm?
  • Was completion defined?
  • Did the recipient’s future choice expand?
  • Were harms caused by the support repaired?

16. Restoration Profile

Restoration Triggers

Restoration is required when:

  • support becomes control
  • dependency is deliberately maintained
  • authorship is replaced
  • consent is ignored
  • resource access becomes leverage
  • the supported system is publicly appropriated
  • alternatives are blocked
  • support data is exploited
  • temporary substitution becomes permanent
  • assistance preserves structural harm
  • withdrawal is used as punishment
  • support theater leaves need unmet

Cessation Requirements

  • stop coercive assistance
  • end unauthorized access
  • cease loyalty requirements
  • stop speaking for the recipient
  • halt data extraction
  • end punitive withdrawal
  • reduce unnecessary substitution
  • stop isolating the recipient from alternatives
  • suspend aid structures that increase harm
  • cease presenting undelivered support as completed

Audit Requirements

The audit should determine:

  • what need was identified
  • who defined it
  • what support was offered
  • what resources were delivered
  • whether consent existed
  • what access was granted
  • whether alternatives remained
  • whether capacity increased
  • whether dependency increased
  • who controlled the relationship
  • who benefited
  • what burdens the support system added
  • whether withdrawal caused harm
  • whether structural causes were ignored
  • whether completion was possible

Repair Actions

Repair may require:

  • returning decision authority
  • restoring privacy
  • deleting improperly collected data
  • reopening access to alternatives
  • transferring knowledge
  • compensating for coercion or abandonment
  • delivering promised resources
  • redesigning the support around recipient-defined need
  • addressing structural barriers
  • reducing dependency
  • rebuilding trust
  • establishing safe transition
  • acknowledging paternalistic overreach

Authorship Restoration

Authorship restoration may include:

  • returning control over goals
  • allowing the supported system to define need
  • restoring refusal
  • restoring control over data and public narrative
  • providing transparent alternatives
  • ending compulsory gratitude
  • returning responsibility appropriate to capacity
  • enabling independent relationships
  • recognizing valid interdependence without hierarchy
  • allowing the system to outgrow or redefine the support

Completion Recovery

To restore completion:

  • identify the actual need
  • define the target capacity
  • align support with recipient authorship
  • transfer knowledge and resources
  • build alternatives
  • reduce unnecessary access
  • establish review points
  • transition into Learn, Coordinate, Preserve, Restore, Release, or independent action
  • end or transform the support when its current function is complete

Recurrence Prevention

  • use recipient-defined goals
  • preserve informed consent
  • provide multiple support pathways
  • audit dependency incentives
  • separate aid from loyalty
  • minimize data collection
  • define substitution limits
  • measure recipient capacity rather than supporter effort
  • require transition planning
  • preserve appeal and correction
  • distinguish interdependence from control
  • fund structural repair
  • test whether support expands future choice

17. Intention Relationships

Reinforcing Intentions

INT-013 — Connect

Connect establishes the relational channel through which support may move.

INT-014 — Invite

Invite offers support without imposing it.

INT-015 — Witness

Witness makes the actual need and experience more legible.

INT-017 — Coordinate

Coordinate organizes multiple support systems around a shared need.

INT-020 — Restore

Restore gives support a coherent recovery direction.

INT-021 — Stabilize

Stabilize may be the immediate capacity target of support.

Tension Intentions

INT-008 — Refuse

The supported system may decline assistance or limit its scope.

INT-010 — Separate

Separation may reduce access needed for support but restore necessary authorship.

INT-011 — Release

Support may need to end even when valid relationship continues.

INT-019 — Transform

Support may enable transformation or preserve an outdated configuration.

INT-023 — Liberate

Support may restore sovereignty or become the dependency structure from which liberation is required.

INT-024 — Create

Support can expand creative capacity, while excessive support may crowd out original authorship.

Common Predecessors

  • INT-003 — Clarify
  • INT-004 — Verify
  • INT-007 — Protect
  • INT-013 — Connect
  • INT-014 — Invite
  • INT-015 — Witness
  • INT-021 — Stabilize

Common Successors

  • INT-006 — Learn
  • INT-012 — Preserve
  • INT-017 — Coordinate
  • INT-019 — Transform
  • INT-020 — Restore
  • INT-021 — Stabilize
  • INT-022 — Integrate
  • INT-023 — Liberate
  • INT-024 — Create
  • INT-011 — Release

18. Domain Applications

Personal and Relational Systems

Support may involve:

  • listening
  • helping with a task
  • offering transportation
  • providing time or space
  • sharing resources
  • accompanying someone
  • helping maintain a boundary
  • offering information
  • reducing temporary burden
  • assisting without taking over

Example:

A person is moving through a demanding transition and asks for help managing several practical tasks.

Support may involve completing agreed tasks, checking whether needs change, and returning responsibility as capacity improves.

The supporter does not assume authority over the person’s larger decisions.

Organizational Systems

Support may include:

  • staffing
  • mentorship
  • funding
  • technical assistance
  • accommodations
  • operational resources
  • professional development
  • maintenance
  • infrastructure
  • knowledge transfer
  • workload balancing
  • employee assistance
  • cross-functional help

Organizational Support becomes false when programs exist primarily for reputation while workload, access, authority, and structural barriers remain unchanged.

Governance

Support may operate through:

  • public services
  • benefits
  • emergency aid
  • infrastructure
  • disability access
  • housing assistance
  • education
  • public health
  • legal aid
  • disaster recovery
  • community funding
  • economic stabilization
  • rights-backed accommodation

Governance support should increase public capacity without making basic rights conditional upon political loyalty, invasive surveillance, or permanent dependency.

Artificial Intelligence

Support in AI systems may include:

  • answering questions
  • organizing information
  • assisting creation
  • providing technical guidance
  • reducing repetitive workload
  • translating
  • improving accessibility
  • monitoring authorized systems
  • helping users compare options
  • preserving project continuity

AI Support should remain:

  • user-directed
  • bounded
  • transparent
  • correctable
  • non-coercive
  • separable from identity claims
  • subordinate to user authorship
  • revocable
  • free from hidden data extraction

Healthcare

Support may include:

  • caregiving
  • rehabilitation
  • patient education
  • mobility assistance
  • pain management
  • treatment navigation
  • emotional presence
  • home support
  • accessibility
  • care coordination
  • follow-up
  • peer support

Healthcare Support should increase patient capacity and participation without converting care into indefinite control over bodily or personal decisions.

Justice

Support may concern:

  • legal aid
  • witness assistance
  • reentry services
  • victim support
  • restorative facilitation
  • rehabilitation
  • housing and employment access
  • translation
  • disability accommodation
  • procedural guidance
  • community reintegration

Justice support should not make essential help conditional upon compelled confession, waived rights, or permanent identity as offender or victim.

Education

Support may include:

  • tutoring
  • mentorship
  • accommodations
  • assistive technology
  • learning resources
  • feedback
  • financial aid
  • peer support
  • advising
  • accessibility
  • language support
  • flexible pacing

Educational Support should increase learner authorship and competence rather than preserve dependence on the institution or instructor.

Symbolic Systems

Support may be represented through:

  • the pillar
  • the staff
  • the bridge
  • the supporting hand
  • the roots
  • the vessel
  • the shelter
  • the woven net
  • the foundation stone
  • the companion light

Symbolic Support should express enabling capacity rather than hierarchy, rescue, possession, or permanent weakness.

Game Systems

Support may operate through:

  • companion abilities
  • resource sharing
  • healing
  • protective effects
  • translation
  • navigation assistance
  • cooperative actions
  • knowledge exchange
  • temporary stat support
  • environmental aid
  • NPC accompaniment
  • restoration mechanics

A coherent game system should make support strengthen agency, unlock options, and create reciprocal relation rather than reducing companions to passive bonuses or the player to permanent dependence.


19. Compact Reference Card

textScroll
INT-016 — SUPPORT

Family:
Relational

Aim:
Increase another system’s capacity, stability, access, resilience, participation, or restoration potential without replacing its authorship.

Target:
A person, relationship, team, institution, community, technical system, project, body, process, or restoration pathway.

Preserves:
Identity, authorship, consent, dignity, responsibility, boundaries, choice, valid interdependence, and meaningful exit.

Common interactions:
Assistance, accompaniment, resource provision, mentoring, caregiving, advocacy, maintenance, accommodation, and load sharing.

Primary operators:
⊗, Λ, ℛ, K, R.

Completion:
The supported system gains sufficient usable capacity, access, stability, or restoration potential while retaining or regaining meaningful authorship.

Forbidden outcomes:
Dependency creation, authorship replacement, coercive assistance, identity override, resource leverage, hidden extraction, and punitive withdrawal.

O⁺:
Capacity increase.

O⁻:
Dependency creation.

Deficit:
Neglect or unsupported burden.

Excess:
Oversupport or substitution.

Captured form:
Paternalistic control.

False form:
Support theater.

Canon line:
Support increases another system’s capacity to act, recover, and choose without becoming the author or owner of its trajectory.

20. Canon Lockbox

  • Support is an intention, not an operator.
  • Support should increase usable capacity.
  • Support must preserve authorship.
  • Support must preserve consent.
  • Support must preserve dignity.
  • Receiving support does not erase responsibility appropriate to capacity.
  • Interdependence is not automatically dependency.
  • Assistance is not entitlement to access.
  • Help does not create ownership.
  • Gratitude is not permanent consent.
  • The supporter must tolerate correction.
  • Support should not make itself indispensable by design.
  • Support should preserve alternatives.
  • Support should address structural barriers where possible.
  • Support without consent becomes imposition.
  • Support without boundaries becomes intrusion.
  • Support without transfer may become substitution.
  • Support without completion may become permanent authority.
  • Support without actual capacity gain becomes theater.
  • Temporal recurrence determines whether support increased sovereignty or merely preserved need and dependence.

21. Canon Line

Support increases another system’s capacity to act, recover, participate, and choose while preserving its identity, dignity, responsibility, authorship, alternatives, and meaningful freedom from the support itself.