hypertwist/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md

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.