# HyperTwist Model A Max-Value Extraction Modus Operandi

Created on `2026-05-13`

## Status

This document is now the canonical `Model A source-evaluation and handoff doctrine` for HyperTwist.

It clarifies how future `Model A` instances should interpret:

- `0R` packet source-value extraction
- `non-promotion` language
- `do not promote` and `do not preserve literally` wording
- clean-room handoff scope
- the difference between `governance exclusion` and `implementation thinning`

It is additive authority.

It does not replace superior repo-specific source findings already recorded in:

- `0R-A`
- `0R-B`
- `0R-C`
- `0R-D`
- `0R-E`
- the live-lane preservation audit

If an older packet already says something more precise, keep that precision.

Use this document to interpret those packets correctly and to prevent future over-narrowing.

## Purpose

HyperTwist wants maximum durable value from retained repos.

That means future `Model A` work must:

- read source directly where allowed
- extract the deepest durable subsystem value
- write richer positive handoffs when a retained repo supports them
- omit only the surfaces that genuinely should not survive

This document exists because `do not promote` language can be misread.

That wording is not supposed to scare later `Model A` instances into shallow handoffs.

It is supposed to:

- protect ownership boundaries
- stop host-shell noise from being laundered into core architecture
- stop exact-source or exact-API copying
- keep later `Model B` work clean

## Scope boundary

This doctrine is for:

- future `Model A` source-reading work
- refreshed `0R` packet updates
- refreshed `Model A` clean-room handoffs
- future boundary-sensitive donor interpretation work

It is not itself a `Model B` implementation handoff.

`Model B` still implements only from scrubbed handoff materials and allowed first-party docs.

## Intake and product-fit clarification

This doctrine does not treat bookmark presence as a reason to extract value.

HyperTwist now treats:

- bookmarked = intake only
- queued = sequencing only
- source-read = evidence gained
- retained = survives evaluation in some posture
- product-fit = separate judgment

That means:

- a repo is not entitled to rich extraction merely because it was bookmarked
- a repo is not entitled to a donor lane merely because it was source-read
- a repo may have real donor value and still fail the HyperTwist product-fit test
- a repo may be retained only as reference-only, pattern-only, or donor-only for later
- restrictive, copyleft, mixed-license, or boundary-sensitive status does not automatically demote a repo beneath a permissive alternative
- if a retained restrictive or boundary-sensitive row is the stronger owner inside its approved lane, `Model A` should say that directly
- clean-room or boundary-first handling changes the route, not the donor-strength verdict

The canonical anti-conflation doctrine now also lives in:

- [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1)
- [HYPERTWIST_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-20.md](C:/HyperTwist/docs/ops/HYPERTWIST_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-20.md:1)

Cross-lane authority note:

- when multiple retained repos compete for one slice, `Model A` should resolve
  that slice under the dedicated HyperTwist `A/R/F` authority doctrine
- capability hierarchy is license-neutral
- license posture changes route, not rank
- if the retained winner is restrictive, the consequence is clean-room,
  boundary-first, or oracle-only routing rather than authority demotion
- do not compare whole repos when the real overlap is subsystem-specific
- preserve unique non-overlapping value from non-winners explicitly as adjunct,
  reference, or pattern value instead of flattening it to exclusion

## Core doctrine

### 1. Maximize retained value

For any retained repo, `Model A` should try to capture the full bounded value of the retained domain.

Default posture:

- `full bounded realization of retained value`

Not default posture:

- one helper
- one convenience function
- one tiny token reference just because the repo is legally sensitive

If the retained domain is rich, the handoff should be rich.

### 2. Positive scope comes first

The main output of `Model A` should be the positive scope:

- what subsystem ideas survive
- what first-party target should exist
- what acceptance markers define success
- what implementation order makes sense

Negative exclusions matter, but they are secondary.

Do not let the exclusion list become the center of gravity.

### 3. Non-promotion language is a filter, not a cap

When a packet says:

- `do not promote`
- `do not preserve literally`
- `host-shell glue`
- `off topic`
- `superseded by stronger retained donor`

interpret it narrowly.

It usually means one of these:

- do not preserve exact source text, exact type names, exact API signatures, exact query params, exact comments, or exact UI shell
- do not let the repo displace an already stronger retained owner outside its proper lane
- do not promote demos, packaging, marketing, community chrome, boilerplate scaffolding, or commodity glue as primary donor value
- do not widen a narrow donor into a whole-product owner when the retained value is bounded

It does **not** mean:

- stop extracting meaningful subsystem value
- reduce a rich retained lane to one helper
- prevent a future `Model A` from writing a stronger positive clean-room handoff

### 4. Stronger-owner boundaries still matter

HyperTwist already made portfolio-level decisions about ownership.

If a stronger retained owner already exists, keep that boundary.

Examples of what this means:

- a viewer donor should not silently become the runtime owner
- a compact parser donor should not silently become a whole classic-cubing runtime owner
- a strategic support-plane donor should not silently displace a foundation anchor

But this still does **not** justify shrinking the retained value inside the donor's proper lane.

Correct reading:

- preserve the donor richly inside its approved lane
- do not let it annex adjacent lanes that already have a stronger owner

### 5. Literal no-copy rules are separate from subsystem richness

`Do not preserve literally` means:

- no exact copied source
- no exact copied grammar text
- no exact copied API surface
- no exact copied comments/docstrings
- no exact copied UI shell

It does not mean:

- no full re-authored subsystem

HyperTwist wants full first-party subsystems where the retained value justifies them.

It does not want exact-source carryover.

### 6. If the handoff undercaptures value, strengthen the handoff

If a future `Model A` instance reads a retained repo and finds that the existing handoff is too thin, the correct move is:

1. strengthen the packet or handoff
2. expand the positive scope
3. keep the guardrails
4. leave `Model B` source isolation intact

The wrong move is:

1. let `Model B` improvise from too little guidance
2. let `Model B` inspect the restrictive mirror
3. silently flatten the subsystem because the handoff was weak

### 7. Exclusions must be justified, not guessed

Any exclusion should name the reason clearly.

Approved exclusion classes:

- inferior duplicate
- superseded by a stronger retained donor
- off topic to HyperTwist's retained product scope
- host-shell glue with no durable architecture value
- commodity scaffolding with no strategic differentiation
- legal, asset-term, or subtree surface that cannot safely enter the lane as ordinary donor value

If `Model A` cannot explain the exclusion concretely, it should not exclude the surface casually.

### 8. Clean-room richness belongs to Model A, not Model B

For restrictive rows:

- `Model A` is supposed to do the rich thinking
- `Model A` is supposed to decide the subsystem boundaries
- `Model A` is supposed to write the full positive handoff

`Model B` is not the place to rediscover donor value from source.

That would defeat the clean-room chain.

So the right way to stay rich is:

- richer `Model A`
- stronger positive handoff
- tighter `Model B` source isolation

not:

- weaker `Model A`
- more source freedom for `Model B`

## Required outputs from future Model A passes

When `Model A` evaluates or refreshes a retained repo, the output should try to include all of these where relevant:

### Source basis

- exact files or directories read
- enough specificity that later operators know what was actually inspected

### Product-fit verdict

- explicit statement of whether the durable value actually belongs in HyperTwist's real product direction
- no hiding product fit inside a generic repo summary

### Preserved subsystem ideas

- the deep durable value
- not just the most obvious exported functions

### HyperTwist-first target

- what first-party subsystem HyperTwist should own afterward
- stated in HyperTwist terms rather than donor-shell terms

### Acceptance markers

- observable signs that the later implementation captured the retained value
- structural and behavioral, not donor-name-dependent

### Recommended implementation order

- a practical sequence for later first-party realization

### Exclusion rationale

- explicit reasons for omitted surfaces
- no vague “not needed” language

### Retention posture and owner-lane placement

- whether the repo is worth later bounded integration, donor-only for later, reference-only, pattern-only, or not worth integrating
- which owner lane it belongs to if retained

### Realization depth

- whether the later target is no implementation, reference-only, pattern-only, bounded subsystem realization, broader bounded realization, or full positive realization of the retained lane

### Locked outcome taxonomy

- exact repo-level outcome category:
  - `implemented now`
  - `retained for later implementation`
  - `retained as reference only`
  - `retained only for pattern extraction`
  - `excluded`
- if retained, exact realization class:
  - `full bounded capability realization`
  - `narrower bounded slice`
- if a narrower slice is chosen, the exact kept capability families and exact
  not-kept capability families

### Explicit anti-misreading note

- what the repo should never be mistaken for
- especially when the repo is technically strong but not a product fit, or retained only in a narrow posture

### No-copy guardrail

- when the row is clean-room-sensitive, make the source-access boundary explicit

### Post-evaluation artifact hygiene

- if the source-evaluation packet ran builds, installs, tests, or other local
  validation, finish the packet docs first and then clean rebuildable
  byproducts
- keep custody mirrors, packet docs, and required handoff artifacts
- remove temporary evaluation worktrees, temporary clones, and rebuildable
  outputs when they are no longer needed
- use
  `docs/ops/HYPERTWIST_PACKET_CLEANUP_AND_REBUILDABLE_ARTIFACT_HYGIENE_2026-05-20.md`
  as the governing cleanup doctrine

## Retroactive interpretation rule for existing packets

This doctrine may inform already closed HyperTwist packets, but it does not
authorize fake whole-corpus rewrites or blind full resets.

Use the governing retroactive backfill doctrine:

- `docs/ops/HYPERTWIST_RETROACTIVE_AUTHORITY_AND_CLEANUP_BACKFILL_2026-05-20.md`

When reading any existing `0R` packet:

- treat `high-value salvage` and equivalent sections as the positive scope center
- treat `subordinate or later value` as demotion, not erasure
- treat `non-promotion decisions and rationale` as boundary protection, not automatic minimization
- treat `do not preserve literally` as anti-copy guidance, not anti-subsystem guidance

If an older packet appears too narrow relative to the retained value:

- reopen the exact earlier affected packet or handoff selectively
- name the exact packet or handoff reopened
- preserve what remained valid explicitly
- change only what later evidence materially changed
- preserve the guardrails

Do not push the ambiguity downstream into `Model B`.

Repo-local extraction may remain valid even when cross-lane authority later
needs selective backfill.

## Document responsibility split

Use the HyperTwist docs this way:

- `0R` packets:
  - source-value extraction
  - overlap resolution
  - exclusion rationale
  - repo-by-repo retained scope
- this document:
  - interpretation doctrine for future `Model A` work
  - anti-over-narrowing rule
  - clean distinction between governance exclusion and subsystem richness
- `REPO_LICENSE_TRACKING.md`:
  - repo-row legal posture
  - attribution
  - notice duties
  - publication duties
  - provenance exceptions
- `*.model-a.md` scrubbed handoffs:
  - the positive clean-room implementation target for `Model B`
- `MODEL_B_SOURCE_ACCESS_BOUNDARY.md`:
  - clean-room access constraints for `Model B`
- `Phase 1R` contract:
  - routing
  - class assignment
  - next phase
- `docs/ops/HYPERTWIST_CANONICAL_COMPACT_CLOSEOUT_FORMAT_2026-05-19.md`:
  - canonical closeout section order
  - mandatory Result taxonomy
  - compactness-without-information-loss rule
- `docs/ops/HYPERTWIST_CROSS_LANE_AUTHORITY_HIERARCHY_AND_RECONCILIATION_2026-05-20.md`:
  - license-neutral `A/R/F` hierarchy model
  - slice decomposition before authority ranking
  - selective retroactive backfill when a later same-family repo materially
    changes an earlier contested-slice authority call
- `docs/ops/HYPERTWIST_RETROACTIVE_AUTHORITY_AND_CLEANUP_BACKFILL_2026-05-20.md`:
  - governing selective retroactive authority and cleanup backfill rule
  - no fake whole-corpus rewrite rule
  - exact reopened-packet reporting rule
- `docs/ops/HYPERTWIST_PACKET_CLEANUP_AND_REBUILDABLE_ARTIFACT_HYGIENE_2026-05-20.md`:
  - post-packet cleanup order
  - rebuildable-artifact rule
  - custody-versus-cleanup boundary

## Practical operator rule

If you are a future `Model A` instance and a retained repo still looks richer than the current handoff:

1. keep the existing owner boundaries
2. keep the no-copy guardrails
3. keep the repo inside its retained lane
4. extract more value, not less
5. update the positive handoff
6. document the rationale for every exclusion

That is the intended HyperTwist posture.

## Current closure note

This doctrine does not reopen `Phase 4R-A`.

`Phase 4R-A` remains closed.

This document only clarifies how future `Model A` instances should read and extend the retained-value work that surrounds the closed packet sequence.
