0. Interaction Scope Note

This entry is conceptual and systems-oriented.

It does not treat scope expansion, iteration, adaptation, project growth, relational deepening, role evolution, repair broadening, investigation expansion, feature growth, or interface extension as inherently failed.

Scope can validly expand.

A system may discover that a problem is larger than initially understood.

A relationship, project, process, or coupling can become more coherent by widening scope when expansion is:

• explicit
• consent-valid
• capacity-accounted
• boundary-aware
• compatibility-tested
• auditable
• reversible where needed
• matched by resources
• matched by repair capacity
• reviewed against affected-state reality
• not hidden inside small adjacent steps
• not imposed through dependency or momentum
• not treated as already authorized by original scope

The failure begins when scope expands without being named.

The issue is not growth.

The issue is scope expansion without boundary revalidation.

Scope Creep occurs when the system keeps adding “just one more” layer until the original agreement, capacity, or purpose no longer governs the actual coupling.

1. Definition

Scope Creep occurs when an interaction, coupling, agreement, repair process, role, project, interface, obligation, permission, investigation, or system relationship gradually expands beyond its original boundary without explicit revalidation, capacity accounting, consent renewal, compatibility testing, or restoration planning.

The expanding scope may involve:

• tasks
• obligations
• roles
• permissions
• data uses
• AI memory
• user profiling
• project requirements
• repair demands
• investigation reach
• emotional labor
• administrative work
• support expectations
• contract terms
• policy coverage
• governance authority
• surveillance coverage
• automation reach
• interface permissions
• model access
• public exposure
• accountability requirements
• relational expectations
• decision authority
• institutional involvement
• downstream reuse
• integration depth

The core failure is:

bounded scope
→ adjacent expansion
→ revalidation skipped
→ capacity / consent mismatch
→ H↑

Scope Creep is not simply growth.

It is growth that outruns its boundary conditions.

2. Core Pattern

The core pattern is:

1. A bounded scope is established.
2. The interaction begins within that scope.
3. Adjacent needs, opportunities, pressures, or conveniences appear.
4. The system adds adjacent scope without treating it as a new boundary event.
5. Each expansion feels small enough to avoid revalidation.
6. The cumulative scope becomes materially different from the original scope.
7. Capacity, consent, compatibility, and repair planning fall behind.
8. Affected nodes carry additional load.
9. The system normalizes the expanded scope as if it were always included.
10. Restoration requires reconstructing the scope ledger and revalidating actual boundaries.

This failure often appears as:

it is just a small addition

while the hidden truth may be:

the cumulative additions have changed the system

or:

this is naturally part of the work

while the overlooked condition is:

it may not be part of the original agreement, capacity, or consent

The restorative question is:

when did the actual scope stop matching the authorized scope?

Scope Creep turns adjacency into authorization.

3. Failure Signature

Typical signature:

scope expansion↑
boundary review↓
capacity mismatch↑
consent drift↑
obligation load↑
H↑

Extended signature:

task expands into role
role expands into obligation
permission expands into access
access expands into surveillance
repair expands into endless process
pilot expands into infrastructure
support expands into unpaid labor
conversation expands into commitment
interface feature expands into data capture

Common forms include:

a project starts with a defined deliverable and accumulates requirements without new resources
an AI assistant stores one useful detail and gradually expands into broad memory without explicit scope review
a workplace role gains extra responsibilities through repeated exception handling
a repair process expands from specific harm into indefinite accountability demands
a platform permission expands from service function to profiling and training
a contract begins with one service and adds adjacent obligations through updates
a relationship starts with one form of support and expands into constant availability expectations
an investigation begins with a narrow issue and expands into broad surveillance
an interface option creates downstream access that was not visible at consent time

The defining condition is not that scope changes.

The defining condition is that scope changes without the gates required to make the new scope valid.

4. Primary U-Layer Origin

Common origin layers:

• U1 — Power / Budgets: stronger nodes benefit from added work, access, authority, or obligation without renegotiation.
• U2 — Configuration / Boundaries: scope boundaries are weak, implicit, or not tracked.
• U3 — Execution / Runtime: additions are accepted operationally before validation.
• U4 — Information / Truth: the current expanded scope is represented as if it were original scope.
• U5 — Coordination / Time: small expansions accumulate gradually.
• U6 — Coherence Field: momentum makes expansion feel natural.
• U7 — Memory / Recurrence: repeated exceptions become normal.
• U8 — Environment / Field: institutional, market, relational, or platform pressure rewards expansion.

Common manifestation layers:

• U2 — Boundaries: scope boundary erodes.
• U3 — Execution: extra work or access becomes routine.
• U4 — Truth: expanded scope is normalized.
• U5 — Time: gradual drift hides threshold crossings.
• U6 — Field: expansion feels inevitable.
• U7 — Memory: exceptions become precedent.

Scope Creep is primarily a BΣ boundary / Τ time-drift failure.

The system loses track of the boundary as gradual expansion accumulates.

5. Typical Development Sequence

A common development sequence is:

1. Scope is defined or assumed.
2. A small adjacent addition appears.
3. The addition is accepted because it seems minor.
4. Another addition follows.
5. The system begins relying on the expanded behavior.
6. No one reconstructs the cumulative change.
7. Capacity falls behind.
8. Consent or agreement becomes stale.
9. Affected nodes experience overload, ambiguity, exposure, or unchosen obligation.
10. The expanded scope becomes new baseline.
11. Attempts to restore original boundaries are treated as withdrawal or resistance.

The loop often looks like:

small addition → normalized exception → new baseline → further addition

Another common loop is:

scope expands → capacity strains → repair needed → repair process expands scope further

Scope Creep becomes self-reinforcing when each accepted expansion becomes precedent for the next.

6. Diagnostic Markers

Diagnostic markers include:

• The system cannot state the original scope.
• Extra work, access, data use, or obligation is justified by adjacency.
• Revalidation is absent after material changes.
• Capacity does not scale with scope.
• Consent records do not match actual use.
• Exceptions become normal operating expectations.
• Affected nodes say, “this was not what I agreed to.”
• Scope is expanded through default, dependency, or momentum.
• Refusing expanded scope is treated as failure to cooperate.
• Repair or governance processes grow without end conditions.
• Hidden work appears outside official responsibility.
• Restoration improves when scope is named, bounded, and revalidated.

Useful diagnostics:

• Scope Boundary Integrity: Tests whether current scope matches authorized scope.
• Scope Expansion Rate: Measures how quickly scope grows.
• Capacity / Scope Fit: Tests whether resources scale with scope.
• Consent / Scope Fit: Determines whether consent covers actual activity.
• Obligation Drift: Tracks expansion of expected duties.
• Repair Scope Drift: Measures whether repair process becomes unbounded.
• Compatibility Fit: Tests whether expanded scope remains compatible.
• Hidden Debt: Tracks burden from unvalidated expansion.
• Auditability: Determines whether scope changes are traceable.
• Local Coherence: Tests whether expansion improves or degrades affected nodes.

7. Related Gates

Relevant gates include:

• Scope Boundary Gate: Fails when actual scope exceeds authorized scope.
• Revalidation Gate: Fails when material scope changes are not explicitly reviewed.
• Capacity Gate: Fails when scope expands without resources.
• Consent Scope Gate: Fails when old consent is applied to new scope.
• Compatibility Gate: Fails when expanded scope is not tested for fit.
• Obligation Gate: Fails when duties expand without agreement or support.
• Repair Scope Gate: Fails when restoration processes become unbounded.
• Auditability Gate: Fails when scope changes cannot be traced.
• Local Coherence Gate: Fails when expanded scope degrades actual conditions.

The first common gate failure is usually the Scope Boundary Gate.

The system fails to notice that the actual scope has crossed the original boundary.

8. Related Operators

Relevant operators include:

• BΣ — Boundary Integrity: Primary operator; preserves scope edges.
• K — Constraint / Load: Rises when added scope becomes burden.
• Au — Auditability: Tracks original scope and changes.
• Γ — Selection: Selects whether to accept, reject, defer, or revalidate additions.
• Λ — Compatibility: Tests whether expanded scope still fits.
• H — Hidden Debt: Accumulates through unaccounted scope.
• R — Restoration Capacity: Repairs overload, invalid expansion, and boundary debt.
• Ψ — Observation / Interface: Determines how scope is displayed or hidden.
• Φ — Flow / Resource Movement: Routes work, access, data, or obligations across expanded scope.
• Τ — Trajectory / Time: Tracks gradual drift and cumulative change.
• D — Damping: Should slow expansion until gates pass.
• O — Coherence: May appear high because expansion seems productive.
• G — Gain: Incentivizes scope expansion for power, profit, efficiency, or control.

Common operator pattern:

initial scope defined
G favors expansion
Γ accepts adjacent addition
BΣ scope boundary weakens
Τ drift accumulates
K rises in affected nodes
Au scope trace weakens
O appears improved through more output
H accumulates

The core operator inversion is:

adjacent → included

instead of:

adjacent + revalidated + resourced + consent-valid + compatible → included

Scope Creep turns proximity into permission.

9. Related Laws and Invariants

Related Laws

• Scope Must Remain Boundary-Bound: scope cannot drift invisibly.
• Expansion Requires Revalidation: material additions require renewed review.
• Scope Drift Creates Hidden Debt: untracked expansion stores burden.
• Consent Must Be Renewed When Scope Changes: old agreement cannot cover new scope automatically.
• Capacity Must Scale with Scope: expansion without capacity creates overload.
• Repair Scope Must Remain Outcome-Bound: restoration must not expand endlessly.
• Coupling Requires Compatibility: expanded scope changes fit conditions.
• Consent Drift: scope creep often occurs through consent drift.
• Boundary Integrity: coherent systems preserve edges.
• Hidden Debt Accumulation: unaccounted additions accumulate burden.
• Process Inflation: process can expand beyond repair.
• U4 Truth Substitution: expanded scope is represented as original scope.

Related Invariants

• Scope Must Remain Auditable: changes must be traceable.
• Scope Expansion Requires Explicit Boundary Update: additions must be named.
• Capacity Must Match Scope: resources and time must scale with demands.
• Consent Scope Must Track Actual Use: consent must fit current activity.
• Obligation Must Not Expand Invisibly: duties require agreement and support.
• Repair Scope Must Not Become Infinite: repair needs boundaries and termination.
• Scope Change Requires Local Coherence Review: expansion must improve or preserve affected-state viability.

10. Common False Positives

Not every expansion is Scope Creep.

Common false positives include:

• Scope expansion explicitly agreed to.
• New scope paired with new resources.
• Material change followed by revalidation.
• Investigation expansion justified by new evidence and bounded review.
• Repair scope widening because hidden harm is discovered and capacity is added.
• Role evolution with renegotiation and support.
• AI memory expansion with clear consent and revocation.
• Interface feature expansion with granular permission and transparency.
• Contract amendment with meaningful choice.
• Project growth with updated budget, timeline, and responsibilities.
• Temporary emergency expansion with expiration.
• Scope expansion that improves local coherence and remains auditable.

Clarifying rule:

This is not Scope Creep unless actual scope expands beyond original or authorized boundaries without explicit revalidation, capacity accounting, consent renewal, compatibility testing, or restoration planning.

11. Common False Repairs

Common false repairs include:

• documenting the expanded scope after the fact
• asking affected nodes to be flexible
• adding process around the expanded scope without reducing it
• renaming extra work as collaboration
• treating boundary restoration as lack of commitment
• adding tools to manage overload instead of reducing scope
• increasing meetings to coordinate scope creep
• asking for retroactive consent
• redefining original scope to include the expansion
• creating vague “other duties as assigned” language
• adding disclaimers to broad data use
• offering opt-out only after scope has expanded
• extending timelines without reducing obligations
• treating hidden work as professional growth
• making scope creep permanent because rollback is inconvenient

False repair often produces the loop:

scope creep exposed → scope documentation updated → expanded scope remains

Another common loop is:

overload appears → coordination added → coordination becomes more scope → overload grows

The repair fails because it legitimizes expanded scope instead of revalidating it.

12. Restoration Direction

Restoration requires reconstructing the original scope, mapping actual expansion, revalidating current scope, matching capacity and consent to scope, removing invalid additions, and installing gates that prevent invisible expansion.

Primary restoration direction:

audit scope,
revalidate expansion,
refit capacity,
and remove invalid obligations

A fuller restoration path includes:

1. Name the original scope. Identify the initial agreement, role, project, repair process, permission, or coupling.
2. Name the current scope. Identify what the system is now actually doing or expecting.
3. Map scope expansion. List added tasks, uses, obligations, exposure, access, authority, or meanings.
4. Identify threshold crossings. Determine when additions became materially different.
5. Audit consent / scope fit. Determine whether current scope is actually authorized.
6. Audit capacity / scope fit. Determine whether resources match actual demands.
7. Audit compatibility. Check whether expanded scope still fits nodes and interfaces.
8. Remove invalid scope. Roll back additions that lack consent, capacity, or fit.
9. Renegotiate valid expansion. Explicitly authorize, resource, and bound what should remain.
10. Repair scope debt. Address burden created by unvalidated expansion.
11. Restore boundaries. Reestablish limits, stop conditions, and refusal paths.
12. Update records. Make scope history and current scope auditable.
13. Install revalidation triggers. Require review when scope changes materially.
14. Validate local coherence. Confirm current scope improves or preserves affected-node viability.

A valid restoration path should reduce:

scope ambiguity
invisible obligation
capacity mismatch
consent mismatch
boundary erosion
repair sprawl
untracked expansion
hidden scope debt
H

Scope Creep is not repaired by managing a larger uncontrolled scope better.

It is repaired by making the real scope visible, bounded, consent-valid, and resourced.

13. Cross-Module Links

• Interactions / Signals / Couplings: Core ISC failure where boundaries expand gradually through interaction.
• Interfaces: Permissions, settings, defaults, feature additions, notifications, and user flows can hide scope expansion.
• AI Governance: AI memory, personalization, training, profiling, automation, and user-model integration can expand beyond initial permission or comprehension.
• Cybernetics: Scope expansion changes feedback load and control requirements.
• Justice: Investigations, remedies, settlements, testimony, and monitoring can expand beyond valid scope.
• Contracts: Terms, role clauses, renewals, and service updates can normalize scope creep.
• Organizations: Projects, roles, committees, and repair processes often expand through repeated exceptions.
• Restoration: Repair requires scope boundaries, capacity fit, and termination conditions.
• Diagnostics: Requires scope-boundary, capacity/scope, consent/scope, obligation-drift, and hidden-debt diagnostics.
• Coherence: Coherence requires scope to remain visible, bounded, and answerable to actual capacity.

14. Relationship to Parent / Child Modes

Production treatment: Standalone Entry

This mode maps upward to:

• FM-ISC-009 — Consent Drift
• FM-ISC-005 — Coupling Without Compatibility
• FM-R-002 — Process Inflation
• FM-ECO-010 — Expansion Without Capacity
• FM-CORE-002 — Hidden Debt Accumulation

Sibling or related ISC modes include:

• FM-ISC-004 — Echo Loop Amplification
• FM-ISC-005 — Coupling Without Compatibility
• FM-ISC-006 — Asymmetric Bandwidth Coupling
• FM-ISC-007 — Premature Irreversible Coupling
• FM-ISC-008 — Coupling Under False Coherence
• FM-ISC-009 — Consent Drift
• FM-ISC-011 — Invisible Intrusion
• FM-ISC-012 — Restoration Lock-In
• FM-ISC-013 — Empowerment Without Boundaries
• FM-ISC-020 — Operator Skipping

Related cross-family modes include:

• FM-R-002 — Process Inflation
• FM-R-010 — Infinite Repair Loop
• FM-ECO-010 — Expansion Without Capacity
• FM-ECO-014 — Economic Over-Constriction
• FM-ECO-026 — Dependency Lock-In
• FM-JC-007 — Manufactured Consent
• FM-CORE-002 — Hidden Debt Accumulation
• FM-CORE-006 — U4 Truth Substitution
• FM-AIX-015 — User Agency Compression
• FM-SEC-004 — Consent Theater / Invalid Authorization
• FM-MT-010 — Contractual Reality Capture
• FM-C-013 — Capacity Collapse / Control Impossibility

Aliases preserved from source material:

• Scope Creep
• Interaction Scope Creep
• Coupling Scope Creep
• Boundary Scope Drift
• Obligation Scope Creep
• Repair Scope Creep
• Permission Scope Creep
• Role Scope Creep
• Project Scope Drift
• Unbounded Scope Expansion

15. Minimal Entry Version

Definition: Scope Creep occurs when an interaction, coupling, agreement, repair process, role, project, interface, obligation, permission, investigation, or system relationship gradually expands beyond its original boundary without explicit revalidation, capacity accounting, consent renewal, compatibility testing, or restoration planning.

Signature:

scope expansion↑
boundary review↓
capacity mismatch↑
consent drift↑
obligation load↑
H↑

Restoration direction:

• name the original scope
• name the current scope
• map scope expansion
• identify threshold crossings
• audit consent / scope fit
• audit capacity / scope fit
• audit compatibility
• remove invalid scope
• renegotiate valid expansion
• repair scope debt
• restore boundaries
• update records
• install revalidation triggers
• validate local coherence

16. Machine-Readable Summary

failure_mode:
  id: "FM-ISC-010"
  name: "Scope Creep"
  family: "Interactions / Signals / Couplings"
  production_treatment: "Standalone Entry"
  parent_modes:
    - "FM-ISC-009 — Consent Drift"
    - "FM-ISC-005 — Coupling Without Compatibility"
    - "FM-R-002 — Process Inflation"
    - "FM-ECO-010 — Expansion Without Capacity"
    - "FM-CORE-002 — Hidden Debt Accumulation"
  primary_failure: "Actual scope expands beyond original or authorized boundaries without explicit revalidation, capacity accounting, consent renewal, compatibility testing, or restoration planning."
  source: "UTS — Failure Modes Registry"
  source_id: "FM-ISC-010"
  scope_note: "Conceptual and systems-oriented; does not treat scope expansion, iteration, adaptation, project growth, relational deepening, role evolution, repair broadening, investigation expansion, feature growth, or interface extension as inherently failed."
  aliases:
    - "Scope Creep"
    - "Interaction Scope Creep"
    - "Coupling Scope Creep"
    - "Boundary Scope Drift"
    - "Obligation Scope Creep"
    - "Repair Scope Creep"
    - "Permission Scope Creep"
    - "Role Scope Creep"
    - "Project Scope Drift"
    - "Unbounded Scope Expansion"
  signature:
    - "scope expansion↑"
    - "boundary review↓"
    - "capacity mismatch↑"
    - "consent drift↑"
    - "obligation load↑"
    - "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:
    - "BΣ"
    - "K"
    - "Au"
    - "Γ"
    - "Λ"
    - "H"
    - "R"
    - "Ψ"
    - "Φ"
    - "Τ"
    - "D"
    - "O"
    - "G"
  first_gate_failure: "Scope Boundary Gate"
  restoration:
    - "Scope Boundary Audit"
    - "Scope Revalidation"
    - "Capacity / Scope Refit"
    - "Consent Scope Recheck"
    - "Obligation Thinning"
    - "Repair Scope Recontainment"
    - "Compatibility Review"
    - "Scope Ledger Reconstruction"
    - "Hidden Scope Debt Accounting"
    - "Local Coherence Restoration"