[AzielEliab]

Off main 865c5fc.

What the drop-down shows

• Applicable factors: each one's value exactly as TRIAD_V3 returned it, the applicability reason, and the checker's own output copied field for field. Examples: SPRE pc, band, factors including penalty names such as official_narrative_without_evidence, and audit_flags. Truth Formula score, mode, factors and formula. Bayesian posterior, applied, hits and hypotheses. PLR coherence/neutrality, status, lights and flags. CLCE structural, band and counts. No model is called and no reason is invented.
• Pairings: every ordered factor_i × factor_j product, plus combined as their mean. A test checks that the products reproduce combined within rounding.
• Omitted factors: each with the checker's applicability reason ("checker returned no reason" if it gave none) and "Not scored as 0."
• Rescores: which factor values changed, before → after with a signed delta. The deltas come from stored triad_json only.
• Older receipts: "per-factor detail not stored for this receipt". Nothing is backfilled.

Storage and D1 cost

• factor_detail is written at submit and rescore time into receipt_rescores.triad_json. It is not recomputed on expand.
• triad_json is not part of any receipt content_sha256 or ledger entry hash, so old and new hashes are unaffected.
• The receipt route's existing rescoreHistory query now also selects triad_json. Same rows, no extra query.

Rendering

• Everything is rendered with textContent inside the existing drop-down, with no new chrome.
• The "Hash-linked and sealed. Not signed." label is kept. No bias-proof claims.

Tests: 295/295 (new factor-detail.test.mjs). Not merged, not deployed.

[AzielEliab]

Updated at b06a13c for AZBot's seal-coverage blocker:

• New SUBMIT and RESCORE ledger payloads now include factor_detail_sha256 (sha256 of the canonical factor_detail). The field is additive, so old entry hashes are unchanged.
• JSON now returns receipt.factor_detail_sealed. It's true only when the proof is verified, the SUBMIT row matches the checkpoint (hash_ok, in range, matches_checkpoint), and the sha256 of the stored factor_detail equals the field. Old receipts and any mismatch give false.
• The drop-down's first per-factor line states coverage. Otherwise it reads: 'Per-factor detail is stored data. It is not covered by the seal.'
• Tests: covered case, triad_json edited after the write (false), old SUBMIT without the field (false), unverified proof (false). Pairing products now display rounded to 4 places.
• 300/300 pass. Not merged, not deployed.