Add determinism tests for verdict artifact generation and update SHA256 sums script

- Implemented comprehensive tests for verdict artifact generation to ensure deterministic outputs across various scenarios, including identical inputs, parallel execution, and change ordering.
- Created helper methods for generating sample verdict inputs and computing canonical hashes.
- Added tests to validate the stability of canonical hashes, proof spine ordering, and summary statistics.
- Introduced a new PowerShell script to update SHA256 sums for files, ensuring accurate hash generation and file integrity checks.

docs/policy/vex-trust-model.md

@@ -1,15 +1,53 @@
-# VEX Trust Model — Draft Skeleton (2025-12-05 UTC)
+# VEX Trust Model
 
-Status: draft placeholder. Inputs pending: waiver/exception guidance, policy knobs.
+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.
 
-## Policy Knobs
-- Thresholds, weighting, override rules (to fill).
+## Inputs to Trust
 
-## Simulation
-- How to simulate decisions before enforcement.
+Policy decisions about VEX rely on evidence produced by VEX ingestion and correlation layers:
 
-## Examples
-- Placeholder for sample policies.
+- **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
 
-## Open TODOs
-- Add concrete policies and simulator instructions once provided.
+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`