# HyperTwist Cross-Lane Authority Hierarchy And Reconciliation - 2026-05-20

## Status

This document is now the governing HyperTwist authority doctrine for
cross-lane overlap, contested retained slices, and targeted reconciliation.

If a looser prompt, packet, or standing note conflicts with this document on
authority ranking, execution routing, realization width, or selective
retroactive backfill, this document wins.

Retroactive backfill behavior itself is governed by:

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

## Purpose

This document defines the mature decision model for cross-lane discrepancies
when two or more repos compete for the same retained capability slice.

Its job is to keep three separate questions from being blended together:

1. which repo is strongest for the slice
2. how that slice must be implemented
3. how much of that winning slice should actually be realized in HyperTwist

Those are separate questions.

## Core correction

Capability hierarchy is license-neutral.

License posture must not decide which repo is primary authority for a retained
slice.

License posture decides execution route only.

So the order is:

1. determine the strongest slice authority on capability grounds
2. preserve secondary non-overlapping value from the other candidates
3. only then decide whether implementation is direct, boundary-first,
   clean-room, oracle-only, or excluded

If the strongest repo for a slice is restrictive, mixed, no-license, or
otherwise unsuitable for ordinary direct incorporation, it still remains the
highest capability authority for that slice.

The consequence is not demotion.

The consequence is boundary-first, clean-room, or oracle-only routing.

## Three-axis model

Every meaningful overlap decision must separate three axes.

### Axis A - capability authority tier

This is the hierarchy axis.

Use these slice-local tiers:

- `A1` - primary slice authority
  - the strongest source-backed owner for the retained slice
- `A2` - adjunct donor
  - not the primary owner, but still carries unique non-overlapping value that
    must be preserved
- `A3` - reference authority
  - useful for understanding, operator expectations, examples, or checks, but
    not selected as implementation owner
- `A4` - pattern authority
  - useful only for architectural patterns or heuristics, not for direct
    retained ownership
- `A5` - excluded
  - no retained value in the current horizon for the relevant slice

`A1` is decided per slice, not per repo globally.

Do not force whole-repo winner-take-all decisions when the source reality is
subsystem-specific.

Later superior evidence may replace an earlier `A1`, but only for the exact
contested slice or sub-slice it is demonstrably stronger at.

### Axis R - execution route

This is not hierarchy.

This is the implementation-routing axis.

Use:

- `R1` - direct first-party incorporation or vendored integration is allowed
- `R2` - boundary-first adapter, sidecar, or isolated integration route
- `R3` - clean-room implementation route from a restrictive or otherwise
  unsafe donor
- `R4` - oracle-only or correctness-reference route
- `R5` - no implementation route in the current horizon

Rule:

- `A1` does not imply `R1`
- a slice can be `A1 + R3`
- that means it is the best authority, but implementation must be first-party
  clean-room

### Axis F - realization width

This is the scope-width axis.

Use:

- `F1` - full bounded capability realization
- `F2` - narrower bounded slice

Rule:

- `A1` does not imply `F1`
- a slice can be `A1 + R1 + F2`
- or `A1 + R3 + F2`

That means it is the best authority, but HyperTwist still intentionally takes
only the narrower bounded part.

## Mandatory comparison scaffolds

### Scaffold 1 - slice decomposition

Before comparing repos, break the overlap into named slices.

Never compare entire repos when the real competition is only one subsystem.

If two repos only appear to overlap because the slice was defined too broadly,
refine the slice before ranking.

### Scaffold 2 - capability comparison matrix

For each candidate repo and each contested slice, compare on:

1. slice completeness
2. source-backed correctness or maturity
3. validation evidence
4. composability
5. operator quality
6. unique retained value
7. boundary cleanliness

Do not compare on license here.

License is handled later under Axis `R`.

### Scaffold 3 - authority resolution

After the comparison matrix:

- assign one `A1` per contested slice
- assign `A2` to any candidate with non-overlapping retained value that must
  survive
- assign `A3` or `A4` where only reference or pattern value survives
- assign `A5` only when the slice truly adds no retained value in the current
  horizon

Default bias:

- preserve secondary unique value
- do not collapse a losing candidate to `A5` if it still offers unique
  operator, fixture, protocol, adjunct, or neighboring-slice value

### Scaffold 4 - execution routing

Only after `A1` is known, assign `R`.

This is the exact point where license posture matters.

It matters to route.

It does not matter to hierarchy.

### Scaffold 5 - realization width

For the `A1` winner, decide whether the retained return is `F1` or `F2`.

If `F2`, name:

- the exact promoted sub-slice
- the exact families not being promoted
- which secondary repo, if any, remains the best adjunct, reference, or
  pattern authority for the non-promoted remainder

## Decision rules

### Rule 1 - best capability wins

The strongest source-backed slice wins `A1`.

Not the easiest license.

Not the easiest integration.

Not the most convenient current worktree.

### Rule 2 - license affects route, not rank

If a restrictive repo is strongest for the slice:

- it still gets `A1`
- its route becomes `R3` or `R4`
- implementation becomes clean-room or oracle-routed as appropriate

### Rule 3 - preserve secondary value explicitly

If repo `X` wins `A1` for a slice and repo `Y` still has unique value:

- `Y` becomes `A2`, `A3`, or `A4`
- the packet must say exactly what survives from `Y`
- that value must not disappear merely because `X` won primary ownership

Weaker or partial later repos remain bounded adjuncts.

Do not let a later partial winner blur neighboring ownership merely because it
arrived later or is more convenient to implement.

### Rule 4 - split coarse overlaps into sub-slices

If each repo is stronger at different sub-parts of an apparent overlap, do not
force a false single winner.

Instead:

- split the slice
- assign separate `A1` owners
- reconcile only the real contract between them

### Rule 5 - avoid mushy co-ownership

Do not default to “both own it.”

If the overlap is real, assign:

- one `A1`
- one or more `A2` or `A3` or `A4`

Only use effectively shared authority when the slice is still too coarse and
must be decomposed further.

### Rule 6 - tie-break with capability evidence, not license

If two candidates look close, tie-break in this order:

1. stronger slice completeness
2. stronger source-backed correctness or validation evidence
3. cleaner subsystem boundary and composability
4. stronger unique operator or workflow value
5. stronger retained adjunct coverage across neighboring slices

If still unresolved, do not force certainty.

Mark it as requiring targeted cross-lane reconciliation or deeper validation.

## Required packet outputs when overlap exists

When a repo packet or cross-lane checkpoint touches a real overlap, it must
name:

- exact contested slice
- candidate repos considered
- `A` tier per candidate for that slice
- `R` route per candidate where relevant
- `F` class for the retained winner if implementation is plausible
- primary winner rationale
- secondary preserved value from non-winners
- exact non-promoted families
- whether further targeted cross-lane reconciliation is required

## Required closeout behavior

If a closeout references a repo whose retained slice competes with another
retained repo, the closeout should surface:

- who is `A1` for the contested slice
- what survives as `A2` or `A3` or `A4`
- whether the execution route is `R1`, `R2`, `R3`, `R4`, or `R5`
- whether the realization width is `F1` or `F2`

Do not hide the real winner behind generic donor prose when authority was
actually resolved.

## Targeted cross-lane checkpoint trigger

Open a targeted cross-lane reconciliation pass only when one of these is true:

- the `A1` owner is still unresolved after slice decomposition
- the slice boundary is clear, but the API, protocol, semantic, or persistence
  contract between adjacent winners is unresolved
- two prior packets contradict each other about the same contested slice
- the next implementation bound would otherwise silently widen into a
  neighboring owner surface

Do not open the checkpoint merely because:

- two repos look similar at README level
- one repo is restrictive
- the losing repo still has preserved adjunct value

## Relationship to existing doctrine

This document extends, but does not replace:

- `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md`
- `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_RETROACTIVE_AUTHORITY_AND_CLEANUP_BACKFILL_2026-05-20.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_CANONICAL_COMPACT_CLOSEOUT_FORMAT_2026-05-19.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_PACKET_CLEANUP_AND_REBUILDABLE_ARTIFACT_HYGIENE_2026-05-20.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\MODEL_OUTPUT_RULES.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\README.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\bounded-implementation-workflow.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\GENERIC_OPERATOR_SEQUENCE_AND_PROMPTING.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\0600-phase5r-clean-room-operator-sequence-and-handoff.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\0500-phase5r-restrictive-lanes.model-b-consolidation-prompt.md`

## Retroactive backfill rule

Use the governing retroactive backfill doctrine:

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

Authority backfill here is selective, comparative, and slice-local.

Required rule:

- do not do fake whole-corpus rewrites
- do not do blind full resets
- do not invent certainty for older ambiguous packets
- reopen only the earlier affected packet or standing note when later
  same-family evidence materially changes a contested slice
- preserve valid repo-local extraction explicitly when only cross-lane
  authority changed
- name the exact earlier packet or standing note reopened

If the revision affects active memory or continuity canon, propagate the
corrected slice-local authority through the dependent HyperTwist canon layers
instead of leaving the change inside one packet or one reopen note.

At minimum propagate through:

- `HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md`
- `HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md`
- `ARCHITECTURE.md`
- `FEATURE_REGISTRY.md`
- `PROVENANCE_AND_TRUST_MODEL.md`

Stronger later evidence does not justify automatic whole-repo absorption or
silent architecture rewrite.

Backfill only where the hierarchy model materially changes interpretation,
implementation routing, checkpoint gating, or preserved secondary value.
