# HyperTwist - PROVENANCE_AND_TRUST_MODEL.md

## Purpose

Define how provenance, custody, and trust state should appear inside
HyperTwist.

This is not only a reporting/export concern. It is a training, replay,
recognition, coaching, and publication concern.

## Core rule

Any action-bearing, evidence-bearing, or recommendation-bearing object should
be able to answer:

- what is this
- where did it come from
- who/what produced it
- when
- under what custody class
- what trust caveats apply
- how it links to replay/evidence/state history

## Minimum visible provenance fields

Where relevant, HyperTwist should preserve and surface:

- object identity
- source repo/path/artifact origin
- producer/service/tool identity
- timestamp and session/run identity
- custody class
- approval/correction history
- warning/partiality state
- replay/evidence linkage

## Custody classes

HyperTwist should be able to distinguish at least:

- first-party authoritative
- permissive donor-derived
- boundary-sensitive first-party derived
- restrictive clean-room-derived
- external live service output
- user-authored
- unresolved/untrusted

## Trust posture examples

Typical trust/state markers include:

- observed
- inferred
- corrected
- replayable
- verified
- derived
- externally supplied
- approval required
- stale
- disconnected

## Product implication

Provenance/trust is not a late reporting embellishment.

It should influence:

- recognition correction surfaces
- replay/history views
- coaching explanations
- challenge/publication surfaces
- import/export/report builders
- compact memory views

## Derived compacted state rule

If HyperTwist introduces compacted, reduced, summarized, or otherwise
assistive-transformed variants of a raw object, those variants should surface
as derived state rather than replacing the authoritative source object.

The governing authorities are:

- `C:\HyperTwist\docs\ops\HYPERTWIST_OPTIONAL_ASSISTIVE_FEATURE_DEACTIVATION_AND_REMOVABILITY_DOCTRINE_2026-05-21.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_CONTINUITY_LATTICE_AND_CONTEXT_ASSEMBLY_PROFILE_DOCTRINE_2026-05-23.md`

Companion extraction surface:

- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\FEATURE_REGISTRY.md`

## Skill-specific consequence

The skillization doctrine now requires provenance-visible declaration even
before wrapper execution lands.

The landed bounded first-party `Phase S1-A` packet keeps:

- skill id, owner-lane, and status truth first-party
- command/service bindings declared rather than inferred ad hoc
- permission/scope declarations explicit
- the landed bounded first-party `Phase S1-C` packet now keeps invocation
  record format, command/service provenance, and failure/cancel audit storage
  first-party
- the landed bounded first-party `Phase S1-B` packet keeps durable master and
  per-skill off-state control first-party rather than hidden prompt babysitting
- the landed bounded first-party `Phase S1-D` packet now keeps authoring
    template, registry-grounded examples, and smoke/eval validation structure
  first-party before wrappers land
- the landed bounded first-party `Phase S2-A` packet now keeps structured
  architecture scan, policy scan, route inspection, and watch-and-recheck
  wrapper outputs provenance-visible through first-party command/service
  bindings rather than deferred wrapper prose
- the landed bounded first-party `Phase S2-B` packet now keeps restrictive
  skill command contracts first-party, provenance-visible, and explicitly
  unable to mutate product truth
- the landed bounded first-party `Phase S2-C` packet now keeps restrictive
  skill specs expressible entirely in first-party terms without donor wording
  or implied live runtime ownership
- the landed bounded first-party `Phase S3-A` packet now keeps continuity and
  resume skill output provenance-visible over authoritative memory stores while
  leaving `capture-note` explicit, non-live, and separately owner-gated
- the landed bounded first-party `Phase S3-B` packet now keeps recall and
  compact-view output provenance-visible while requiring compact views to
  remain optional and linked back to authoritative sources
- the landed bounded first-party `Phase S3-C` packet now keeps workflow-memory
  capture output provenance-visible while requiring capture state to remain
  anchored to authoritative workflow entities, separate from user-authored
  notes, and free of opaque summary collapse
- the landed bounded first-party `Phase S4-A` packet now keeps docs extraction
  and design-spec extraction provenance-visible while requiring structured
  extraction to remain bounded and unable to widen into design translation
- the landed bounded first-party `Phase S4-B` packet now keeps browser trace
  capture and browser/API discovery provenance-visible while requiring
  browser diagnostics to remain bounded and unable to widen into design
  translation
- the landed bounded first-party `Phase S4-C` packet now keeps design-shell
  translation and interaction-contract translation provenance-visible while
  requiring the output to remain bounded, derived-only, and unable to widen
  into generic browser-shell orchestration

## Memory-specific consequence

The memory doctrine defines provenance/trust-ledger memory as a distinct lane
and requires provenance to survive:

- the landed bounded first-party `Phase 6R-M1` memory contracts and ledger
  packet
- the landed bounded first-party `Phase 6R-M2` chronicle and continuity
  packet
- the landed bounded first-party `Phase 6R-M3` recall and shared-context
  packet
- the landed bounded first-party `Phase 6R-M4` cognitive consolidation packet
- the landed bounded first-party `Phase 6R-M5` knowledge and notes packet
- the landed bounded first-party `Phase 6R-M6` derived memory and optional
  adjunct packet
- chronicle capture
- continuity/resume packets
- explicit recall and provenance drill-down
- derived compact views through the landed `6R-M6` seam
- active user-authored note capture beyond the landed `6R-M5` seam

Important continuity-profile reading:

- `Max-Retention Mode` and `Economic-Retention Mode` are transmission and
  context-assembly profiles only
- they do not change provenance rank, custody visibility, memory ownership, or
  truth arbitration
- confidence does not outrank authority
- a high-confidence derived record must not outrank a raw authoritative record

Cross-project synchronization consequence:

- the live VectorShell-memory entrypoint is
  `C:\HyperTwist\docs\VECTORSHELL_MEMORY_SYSTEM_IMPORT_AUTHORITY_FOR_HYPERTWIST_2026-05-25.md`
- later superior evidence may revise an earlier memory or continuity `A1`
  call only for the exact lane or sub-slice it is demonstrably stronger at
- weaker or partial later repos remain bounded adjuncts
- if a revision happens, provenance-visible canon must be updated across the
  dependent HyperTwist authority surfaces rather than leaving the change in
  one packet
- a stronger later repo does not justify automatic whole-repo absorption or
  silent architecture rewrite

## Redaction and publication

Publication surfaces should preserve enough provenance to remain auditable
while still allowing:

- redaction
- audience scoping
- clean-room-safe publication
- policy-bound evidence export
