Why this exists

Advisory only. Classifications are hypotheses for human review. Verify against TRUST_GROUNDING.md before acting.

DA competes for business on a network it no longer controls. This tool gives the SDK team visibility into ecosystem proposals before they become defaults — so architectural decisions are deliberate, not inherited.

Canton has two approval tracks that share the same Super Validator voting body. This tool watches where they diverge — and where the Dev Fund quietly pays for DA’s own core work.

Track 1 — Technical merit

Idea → cip-discuss → Draft CIP → Working Group review → SV sponsor + endorser → ⅔ SV vote → implementation (DA can veto on core OSS repos via CIP-0100) → Final when ⅔ adopt on-chain.

Track 2 — CC economics

Build app → generate traffic → lock CC (CIP-0116) → Featured App → same ⅔ SV vote → traffic-weighted rewards (CIP-0104) → reinvest / lock more.

Collision zone

Same SVs vote both paths. More apps → more traffic → more CC for SVs. That creates a structural incentive to approve high-traffic apps even when architecture is weak.

Cited economics (TRUST_GROUNDING.md):

What every proposal is tested against

Live frame: PROMPT_VERSION=trust-v8 (matches grounding.py). The scanner reads each proposal against three architectural invariants grounded in Elsner’s published writing:

• Privacy — sub-transaction privacy; parties see only what they are entitled to
• Authorization — rights and obligations stay enforceable on-ledger
• Composability — workflows compose atomically without breaking the above

violated can raise severity to critical; at_risk floors it at watch. Cited facts still gate every institutional claim.

Proposal lens (not PR body)

Grant content lives under /proposals/*.md. The GitHub PR body is a short checklist — do not treat it as the proposal.

Code authority (DA maintains Daml / Canton / Splice) is still true. Who pays is partly the Dev Fund. Showing both is the structural insight.

What it scans

Decision Health patterns (hypotheses)

1. Fast-track — CIP approved while unresolved technical objections remain.
2. SV weight concentration — how few SVs reach ⅔ weight (text heuristic, not on-chain coalitions).
3. Featured App without tech-review language — FA path needs lock + SV vote; absence of review keywords ≠ no offline review.
4. Weak / artifact milestones — read proposal files (and linked issues), not PR checklists.
5. Feasibility limbo — long Approved → Final gap (>60d).

How to use the UI

Orienting map (open the dashboard after this):

• Focus — four mutually exclusive urgency queues at the top (Alignment risk · Attention · Opportunity · Info). Pick one pile to work; Clear returns to all cards.
• Action — appears under Focus once a queue is selected. Narrows that pile by HITL verb (Respond · Track · Co-develop · …). The verb also stays on each card — the tool proposes, the human decides. Attention ≠ Track: Attention = urgency queue; Track = “follow, no move yet.”
• Intelligence — optional explainers below the nav (Approval chains · Know vs assume · Patterns · Predictions · Who). One lens at a time; Clear hides the panel.
• Source / Chain — filters inside Approval chains (CIP · Grant × Technical · Economics · Collision). Click a row to show matching cards.
• Reference — strip under the title: live DA product context (Daml backlog · Canton · Splice) plus cross-ref filters. Not classification cards.
• Every Intelligence card ends with labeled Sources + Citing.

Grounding rule

Every claim must cite either:

• a fact in TRUST_GROUNDING.md / cited_facts.py, or
• the scanned artifact itself (PR text, /proposals/*.md, issue, workflow YAML).

If it cannot be cited → do not assert it. Prefer insufficient data.

Attribution rule

Never invent institutions from GitHub handles.

• DA = -da suffix or verified list (meiersi-da, bame-da, moritzkiefer-da, Stephan-da, waynecollier-da, hrischuk-da, davidrichards-da).
• Foundation = e.g. hythloda (verified), pedrodneves (inferred ops).
• Anonymous handles stay unverified (bstolman1 is not Eric Saraniecki).

Limitations

• Severity, actions, and discrepancy tags are proposals for HITL — not orders.
• Keyword / heuristic detection is not semantic proof.
• Dashboard reflects last scan, not live chain state.
• Comment counts come from the GitHub issues API (pulls omit them).
• Fork radar / pulse sparklines / full proposal-body budget parse are not yet first-class UI.
• Foundation aipricheck.yml validates single PRs with pattern-matching heuristics; this scanner adds cross-repo drift — complementary, not duplicate.

Related

• TRUST_GROUNDING.md — citation map
• LOGIC.md — pipeline
• SPEC.md — product contract
• DATA_PULL_MAP.md — what the scan stores and what feeds Intelligence
• Admin: architecture notes + trust-v8 privacy patch (implementation detail)