TT Claude Memory

feedback_ecosystem_not_dade_in_specs

Properties1
description20 April 2026 — Rich directed that specifications of any sort (InheritKit, INHERIT, any product or architecture doc) + commit messages must use the abstraction "Ecosystem" rather than naming DADE specifically. Confidentiality + strategic flexibility reasons. Docs dedicated TO DADE (e.g. standard/orgs/dade/complementary-positioning.md) are the exception.

5 min read

The rule (Rich’s exact words, 20 April 2026):

  1. First pass: “i think when I typed ‘Don’t mention inheritkit’, it was in error — I actually meant ‘Don’t specifically mention DADE when making specifications for Inheritkit’ — please adjust any notes”
  2. Broadened: “i also meant ‘Don’t specifically mention DADE when making specifications of any sort — use the term Ecosystem instead’”
  3. Urgency context: “i am saying this because we made some github commits which mentioned Dade, and will be publically visible — quite embarrassing”
  4. Refined 20 April 2026 evening: “I am happy for it to be mentioned in internal documents, but i don’t want us to name entities in inherit v2 and inheritkit specifically after Dade: i would like to use ‘ecosystem’ in any entities we have that are there because we want to be ready to interoperate with Dade when the time comes.”

Precise scope of the discipline (refined):

  • Entity names in INHERIT v2 + InheritKit code / schema / specs — NEVER use Dade* naming. Use Ecosystem* prefix/suffix. Applies to: schema entity types (classes, fields), InheritKit module names, Catala file names, Rego resource names, MCP tool names, API endpoints, database tables + columns, environment variable names.
    • ❌ DadeDelegation, @inheritkit/dade-interop, dade_credential_id, validate_dade_delegation, dade.delegation.v1, dade-token-exchange.catala_en
    • ✅ EcosystemDelegation, @inheritkit/ecosystem-interop, ecosystem_credential_id, validate_ecosystem_delegation, ecosystem.delegation.v1, ecosystem-token-exchange.catala_en
  • Internal-document prose (CLAUDE-strategy-repo, CLAUDE-admin-repo, richard-tasks.md, brand-architecture.md, partnership-targets.md, ideas captures, memories) — DADE may be named directly for partnership/strategy/positioning discussion.
  • Docs dedicated TO DADE (e.g. standard/orgs/dade/complementary-positioning.md, foundation-arch-research/23-oidf-dasdt.md) — DADE named throughout; scope is partner-specific research/strategy.
  • Commit messages for code/spec work — use Ecosystem* naming per the entity-names rule; DADE in commit messages leaks through git history.
  • Public / partner-facing material (websites, public releases, NDA pitch-packs for audiences other than DADE themselves) — use Ecosystem* framing; DADE not named.

Why:

  • Confidentiality. If testatetech/docs-strategy ever becomes public (or commits/content get exposed via acquirer diligence, pitch decks, partner sharing, leak), DADE mentions in specs become strategically embarrassing. DADE co-chairs haven’t been approached yet; IIW 28-30 April 2026 is the planned approach window. Pre-approach DADE references in public/semi-public material undermine the intended framing.
  • Strategic flexibility. DADE may not succeed — CG → WG → published protocol has failure modes at each stage. Designing specs around DADE ties our fate to theirs. “Ecosystem” covers DADE + OAuth 2.0 Token Exchange + UMA + Sovrin + W3C VC-DM + any future partner.
  • Abstraction durability. “Delegation credentials arrive from the Ecosystem” is true regardless of which protocol wins.
  • Commercial flexibility. Customers who prefer different delegation-protocol standards shouldn’t see INHERIT/InheritKit as DADE-locked.

How to apply:

  1. In specifications of any sort (INHERIT specs, InheritKit specs, Option G, brand docs, architecture research, MCP design, Catala module descriptions, etc.): use “Ecosystem” as the abstraction. Examples:
    • Instead of “InheritKit MCP server handles DADE delegation” → “InheritKit MCP server handles Ecosystem delegation protocols”
    • Instead of “Auto-MCP has no native DADE delegation support” → “Auto-MCP has no native Ecosystem delegation support (OAuth 2.1 + delegation credentials)”
    • Instead of “InheritKit will consume DADE protocols” → “InheritKit will consume Ecosystem delegation wire protocols as they emerge”
  2. In commit messages: use “Ecosystem” not “DADE” when describing spec work. Commit messages live in git history and can leak through channels beyond the repo itself (PR descriptions, diligence reports, partner visibility during joint work).
  3. In positioning/strategy docs that happen to mention DADE partnership or cite DADE as a target: naming DADE is fine (e.g. tt-products/inherit-fhir-monetisation-analysis.md listing DADE as a partnership target). The rule is about SPECS, not positioning.
  4. In docs dedicated TO DADE (e.g. standard/orgs/dade/complementary-positioning.md): DADE can be named throughout — the doc IS about DADE. Exception to the rule.
  5. In presentations to DADE co-chairs themselves: DADE can be named directly — you’re talking to them.

Boundary test: “If this content were to leak publicly tomorrow, would DADE co-chairs be surprised or uncomfortable finding themselves named?” If yes → use “Ecosystem”. If no (because the doc IS about approaching them, or IS a dedicated partnership analysis) → naming is fine.

Past commits (20 Apr 2026): commits 1acfbf5 (“docs: FHIR monetisation + DADE positioning refreshed”) and 2a85abe (“docs: DADE positioning v2.2 — InheritKit as Firely-equivalent”) explicitly name DADE. Repo testatetech/docs-strategy is PRIVATE (confirmed via gh repo view) so these are not currently publicly visible. Going-forward rule applied from Monday 20 April 2026 onwards. Do NOT attempt git-history rewriting to retroactively clean past commits — rewriting shared history is destructive and doesn’t fit the private-repo-so-not-urgent reality. If public exposure becomes a real risk later, a separate decision + careful git filter-repo campaign can be planned.

What NOT to do:

  • Do NOT strip DADE from standard/orgs/dade/complementary-positioning.md — that doc’s whole purpose is DADE positioning.
  • Do NOT strip DADE from foundation-arch-research/23-oidf-dasdt.md — that doc IS specifically DADE/DASDT research.
  • Do NOT replace “DADE” in strategy/partnership-target contexts (tt-products/inherit-fhir-monetisation-analysis.md partnership-target section, brand-architecture.md if it ever references DADE as a target).
  • DO strip DADE from specs and replace with “Ecosystem” — see the violations list below.

Violations fixed 20 April 2026:

  • foundation-arch-research/30-sourcemeta-auto-mcp.md lines 177, 209 — InheritKit MCP architecture spec claims that tied specifically to DADE delegation. Rewritten to “Ecosystem delegation protocols (OAuth 2.1 + delegation credentials)”.
  • foundation-arch-research/23-oidf-dasdt.md scope field — “INHERIT v4.0.0 Layer 5 DADE integration” rephrased to acknowledge this research doc IS DADE-specific, but the spec CLAIM that InheritKit has a DADE-specific architectural layer is genericised.
  • standard/orgs/dade/complementary-positioning.md §4a row 4 — “InheritKit will CONSUME whatever DADE WG specifies” genericised to “InheritKit will consume Ecosystem delegation wire protocols” with DADE identified as one forthcoming source.

Graph View

Backlinks