themesd advisories enhanced

docs/product-advisories/14-Dec-2025 - Proof and Evidence Chain Technical Reference.md

@@ -25,6 +25,7 @@ EvidenceID       = hash(canonical_evidence_json)
 ReasoningID      = hash(canonical_reasoning_json)
 VEXVerdictID     = hash(canonical_vex_json)
 ProofBundleID    = merkle_root(SBOMEntryID, EvidenceID[], ReasoningID, VEXVerdictID)
+GraphRevisionID  = merkle_root(nodes[], edges[], policyDigest, feedsDigest, toolchainDigest, paramsDigest)
 TrustAnchorID    = per-dependency anchor (public key + policy)
 ```
 
@@ -61,6 +62,33 @@ public sealed record ProofSubject(
 sbomId = sha256(canonical_sbom_bytes)
 ```
 
+### 1.5 Graph Revision ID (graphRev)
+
+Use `GraphRevisionID` as the stable snapshot identifier for an artifact's *decision graph* (facts + derived edges) so receipts, UI/API responses, logs, exports, and replays can be correlated without ambiguity.
+
+Rules:
+- Graph revisions are content-addressed: any input change produces a new `GraphRevisionID`.
+- Inputs must be canonicalized (stable ordering, stable casing, UTC timestamps stripped/isolated) before hashing.
+- A graph revision must bind to the scan manifest inputs: `sbomDigest`, `feedsDigest`, `policyDigest`, `toolchainDigest`, and `paramsDigest`.
+
+Recommended string format:
+```
+graphRevisionId = "grv_sha256:" + sha256(canonical_graph_bytes)
+```
+
+### 1.6 Proof-of-Integrity Graph (build/runtime ancestry)
+
+Treat provenance as a first-class, append-only graph so "what is running?" can be traced back to "how was it built and attested?"
+
+Minimum model:
+- Nodes: `repo`, `commit`, `build`, `sbom`, `attestation`, `image`, `container`, `host`
+- Edges: `built_from`, `scanned_with`, `attests`, `deployed_as`, `executes_on`, `derived_from`
+- IDs: use content digests where possible (image digest, SBOM hash, DSSE hash); stable IDs for non-content entities (run IDs, host IDs)
+
+Operational rules:
+- Never delete/overwrite nodes; mark superseded instead.
+- Every UI traversal must be backed by API queries over this graph (no UI-only inference).
+
 ## 2. DSSE ENVELOPE STRUCTURES
 
 ### 2.1 Evidence Statement
@@ -165,7 +193,32 @@ Signer: VEXer key or vendor key
 
 Signer: Authority key
 
-### 2.5 SBOM Linkage Statement
+### 2.5 Verdict Receipt Statement (per finding/verdict)
+
+Use a receipt to bind the *final surfaced decision* to `graphRevisionId` and to the upstream proof objects (evidence/reasoning/VEX/spine). This is the primary export object for audit kits and benchmarks.
+
+```json
+{
+  "payloadType": "application/vnd.in-toto+json",
+  "payload": {
+    "_type": "https://in-toto.io/Statement/v1",
+    "subject": [{"name": "<ArtifactID>", "digest": {"sha256": "..."}}],
+    "predicateType": "verdict.stella/v1",
+    "predicate": {
+      "graphRevisionId": "<GraphRevisionID>",
+      "findingKey": {"sbomEntryId": "<SBOMEntryID>", "vulnerabilityId": "CVE-XXXX-YYYY"},
+      "rule": {"id": "POLICY-RULE-123", "version": "v2.3.1"},
+      "decision": {"status": "block|warn|pass", "reason": "short human-readable summary"},
+      "inputs": {"sbomDigest": "sha256:...", "feedsDigest": "sha256:...", "policyDigest": "sha256:..."},
+      "outputs": {"proofBundleId": "<ProofBundleID>", "reasoningId": "<ReasoningID>", "vexVerdictId": "<VEXVerdictID>"},
+      "createdAt": "2025-12-14T00:00:00Z"
+    }
+  },
+  "signatures": [{"keyid": "<KID>", "sig": "BASE64(SIG)"}]
+}
+```
+
+### 2.6 SBOM Linkage Statement
 
 ```json
 {