# HyperTwist Continuity Lattice And Context Assembly Profile Doctrine - 2026-05-23

## Purpose

This doctrine integrates the useful context-assembly and transmission-profile
improvements from the newer retained continuity framing into HyperTwist
without replacing HyperTwist's stronger existing memory doctrine.

It answers these questions:

1. what `Continuity Lattice` means inside HyperTwist
2. how it relates to the canonical `Memory Lanes`
3. what `Max-Retention Mode` and `Economic-Retention Mode` mean
4. which imported ideas are accepted, and which are rejected

## Governing relationship

The existing memory doctrine remains canonical:

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

That doctrine still owns:

- lane taxonomy
- lane authority
- write and derivation rules
- provenance rules
- custody visibility
- clean-room boundaries
- implementation order

This doctrine is additive only.

It adds:

- a short substrate name
- context-assembly profile terminology
- transmission and retrieval posture
- explicit override scope
- escalation and cost-aware routing rules

It does not replace or demote:

- lane authority
- provenance law
- custody law
- clean-room boundaries
- raw-authority preservation
- contradiction visibility
- non-regression rules

Do not treat this as a second memory system.

Do not treat this as a replacement memory theory.

The synchronized VectorShell memory authority is authoritative here, but not
frozen.

HyperTwist should therefore use pointer-based synchronization and selective
bounded reuse rather than freezing a stale local fork of the continuity or
memory canon.

## Canonical taxonomy

Use these short names inside the product taxonomy:

1. `Continuity Lattice`
   - the federated continuity, memory, provenance, retrieval, and
     context-assembly substrate
2. `Memory Lanes`
   - the bounded lane taxonomy defined in the canonical memory doctrine
3. `Max-Retention Mode`
   - the high-fidelity context-assembly profile
4. `Economic-Retention Mode`
   - the authority-aware token-economical context-assembly profile

The correct relationship is:

- `Continuity Lattice` is the substrate name only
- `Memory Lanes` remain the canonical internal memory taxonomy
- `Max-Retention Mode` and `Economic-Retention Mode` are context-assembly
  profiles over the same substrate

This is not a second memory system.

## What HyperTwist already kept and what this doctrine adds

HyperTwist already had the stronger memory architecture:

- bounded memory lanes instead of one monolithic memory blob
- raw authority surviving derivation
- session continuity distinct from cognition
- shared coordination distinct from durable memory
- optional assistive reducers and compactors

This doctrine therefore imports only what actually improves HyperTwist:

1. explicit substrate wording
2. explicit context-assembly profile wording
3. transmission and retrieval posture
4. explicit override scope
5. escalation law
6. cost-aware routing language

## Adopted continuity-profile rules

The following imported ideas fit HyperTwist and are now adopted:

1. one substrate, two context-assembly profiles
2. storage retention is separate from active transmission
3. raw authority remains preserved in both modes
4. summaries and compact views remain derived and optional
5. delta transmission is economically stronger than naive replay
6. retrieval should be lane-aware, authority-aware, and custody-aware
7. context assembly should stay reversible enough to reopen raw authority
8. escalation should happen before uncertainty becomes dangerous

State these rules explicitly:

- storage retention != active transmission
- one substrate, two context-assembly profiles
- raw authority remains preserved in both modes
- economic behavior must never silently replace truth

## Rejected flattening

The following imported tendencies are explicitly rejected:

1. one single authority ladder for everything
2. confidence as a substitute for authority
3. any framing that flattens restrictive custody or clean-room boundaries into
   a generic relevance score
4. any framing that lets compact or derived views quietly replace raw
   authority
5. any framing that lets economic optimization override provenance, custody,
   non-regression, or legal boundaries

The governing rule is:

- confidence does not outrank authority

## 2026-05-26 VectorShell delta-sync consequence

If later source-backed evidence shows a stronger repo for an exact continuity
or context-assembly sub-slice, HyperTwist may replace the earlier `A1` owner
for that exact sub-slice only.

That does not authorize:

- replacing the memory-lane taxonomy
- widening a continuity/profile win into neighboring memory-lane ownership
- automatic whole-repo absorption
- silent architecture rewrite

Weaker or partial later repos remain bounded adjuncts for the exact value they
still preserve.

## Profile definitions

`Max-Retention Mode` and `Economic-Retention Mode` are:

- preset-backed defaults
- overrideable
- not rigid bundles
- not separate storage systems
- not separate truth systems

They differ in:

- context-assembly posture
- transmission aggressiveness
- raw-authority injection behavior
- retrieval and escalation policy

They do not differ in:

- memory ownership
- truth rank
- custody law
- provenance law

## Max-Retention Mode

Purpose:

- maximize reasoning fidelity when omission risk is more dangerous than token
  cost

Use when:

- architecture doctrine is active
- memory governance is active
- clean-room extraction is active
- cross-repo consolidation is active
- contradiction-heavy work is active
- non-regression-sensitive work is active
- the user explicitly requests omission-intolerant handling

Rules:

- preserve rich authority injection
- prefer raw authority near the model
- use derived summaries only as navigation aids
- keep contradiction state explicit
- keep donor and clean-room boundary state explicit

## Economic-Retention Mode

Purpose:

- maximize useful capability per transmitted token without deleting truth

Use when:

- routine coding is active
- local debugging is active
- bounded feature work is active
- repeated build-fix loops are active
- known-scope implementation is active
- contradiction and boundary risk remain low

Rules:

- retain all authority in storage
- inject only what the current reasoning boundary requires
- prefer delta transmission
- prefer retrieval-first assembly
- prefer stable prefixes for invariant doctrine
- use summaries only as routing and navigation surfaces

## Escalation law

Escalate from `Economic-Retention Mode` to `Max-Retention Mode` before
uncertainty becomes dangerous.

Do not wait for silent semantic erosion.

Escalate if any of the following becomes true:

1. contradiction is detected
2. clean-room or restrictive custody becomes active
3. source authority becomes unclear
4. doctrine changes or branch or `HEAD` drift invalidate a compact packet
5. stale derived-view detection fires
6. unresolved contradiction count rises above the safe bound
7. the user requests exhaustive or omission-intolerant handling

Also escalate when a later VectorShell or same-family donor appears strong
enough to challenge an existing continuity or memory `A1` call and the
slice-local comparison has not yet been propagated through the dependent
HyperTwist canon surfaces.

## Preset and override law

`Max-Retention Mode` and `Economic-Retention Mode` should be implemented as
first-party preset profiles over the same `Continuity Lattice`.

The expected control model is:

1. profile selection
   - `Max-Retention Mode`
   - `Economic-Retention Mode`
   - later custom profiles where useful
2. optional assistive feature toggles
   - per-feature control for compactors, token reducers, token strippers,
     summarizers, memory reducers, prompt-shaping helpers, auto-triggered
     skills, and similar adjuncts
3. override scope
   - global
   - per-project
   - per-session
4. non-optional core law surface
   - provenance preservation
   - lane separation
   - custody visibility
   - clean-room boundaries
   - authoritative raw-path preservation
   - contradiction visibility
   - rebuildability rules for indexes and derived views

The practical rule is:

- profiles are preset-backed defaults, not locks
- singular assistive components remain individually toggleable
- future custom profiles are allowed
- off-state behavior remains valid and supported

Examples HyperTwist must be able to represent:

- `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 derived from one preset but with selective overrides

## Optional assistive adjunct governance

Assistive adjuncts remain:

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

This includes:

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

The modes may choose different defaults for those components.

They may not make those components mandatory infrastructure.

Presets may set defaults.

Users must still be able to override individual components.

## Non-optional law surface

The following are not optional assistive features and must not be toggled off
as if they were mere UX helpers:

- provenance preservation
- lane separation
- custody visibility
- clean-room boundaries
- authoritative raw-path preservation
- contradiction visibility
- rebuildability rules for indexes and derived views

Import-order note for any later broader VectorShell-memory adoption:

1. doctrine and authority docs first
2. first-party VectorShell code and contract surfaces second
3. bounded donor-derived adjuncts third

Do not directly copy donor code for any `R3` slice.

Assistive adjuncts are optional.

Governing safety and authority laws are not optional.

## Architectural distinctions

Keep these orderings separate.

Do not collapse them into one generic importance ranking.

### Truth arbitration order

Use this when deciding what is true:

1. first-party doctrine and non-regression rules
2. first-party live implementation and verified runtime state
3. lane-specific authority docs and accepted first-party packets
4. approved clean-room handoffs and deep-source donor packet conclusions
5. curated knowledge entries and user-authored notes in their own lanes
6. provenance-backed consolidated memory
7. compact or derived navigation views
8. retrieval indexes
9. shallow placeholders

### Transmission priority

Use this when assembling an active context packet:

1. current explicit user instruction
2. current packet scope
3. active local diffs, files, errors, and runtime blockers
4. minimal relevant non-regression and safety constraints
5. relevant doctrine or lane slices
6. raw authority slices
7. continuity packet
8. derived navigation summaries
9. retrieval handles for dormant but reopenable authority

Mode controls how aggressively items `5` through `9` expand.

### Retrieval priority

Use this when reopening stored authority:

1. active branch and `HEAD` aligned raw records
2. same-lane authoritative records with intact provenance
3. contradiction records and unresolved conflict objects
4. custody-bound records required by the current route
5. user-authored notes and curated knowledge where relevant
6. derived navigation views
7. rebuildable indexes and stale derived packets

### Custody visibility

Use this when deciding what a given implementation actor may see:

1. first-party authoritative surfaces
2. approved Model B safe handoffs
3. public or permissive reference surfaces
4. Model A restrictive source custody only where the workflow explicitly
   allows it

This is a visibility rule, not a truth-ranking rule.

## Target-shape guidance for future implementation

HyperTwist does not yet claim full implementation of these record shapes.

These are target-shape requirements for later work.

At minimum a future memory record should carry:

- authority class
- custody class
- lane
- provenance
- stale or superseded state
- model-visibility constraints

Future records and retrieval handles should support:

- dormant but reopenable raw authority
- explicit model-visibility constraints
- contradiction objects rather than a boolean-only contradiction flag

A future mode selector should consider:

- task risk
- cost sensitivity
- clean-room boundary
- contradiction detection
- doctrine changes
- branch or `HEAD` changes
- stale derived-view detection
- unresolved contradiction count

## Provenance and derived-memory law

Keep these rules explicit:

- raw capture remains authoritative
- derived views remain derived
- summaries are routing and navigation surfaces, not truth
- provenance survives every derivation
- compact views do not replace raw authority
- retrieval indexes remain rebuildable
- user-authored notes remain distinct from machine-derived memory
- continuity is not cognition
- shared coordination memory is not durable authority

## Discovery surfaces

This doctrine should be discoverable from:

- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\ARCHITECTURE.md`
- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\ROADMAP.md`
- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\FEATURE_REGISTRY.md`
- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\PROVENANCE_AND_TRUST_MODEL.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_OPTIONAL_ASSISTIVE_FEATURE_DEACTIVATION_AND_REMOVABILITY_DOCTRINE_2026-05-21.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\README.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\MODEL_OUTPUT_RULES.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\GENERIC_OPERATOR_SEQUENCE_AND_PROMPTING.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\bounded-implementation-workflow.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\0600-phase5r-clean-room-operator-sequence-and-handoff.md`

That is the doctrine.
