# 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.

## 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

### 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

### No-copy guardrail

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

## Retroactive interpretation rule for existing packets

This doctrine applies retroactively to the already closed HyperTwist packets.

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:

- update the packet
- update the clean-room or boundary-sensitive handoff
- preserve the guardrails

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

## 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

## 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.
