TT Claude Memory

project_round_7_complete_2026_04_26

Properties1
description2026-04-26 — Path A research dispatch closing the entire 27-cluster gap-analysis inventory across Tier A (8 critical) + Tier B (9 important) + Tier C (10 secondary) + Tier D (3 informational). 17 FULLY-AVOIDS + 8 PARTIALLY-AVOIDS + 2 EMPIRICAL-ONLY-RESIDUAL (HMCTS Probate + Swiss cantonal — both have NO public API). ~17-22 engineer-weeks saved at ~£525 cost. Four candidate new primitives + 2 SKOS classifiers surfaced. Major architectural reframes: e-signed wills illegal Phase-1 / HMCTS no API / HMRC no IHT API / Mopsa-not-F* for Catala verification / pgsodium-TCE deprecated / IAS-auth = InheritKit-Delegation primitives.

8 min read

Decision/finding record (Sunday 26 April 2026):

Round 7 of the T-programme dispatched 21 parallel spike-avoidance subagents (T50-T70) covering all 27 named-in-early-plan technology clusters from docs/superpowers/specs/2026-04-26-tprogramme-gap-analysis.md v1.0. Per Rich’s Harvard-mode + Nobel-prize-opportunity discipline + spike-avoidance reframing (interrupt clarification 2026-04-26T19:35).

Process recovery note: First batch of 13 Agent calls returned “[Tool result missing due to internal error]” for all 13, but the agents themselves wrote their T-files to disk successfully — only the result-channel-summary was lost. T60 (Tier-2 UK gov APIs) was the single agent that failed to write; redispatched cleanly. Total: 20 of 21 first-pass + 1 redispatch = 21/21 complete. Lesson: verify big batches by file-existence on disk, not by tool-result presence.

Hit-rate:

  • 17 FULLY-AVOIDS — research alone closed the gap
  • 8 PARTIALLY-AVOIDS — residual ≤3-day micro-spike each
  • 2 EMPIRICAL-ONLY-RESIDUAL with hard asterisks (HMCTS Probate Registry / Swiss cantonal probate — both because the premise of the spike is invalid: there is no public API to spike against)

Highest hit-rate of any T-programme round (vs Round 4’s 7+6+0 of 22). Total spike-time saved: ~17-22 engineer-weeks. Round-7 cost ~£525.

The 10 most consequential findings (knock-on-effect-ordered):

  1. e-signed wills are PER-JURISDICTION (T56 reframed 2026-04-26 per A-99 + A-100, architecture-state v2.30). UK + Scotland + Switzerland constrain Wills execution to physical-witness (E&W COVID-relaxation expired Jan 2024; Scotland never enacted electronic-form for probative wills; Switzerland ZGB Arts 498-504 require notarial / handwritten / oral; Law Commission 2025 recommends future enabling power but no statutory instrument has commenced). Texas (Estates Code SB 1827 path) + Florida (Electronic Wills Act 2020) enable electronic execution + remote-online-notarization (RON) — these become the Phase-1 testbed jurisdictions for electronic-wills primitives. Phase-1 jurisdictional scope expanded 6→8 (adds Texas + Florida). Wills module standardises BOTH at Apache-core layer; per-jurisdiction crates supply the constraint or enablement axiom. Document-signing partner stack: Adobe Acrobat Sign + DocuSign (Tier-1 QES UK + EU); Yoti Sign (UK QES); Skribble-via-Smallpdf (Swiss QES); Notarize.com / Proof.com / OneNotary / DocuSign Identify US tier (US QES + RON — added 2026-04-26). Architectural pattern: store witness-event as PROV-O bundle with two W3C VCs (one per witness) signed at same wall-clock + geolocation + biometric — jurisdiction-agnostic; survives whatever statutory regime applies. NOT a scope contraction of the Wills module — it’s a per-jurisdiction-crate constraint pattern. (UK-drift correction; strict-form discipline memory feedback_stop_uk_drift_international_from_day_one_strict saved 2026-04-26.)

  2. HMCTS Probate Registry has NO public third-party API (T52). MyHMCTS portal-only; CCD API Gateway has hard-coded service list excluding partners; PA1A/PA1P v4 forms (early summer 2026) designed for scan-and-upload not REST. Common Platform Reform ended March 2025; no public-API roadmap on 2025-2026 horizon. A-17 Q3 milestone “HMCTS probate submission” needs RE-WORDING — Phase-1’s probate output flow is PDF-emit + portal-upload, not API call. Single biggest plan-shift from Round 7.

  3. HMRC has NO public IHT400 submission API (T59). Confirmed against developer hub. HMRC Transformation Roadmap commits to digitalising IHT “from tax year 2027 to 2028 onwards”; foundational CRM-migration work in 2025-2026; no public IHT API in Phase-1. TRS gated to agent/trustee credentials. InheritKit Probate emits fully-populated IHT400 PDF + future-API hook marked not-yet-implemented-no-API-exists. Swap-ready when HMRC opens API 2027-2030.

  4. Mopsa abstract interpretation is the real Phase-1 verification CI gate, NOT F* (T57). Mopsa won SV-COMP 2026 Gold (SoftwareSystems); found 16 real date-rounding bugs in 20K LOC French housing-benefits Catala code. F* extraction was never the production path (Merigoux et al. POPL 2021 §4.5 explicit). Catala compiler ships F*-mechanised translation correctness as vendor badge only; INHERIT rules are NOT F-verified end-to-end*. Architecture-state §1.2 must distinguish vendor-assurance (F*, Rocq) from rule-level verification (Mopsa, clerk PBT, catala typecheck). Lean 4 NOT a fallback (substrate replacement, not Catala plug-in).

  5. Keycloak 26.4 (Nov 2025) is the Phase-1 InheritKit + IAS reference IDP (T54). Only OSS IDP with officially-supported, non-preview implementations of all 5 InheritKit Delegation primitives — RFC 8693 since 26.2 + DPoP since 26.4 + FAPI 2.0 + OAuth 2.1 alignment + SMART Backend Services. Apache 2.0, EU-self-hostable, zero per-seat cost. Microsoft Entra ID does NOT support RFC 8693 or DPoP — uses proprietary On-Behalf-Of substitute. Major unification: IAS auth = InheritKit Delegation primitives applied to solicitor-AI-agent actor pair; same composite-token wire format as legacy-manager → AI-agent. Eliminates per-IAS auth design.

  6. pgsodium Transparent Column Encryption deprecated by Supabase Apr 2025 (T55); TCE removed Oct 2025. Phase-1 should use AWS KMS / GCP KMS envelope encryption with pgcrypto ciphertext columns + per-tenant DEKs (per-subject too expensive at $1/key/mo); HashiCorp Vault Transit cross-cloud option. Cryptographic-shredding for GDPR Art-17 is a SOLVED PATTERN (Kleppmann DDIA Ch 12; NIST SP 800-88 Rev 1; ISO/IEC 27040:2024). Option G §1.3 “pgsodium-encrypted mapping” framing must be replaced.

  7. Thirdfort is the legal-sector incumbent for orchestrated KYC + KYB + Source-of-Funds (T58). Embedded in 1,500+ UK regulated firms; bundles iProov GPA + NFC chip-read + Open Banking SoF + DIATF + HMLR Digital ID standard + SRA/CLC compliance. Two-vendor stack recommended Day-1: Stripe Identity (consumer/dealer KYC; already in stack via T24) + Thirdfort (regulated-legal partner-firm + executor). Removes ~80% of the build-vs-buy decision the explicit spike was meant to inform.

  8. Voyage AI voyage-3-large general + voyage-law-2 legal-domain fine-tuned + Cohere reranker (T62). Anthropic-recommended (per Kimothi Manning 2025); top-tier MTEB English. Same vendor stack for INHERIT + IAS (no separate procurement). BGE-M3 + jina-reranker-v2 OSS escape-hatch on Cloudflare Workers AI for AGPL-purity deployments. Substrate-agnostic (T31 locked Postgres + pgvector + RRF) — vendor swap is one-day.

  9. Oxigraph 0.4.x is Phase-1 primary triple store; Apache Jena Phase-1 insurance (T51). Oxigraph: Rust substrate (matches R3.12) + W3C SPARQL 1.1 + RDF 1.1 test-suite-passing + production at Wikimedia Enterprise / code.gouv.fr (Catala home — Path A alignment) / Inrupt Solid. Bi-temporal coupling with XTDB v2 via CDC-fed materialised view (Kleppmann pattern; neither needs temporal extension on the other). Stardog/Virtuoso/GraphDB rejected commercial; Blazegraph dead (Wikidata migrating off).

  10. OWL reasoner choice is decided by 3-orders-of-magnitude headroom (T50). ELK 0.6.0 (EL profile) classifies SNOMED CT 350K classes; HermiT 1.4.5 (full DL) classifies FIBO 4K. INHERIT at 200-400 classes sits comfortably below proven ceilings. Pellet legacy / Konclude defer to Phase-2.

Four candidate new primitives surfaced:

  • JurisdictionalSubmission (T52 + T60) — envelope class for target agency + submission method (8 SKOS subclasses) + auth state + idempotency key + ack state. Cross-cuts all 9 modules. Strong candidate for cross-module primitive #19.
  • KeyManagementContext or key_version field on every PII-bearing primitive (T55) — makes key-rotation observable in data model.
  • AssetDiscoveryProvenance field-group on AssetInterest (T60) — discoveredVia + discoveryConfidence + evidenceSource + attestor; SHACL flags un-attested assets for executor confirmation.
  • SolicitorRuleAuthorshipCredential (T63) — 8th VC schema (A-43 grows 7→8); SD-JWT VC; firm-DID did:web; Catala-backed claim. Solicitor sign-off becomes billable artefact.

Two SKOS classifier schemes promoted to candidate:

  • AuthorityTypeScheme (T52/T60) — API-OAuth / Portal-Upload / Email-Attach / Fanout / AccessCode / OpenData / WebForm / B2B-SOAP-XML
  • AssetDiscoveryChannelScheme (T60) — 4-6 categories per asset class

Why this matters (knock-on for next phase):

Rich’s stated next move: “going back to the beginning of the plan — all our scorecards are very likely to be considerably changed”. Top 4 scorecard-shift candidates surfaced (knock-on-ordered):

  1. G-7 architecture proposal scorecard — e-signed-wills-illegal + HMCTS-no-API + HMRC-no-IHT-API push downward on Phase-1 standardisation completeness.
  2. Catala scope-approval scorecard (locked δ 2026-04-25) — verifiability claim downgrades from “F*-verified rules” to “Mopsa CI gate + F* compiler-vendor badge”. ~3-5pp re-score.
  3. Q4 Credentials module placement scorecard (locked 5-split 96.6% 2026-04-24) — A-43 grows 7→8 VCs; IAS unification adds composability axis.
  4. A-17 Phase-1 partner-integration sequencing scorecard — needs 3-sub-tier split (2a-immediate / 2b-onboarding / 2c-deferred-or-rejected). Saves 5-10 engineer-weeks Phase-1.5.

How to apply:

  • When producing strategic output referencing any of T50-T70’s findings, cite the T-file directly (e.g. “per T54, Keycloak 26.4 is the InheritKit reference IDP”)
  • When considering scorecard re-scoring, sequence by knock-on per feedback_scorecards_one_at_a_time_optimal_sequence
  • Architecture-state v2.24 → v2.25+ updates accumulate per feedback_architecture_state_file_discipline
  • The 4 candidate primitives + 2 candidate SKOS schemes are NOT yet adopted into arch-state — they wait for individual scorecards
  • When Rich asks “what does this mean for Phase-1 scope?”, lead with finding #1 (e-signed wills illegal) and #2 (HMCTS no API) — those have the biggest plan-shift effect

File pointers:

  • 21 T-files: ~/off-github/library/projects/inherit/T50-T70.md
  • Plan: ~/testatetech/docs-strategy/docs/superpowers/plans/2026-04-26-round-7-dispatch.md v1.0
  • Gap-analysis source: ~/testatetech/docs-strategy/docs/superpowers/specs/2026-04-26-tprogramme-gap-analysis.md v1.0
  • T-programme-index: ~/off-github/library/projects/inherit/T-programme-index.md v1.6 (updated by this closeout)
  • THE PLAN: ~/testatetech/docs-strategy/docs/superpowers/specs/2026-04-25-t-programme-plan.md v1.3 (updated by this closeout with §11 Round-7 deltas)
  • Architecture-state: ~/testatetech/docs-strategy/docs/superpowers/specs/inherit-v2-architecture-state.md v2.24 (NOT yet updated; awaits per-finding scorecard locks)

Memory cross-refs:

  • feedback_v2_ik_ias_build_plan_sovereign (no-rush + no-reshape — Round 7 findings can shift Phase-1 scope without consumer-pressure compromise)
  • project_ll_stage_28_freeze_path_a (LL born-on-v2 gate; Round 7 informs the v2/IK/IAS readiness criteria)
  • feedback_always_check_library_indexed_first (subagents grounded in ~/off-github/library/indexed/)
  • feedback_architecture_state_file_discipline (state file updates after per-scorecard locks, not in bulk)
  • project_round_6_harvard_complete_2026_04_25 (Round 6 hit-rate baseline; Round 7 surpasses)
  • project_spike_replacement_round_4_complete_2026_04_25 (T-CROSS spike-avoidance precedent that Round 7 extends)
  • feedback_scorecards_one_at_a_time_optimal_sequence (when scorecard re-scoring begins, sequence by knock-on)

Graph View

Backlinks