TT Claude Memory

feedback_inherit_v2_evaluation_criteria

Properties1
description20 April 2026 — Rich rejected two criteria from the schema/format scorecard: "cost to migrate from JSON Schema" and "developer familiarity". Reason: INHERIT v2 is from-scratch; v6.6 is inspiration only, not a migration baseline. And developer-familiarity is not a Rich priority — he'll invest in less-familiar tech if fundamentals are better.

4 min read

The rule. When scoring INHERIT v2 architecture, format, paradigm, or tech-stack options, do NOT include these categories of criteria unless Rich explicitly asks:

  1. “Cost to TT to adopt” / “cost to migrate from current state” — INHERIT v2 is a from-scratch rebuild; v6.6 is inspiration only, not a migration baseline. Any criterion that rewards “already in use” or penalises “major migration” biases the score toward the incumbent regardless of merit.

  2. “Developer familiarity” — Rich is willing to invest in less-familiar tech if the fundamentals are better. Rewarding a format because “every web dev can read it” penalises formats like RDF/OWL, Catala, Alloy, TLA+ for no reason that matches Rich’s decision criteria.

Why: Rich’s direct feedback on the schema/format scorecard v1.0 (Monday 20 April 2026): “you should not have scored points on cost to migrate from JSON Schema — I have repeatedly told you that inherit v2 will be started from scratch, with inherit v1 (6.6) just a good starting point/inspiration. Developer familiarity is not important to me either.”

This aligns with:

  • “No current-stack bias for INHERIT v2” (sibling memory feedback_no_current_stack_bias_for_inherit_v2.md) — Vercel/Supabase/current stack is not a constraint; evaluate on merit.
  • “Logic trumps hallucinations” (feedback_logic_trumps_hallucinations.md) — formal rigour takes priority over LLM-friendly patterns when they conflict.
  • INHERIT architecture mandate (project_inherit_architecture_mandate.md) — Rich is willing to throw away JSON Schema and rebuild from scratch if a better paradigm emerges.

The theme: Rich prioritises fundamentals over friction. Adoption costs, migration burden, developer-onboarding difficulty are noise when evaluating the right architecture for a 20-year-horizon standard. He’ll pay those costs; they shouldn’t sway the evaluation.

How to apply:

  1. When building an architecture / format / paradigm scorecard, start the criteria list by asking: “does this criterion reward fundamentals (expressiveness, semantic precision, long-term durability, legal fit, AI-vendor ingestion, standards-body appeal) or does it reward friction-reduction (already-adopted, easy-to-learn, low-migration-cost)?” Reject the latter unless Rich explicitly asks.
  2. When composing a criterion, prefer semantic/technical dimensions (expressiveness, formal-semantics precision, cross-jurisdiction support, validation depth, governance-body attractiveness, AI-vendor + LLM friendliness on the OUTPUT side) over adoption/friction dimensions.
  3. Acceptable adoption-adjacent criteria (not forbidden, just used carefully): 20-year durability (is the format going to exist in 2046?) is fine because it’s about the format’s FUTURE, not its past/present familiarity.
  4. When Rich does ask about cost/effort (e.g. “can I afford to build this in 2 months?”), then cost is legitimate — but as a SEPARATE question, not a scoring criterion for architecture merit.
  5. When a subagent or Claude session is briefed on INHERIT v2 evaluation, include this rule explicitly so the bias doesn’t creep back in through defaulting.

Rejected criteria examples (do NOT include in INHERIT v2 evaluation scorecards without Rich’s explicit go-ahead):

  • “Cost to TT to adopt” / “cost to migrate from X” / “already in production”
  • “Developer familiarity” / “learning curve” / “onboarding difficulty”
  • “Time to first shipping” / “time to first paying customer” (EXCEPT when Rich explicitly asks about Phase 1 shipping timeline as a separate lens — e.g. Option F→G commercial-pragmatism lens)
  • “LOC count” / “codebase size” (EXCEPT when Rich explicitly asks — Option G’s commercial scorecard legitimately uses LOC; the default INHERIT v2 scorecard should not)
  • “Current-stack compatibility” / “works with Vercel/Supabase/Pydantic-v2”

Accepted criteria examples (fundamentals-oriented — these are the kinds of criteria to prefer):

  • Expressiveness for the domain (legal / estate / cross-jurisdiction)
  • Formal-semantics precision / mathematical rigour
  • Validation depth (structural vs constraint vs logical)
  • Tooling ecosystem maturity (measured independently of TT’s current choices)
  • Codegen ecosystem (measured independently of TT’s current choices)
  • Industry-legal precedent (has this succeeded in analogous regulated domains?)
  • Governance-body attractiveness (OIDF / W3C / OASIS / ISO)
  • AI-vendor consumption ease (structured-output, tool-use compatibility)
  • LLM-friendliness (token-efficient, self-describing — measured on the output-quality side, not the “easy for devs to learn” side)
  • Multilingual / cross-jurisdiction support
  • 20-year durability (forward-looking)

What to do if a past scorecard already included the rejected criteria: surface the issue, remove the criteria, rescore cleanly, and show the old + new totals so the effect of the bias is visible. (Did this for schema/format scorecard v1.0 → v1.1 on 20 April 2026.)

Graph View

Backlinks