# VectorShell Memory System Import Authority For HyperTwist - 2026-05-25

*Copied from VectorShell authority: 2026-05-25*  
*Status: Active cross-project memory reference; VectorShell remains canonical*

## Purpose

This file exists so a HyperTwist instance can find, inspect, and if necessary
adopt the current VectorShell memory system doctrine without guessing which
files matter.

This is an import-facing operating copy.

It is not the canonical source of truth.

The canonical source remains the VectorShell docs and first-party code paths
listed below.

## Synchronization scope

HyperTwist already carries earlier synchronized memory-system doctrine from
VectorShell.

So this file should not be read as if HyperTwist had no prior memory import.

Its immediate purpose is narrower:

1. synchronize the latest VectorShell authority-revision rule for later memory
   and continuity donors
2. synchronize the explicit non-automatic-absorption rule
3. synchronize the required propagation behavior when an earlier authority call
   is revised by later deep-source evidence
4. preserve the path and procedure for a future fuller or wholesale import once
   the VectorShell memory system is mature enough to freeze as an export

Read this file as:

- a delta-sync on top of the earlier imported memory doctrine
- an authority map for where the live VectorShell canon now resides
- a rulebook for how HyperTwist should reason about future stronger memory
  donors

## Canonical VectorShell authority map

Open these VectorShell files first, in this order:

1. `C:\VectorShell\docs\ops\VECTORSHELL_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md`
2. `C:\VectorShell\docs\ops\VECTORSHELL_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-22.md`
3. `C:\VectorShell\docs\ops\VECTORSHELL_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-19.md`
4. `C:\VectorShell\docs\ops\VECTORSHELL_OPTIONAL_ASSISTIVE_FEATURE_DEACTIVATION_AND_REMOVABILITY_DOCTRINE_2026-05-21.md`
5. `C:\VectorShell\docs\v6_5_deep_manual_pack\VectorShell\PROVENANCE_AND_TRUST_MODEL.md`
6. `C:\VectorShell\docs\v6_5_deep_manual_pack\VectorShell\ARCHITECTURE.md`
7. `C:\VectorShell\docs\v6_5_deep_manual_pack\VectorShell\FEATURE_REGISTRY.md`
8. `C:\VectorShell\docs\ops\VECTORSHELL_0R_C_RETROACTIVE_A_R_F_BACKFILL_2026-05-19.md`
9. `C:\VectorShell\docs\ops\VECTORSHELL_0R_C_RETROACTIVE_SKILLIZATION_BACKFILL_2026-05-21.md`

Those files together define the current VectorShell memory architecture,
continuity substrate, authority hierarchy, provenance law, and repo-derived
supporting lanes.

## Current VectorShell memory doctrine in plain terms

VectorShell does not define memory as one opaque feature.

It defines a federation of bounded memory lanes with explicit ownership, explicit
write rules, explicit provenance, and explicit optional-assistive boundaries.

The current memory family includes:

- `Activity Chronicle`
- `Session Continuity`
- `Shared Context`
- `Smart Recall`
- `Cognitive Memory`
- `Knowledge Atlas`
- `Working Notes`
- `Memory Ledger`
- `Workspace Recall`
- `Preferences`
- `Compact Views`
- `Workflow Memory`

VectorShell also uses `Continuity Lattice` as the substrate short name for the
federated continuity, provenance, retrieval, and context-assembly layer that
serves these lanes.

`Continuity Lattice` is not a second memory system.

It is not allowed to replace the lane taxonomy.

## Explicit authority rules HyperTwist must understand

### 1. Default posture for new donor repos

When VectorShell encounters a new memory or continuity donor:

1. decompose the exact contested lane or sub-slice
2. compare on capability, correctness, validation, composability, and retained
   operator value
3. keep weaker later repos bounded as adjuncts instead of letting them blur
   ownership
4. do not let README similarity, convenience, or chat summaries silently
   replace canonical lane ownership

### 2. What happens if a later repo is genuinely superior

A later repo is not automatically subordinated to the old vision.

If it is clearly stronger for an exact lane or sub-slice, it may promote into a
stronger lane and may replace the earlier `A1` owner for that exact slice.

That replacement is valid only when it is:

- source-backed
- slice-local
- explicitly documented
- propagated across the dependent canon layers

### 3. What does not happen automatically

Even when a later repo is stronger, VectorShell does not automatically:

- absorb the whole repo
- widen one lane win into neighboring ownership
- let derived summaries replace raw authority
- bypass clean-room or boundary routing
- silently rewrite architecture

Full replacement is rare and requires explicit doctrine repair.

## Latest synchronization delta from VectorShell

The latest VectorShell update now makes these points explicit rather than only
implicit:

1. the existing 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 should remain bounded adjuncts rather than
   blurring lane ownership
4. any authority revision must propagate through the dependent canon layers
   instead of living only inside one new packet
5. even a clearly superior repo does not justify automatic whole-repo
   absorption or silent architecture rewrite
6. full or wholesale import remains a later deliberate option, not the default
   response to one strong donor

That is the main 2026-05-25 synchronization payload for HyperTwist.

## What HyperTwist should import if it wants the VectorShell memory system

If HyperTwist later chooses to adopt the VectorShell memory system wholesale,
import in this order:

1. doctrine and authority docs first
2. first-party data contracts and lane naming second
3. first-party continuity and workspace-recall code surfaces third
4. bounded donor-derived adjuncts only after the doctrine and first-party
   substrate are understood

Do not start by copying third-party donor code.

Start from VectorShell first-party doctrine and first-party implementation.

## Current first-party VectorShell code surfaces worth inspecting

The current live first-party continuity and workspace-recall code surfaces are
primarily here:

- `C:\VectorShell\UnrealVectorShell\Source\UnrealVectorShell\Graph\VectorShellGraphSubsystem.cpp`
- `C:\VectorShell\UnrealVectorShell\Source\UnrealVectorShell\Core\VectorShellTypes.h`
- `C:\VectorShell\UnrealVectorShell\Source\UnrealVectorShell\Foundation\VectorShellFoundationProjectionProvider.cpp`
- `C:\VectorShell\UnrealVectorShell\Source\UnrealVectorShell\Core\VectorShellSessionSaveGame.h`
- `C:\VectorShell\UnrealVectorShell\Source\UnrealVectorShell\World\VectorShellPlayerController.cpp`
- `C:\VectorShell\UnrealVectorShell\Source\UnrealVectorShell\World\VectorShellWorldShellActor.cpp`

These files do not yet mean the entire long-horizon memory doctrine is fully
implemented.

They are the present first-party continuity and projection-memory substrate.

## Import safety rules

If HyperTwist wants to incorporate VectorShell memory behavior:

1. treat the VectorShell docs above as the source of truth
2. prefer copying first-party VectorShell code and contracts over re-deriving
   from donor repos
3. if the underlying donor for a desired slice is `R3`, do not copy donor code;
   follow VectorShell's clean-room handoff and doctrine instead
4. if the desired slice is only `F2`, do not widen it to `F1` by assumption
5. if later VectorShell deep-source evaluation changes the lane authority,
   resync from VectorShell instead of treating this file as frozen canon

## Recommended present usage

Use this file as a discovery and routing document now.

Do not treat it as a frozen local fork of VectorShell memory authority.

Until VectorShell finishes more of the deep-source evaluation and the memory
lane stabilizes further, the right posture is:

- pointer-based import now
- selective bounded reuse when necessary
- full doctrine or implementation snapshot later, once VectorShell declares a
  stable export point

## HyperTwist operator addendum prompt

Use this prompt text if a HyperTwist instance needs to pick up the latest
VectorShell memory-system update:

```text
Use `C:\HyperTwist\docs\VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md` as the entrypoint for VectorShell-memory synchronization work.

Important: HyperTwist already carries earlier synchronized VectorShell memory doctrine. This file is the latest delta-sync plus the live authority map. Do not treat it as a brand-new replacement memory spec and do not re-derive the system from scattered packet notes.

Synchronize these explicit VectorShell rules:
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 canon layers instead of living only in one packet
5. stronger later repos do not justify automatic whole-repo absorption or silent architecture rewrite

Treat the VectorShell files listed in that HyperTwist doc as canonical authority. If wholesale adoption is ever needed later, import in this order: VectorShell doctrine docs first, first-party VectorShell code surfaces second, bounded donor-derived adjuncts third. Do not directly copy donor code for any `R3` slice. Until VectorShell declares a stable export point, use pointer-based synchronization and selective bounded reuse rather than freezing a stale fork.
```
