# Model B Source Access Boundary

Created on `2026-04-23`

Purpose:

- make the clean-room `Model B` boundary explicit for HyperTwist work
- prevent accidental reading of restrictive mirrors or unrelated sensitive ops material

## Allowed for clean-room `Model B`

- `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist`
- `C:\Workspaces\HyperTwist\clean-room-specs\*`
- `C:\Workspaces\HyperTwist\repos.manifest.json`
- curated first-party docs in:
  - `C:\HyperTwist\docs\MODEL_B_SOURCE_ACCESS_BOUNDARY.md`
  - `C:\HyperTwist\docs\HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`
  - `C:\HyperTwist\docs\HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
  - `C:\HyperTwist\docs\HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`
  - `C:\HyperTwist\docs\HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md`
  - `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md`
  - `C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md`
  - `C:\HyperTwist\docs\HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md`
  - `C:\HyperTwist\docs\HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md`
  - `C:\HyperTwist\docs\HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md`
  - `C:\HyperTwist\docs\HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md`
  - `C:\HyperTwist\docs\HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md`
  - `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md`
  - `C:\HyperTwist\docs\HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md`
  - `C:\HyperTwist\docs\REPO_LICENSE_TRACKING.md`
  - `C:\HyperTwist\docs\arch\HYPERTWIST_IMPORTED_GENERATED_MODE_EXECUTOR_PACKET_2026-05-05.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\README.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\AGENTS.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\API.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\ARCHITECTURE.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\DEVELOPMENT.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\LICENSETRACKING.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\PRD.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\ROADMAP.md`
- curated safe parse/workbook docs in:
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\06-project-agnostic-repo-evaluation-modus-operandi.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\07-benchmark-oracle-vs-clean-room-implementation.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\14-clean-room-model-a-model-b-prompts.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\88-roadmap-implementation-workbook.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\89-phase-0-and-phase-1-bootstrap-packet.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\90-clean-room-safe-project-context.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\122-hypertwist-phase-0r-restart-authority-and-sequencing.md`
- first-party staging docs and acceptance materials in:
  - `C:\Workspaces\HyperTwist\implementation-workspaces\scratch\roadmap-bootstrap\docs\contracts\*`
  - `C:\Workspaces\HyperTwist\implementation-workspaces\scratch\roadmap-bootstrap\docs\architecture\*`
- first-party acceptance tests and public compatibility requirements

## Forbidden for clean-room `Model B`

- `C:\Workspaces\HyperTwist\mirrors\restrictive\*`
- source-backed restrictive dossiers in:
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\42-kash-cubedesk-clean-room-dossier.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\43-onionhoney-roux-trainers-clean-room-dossier.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\44-cubing-alg-js-clean-room-dossier.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\45-cubing-twisty-js-clean-room-dossier.md`
  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\46-hactarce-2x2x2x2-scrambler-clean-room-dossier.md`
- mixed-license restricted subtrees inside otherwise partially permissive repos, for example:
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\ee\*`
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\screenpipe\screenpipe\ee\*`
- copied sensitive ops references such as:
  - `C:\HyperTwist\docs\refs\FORGEJO_WOODPECKER_VPS_A_TO_Z_SENSITIVE_RUNBOOK.md`
- secret-bearing or admin-bearing docs such as:
  - `C:\HyperTwist\docs\refs\ADMIN_CREDENTIALS.md`
  - `C:\HyperTwist\docs\refs\AUTH_CONFIGURATION_GUIDE.md`
  - `C:\HyperTwist\docs\refs\OAUTH_ACTIVATION.md`
  - `C:\HyperTwist\docs\refs\OVERLEAF_ADMIN_SETUP.md`
- unrelated product ops folders, SSH material, or secret-bearing runbooks

## Operational rule

- if a file exists only because `Model A` inspected a restrictive repo, `Model B` must not read it unless it was explicitly scrubbed into `clean-room-specs`
- the `HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md` file is allowed because it is process doctrine only; it does not enlarge `Model B` source access beyond the scrubbed handoffs
- benchmark oracles remain source-forbidden to `Model B`
- this rule still applies when the upstream repo says `all rights reserved`, has no explicit license, or contains contradictory license notices; those repos may still inform `Model A`, but never become direct `Model B` source input
- if a repo mixes permissive and restricted trees, default to forbidding the whole mirrored repo to `Model B` unless a narrower allowlist has been explicitly created in writing
- for the imported generated-mode executor packet, `Model B` should implement from owned `HyperTwistTraining` runtime/request contracts rather than from donor-facing raw extract files or bundled intake JSON unless those assets were separately scrubbed and allowlisted
- this boundary file governs route, not donor rank; a restrictive or boundary-sensitive row may still be the strongest owner for its lane
- clean-room, subtree-exclusion, or sidecar routing does not imply technical weakness; it only constrains how `Model B` may realize the winning value

## Current topology default

HyperTwist currently defaults to:

- `Model A`
- `Model B` as both clean implementer and clean integrator

The optional third clean `mainline integrator` instance remains documented, but it is not the default.

For the current `Phase 5R` restrictive queue:

- source-exposed `Model A` runs one repo per source-exposed thread
- clean `Model B` contributor threads run one repo per clean thread
- the repo-specific primer is required by default only for the clean contributor thread
- the cross-lane consolidation thread does not get the primer by default
- the bounded implementation thread does not get the primer by default
- the standing operator packet for this sequence is:
  - `C:\HyperTwist\docs\HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md`

## Current verified restrictive implementation truth

At the moment, HyperTwist should treat only one restrictive repo as both:

- properly governed through clean-room separation
- and already implemented/live in owned first-party surfaces

That repo is:

- `onionhoney/roux-trainers`

Implications for `Model B`:

- `Model B` may work with the already-landed first-party Unreal outputs and scrubbed clean-room specs for that lane
- `Model B` may read the live-lane preservation audit for that lane because it points back to first-party outputs and scrubbed handoffs rather than granting mirror access
- `Model B` must still not read the restrictive mirror itself
- do not describe other restrictive HyperTwist repos as already landed unless the same level of clean-room and live-evidence closure is explicitly documented
- for future restrictive-lane widening, use the closed `Phase 1R` retained-set contract and wait for `Phase 2R` packet ratification before selecting the next clean-room target

## Brownan / Oracle clarification

Brownan's solver mirror is allowed for `Model A` research and oracle derivation only.
It does not justify `Model B` access to any VPS runbook, CI document, SSH key, or other unrelated operations material.
