⚠️ SECOND REVERSAL — 22 April 2026 (AUTHORITATIVE)
Current rule (Wednesday 22 April 2026, locked during architecture-lock session): LEAN TO INHERITKIT in close calls.
Rich’s words (2026-04-22, during fix-list review of independent plan-reviewer critique): “we lean towards inheritkit - we do not lean towards apache.”
This RE-REVERSES the 2026-04-20 lean-to-Apache default that this memory previously established (see superseded section below). The current direction returns to the 2026-04-16 original — default to InheritKit when genuinely uncertain.
The current rule (2026-04-22)
Rule: When genuinely uncertain whether content belongs in Apache INHERIT or AGPL+commercial InheritKit, lean InheritKit.
Why (Rich’s reasoning today): Commercial moat preservation. Moving content from Apache to AGPL later is structurally impossible (Apache is irrevocable). Moving content from InheritKit to Apache later is always possible. Under genuine uncertainty, prefer the reversible direction. Plus: InheritKit is where TT’s revenue + acquirer-value compounds; over-publishing to Apache gives away that compounding.
Scope
- Applies to borderline content where two-lawyers-test + competitor-test are ambiguous.
- Does NOT override clearly-statutory content (always Apache) or clearly-interpretive content (always AGPL+commercial).
- Specifically: Q5 memo v1.2 §1 framing of “lean-to-InheritKit default” is now correct per this directive (was previously mis-cited against this memory’s 20 April content; Rich’s 22 April directive aligns it).
Historical reversals — audit trail
| Date | Direction | Session trigger |
|---|---|---|
| 16 April 2026 | Lean-to-InheritKit (original) | Brainstorm — commercial-moat framing |
| 20 April 2026 | Lean-to-Apache (FIRST reversal) | Rich-word: “lean Apache: if we don’t, a competitor will” |
| 22 April 2026 | Lean-to-InheritKit (SECOND reversal — current) | Rich-word during fix-list review: “we lean towards inheritkit” |
The 20 April 2026 rationale (commercial competitor will Apache-release what TT doesn’t) is ACKNOWLEDGED but deprioritised under the 2026-04-22 directive. Rich accepts the competitor-Apache risk in exchange for preserving the InheritKit commercial moat + reversibility discipline.
Cascades from this 2026-04-22 reversal
- Q5 memo v1.2 §1 — already written assuming lean-to-InheritKit; NOW CORRECT (was technically contradictory to 2026-04-20 memory at time of writing).
- architecture-proposal v1.5 — all claims about Module-decomposition Apache-vs-AGPL split for borderline content default InheritKit. Core + 6 family SCHEMAS stay Apache (clearly statutory/structural); per-family
@inheritkit/*crates stay AGPL+commercial (clearly interpretive + tooling). These are NOT close calls. Close-call borderline content under Z4-LICENCE + Z24-MODULARITY research now defaults InheritKit. - Z4-LICENCE agent prompt — must cite this 2026-04-22 direction.
- Z24-MODULARITY agent prompt — must cite this 2026-04-22 direction for per-module licensing deliberations.
ideas/2026-04-20-lean-to-apache-default.md— flagged superseded.
Decision tests (restated under lean-to-InheritKit)
Both tests must point InheritKit for InheritKit to be chosen (maintains asymmetry but in opposite direction now):
- Two-lawyers test: if two competent lawyers would agree on the content without case-law argument → Apache. If they’d disagree → InheritKit.
- Reversibility test (new under 2026-04-22): “Can TT move this from InheritKit to Apache later if needed?” If yes → start in InheritKit. Apache is irrevocable; InheritKit is reversible.
Both tests point InheritKit in most Phase 1 close-call cases.
⚠️ SUPERSEDED — First reversal 20 April 2026 (lean-to-Apache)
Superseded 2026-04-22 by the second reversal above. Preserved for audit trail.
The 20 April 2026 reversal established lean-to-Apache as default, on reasoning that competitors would Apache-release content TT kept AGPL, stealing contribution momentum. Rich’s 22 April directive accepts this is possible but ranks it lower-priority than commercial-moat preservation + reversibility.
See full primary-evidence capture: docs-strategy/ideas/2026-04-20-lean-to-apache-default.md (now marked superseded 2026-04-22).
20 April 2026 rule (SUPERSEDED)
Old rule (1st reversal): When genuinely uncertain whether content belongs in Apache INHERIT or AGPL+commercial InheritKit, lean Apache.
Rich’s 20 April words: “i am beginning to think that, if in doubt, we will lean to Apache: this is because if we don’t think it is Apache, a competitor may — so we need to be pragmatic (not optimistic)!”
Moat-shifts-up-the-stack argument (still valid but deprioritised): commercial moat sits in interpretive layer + productised assembly + practitioner-workflow tooling, not base-layer statutory encoding. Rich accepts this argument but now weights it below reversibility + revenue-preservation.
⚠️ HISTORICAL — Original 16 April 2026 (lean-to-InheritKit)
Superseded 20 April 2026 (first reversal). Effectively RESTORED by 22 April 2026 (second reversal). Retained for audit.
Original 16 April 2026 bias: “If we have a close call whether to put something into the INHERIT standard schema, or into InheritKit, then we should always go with InheritKit, as it may be problematic to move it out and put into InheritKit at a later date, due to licensing.”
That original framing is effectively what’s authoritative again as of 22 April 2026.
Operational rule going forward (2026-04-22 authoritative)
- Read this memory’s top section (SECOND REVERSAL) as the current rule.
- Do NOT apply the 20 April lean-to-Apache rule — it is superseded.
- Do NOT apply the 16 April original phrasing literally — the 22 April directive is aligned with it but should be cited as the 22 April directive, not 16 April, because today’s Rich-word is the current authority.
When a close-call licensing question arises in v2 + InheritKit specs, research memos, or agent outputs: default InheritKit.