# HyperTwist - CAPABILITY_CONSOLIDATION_DOCTRINE.md

## Purpose

Define how dozens of evaluated repos collapse into a manageable first-party
HyperTwist architecture.

The output of the repo program is not "many repos inside the app."

The output is a first-party capability map.

Canonical normalized feature extraction surface:

- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\FEATURE_REGISTRY.md`

## Core rule

Consolidate by capability lane, not by donor product.

Each retained repo should resolve into one or more of:

- primary owner candidate
- secondary donor
- adjunct pattern donor
- clean-room-only donor
- discard/overlap

## Canonical capability lanes

### 1. Puzzle runtime and replay

Includes:

- puzzle-state runtime
- notation/semantic adapters
- replay timeline
- state serialization
- runtime verification

### 2. Recognition and reconstruction

Includes:

- camera/frame ingestion
- calibration
- face observation
- reconstruction
- correction/explanation shells

### 3. Training, coaching, and session control

Includes:

- training sessions
- drills
- coach flows
- follow-up state
- scheduling/queue behavior

### 4. Catalog, curriculum, and knowledge

Includes:

- imported packs
- generated-mode launch
- curriculum bundles
- hypercubing knowledge/reference

### 5. Publication, entitlement, and social training

Includes:

- publication projection
- leaderboard reference
- entitlement
- local social challenge state
- later admin/report only when justified

### 6. Hyper topology and immersive expansion

Includes:

- hyper puzzle catalog
- topology families
- non-Euclidean interaction
- immersive/world presentation

### 7. Speech and voice sidecars

Includes:

- STT session boundaries
- VAD/segmentation
- transcript/result shaping
- later TTS/narration sidecars

### 8. Analytics, media, and export

Includes:

- analytics/reporting
- media export
- embedded playback
- browser-spatial adjuncts

### 9. Provider and optional assistive control plane

Includes:

- provider-neutral contracts
- BYOK/profile custody
- normalized usage/cost/routing
- optional skills
- reducers/compactors

## Cross-lane invariants

Every lane still shares:

- object identity
- provenance/trust
- session continuity
- replay/evidence linkage
- operator override
- packet authority

These are not donor-owned mini-lanes. They are product invariants.

## Ownership rule

For each lane, prefer:

1. one primary first-party owner
2. a small number of secondary donors
3. adjuncts only where they remove real gaps

Avoid:

- duplicate shells
- duplicate session systems
- duplicate provenance systems
- donor-shaped product sprawl

## Relationship to current doctrine

Use this consolidation doctrine with:

- `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\v6_5_deep_manual_pack\HyperTwist\WORKBENCH_FEATURE_TARGETS.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.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`

## Acceptance rule

A donor is useful only when it clarifies one of:

- ownership
- design pattern
- test oracle
- schema/contract
- bounded implementation target

If it does none of those, it should not shape the product.
