TT Claude Memory

feedback_v2_ik_ias_build_plan_sovereign

Properties1
description2026-04-26 Rich directive — v2 + InheritKit + IAS proceed at proper-build pace AND in their natural sequence (Phase-1 Seq G1 + Phase-2 crate order + IAS roadmap); do NOT compromise quality, scope, sequencing, or priorities to accommodate LL or any other waiting consumer

4 min read

The INHERIT v2 + InheritKit + IAS build plan is sovereign. Two distinct disciplines, both in force:

  1. No rushing — quality first, ISO-track positioning, build properly. The 16-22 week Phase-1 estimate may slip; that is fine.
  2. No reshaping for downstream consumers — do NOT reorder Phase-1 Seq G1 modules (Core → Credentials → Assets → Transfer → Wills → Delegation → Commerce → Trusts → Probate), do NOT reorder Phase-2 InheritKit crate-building, do NOT prioritise IAS use cases, in order to land deliverables that a waiting consumer (LL, MFI, IW, anything) needs sooner.

The build proceeds in its natural sequence per inherit-v2-architecture-state.md v2.24+ + THE PLAN v1.2 + the architecture-state’s amendment registry. Consumer resume-dates are derived from that natural sequence, not the other way around.

Why: Rich’s 2026-04-26 directives, given in two iterations after agreeing the Stage-28 LL freeze:

  • First iteration: “we are not going to rush inherit v2 and inheritkit and ias - they must be built properly” (locks no-rushing).
  • Second iteration: “I do not want to modify the Inherit v2 & inheritkit & IAS build plan, in order to ‘accommodate’ LL” (locks no-reshaping).

The combined directive prevents the classic failure mode where a downstream team idling (Josh post-Stage-28) generates upstream pressure (Rich + Claude on v2/IK/IAS) to ship something — anything — to relieve the wait. Quality erodes in that pattern. By making the freeze open-ended AND the build plan unmodifiable, the freeze itself becomes a discipline mechanism rather than a problem to solve. Reinforces other build-discipline memories: ISO-track positioning, build-properly-before-moving-on, Apache-irrevocability conservatism, no-half-finished-implementations.

How to apply:

  • When LL (or any TT consumer brand: MFI / IW / OpenInherit / future) is waiting on a v2 module, IK crate, or IAS feature → state the natural delivery date per architecture-state + THE PLAN, NOT a date reverse-engineered from when the consumer needs it.
  • When tempted to reorder Seq G1 (e.g. “Commerce earlier because LL needs it” or “Assets before Credentials because LL needs it”) → DO NOT. Phase-1 Seq G1 is locked per A-24 at gap-discovery-optimal ordering.
  • When tempted to reorder Phase-2 crate-building (e.g. “marketplace before wills crate”) → DO NOT. Phase-2 sequence follows InheritKit’s own commercial-customer-driven roadmap.
  • When tempted to scope-cut a module to ship sooner (e.g. “Commerce v0.1 with only LL-needed fields”) → DO NOT. Each module is built to architecture-state spec.
  • When tempted to scope-add to a module to handle a consumer use case (e.g. “Add LL’s grading-systems requirements into Commerce module so InheritKit doesn’t need a separate grading-systems crate”) → DO NOT without re-running the architecture-state placement rules + introduction-module rule.
  • When the consumer’s wait window seems painful (e.g. Josh idle 12-24 months) → say so transparently AND hold the line. The wait is the discipline.
  • When asked “can we accelerate v2 / IK / IAS to unblock LL sooner?” → answer NO with reference to this rule, then offer scope-cut alternatives ON THE LL SIDE (delay LL launch, narrow LL scope, keep LL on v6.6 for first launch, etc.) rather than v2/IK/IAS-side compromises.
  • This rule does NOT prevent Phase-1.5 stress-test gate jurisdictional crates from being built in parallel where they don’t compromise Phase-1 Apache-core sequencing.
  • This rule does NOT prevent natural opportunism — if LL-needed Commerce module work happens to be more tractable to build before Wills (per genuine architecture-internal reasoning), do so. The rule prohibits reshaping for LL-pressure, not natural-priority adjustment for architecture-internal reasons.

Relationship to existing memories:

  • Reinforces feedback_v2_apache_deferred_until_public_release (Apache-irrevocability conservatism — same family of “build it properly, don’t rush commitments”)
  • Reinforces project_inherit_international_iso_intent (ISO-track positioning needs proper-quality output)
  • Reinforces feedback_weak_criteria_to_avoid_in_scorecards (the discipline pattern of saying “no” to expedient-but-wrong choices)
  • Pairs with project_ll_stage_28_freeze_path_a (the LL-side decision that triggered this build-plan-sovereign directive)
  • Compounds with feedback_apache_commitment_low_priority (do not push topics that compromise build quality)

Boundary test: before agreeing any v2/IK/IAS schedule change, scope addition, scope removal, or sequencing change, ask: “would this happen if LL did not exist?” If the answer is no — REJECT the change and say so explicitly with reference to this rule.

Graph View

Backlinks