diff --git a/docs/VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md b/docs/VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md new file mode 100644 index 0000000..e2da600 --- /dev/null +++ b/docs/VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md @@ -0,0 +1,227 @@ +# 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. +``` diff --git a/docs/ops/HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md b/docs/ops/HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md index 87b5ab8..63ddff2 100644 --- a/docs/ops/HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md +++ b/docs/ops/HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md @@ -18,6 +18,7 @@ It answers these questions: 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: @@ -53,6 +54,13 @@ 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: @@ -132,6 +140,22 @@ 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: @@ -222,6 +246,11 @@ Escalate if any of the following becomes true: 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 @@ -305,6 +334,14 @@ as if they were mere UX helpers: - 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. diff --git a/docs/ops/HYPERTWIST_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-20.md b/docs/ops/HYPERTWIST_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-20.md index 15ba4e2..edc7f0d 100644 --- a/docs/ops/HYPERTWIST_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-20.md +++ b/docs/ops/HYPERTWIST_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-20.md @@ -79,6 +79,9 @@ Use these slice-local tiers: Do not force whole-repo winner-take-all decisions when the source reality is subsystem-specific. +Later superior evidence may replace an earlier `A1`, but only for the exact +contested slice or sub-slice it is demonstrably stronger at. + ### Axis R - execution route This is not hierarchy. @@ -212,6 +215,11 @@ If repo `X` wins `A1` for a slice and repo `Y` still has unique value: - the packet must say exactly what survives from `Y` - that value must not disappear merely because `X` won primary ownership +Weaker or partial later repos remain bounded adjuncts. + +Do not let a later partial winner blur neighboring ownership merely because it +arrived later or is more convenient to implement. + ### Rule 4 - split coarse overlaps into sub-slices If each repo is stronger at different sub-parts of an apparent overlap, do not @@ -329,5 +337,20 @@ Required rule: authority changed - name the exact earlier packet or standing note reopened +If the revision affects active memory or continuity canon, propagate the +corrected slice-local authority through the dependent HyperTwist canon layers +instead of leaving the change inside one packet or one reopen note. + +At minimum propagate through: + +- `HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md` +- `HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md` +- `ARCHITECTURE.md` +- `FEATURE_REGISTRY.md` +- `PROVENANCE_AND_TRUST_MODEL.md` + +Stronger later evidence does not justify automatic whole-repo absorption or +silent architecture rewrite. + Backfill only where the hierarchy model materially changes interpretation, implementation routing, checkpoint gating, or preserved secondary value. diff --git a/docs/ops/HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md b/docs/ops/HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md index 2293f82..e0c752b 100644 --- a/docs/ops/HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md +++ b/docs/ops/HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md @@ -67,6 +67,47 @@ Companion authorities: - `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 @@ -104,6 +145,18 @@ It must not demote: - 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: @@ -673,3 +726,14 @@ 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` diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/ARCHITECTURE.md b/docs/v6_5_deep_manual_pack/HyperTwist/ARCHITECTURE.md index e4daa64..e94dec8 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/ARCHITECTURE.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/ARCHITECTURE.md @@ -22,6 +22,8 @@ Use these alongside this document: for memory-lane architecture - `C:\HyperTwist\docs\ops\HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md` for continuity substrate and context-assembly profiles +- `C:\HyperTwist\docs\VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md` + for the live VectorShell-memory authority map and delta-sync rule - `C:\HyperTwist\docs\ops\HYPERTWIST_OPTIONAL_ASSISTIVE_FEATURE_DEACTIVATION_AND_REMOVABILITY_DOCTRINE_2026-05-21.md` for optional assistive and off-state governance - `C:\HyperTwist\docs\ops\HYPERTWIST_PROVIDER_NEUTRALITY_AND_BYOK_DOCTRINE_2026-05-21.md` @@ -153,6 +155,15 @@ Do not treat memory as one opaque monolith. Do not treat provider-specific donors as top-level contract owners. +For cross-project memory synchronization, use: + +- `C:\HyperTwist\docs\VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md` + +as the live VectorShell-memory entrypoint. + +This is a pointer-based synchronization surface, not a frozen local fork and +not a brand-new replacement memory spec. + Those two corrections are governed by: - `C:\HyperTwist\docs\ops\HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md` @@ -187,6 +198,23 @@ It does not mean: - summary-first authority - a second memory system competing with the established memory-lane doctrine +It also does not mean: + +- automatic whole-repo absorption when a later donor wins one exact memory + sub-slice +- silent architecture rewrite from one packet-local authority revision +- direct donor-code copying for an `R3` slice + +If HyperTwist later needs a broader VectorShell-memory import, do it in this +order: + +1. VectorShell doctrine and authority docs first +2. first-party VectorShell code and contract surfaces second +3. bounded donor-derived adjuncts third + +Until VectorShell declares a stable export point, keep the synchronization +pointer-based and slice-local. + ## Skillization correction Do not let donor commands or optional skills become hidden product truth. diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md b/docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md index 7fa3f6b..00dfb4b 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md @@ -48,6 +48,7 @@ Primary authority surfaces behind this registry: - `C:\HyperTwist\docs\ops\HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md` - `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\VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.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` - the relevant implementation packet docs @@ -244,10 +245,10 @@ repo. |---|---|---|---| | Session continuity and workspace recall fragments | Implemented now | first-party runtime/training surfaces | Real substrate fragments under the canonical `Memory Lanes`; not yet a full lane implementation. | | Provenance-aware training/replay/publication state | Implemented now | first-party contract/provenance surfaces | Existing product truth. | -| Layered memory federation | Deep-source grounded retained | memory doctrine | Governing taxonomy exists; lane widening remains future work. | -| Continuity Lattice context assembly | Deep-source grounded retained | continuity-lattice doctrine | One federated substrate with two preset-backed, overrideable profiles: `Max-Retention Mode` and `Economic-Retention Mode`. This is not a second memory system and does not weaken lane authority or optional-assistive override control. | +| Layered memory federation | Deep-source grounded retained | memory doctrine + VectorShell import entrypoint | Governing taxonomy exists; HyperTwist uses pointer-based synchronization to the current VectorShell memory canon rather than a frozen local fork. Lane widening remains future work and later superior evidence may revise only the exact affected lane or sub-slice. | +| Continuity Lattice context assembly | Deep-source grounded retained | continuity-lattice doctrine + VectorShell import entrypoint | One federated substrate with two preset-backed, overrideable profiles: `Max-Retention Mode` and `Economic-Retention Mode`. This is not a second memory system, does not weaken lane authority or optional-assistive override control, and does not justify automatic whole-repo absorption when one continuity sub-slice changes owner. | | User-authored note lane | Deep-source grounded retained | memory doctrine, owner unresolved | Do not describe as shipped. | -| Compact memory views / reducers | Deep-source grounded retained | optional-assistive + memory doctrine | Must remain derived and optional. | +| Compact memory views / reducers | Deep-source grounded retained | optional-assistive + memory doctrine | Must remain derived and optional. Do not copy donor code for any `R3` memory slice; import first-party VectorShell doctrine and code surfaces before bounded donor-derived adjuncts if broader adoption is later justified. | ### 10. Skills and optional assistive layer diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/PROVENANCE_AND_TRUST_MODEL.md b/docs/v6_5_deep_manual_pack/HyperTwist/PROVENANCE_AND_TRUST_MODEL.md index 7d5d2f9..5ce31e8 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/PROVENANCE_AND_TRUST_MODEL.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/PROVENANCE_AND_TRUST_MODEL.md @@ -110,6 +110,19 @@ Important continuity-profile reading: - confidence does not outrank authority - a high-confidence derived record must not outrank a raw authoritative record +Cross-project synchronization consequence: + +- the live VectorShell-memory entrypoint is + `C:\HyperTwist\docs\VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md` +- later superior evidence may revise an earlier memory or continuity `A1` + call only for the exact lane or sub-slice it is demonstrably stronger at +- weaker or partial later repos remain bounded adjuncts +- if a revision happens, provenance-visible canon must be updated across the + dependent HyperTwist authority surfaces rather than leaving the change in + one packet +- a stronger later repo does not justify automatic whole-repo absorption or + silent architecture rewrite + ## Redaction and publication Publication surfaces should preserve enough provenance to remain auditable