# HyperTwist Model A / Model B Coordinator Doctrine

Created on `2026-05-14`

## Status

This document is now the coordinator-facing doctrine for HyperTwist repo
evaluation, clean-room routing, and implementation-state discipline.

It is the HyperTwist-local coordinator counterpart to:

- [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_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.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)
- [HYPERTWIST_PACKET_CLEANUP_AND_REBUILDABLE_ARTIFACT_HYGIENE_2026-05-20.md](C:/HyperTwist/docs/ops/HYPERTWIST_PACKET_CLEANUP_AND_REBUILDABLE_ARTIFACT_HYGIENE_2026-05-20.md:1)
- [HYPERTWIST_RETROACTIVE_AUTHORITY_AND_CLEANUP_BACKFILL_2026-05-20.md](C:/HyperTwist/docs/ops/HYPERTWIST_RETROACTIVE_AUTHORITY_AND_CLEANUP_BACKFILL_2026-05-20.md:1)
- [MODEL_B_SOURCE_ACCESS_BOUNDARY.md](C:/HyperTwist/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md:1)

## Purpose

The coordinating HyperTwist instance must not let intake metadata, queue
position, frequent mention, or packet presence impersonate product truth.

Coordinator work must keep these states separate:

- bookmarked
- queued
- source-read
- retained
- product-fit
- implementation-authorized
- implemented

## Core coordinator rules

### 1. Intake is not intent

A bookmarked repo is only intake.

It is not:

- an integration commitment
- a retained-donor decision
- a product-fit decision
- an implementation authorization
- proof of current implementation

### 2. Queue is not merit

If a repo appears in a queue, packet, sequence doc, or prompt pack, that means
sequencing only.

It does not make the repo:

- preferred
- stronger than an existing owner
- more product-fit than a non-queued alternative
- already implementation-authorized
- already implemented

### 3. Source-read is evidence, not approval

Source reading can justify stronger judgment.

It does not, by itself, mean:

- keep
- fit
- retain
- implement

### 4. Retained is not automatically active build scope

A retained repo may still be:

- donor-only for later
- reference-only
- pattern-only
- later-horizon only
- outside current implementation scope

### 5. Ownership and route are separate judgments

Coordinator rule:

- donor strength and legal posture are separate axes
- technical ownership is not decided by permissive status alone
- a restrictive, mixed-license, or boundary-sensitive repo may still be the stronger owner for a lane
- if it wins technically, preserve that ownership verdict and then choose the correct route

Decide in this order:

1. technical and product-fit ownership
2. legal and compliance route

Harder route does not mean weaker donor.

Use the governing three-axis authority document when overlap is real:

- `A` = capability authority tier
- `R` = execution route
- `F` = realization width

Do not leave contested-slice authority in vague “stronger donor” prose when
it must be resolved precisely.

### 6. Implementation requires explicit authority

Treat a repo as implementation-authorized only when a bounded implementation
lane has been explicitly approved in the active authority path.

Treat a repo as implemented only when first-party product surfaces actually
landed through explicit implementation authority.

### 7. Live-surface scanning is exception-based

Routine live or product-surface scanning is no longer the default evaluation
step.

Assume a repo is not implemented unless explicit implementation authority says
otherwise.

Only verify current implementation state when the active task actually depends
on it.

## Coordinator routing order

When coordinating repo judgment or widening, use this order:

1. [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)
2. [HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md](C:/HyperTwist/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md:1)
3. [HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md:1)
4. [HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md:1)
5. repo-specific packet authority docs
6. [HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md:1)
7. [HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md:1)
8. [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)
9. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1)
10. [MODEL_B_SOURCE_ACCESS_BOUNDARY.md](C:/HyperTwist/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md:1) when clean-room-sensitive work is involved

## Cross-lane authority rule

When multiple repos compete for the same retained slice:

- capability hierarchy is license-neutral
- license posture affects route, not rank
- decompose the overlap into slices before assigning authority
- assign one `A1` per contested slice and preserve secondary non-overlapping
  value from non-winners explicitly as `A2`, `A3`, or `A4`
- do not force whole-repo winner-take-all when the real overlap is
  subsystem-specific
- if a later same-family repo materially changes an earlier contested-slice
  authority call, reopen the earlier affected packet selectively instead of
  pretending the whole corpus needs a rewrite

For coordination that resolves real overlap, require the packet or standing
note to state:

- exact contested slice
- candidate repos considered
- `A` tier per candidate
- `R` route per candidate where relevant
- `F` class for the retained winner
- preserved secondary value
- non-promoted families

Retroactive authority backfill is governed by:

- `C:\HyperTwist\docs\ops\HYPERTWIST_RETROACTIVE_AUTHORITY_AND_CLEANUP_BACKFILL_2026-05-20.md`

Required rule:

- repo-local extraction may remain valid even when cross-lane authority needs
  backfill
- reopen the earlier affected packet or standing note selectively
- do not silently contradict older packets
- do not bulk-rewrite history for appearance
- preserve valid earlier value explicitly

## Cleanup coordination rule

Packet cleanup and worktree hygiene are governed by:

- `C:\HyperTwist\docs\ops\HYPERTWIST_PACKET_CLEANUP_AND_REBUILDABLE_ARTIFACT_HYGIENE_2026-05-20.md`

Required coordinator behavior:

- finish packet truth first
- then clean rebuildable byproducts only
- do not weaken deep-source evaluation merely to avoid artifact growth
- do not claim a repo is clean if only packet dirt was removed but
  pre-existing residue remains
- if an older operationally relied-on packet is cleanup-ambiguous, mark it for
  selective backfill instead of inventing certainty

## Model A / Model B split

Coordinator rule:

- `Model A` may read allowed donor source where appropriate
- `Model B` must not read forbidden donor source
- if the handoff is too thin, strengthen `Model A`
- do not quietly move discovery burden into `Model B`
- if a restrictive or boundary-sensitive repo wins technically, preserve that
  owner verdict in the `Model A` handoff and use `Model B` only as the clean
  route, not as a technical demotion

## Current Phase 5R clarification

For the current clean-room sequence:

- repo presence in the `Phase 5R` prompt pack means active clean-room routing
- it does not mean those repos are already implemented
- it does not mean queue presence is proof of merit beyond the already-closed retained-set and packet decisions
- the prompt pack is routing authority, not product-surface proof
- the default operator flow is repo-local:
  - `Model A`
  - clean `Model B` primer
  - clean `Model B` contribution
  - repo-local consolidation
  - bounded implementation one bound at a time
- one bounded implementation run equals one bound
- after each bounded run, the coordinating instance must require an explicit
  next-step decision:
  - same bound again
  - next bound
  - repo-local reconsolidation if the standing map is too thin or stale
  - targeted cross-lane reconciliation only if the standing note or
    just-finished bound closeout explicitly says the next bound depends on
    unresolved overlap
  - owner-scoped validation-unblock packet only if validation is blocked by a
    broader first-party issue outside the lane owner surface
- the coordinating instance must not allow silent multi-bound widening in one
  pass merely because a clean implementation thread is already open
- the coordinating instance may allow the same clean `Model B` instance,
  including the clean coordinating instance, to perform repo-local
  consolidation and then the immediately following bounded implementation pass
  for one repo
- the coordinating instance may also allow the same clean `Model B` instance
  to run a targeted cross-lane checkpoint and then the immediately following
  bounded implementation pass for one explicitly selected affected repo
- that reuse is legal only if the conversation remained clean, the standing
  reconciled note or checkpoint note was written first, and the repo and bound
  were explicitly selected before coding
- for continuation inside an already-open clean bounded implementation thread,
  the coordinating instance may allow the prompt to assume cleanliness when
  that thread was initialized from the clean prompt and no contrary evidence
  exists
- the coordinating instance should not force redundant cleanliness dialogue in
  that case; the fallback is a new clean thread only when the existing thread
  is suspect, known non-clean, or stricter audit separation is wanted
- shared cross-lane reconciliation is an exception checkpoint, not the default
  immediate next step after every contribution pass
- repo-local and shared reconciliation are additive, not reset-oriented
- the coordinating instance must require those passes to account for all
  qualifying prior clean notes and standing reconciled notes in scope
- the coordinating instance must not allow earlier valid effort to disappear
  silently; supersessions, exclusions, and deferrals must be explicit
- the coordinating instance must also require those dispositions to be printed
  in the task summary for the pass, not only buried inside the reconciled note

## Closing rule

The coordinating HyperTwist instance must preserve the right to say:

- worth bookmarking, not worth integrating
- worth reading, not worth retaining
- retained, but not active build scope
- product-fit, but later-horizon only
- technically strongest, but route-constrained
- implementation-authorized, but not yet implemented

If the coordinator cannot say those things cleanly, the authority docs have
drifted and must be corrected.
