Separate donor strength from integration route

docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md

@@ -123,6 +123,10 @@ Canonical doctrine docs:
 Operational implication:
 
 - do not let bookmark presence, queue position, frequent mention, planning artifacts, or docs metadata masquerade as product intent or proof of implementation
+- donor strength and legal posture are separate axes
+- permissive status does not automatically win a lane
+- restrictive or boundary-sensitive status does not automatically lose a lane
+- harder route does not mean weaker donor
 - 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
 - verify current implementation state only when the active task depends on that fact

docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md

@@ -82,6 +82,9 @@ That means:
 - a repo is not entitled to a donor lane merely because it was source-read
 - a repo may have real donor value and still fail the HyperTwist product-fit test
 - a repo may be retained only as reference-only, pattern-only, or donor-only for later
+- restrictive, copyleft, mixed-license, or boundary-sensitive status does not automatically demote a repo beneath a permissive alternative
+- if a retained restrictive or boundary-sensitive row is the stronger owner inside its approved lane, `Model A` should say that directly
+- clean-room or boundary-first handling changes the route, not the donor-strength verdict
 
 The canonical anti-conflation doctrine now also lives in:
 

docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md

@@ -76,7 +76,23 @@ A retained repo may still be:
 - later-horizon only
 - outside current implementation scope
 
-### 5. Implementation requires explicit authority
+### 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.
+
+### 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.
@@ -84,7 +100,7 @@ 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.
 
-### 6. Live-surface scanning is exception-based
+### 7. Live-surface scanning is exception-based
 
 Routine live or product-surface scanning is no longer the default evaluation
 step.
@@ -117,6 +133,9 @@ Coordinator rule:
 - `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
 
@@ -135,6 +154,7 @@ The coordinating HyperTwist instance must preserve the right to say:
 - 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

docs/HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md

@@ -66,6 +66,13 @@ Evaluation-state rule:
 - implementation-authorized = separate later judgment
 - implemented = explicit landed first-party work only
 
+Ownership-versus-route rule:
+
+- boundary-sensitive, mixed-term, or subtree-constrained status does not automatically demote a repo beneath a permissive alternative
+- decide technical and product-fit ownership first
+- decide adapter, sidecar, allowlist, publication, subtree, or other boundary route second
+- harder route does not mean weaker donor
+
 Canonical doctrine:
 
 - [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)

docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md

@@ -74,6 +74,14 @@ Future instances must keep the state vocabulary separate:
 - implementation-authorized = explicit approval for a bounded clean-room build lane
 - implemented = landed in first-party product surfaces under explicit implementation authority
 
+Ownership-versus-route rule:
+
+- restrictive status does not automatically demote a repo beneath a permissive or boundary-sensitive alternative
+- decide technical and product-fit ownership first
+- decide clean-room and compliance routing second
+- if a restrictive row wins technically, preserve that win and then route it through the correct clean-room discipline
+- harder route does not mean weaker donor
+
 For these restrictive rows, clean-room prompt packs, handoff files, or queue position are routing evidence only.
 
 They are not proof of current implementation.

docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md

@@ -142,6 +142,10 @@ The `39` non-live active implementation-board rows break down as:
 - Discarded rows are not soft-retained. They are out of the active set unless new evidence reopens them explicitly.
 - `Permissive` does not automatically mean `high priority`.
 - `MIT` or `Apache-2.0` status never outranks stronger retained anchors, domain fit, or already-set ownership boundaries.
+- donor strength and legal posture are separate axes.
+- a restrictive or boundary-sensitive row may still be the stronger technical owner for its bounded lane.
+- if such a row wins technically, preserve that owner verdict and then route it through clean-room, sidecar, adapter, allowlist, or other required boundary discipline.
+- easier route never decides the ownership comparison by itself.
 - implementation truth is exception-based: assume a row is not implemented unless explicit landed packet authority or the live-lane audit says otherwise.
 
 ## Landed preserve lanes

docs/HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md

@@ -69,6 +69,7 @@ This packet means:
 
 - the four restrictive rows are already selected retained clean-room candidates with active routing
 - the four rows are queued for explicit `Model A` and `Model B` clean-room work
+- clean-room routing is the required route discipline, not a statement that these lanes are technically weaker than permissive alternatives
 
 This packet does not mean:
 
@@ -76,6 +77,12 @@ This packet does not mean:
 - those rows outrank stronger owners outside their approved lanes
 - those rows became product truth merely by being listed here
 
+If one of these rows is the strongest owner inside its bounded lane, the correct result is:
+
+- preserve that owner verdict
+- keep raw restrictive source away from clean `Model B`
+- route realization through the clean-room stack
+
 Canonical doctrine docs:
 
 - [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)

docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md

@@ -50,6 +50,9 @@ Strong rule:
 - product-fit is a separate judgment from retention
 - implementation-authorized is a separate judgment from product-fit
 - implemented means landed in first-party product surfaces under explicit implementation authority
+- donor strength and legal posture are separate axes
+- permissive status does not automatically win a lane
+- restrictive or boundary-sensitive status does not automatically lose a lane
 
 Schedule implication:
 
@@ -57,11 +60,17 @@ Schedule implication:
 - do not treat a source-read repo as automatically approved
 - do not treat a retained repo as automatically implementation-authorized
 - do not treat a discussed repo as already implemented
+- decide technical ownership first and integration route second
+- do not let route convenience answer an ownership comparison by itself
 
 Future serious repo evaluations should now explicitly try to state:
 
 - exact source basis read
 - licensing posture
+- technical donor-strength verdict
+- ownership verdict
+- explicit displacement or non-displacement rationale
+- integration-route verdict
 - preserved subsystem ideas
 - subordinate or later value
 - explicit product-fit verdict

docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md

@@ -56,6 +56,9 @@ Future HyperTwist instances must not collapse the following into one vague
 - legally usable != strategically correct
 - feature-rich != product-relevant
 - technically elegant != worth integrating
+- permissive != stronger donor
+- restrictive != weaker donor
+- harder route != weaker donor
 
 These distinctions are mandatory.
 
@@ -192,12 +195,58 @@ Implementation authorization must be explicit.
 
 Planning artifacts alone are not authorization.
 
+## Donor strength and legal posture are separate axes
+
+HyperTwist must explicitly separate:
+
+1. technical and product-fit ownership judgment
+2. legal, compliance, and integration-route judgment
+
+These are different axes.
+
+A restrictive, copyleft, mixed-license, or boundary-sensitive repo can still
+be:
+
+- the technically stronger donor
+- the better product fit
+- the rightful owner of a bounded subsystem lane
+- the repo that should displace a permissive alternative on technical grounds
+
+Permissive status does not automatically win the ownership comparison.
+
+Restrictive status does not automatically lose it.
+
+What legal posture changes is the allowed route, for example:
+
+- direct permissive incorporation
+- bounded adapter
+- sidecar or service boundary
+- protocol boundary
+- clean-room handoff
+- reference-only
+- pattern-only
+- donor-only for later
+- no integration despite technical strength
+
+HyperTwist therefore evaluates overlapping repos in two passes:
+
+1. decide which repo is stronger on technical, product-fit, and ownership grounds
+2. decide what route the winner may use given license posture and compliance constraints
+
+Harder route does not mean weaker donor.
+
+It means harder route.
+
 ## Required evaluation output standard
 
 Every serious repo evaluation should now try to state all of the following:
 
 - exact source basis read
 - licensing posture
+- technical donor-strength verdict
+- ownership verdict
+- explicit displacement or non-displacement rationale
+- integration-route verdict
 - preserved subsystem ideas
 - subordinate or later value
 - explicit product-fit verdict
@@ -283,6 +332,40 @@ If it still has residual value in a narrower lane, preserve that value there.
 
 If it has no durable lane, say so.
 
+## Ownership-versus-route examples
+
+Example A:
+
+- a permissive repo is easier to incorporate
+- a restrictive repo is clearly stronger in the bounded subsystem
+
+Correct result:
+
+- the restrictive repo may still win ownership
+- the implementation route becomes boundary-first, clean-room, sidecar, or another constrained path as required
+
+Example B:
+
+- a restrictive repo is impressive
+- a permissive repo is still the stronger product fit and better owner
+
+Correct result:
+
+- the permissive repo wins
+- the restrictive repo may remain reference-only, donor-only for later, or subordinate
+- the restrictive repo does not lose merely because it is restrictive; it loses because it is the weaker owner here
+
+Example C:
+
+- a restrictive repo wins a narrow lane
+- a broader permissive repo remains the stronger owner in a neighboring lane
+
+Correct result:
+
+- preserve the restrictive repo as the narrow owner where it is strongest
+- preserve the permissive repo as the broader owner where it is stronger
+- do not let route difficulty distort lane boundaries
+
 ## Failure cases to prevent
 
 This doctrine exists to block the following failure modes:
@@ -312,6 +395,32 @@ if the full product should be integrated.
 A repo is discussed often enough that later instances casually describe it as
 if it already exists in product surfaces.
 
+### 6. Permissive bias
+
+A later instance assumes that a permissive repo should win by default over a
+restrictive or boundary-sensitive repo.
+
+### 7. Restrictive demotion by reflex
+
+A later instance sees GPL, AGPL, mixed-license, enterprise-sliced, custom, or
+boundary-sensitive posture and casually downgrades the repo's technical
+ownership claim without comparing subsystem value.
+
+### 8. Ownership-route collapse
+
+A later instance uses legal posture to answer a technical ownership question.
+
+### 9. Route-to-rank confusion
+
+A later instance assumes that because a repo must route through clean-room,
+sidecar, allowlist, or subtree-boundary handling, it therefore cannot be the
+strongest donor.
+
+### 10. Overcorrection
+
+A later instance swings too far in the other direction and starts treating
+restrictive repos as automatically superior or specially authoritative.
+
 All of these are doctrine failures.
 
 ## Operational vocabulary
@@ -338,6 +447,26 @@ The repo survived evaluation as having some meaningful preserved value.
 
 The retained value actually belongs in HyperTwist’s real product direction.
 
+### Technical owner
+
+The repo that best owns a lane on architecture, subsystem quality, and
+product-fit grounds.
+
+### Ownership verdict
+
+The explicit judgment about who should own the lane on technical and
+product-fit grounds.
+
+### Integration route
+
+The allowed path for using or realizing retained value given license posture,
+custody, compliance, and boundary constraints.
+
+### Route verdict
+
+The explicit judgment about how the winning value may enter the product, if at
+all.
+
 ### Implementation-authorized
 
 A bounded implementation lane has been explicitly approved.
@@ -360,6 +489,16 @@ lane.
 
 Potentially useful later, but not active implementation scope now.
 
+### Permissive route
+
+A lower-friction incorporation path available when the repo posture allows it.
+
+### Restrictive route
+
+A constrained path such as clean-room, sidecar, protocol boundary,
+reference-only use, pattern-only use, donor-only deferral, or explicit
+non-integration.
+
 ### Not worth integrating
 
 No later bounded implementation should be assumed from the current evaluation.

docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md

@@ -147,6 +147,12 @@ This board is not proof of bookmark merit by itself.
 
 This board is not proof of implementation by itself.
 
+Legal posture does not decide technical ownership by itself.
+
+A restrictive or boundary-sensitive row can still be the stronger owner for a lane.
+
+Harder route does not mean weaker donor.
+
 Use explicit `Current live state`, landed packet authority, and the live-lane
 audit when implementation truth matters.
 
@@ -169,6 +175,8 @@ audit when implementation truth matters.
 - `Prior bucket`, `Prior action`, `Reset lane`, and `Next step` are not merit signals by themselves.
 - queue position or row presence does not prove product fit.
 - row presence does not prove implementation.
+- license posture does not prove that a row is stronger or weaker than an overlapping alternative.
+- route difficulty does not answer ownership by itself.
 - routine live-surface scanning is no longer the default evaluation step; when implementation truth matters, verify it from explicit implementation authority rather than from queue or board metadata alone.
 
 ## Landed Permissive Lanes

docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md

@@ -79,6 +79,8 @@ Purpose:
 - 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
 

docs/REPO_LICENSE_TRACKING.md

@@ -48,14 +48,32 @@ Use it for:
 
 Do not use it as the primary architecture ledger. The architecture and donor decisions remain in the GPT parse files.
 
+## 2026-05-14 donor-strength versus route doctrine
+
+This file records legal posture, compliance burden, and route constraints.
+
+It does not decide technical ownership by permissive status alone.
+
+Rule:
+
+- donor strength and legal posture are separate axes
+- a restrictive, copyleft, mixed-license, or boundary-sensitive repo can still be the stronger owner for a lane
+- if it wins technically, the route may still be clean-room, sidecar, protocol boundary, reference-only, pattern-only, donor-only for later, or explicit non-integration
+- harder route does not mean weaker donor
+- easier route does not mean better owner
+
+Use packet and retained-set docs for ownership verdicts.
+
+Use this file for legal posture and route constraints after the ownership comparison is made.
+
 ## 2026-05-13 current HyperTwist implementation truth
 
 This file now also preserves the current truth that future models must not lose:
 
 - current curated HyperTwist shallow-eval set: `71` repos
-- currently verified live/implemented in checked `UnrealHyperTwist` surfaces: `19`
+- currently verified live/implemented in checked `UnrealHyperTwist` surfaces: `20`
 - permissive live lanes: `13`
-- boundary-sensitive live lanes: `5`
+- boundary-sensitive live lanes: `6`
 - restrictive live lanes: `1`
 
 The thirteen permissive live lanes are:
@@ -74,13 +92,14 @@ The thirteen permissive live lanes are:
 - `poliva/cubedex`
 - `newyork-anthonyng/rubiks-cross-trainer`
 
-The five boundary-sensitive live lanes are:
+The six boundary-sensitive live lanes are:
 
 - `cubing/cubing.js`
 - `cutelyaware/magiccube4d`
 - `google/model-viewer/packages/shared-assets`
 - `PostHog/posthog`
 - `screenpipe/screenpipe`
+- `remotion-dev/remotion`
 
 The one restrictive live lane is:
 
@@ -99,7 +118,7 @@ Interpretation rule:
 
 Reset rule:
 
-- preserve the nineteen landed/live lanes
+- preserve the twenty landed/live lanes
 - do not treat the remaining non-live rows as already absorbed
 - route all non-live rows only through the closed `Phase 1R` retained-set contract and the relevant `0R-*` packet
 

docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md

@@ -26,6 +26,12 @@ State-separation rule:
 Do not let bookmark presence, queue position, or frequent mention masquerade as
 product intent or proof of implementation.
 
+Donor-strength rule:
+
+- donor strength and legal posture are separate axes
+- a restrictive or boundary-sensitive repo can still be the strongest owner for a lane
+- route difficulty changes how retained value may enter the product, not whether it may win technically
+
 Current truth:
 
 - `20` repos are currently verified live in checked Unreal surfaces

docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md

@@ -8,6 +8,14 @@ Every repo should be judged as:
 - reverse engineer
 - pattern-only
 
+Ownership and route are separate judgments:
+
+- donor strength and legal posture are separate axes
+- a restrictive, mixed-license, or boundary-sensitive repo may still be the stronger technical owner for a lane
+- permissive status does not automatically win a lane
+- restrictive status does not automatically lose a lane
+- the route categories above answer how a winning repo may be used, not whether it was the stronger donor
+
 ## File boundary
 
 This file is the project-level license policy file.
@@ -176,7 +184,7 @@ These are often strategic donors or comparators rather than foundations.
 Current HyperTwist correction:
 
 - thirteen permissive lanes are already live, including the landed analytics/reporting lane, the landed hypercubing knowledge and community-reference lane, and the landed browser spatial owner trio
-- four boundary-sensitive lanes are already live: `cubing/cubing.js` through an explicit `MPL`-aware adapter posture, `cutelyaware/magiccube4d` through an explicit attribution/provenance boundary, `google/model-viewer/packages/shared-assets` through an explicit allowlist/provenance boundary, and `PostHog/posthog` through an explicit root-`MIT`-core-versus-`ee/` subtree boundary
+- six boundary-sensitive lanes are already live: `cubing/cubing.js` through an explicit `MPL`-aware adapter posture, `cutelyaware/magiccube4d` through an explicit attribution/provenance boundary, `google/model-viewer/packages/shared-assets` through an explicit allowlist/provenance boundary, `PostHog/posthog` through an explicit root-`MIT`-core-versus-`ee/` subtree boundary, `screenpipe/screenpipe` through an explicit permissive-core-versus-`ee/` subtree boundary, and `remotion-dev/remotion` through an explicit package-split commercial boundary
 - `onionhoney/roux-trainers` is the one restrictive training lane already landed through clean-room implementation
 - timer comparators such as `cstimer` still remain benchmark/reference rows until deep evaluation says otherwise
 

docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md

@@ -17,6 +17,12 @@ State-separation rule:
 Do not let bookmark presence, queue position, planning artifacts, or docs
 metadata masquerade as product intent or proof of implementation.
 
+Donor-strength rule:
+
+- donor strength and legal posture are separate axes
+- a restrictive or boundary-sensitive repo can still be the strongest owner for a lane
+- route difficulty changes how retained value may enter the product, not whether it may win technically
+
 - current shallow-eval set: `71` repos
 - currently verified live/implemented in checked Unreal surfaces: `20`
 - permissive live lanes: `13`