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