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

## Memory-specific consequence

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

- chronicle capture
- continuity/resume packets
- cognitive coach-state consolidation
- knowledge promotion
- derived compact views

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
