# VEX Trust Model

This document explains how policy evaluation uses VEX evidence and issuer trust to produce deterministic, explainable outcomes. It focuses on *policy posture* rather than API details.

## Inputs to Trust

Policy decisions about VEX rely on evidence produced by VEX ingestion and correlation layers:

- **Raw observations** and provenance (issuer, timestamps, signatures, content hashes)
- **Normalized tuples** (status, justification, scope) emitted by VEX ingestion
- **Linksets** that correlate multiple sources without merging them
- **Consensus view** (when enabled) that summarizes the current effective status and conflicts
- **Issuer registry / directory** that defines trust tiers and verification rules per tenant

See `docs/16_VEX_CONSENSUS_GUIDE.md` for the conceptual model and `docs/modules/excititor/architecture.md` + `docs/modules/vex-lens/architecture.md` for implementation details.

## Principles

- **Provenance-first:** VEX is stored and referenced as evidence; policy never “rewrites” upstream statements.
- **Conflicts are first-class:** disagreements remain visible; policy chooses a posture for gating and explainability.
- **Deterministic evaluation:** given the same evidence set and policy pack, evaluation must produce identical results (ordering, timestamps, digests).

## Trust Signals Used by Policy

Typical signals include:

- **Issuer identity:** stable provider IDs and (when present) cryptographic identity assertions.
- **Verification status:** signature validity, certificate chain, transparency proof availability (offline-compatible).
- **Trust tier / weight:** tenant-configured tiering (e.g., vendor/distro/internal) and weighting used for precedence.
- **Freshness / staleness:** evidence age relative to time anchors; stale evidence can be down-weighted or gated.
- **Scope fit:** whether the VEX statement’s scope matches the evaluated artifact/environment.

## Policy Knobs (Posture)

Common policy knobs are expressed as rules rather than hard-coded behavior:

- Require cryptographic verification for certain tiers (or for all `not_affected` gating).
- Define how to treat conflicts (e.g., block on high-tier disagreement, or downgrade to `under_investigation`).
- Set staleness budgets for offline snapshots and how they affect acceptance of `not_affected`.
- Define which justifications are acceptable for suppressing a finding (and whether reachability evidence is required).

## Simulation (What-if Analysis)

Policy simulation is used to preview how changes in VEX trust settings or exception/waiver objects would affect outcomes before promotion. See:

- `docs/api/gateway/policy-exceptions.md` (simulation contract)
- `docs/60_POLICY_TEMPLATES.md` (policy packs and examples)

## References

- `docs/16_VEX_CONSENSUS_GUIDE.md`
- `docs/modules/excititor/architecture.md`
- `docs/modules/vex-lens/architecture.md`