# HyperTwist Optional Assistive Feature Deactivation And Removability Doctrine

Created on `2026-05-21`.

## Purpose

This doctrine records one non-negotiable HyperTwist product rule:

- compactors
- token reducers
- token strippers
- summarizers
- prompt-shaping helpers
- memory reducers
- skill packs
- auto-trigger skills
- provider-specific overlays
- usage-optimization helpers
- coach brief compressors
- and similar assistive adjuncts

must remain optional, user-deactivatable, and removable without breaking the
core product.

This exists to block a predictable failure mode:

- assistive behavior gets woven into core training, recognition, coaching, or
  publication flows
- later removal becomes risky
- reduced or transformed outputs become harder to bypass
- users who do not want those features receive a degraded or infantilized
  product path

That outcome is not allowed.

## Core rule

HyperTwist must work correctly when every assistive adjunct in this family is
disabled.

These features may improve specific workflows.

They must not become silent mandatory infrastructure for all users.

## Scope

This doctrine applies to any feature that changes, trims, compresses,
summarizes, routes, auto-loads, or auto-shapes user-facing context or system
behavior beyond the irreducible core product flow.

Examples include:

- compact coach briefs
- condensed replay/session summaries
- token-budget reducers for provider-backed coaching
- transcript or speech-summary reducers
- prompt-context reducers
- raw-to-summary substitution helpers
- skill loading, auto-triggering, or skill recommendation systems
- usage-optimization helpers
- context-packaging helpers
- memory compactors and reduction views

## Product invariants

### 1. Core-first operation

The core product must remain usable and correct with all assistive adjuncts
off.

That means:

- no core training run depends on a compactor
- no core recognition loop depends on a skill pack
- no core session continuity depends on a summary reducer
- no core settings flow depends on prompt-shaping helpers

### 2. Self-service deactivation

Users must be able to deactivate these features themselves.

They must not need:

- donor knowledge
- hidden config edits
- operator intervention
- source-code changes

Minimum expectation:

- every user-facing assistive feature must be reachable from settings
- if it appears in a menu, toolbar, panel, or command surface, it must also
  have an explicit enable/disable or equivalent control path
- a user must be able to tell whether it is on or off

### 3. No hidden mandatory transform

No assistive adjunct may silently replace the authoritative raw path.

If a feature compacts, summarizes, strips, reduces, or reshapes information:

- the raw or fuller upstream state remains authoritative
- the reduced form is derived state
- the reduced form must not become the only recoverable state unless the user
  deliberately chose that mode and the boundary remains reversible

### 4. No inferior forced outcome

Users who disable these features must not receive a second-class product path.

Turning them off must not break:

- navigation
- session start/continue/finalize flows
- recognition or replay correctness
- publication or challenge flows
- persistence
- training history
- provider-backed speech/vision contracts

### 5. No deep interweaving into the critical path

Assistive adjuncts must not be wired directly into the irreducible core in a
way that makes later removal structurally dangerous.

They must be introduced as bounded adjunct modules with explicit interfaces.

### 6. Removability

If an assistive adjunct is removed later:

- core builds must still succeed
- core runtime must still start
- saved state must still load safely
- any derived state for that adjunct must degrade gracefully

Removal difficulty is a design smell, not a justification for keeping the
feature mandatory.

## Required implementation model

### Capability registration

Every assistive adjunct in this family should have a stable first-party
capability identity, including:

- feature id
- family
- settings key
- optional menu path
- default state
- dependency list
- produced derived artifacts
- fallback behavior when disabled

This must be a first-party registry concept, not scattered booleans.

### Layer boundary

The required architectural posture is:

- core product surface
- optional assistive feature interface
- concrete assistive implementations

not:

- core product surface directly importing arbitrary reducers, summarizers, or
  skill logic

### Global and per-feature toggles

At minimum, support:

- a global master gate for assistive adjuncts where practical
- per-feature enable/disable controls

Preferred next level:

- per-project overrides
- per-session overrides

If HyperTwist uses named context-assembly presets such as `Max-Retention Mode`
or `Economic-Retention Mode`, those presets must remain preset-backed
defaults, not rigid bundles.

They may set defaults.

They must remain overrideable at:

- global scope
- per-project scope
- per-session scope

Users must still be able to disable individual assistive adjuncts inside those
profiles.

### Settings and menu rule

If a feature is operator-visible, it should be operator-controllable.

That means:

- settings should expose durable control
- menus or command surfaces may expose immediate control
- menu visibility alone is not enough if durable settings do not exist
- hidden config-file-only control is not an acceptable default UX

### Raw versus derived state rule

Any compactor, reducer, summarizer, or helper must store its outputs as
derived state, not canonical state.

Canonical state examples:

- full training repository state
- full replay and recognition history
- full speech transcript segments
- full publication or challenge state
- full coach evidence or attempt history

Derived state examples:

- compact coach briefs
- condensed recall packets
- reduced context packets
- summary cards
- token-budget hints

Derived state must be:

- labeled as derived
- replaceable
- safe to discard
- regenerable where practical

## Context-assembly profile interaction rule

`Max-Retention Mode` and `Economic-Retention Mode` may choose different
defaults for optional assistive components such as:

- compactors
- token reducers
- token strippers
- summarizers
- memory reducers
- prompt-shaping helpers
- auto-trigger skills
- similar adjuncts

They must not make those components mandatory infrastructure.

They must remain:

- optional
- user-deactivatable
- removable
- non-authoritative

The practical rule is:

- presets may set defaults
- presets may not silently remove per-feature control
- presets may not demote the raw authoritative path
- off-state behavior remains valid and supported
- future custom profiles are allowed if they obey the same non-optional law
  surface

Examples HyperTwist must support:

- `Max-Retention Mode` with summarizers off
- `Economic-Retention Mode` with token stripping off
- `Economic-Retention Mode` with only delta or retrieval behavior active
- a custom profile with selective assistive overrides

## Non-optional law surface

The following are not optional assistive features and must not be profile-
toggled off:

- provenance retention
- authority ordering
- custody visibility
- lane separation
- clean-room boundaries
- authoritative raw-path preservation
- contradiction visibility
- rebuildability of indexes and derived views

## Donor adoption rule

Any donor-derived capability in these families must enter HyperTwist as an
optional assistive adjunct unless a later explicit product decision says
otherwise.

Donor value here is not implementation authority for core mandatory behavior.

## Memory consequence

Compacted or reduced memory views belong only to the derived lane defined by:

- `C:\HyperTwist\docs\ops\HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md`

They must not replace:

- raw chronicle/history
- session continuity
- user-authored notes
- curated knowledge
- provenance/ledger records

## Testing and acceptance rule

Any future implementation in this family should be accepted only if it passes:

1. all-assists-off test
2. single-feature-off test
3. single-feature-on test
4. removal test
5. persisted-state compatibility test
6. raw-state availability test

The acceptance standard is:

- core product still works
- disabling one adjunct removes only that adjunct
- enabling it does not mutate authority state irreversibly
- removing the implementation module does not break core build or startup
- older state still loads when the adjunct is absent
- reduced output never destroys the authoritative fuller path

## Relationship to active doctrine

Use this doctrine with:

- `C:\HyperTwist\docs\ops\HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_PROVIDER_NEUTRALITY_AND_BYOK_DOCTRINE_2026-05-21.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_SKILLIZATION_AND_COMMAND_SURFACE_DOCTRINE_2026-05-21.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md`
- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\FEATURE_REGISTRY.md`
- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\WORKBENCH_FEATURE_TARGETS.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\README.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\MODEL_OUTPUT_RULES.md`

## Governing consequence for future work

Future instances must not propose or land:

- hardwired mandatory compactors
- unavoidable skill auto-routing
- summary-only authority paths
- settings-invisible assistive behavior
- provider-specific overlays that become the only product path

unless a later explicit doctrine supersedes this one.

No such supersession exists now.
