# HyperTwist Memory Lane Authority And Phase Implementation Doctrine - 2026-05-21

## Purpose

This doctrine gives HyperTwist one implementation-safe memory architecture.

It exists to answer these questions precisely:

1. what memory actually means inside HyperTwist
2. which distinct memory lanes exist
3. which lanes are already first-party owned versus still unresolved
4. how those lanes should interoperate without collapsing into one blob
5. how to implement later memory widening under HyperTwist's own phase model

This document also exists to make later product/manual work easier.

It gives stable internal names, user-facing labels, phase placement, and lane
descriptions that can later be extracted into product, help, or manual
surfaces without re-deriving the taxonomy from packet notes.

## Core thesis

HyperTwist should not ship "one memory system."

It should ship a federation of bounded memory lanes with clear ownership,
explicit data contracts, and one-way derivation rules.

The product becomes stronger when it combines:

- exact training history
- trustworthy session continuity
- explicit recall
- coach-facing durable state
- curated curriculum knowledge
- human-authored notes
- provenance and trust traceability
- workspace/cockpit recall

without confusing those layers with each other.

The product becomes weaker when it:

- lets summaries replace authority
- lets session continuity masquerade as cognition
- lets shared temporary context masquerade as durable memory
- lets compacted output become the only surviving state

## Governing rules

The following product rules are non-negotiable:

1. memory hierarchy is slice-local, not monolithic
2. raw capture remains authoritative
3. derived memory remains derived
4. user-authored notes remain distinct from machine memory
5. session continuity remains distinct from cognitive memory
6. shared coordination memory remains distinct from durable memory
7. provenance must survive every compaction or derivation step
8. assistive compactors and reducers must remain optional and deactivatable
9. memory lanes must be removable or disableable without breaking the core
10. memory implementation route follows capability authority, not route
    convenience

Companion authorities:

- `C:\HyperTwist\docs\ops\HYPERTWIST_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-20.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_OPTIONAL_ASSISTIVE_FEATURE_DEACTIVATION_AND_REMOVABILITY_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_IMPLEMENTATION_PHASE_1_KICKOFF.md`
- `C:\HyperTwist\docs\VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md`

## 2026-05-26 VectorShell memory synchronization rule

Use:

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

as the HyperTwist entrypoint for later VectorShell-memory synchronization
work.

This is a delta-sync on top of HyperTwist's earlier synchronized VectorShell
memory doctrine.

It is not permission to re-derive the memory system from scattered packet
notes and it is not a brand-new replacement memory spec.

The synchronized VectorShell rules now carried into HyperTwist are:

1. the VectorShell memory doctrine is authoritative, but not frozen
2. a later superior repo may replace an earlier `A1` only for the exact lane
   or sub-slice it is demonstrably stronger at
3. weaker or partial later repos remain bounded adjuncts instead of blurring
   lane ownership
4. authority revisions must propagate through the dependent HyperTwist canon
   layers instead of living only in one packet
5. a stronger later repo does not justify automatic whole-repo absorption or
   silent architecture rewrite

Operational consequence:

- keep HyperTwist memory and continuity authority pointer-synchronized to the
  current VectorShell canon until VectorShell declares a stable export point
- if HyperTwist later adopts the VectorShell memory system more broadly,
  import in this order:
  - VectorShell doctrine docs first
  - first-party VectorShell code and contract surfaces second
  - bounded donor-derived adjuncts third
- do not directly copy donor code for any `R3` slice
- do not let a later slice-local improvement silently widen into neighboring
  lane ownership

## 2026-05-23 continuity substrate correction

This memory doctrine remains canonical.

HyperTwist should not replace it with a new monolithic continuity concept.

Use `Continuity Lattice` only as the substrate short name for the federated
continuity, provenance, retrieval, and context-assembly layer that already
rests on these `Memory Lanes`.

The required relationship is:

- `Continuity Lattice` is the substrate name only
- `Memory Lanes` remain the governing internal taxonomy
- `Max-Retention Mode` and `Economic-Retention Mode` are preset-backed,
  overrideable context-assembly profiles over the same substrate

This import is additive only.

It may improve:

- context assembly
- transmission strategy
- override semantics
- explicit preset wording
- escalation logic
- cost-aware routing

It must not demote:

- lane authority
- provenance law
- custody law
- clean-room boundaries
- raw-authority preservation

The `2026-05-26` VectorShell synchronization delta is additive here as well.

It may revise only the exact memory or continuity sub-slice that later
source-backed evidence proves stronger.

It must not:

- replace the lane taxonomy wholesale
- widen one sub-slice win into neighboring lane ownership
- absorb a whole repo by convenience
- freeze HyperTwist on a stale local fork of VectorShell memory authority

## Current evidence posture

HyperTwist already contains real first-party memory-adjacent state in:

- `HyperTwistTrainingSubsystem`
- `HyperTwistTrainingRuntimeLibrary`
- `HyperTwistTrainingPanelWidget`
- `HyperTwistCoachDashboardWidget`
- `HyperTwistTrainingPersistenceLibrary`
- `HyperTwistContractLibrary`

That is enough to write a lane taxonomy and write-direction rules.

It is not enough to assign strong non-first-party donor `A1` authority for
every memory lane.

So this doctrine does both:

- assigns first-party ownership where current product evidence is already real
- marks external donor ownership unresolved or provisional where HyperTwist has
  not yet performed source-grounded same-family memory evaluation

Do not invent certainty beyond that.

## Canonical memory lane taxonomy

Each lane includes:

- internal lane name
- recommended user-facing label
- exact role
- current authority posture
- implementation rule

### Lane 1 - identity and policy memory

User-facing label:

- `Preferences`
- `Training Defaults`
- `Policy`

Role:

- user preferences
- trust and consent posture
- retention settings
- assistive-feature opt-in/opt-out defaults
- provider profile policy

Authority:

- `A1 / R1 / F1` - first-party HyperTwist settings and trust surfaces

Implementation rule:

- keep this lane first-party owned
- donor repos are not allowed to own consent or policy

### Lane 2 - workspace and cockpit recall memory

User-facing label:

- `Workspace Recall`
- `Cockpit Recall`

Role:

- dashboard state
- panel state
- active training selection
- recent context
- focus/inspection anchors

Authority:

- `A1 / R1 / F1` - first-party current training/runtime/dashboard surfaces

Implementation rule:

- preserve current first-party runtime/UI persistence as authority
- later memory lanes may reference these anchors, not own them

### Lane 3 - chronicle and episodic capture memory

User-facing label:

- `Activity Chronicle`
- `Training Chronicle`

Role:

- append-only attempt history
- recognition event history
- speech transcript segments
- challenge/publication event history
- imported deck/session event grouping

Authority:

- `A1 / R1 / F1` - first-party repository and training-history surfaces
- external donor authority unresolved in current HyperTwist packet set

Implementation rule:

- append-only by default
- every higher memory lane must be able to point back to chronicle evidence

### Lane 4 - continuity and resume memory

User-facing label:

- `Session Continuity`
- `Resume Packs`

Role:

- active run state
- resume pointers
- in-progress recognition sessions
- in-progress speech sessions
- next-step follow-up continuity

Authority:

- `A1 / R1 / F1` - first-party session/run continuity in current code

Implementation rule:

- continuity may reference chronicle and cockpit recall
- it must not replace them

### Lane 5 - shared coordination memory

User-facing label:

- `Shared Context`
- `Coordination State`

Role:

- bounded state shared across coach, recognition, catalog, replay, and sidecar
  subsystems
- scoped temporary coordination
- session-local shared context

Authority:

- `A1 / R1 / F2` - provisional first-party target
- stronger external donor authority unresolved in current HyperTwist packet
  set

Implementation rule:

- keep this bounded and revocable
- do not let it absorb durable cognitive-memory responsibilities

### Lane 6 - recall and retrieval memory

User-facing label:

- `Smart Recall`
- `History Search`

Role:

- explicit search over training history
- replay lookup
- challenge/publication lookup
- curriculum/history retrieval

Authority:

- `A1 / R1 / F2` - provisional first-party target
- stronger external donor authority unresolved in current HyperTwist packet
  set

Implementation rule:

- retrieval indexes may be rebuilt
- recall results must link back to authoritative sources

### Lane 7 - cognitive and consolidated memory

User-facing label:

- `Coach Memory`
- `Long-Term Training State`

Role:

- durable player tendencies
- follow-up signals
- goals, failures, and pattern signals
- contradiction/supersession of stale derived conclusions

Authority:

- `A1 / R1 / F2` - provisional first-party target informed by current coach
  state
- stronger external donor authority unresolved in current HyperTwist packet
  set

Implementation rule:

- every consolidated fact must preserve provenance links
- silent overwrite is not allowed

### Lane 8 - knowledge and wiki memory

User-facing label:

- `Training Atlas`
- `Knowledge Bundle`

Role:

- curated curriculum
- hypercubing knowledge
- imported knowledge bundles
- method references and publication-facing knowledge

Authority:

- `A1 / R1 / F2` - first-party current knowledge/curriculum surfaces

Implementation rule:

- keep this browsable and explicitly reviewable
- do not auto-promote chronicle output into knowledge without rules

### Lane 9 - user-authored notes memory

User-facing label:

- `Training Notes`
- `Notebook`

Role:

- human-authored notes
- annotations
- journals
- attached references

Authority:

- owner unresolved
- current safest posture: provisional first-party target
- no strong HyperTwist packet currently authorizes an external donor `A1` call

Implementation rule:

- keep notes legible and user-owned
- do not bury note content inside opaque machine-memory structures

### Lane 10 - provenance and trust-ledger memory

User-facing label:

- `Memory Ledger`
- `Trust Ledger`

Role:

- source of a memory or recommendation
- transformation chain
- observation source
- imported bundle provenance
- confidence/supersession lineage

Authority:

- `A1 / R1 / F1` - first-party contract/provenance surfaces already present in
  current product architecture

Implementation rule:

- every non-raw memory record must be able to name its parents
- derived state must never lose lineage

### Lane 11 - derived and compacted memory

User-facing label:

- `Compact Views`
- `Coach Summaries`

Role:

- recap cards
- compact coach briefs
- token-saving context packets
- reduced session summaries

Authority:

- `A1 / R1 / F2` - first-party derived-state lane only

Implementation rule:

- derived only
- user-deactivatable
- safe to discard and regenerate
- never the sole authority path

### Lane 12 - procedural and workflow memory

User-facing label:

- `Workflow Memory`
- `Session Templates`

Role:

- durable session templates
- follow-up routines
- queue/scheduling memory
- drill workflows

Authority:

- `A1 / R1 / F1` - first-party current template, follow-up, and scheduling
  surfaces

Implementation rule:

- donor skills or prompts may inform later flows
- they must not become hidden canonical workflow memory

## Cross-lane authority summary

This is the current operational short form:

- identity and policy: first-party `A1`
- workspace/cockpit recall: first-party `A1`
- chronicle capture: first-party `A1`
- continuity/resume: first-party `A1`
- shared coordination: provisional first-party `A1`, external donor unresolved
- recall/retrieval: provisional first-party `A1`, external donor unresolved
- cognitive/consolidated: provisional first-party `A1`, external donor
  unresolved
- knowledge/wiki: first-party `A1`
- user-authored notes: unresolved owner, provisional first-party target
- provenance/trust ledger: first-party `A1`
- derived/compacted memory: first-party `A1` as derived lane only
- procedural/workflow memory: first-party `A1`

This is the corrected mature model for HyperTwist's present evidence.

No single repo owns "memory" globally.

## Data-plane contract

The product should use a layered data-plane contract rather than one shared
blob.

### Authoritative planes

These are authoritative:

1. identity and policy store
2. workspace/cockpit recall state
3. chronicle/event history
4. continuity/resume store
5. user-authored notes
6. curated knowledge objects

### Semi-authoritative synthesized planes

These are authoritative only for their own lane, but must retain lineage:

1. cognitive fact store
2. recall indexes
3. shared coordination scopes while alive

### Derived planes

These are never authoritative:

1. compact summaries
2. reduced context packets
3. ranking hints
4. coach brief summaries

## Write rules between lanes

The safe write rules are:

1. chronicle writes only to chronicle
2. continuity may reference chronicle and cockpit recall, but not rewrite
   chronicle
3. recall indexes may ingest from chronicle, continuity, notes, knowledge, and
   cognitive memory, but remain rebuildable
4. cognitive memory may ingest from chronicle and notes, but must emit
   provenance links
5. knowledge memory may ingest promoted facts, but promotion rules must be
   explicit
6. notes remain directly user-editable and must not be silently rewritten by
   cognitive memory
7. derived memory may read from any authoritative lane but may not become the
   only stored representation
8. shared coordination memory may mirror selected content temporarily, but
   expiry must remain bounded

## Recommended first-party code architecture

Do not begin with one monolithic `MemoryManager`.

Recommended module split:

- `HyperTwistMemoryCore`
  - ids
  - lane enums
  - provenance contract
  - feature toggles
  - policy access
- `HyperTwistMemoryChronicle`
  - history/event browsing
  - chronicle ingestion bridge
- `HyperTwistMemoryContinuity`
  - workstream/session binding
  - resume packs
- `HyperTwistMemoryRecall`
  - remember/recall requests
  - provenance drill-down
- `HyperTwistMemoryKnowledge`
  - curriculum/knowledge navigation
  - promotion/review surfaces
- `HyperTwistMemoryNotes`
  - notebook/note flows
- `HyperTwistMemoryDerived`
  - compact views
  - optional reducers
- `HyperTwistMemoryUI`
  - cockpit memory browser
  - lane-specific panels

These are target-shape families, not claims of current implementation.

## Phase implementation strategy

Use HyperTwist's own phase model.

### `0R`

Goal:

- source-ground future external memory donors before assigning non-first-party
  `A1` authority

### `1R`

Goal:

- contract and ledger reset for memory before feature coding

Required deliverables:

1. this doctrine
2. first-party lane/entity naming
3. authoritative-versus-derived rules
4. provenance requirements
5. feature-toggle and deactivation rules

### `2M`

Goal:

- preserve the current runtime truth without broad memory widening

Meaning:

- keep current session, repository, cockpit recall, coach summary, and
  publication history surfaces stable

### `6R-M1` - memory contracts and ledger packet

Implement:

- lane ids
- memory entity ids
- provenance links
- authoritative-versus-derived flags
- settings keys and feature gates

Current standing:

- the bounded first-party `Phase 6R-M1` memory contracts and ledger packet is
  now landed in current code
- current live `6R-M1` surfaces cover lane ids, memory entity ids, provenance
  links, authority flags, feature gates, retention profiles, and bounded
  ledger serialization
- the bounded first-party `Phase 6R-M2` chronicle and continuity packet is now
  landed in current code
- current live `6R-M2` surfaces cover chronicle events, grouped continuity
  sessions, bounded resume packs, and repo-aware continuity guards over the
  landed `6R-M1` ledger seam
- the bounded first-party `Phase 6R-M3` recall and shared-context packet is now
  landed in current code
- current live `6R-M3` surfaces cover explicit recall matches, history search,
  provenance drill-down, and revocable shared-context projections over the
  landed `6R-M1` and `6R-M2` seams
- the bounded first-party `Phase 6R-M4` cognitive consolidation packet is now
  landed in current code
- current live `6R-M4` surfaces cover provenance-backed cognitive facts,
  contradiction records, supersession links, and confidence-decay entries over
  the landed `6R-M1`, `6R-M2`, and `6R-M3` seams
- the bounded first-party `Phase 6R-M5` knowledge and notes packet is now
  landed in current code
- current live `6R-M5` surfaces cover curated knowledge objects, reviewable
  promotion decisions, and explicit user-notes posture/gate truth over the
  landed `6R-M1`, `6R-M2`, `6R-M3`, and `6R-M4` seams
- the bounded first-party `Phase 6R-M6` derived memory and optional adjunct
  packet is now landed in current code
- current live `6R-M6` surfaces cover compact summaries, reduced context
  packets, and optional digest views in explicit derived-only removable form
  over the landed `6R-M1`, `6R-M2`, `6R-M3`, `6R-M4`, and `6R-M5` seams
- the bounded first-party memory packet family is now closed through `6R-M6`

### `6R-M2` - chronicle and continuity packet

Implement:

- chronicle ledger
- session grouping
- resume packs
- repo-aware continuity guards

### `6R-M3` - recall and shared-context packet

Implement:

- explicit remember/recall
- history search
- provenance drill-down
- scoped shared-memory rules

### `6R-M4` - cognitive consolidation packet

Implement:

- fact extraction
- goals/failures/hypotheses
- contradiction handling
- supersession
- confidence decay

### `6R-M5` - knowledge and notes packet

Implement:

- curated knowledge objects
- reviewable promotion flows
- user-authored note lane if and only if ownership remains justified
- explicit note-lane availability may remain false at landing time when
  ownership is not justified

### `6R-M6` - derived memory and optional adjunct packet

Implement last:

- compact summaries
- reduced context packets
- optional digest views

This packet must prove:

- all-features-off correctness
- derived-only storage
- removability

Current standing:

- the bounded first-party `Phase 6R-M6` packet is now landed
- any later memory work must be narrower than the landed `6R-M1` through
  `6R-M6` packet family

### Clean-room-later rule

If a later boundary-sensitive notebook or memory donor becomes the strongest
owner for a bounded note lane, route that lane through clean-room work.

Do not pre-authorize that route from doctrine prose alone.

## Acceptance conditions for mature HyperTwist memory

HyperTwist should claim strong memory only when all of these are true:

1. raw training chronicle exists
2. exact session continuity exists
3. explicit recall exists
4. cognitive state is provenance-backed
5. curated knowledge is reviewable
6. user-authored notes remain legible and separate
7. workspace recall survives independently
8. every compacted form is derived
9. users can disable assistive memory features themselves
10. deletion and supersession semantics are explicit

## Routing rule for future instances

When future planning, evaluation, or implementation work touches "memory,"
name the exact lane first.

Do not use "memory" as a sufficient implementation scope by itself.

If later source work materially changes one of the provisional or unresolved
calls above, reopen only the affected earlier packet or standing note under
the cross-lane hierarchy doctrine instead of silently revising the
architecture by chat memory.

If that later source work comes through VectorShell or another stronger memory
donor, the revision must also propagate through the dependent HyperTwist canon
surfaces that currently carry memory truth:

- this memory-lane doctrine
- the continuity-lattice doctrine
- the cross-lane hierarchy doctrine
- `ARCHITECTURE.md`
- `FEATURE_REGISTRY.md`
- `PROVENANCE_AND_TRUST_MODEL.md`
