Skip to content
SDC Knowledge Base

sdc-sdapp-trust-receipt

Trust Receipt — make the verification visible in sd-app

Section titled “Trust Receipt — make the verification visible in sd-app”

Background

Section titled “Background”

Strategic-Plan v2.0 Phase 1a, and the highest value-per-hour item in the whole plan.

The ChatGPT brainstorming session (turn 2, §5) proposed a Trust Receipt attached to every recommendation — sources, method, assumptions, confidence, known limitations, conflicts, human review, decision owner — and treated it as a large future platform build. It is not. Per SDC-Strategy-Brainstorming-Upgrades #2, most of that content already exists on disk as the LevPro port’s M5 audit artifacts:

  • ~/projects/monorepo/packages/sd-math/docs/accuracy-audit.md
  • ~/projects/monorepo/packages/sd-math/tools/audit_independent_calc.py — independent re-derivation
  • ~/projects/monorepo/packages/sd-math/tools/generate_audit_report.py
  • the VB6 cross-check against the original licensed LevPro software
  • the PDF-parity diff against Sample Printout.pdf, which found 4 real defects that 18 self-referential tests had missed

Windows paths: `\\wsl$\Ubuntu-24.04\home\ta\projects\monorepo\packages\sd-math\docs\accuracy-audit.md`

So this is a presentation retrofit over verified assets, not a platform. It delivers three things at once: the session’s marquee trust idea, the “guaranteed accuracy” claim SDC/Offerings/Advisor-Firm-Pricing.md already makes to advisors, and the T — Trustworthy that Talbot added to F.A.S.T.T. It is also the answer to the recorded AI threat in Identity/Internal View/Threats.md: an AI-generated leverage calculator can produce the same number, but it cannot show a decade of provenance and a machine-checked cross-derivation.

Why it is not blocked: it needs no Cloudflare Pages project, no Stripe keys, and none of Talbot’s writing. It is verifiable locally by tests and the existing web-testing system.

Tasks

Section titled “Tasks”
  • Inventory what the audit artifacts actually contain before designing anything. Read accuracy-audit.md and both audit tools; list which Trust Receipt fields can be populated from real data today and which cannot. Do not design fields that have no source — an empty “Confidence: 82%” invented for the UI is exactly the AI-slop problem this feature exists to solve.
  • Design the Trust Receipt panel for apps/sd-app. Load the design-context skill (/design-context app) before any visual work — F.A.S.T.T. and Talbot’s brand constraints outrank generic design convention. Progressive disclosure per the session’s turn-1 §13: a one-line trust summary by default, expanding to method → sources → assumptions → what was cross-checked → known limitations → what would change this answer.
  • Implement it in apps/sd-app, with the content sourced from the audit artifacts rather than hardcoded prose. Where a value is genuinely static (e.g. “cross-checked against LevPro VB6 v_”), it may be a constant — but it must be a constant with a named provenance, not a marketing string.
  • Add it to the PDF reports (packages/pdf-reports) as a closing verification block. An advisor’s client sees the PDF, not the app.
  • State the limitations honestly, including the ones that reflect badly. sd-math’s strategies are Canadian-tax-modelled; the target market is U.S. advisors. The receipt must say what the analysis does not cover. Per the session’s turn 2 §11 and §29, appropriate resistance and admitted uncertainty are the trust signal — a receipt that only lists strengths is an advertisement.
  • Tests, following Core/AI/AI-Testing-Standards.md and the web-testing-system evidence gate: the panel renders at narrow widths, the expand/collapse works, the PDF block appears in all report variants, and every claimed source string resolves to a real artifact.
  • Run /create-review-guide ~/projects/monorepo if apps/sd-app/docs/Review-LevPro.md does not already cover this feature; otherwise update it so Talbot can see the change without hunting.
  • Update apps/sd-app/README.md / STATUS.md to record the feature. A docstring is not discoverable.

Success Criteria

Section titled “Success Criteria”
  • A sd-app analysis shows a one-line trust summary that expands to real, sourced verification detail — no invented numbers, no invented confidence scores.
  • The PDF report carries the same verification block.
  • The limitations section names the Canadian-tax-model constraint explicitly.
  • All existing tests still pass; new tests cover render, expand, PDF presence, and source-string resolution.
  • Review-LevPro.md (or its successor) tells Talbot exactly how to see it.

Notes

Section titled “Notes”
  • F.A.S.T.T. — Focused, Adaptive, Simple, Tailored, Trustworthy.
  • LevPro — Leverage Professional, the original Windows software this engine was ported from.
  • M5 — the LevPro-port milestone that produced these audit artifacts.
  • VB6 — Visual Basic 6, the language the original LevPro was written in; the cross-check compares the port’s output against it.
  • Do not ship any claim about returns, rates, or outcomes without Risks sign-off (SDC/Risks/JOB_DESCRIPTION.md hard rule 3). A verification claim about the math is not a claim about outcomes — keep that line clean and do not blur it in the copy.
Section titled “Related”