feedback_actively_use_t_files_in_scorecard_authoring

Before producing any decision-bearing answer (scorecard, decision-analysis, design-section, spec-section, critique, recommendation), READ the relevant T-files + closed-spike artefacts actively (not just cite them by name). Extract 2-4 specific findings per answer with location refs. Quote findings verbatim in the library-evidence section. Use those findings to inform the option set, scoring, and recommendation.

Scope ELEVATED Monday 27 April 2026: this discipline now applies to ALL decision-bearing answers, not just formal scorecards. Brainstorming Q&A (where I propose 2-3 approaches with trade-offs) is decision-bearing. Design-section presentation (where I commit to architectural shape) is decision-bearing. Spec authoring (where I commit choices to disk) is decision-bearing. Each requires the same “read T-files + spike data BEFORE writing” discipline that scorecards already require.

Spike data inclusion (Monday 27 April 2026): this discipline now also covers the 12 closed spikes (S-1 through S-12) at ~/off-github/library/projects/inherit/{spike-slug}/. Spike findings are verbatim-quotable evidence at the same level as T-files. Read them; extract findings; quote in library-evidence sections.

Naming a T-file as “library evidence (c6 = 9)” without reading it is shallow grounding. The scorecard’s evidence-strength score is then over-estimated, and the option set may miss alternatives the T-file would have surfaced.

Why

Triggering directive #1 (Sunday 26 April 2026 after Rich observed 3 scorecards in plan-from-the-beginning re-author):

“are you using the recent learnings in the library to create these scorecards? the T-index library is in off-github/library/projects/inherit”

Honest answer at the time: I was citing T-files (T52, T56, T60) but not reading them during scorecard authoring — relying on session-memory summaries from when the T-files were first dispatched (Round 7, 2026-04-26). The scorecards were architecturally-grounded (Shape X, AC-1 two-rule, A-43 distribution) but library-grounding-shallow.

Triggering directive #2 — ELEVATION (Monday 27 April 2026 during Phase 2 Q2 brainstorming):

“can you explain Library-evidence base (Round 5/6/7) please?”

[…after I admitted scoring c6 from memory + evidence-mapping-matrix descriptions, not from T-file reads…]

“ii” [Rich’s choice: pause + do T-file reads + revise scorecard]

[…after T-file reads completed and revised c6 scores…]

“αε - please ensure you remember to use T-files and spike data for future questions and answers - save this requirement”

Honest gap exposed at the elevation: even after the 2026-04-26 lock, the discipline was scoped to “scorecards” only. Q2 brainstorming presented an organising-principle scorecard whose c6 scores were grounded in memory + matrix descriptions, not actual T-file reads. The Q1 → Q2 brainstorming flow is decision-bearing (Rich’s answer locks one of N options with downstream consequences) — at the same epistemic level as scorecards. The discipline must apply here too.

The elevation closes that scope gap: ANY decision-bearing answer (brainstorming Q&A, design-section presentation, spec authoring, critique authoring, scorecard authoring) requires active T-file + spike-data reads BEFORE production, not after.

The 70 T-files at ~/off-github/library/projects/inherit/T1-T70.md represent ~£1,000-1,300 of dedicated research, ~17-22 engineer-weeks of spike-time saved, and concrete production-grade evidence (vendor docs, statutory citations, library-indexed quotes). Letting that evidence remain dormant during scorecard authoring is structurally wasteful and produces weaker locks.

This discipline is the active-form companion to feedback_always_check_library_indexed_first (which covers ~/off-github/library/indexed/). T-files are the next layer of evidence after indexed library books, and they’re typically more directly applicable to specific scorecards because each T-file was authored against a specific architectural decision.

How to apply

Rule 1 — Read T-files BEFORE scorecard authoring, not after

Before opening the scorecard authoring buffer:

1. Identify the primary T-files for the decision (typically 1-3)
2. Identify secondary T-files if cross-cutting (typically 1-3 more)
3. Read the relevant sections of each (TL;DR + comparison-matrix + verdicts at minimum; full file if substantive)
4. Extract 2-4 specific findings per primary T-file with location refs (file path + section name + line range if granular)
5. Open scorecard authoring buffer; integrate findings

Rule 2 — Quote findings VERBATIM in the library-evidence section

Don’t paraphrase T-file findings. Quote them directly with > blockquote and location:

> "Adobe Trust Services (Ireland) is a listed QTSP under EU/UK eIDAS for QES. Pricing for org tier with QES enabled: ~£25/user/mo (2025) + transactional QES fees."
> — T56 §Per-provider production-readiness (Adobe Acrobat Sign row)

This makes the evidence auditable and lets future-Claude (or Rich) verify the quote against the T-file.

Rule 3 — Use T-file findings to inform option-set construction

T-files often surface options I would have missed without reading them. Before finalising the option set:

• Did any T-file surface a vendor / pattern / approach I haven’t included?
• Did any T-file surface a rejection criterion that disqualifies an option I scored?
• Did any T-file surface a hybrid pattern between options?

Add those options or eliminations BEFORE scoring.

Rule 4 — Use T-file findings to ground scoring at specific criteria

For each criterion, ask: “what does the relevant T-file say about this?” If the T-file is silent, score normally. If the T-file has direct evidence, the score should reflect it (typically higher confidence; sometimes lower — T-files can also disprove an option).

Specifically for c6 library evidence depth: this score should be 9-10 ONLY if I have actually read the T-files and quoted them. If I’m citing without reading, c6 should be 5-7 (acknowledging that named-but-not-read evidence is weaker than quoted evidence).

Rule 5 — Maintain a per-decision T-file mapping

For the plan-from-the-beginning §2.2 queue specifically, the mapping is:

Decision	Primary T-files	Secondary
#1 (JurisdictionalSubmission)	T52 (UK + Swiss gov-agency) + T60 (Tier-2 UK gov)	T54 (OAuth); T56 (e-signing)
#2 (SubmissionMethodScheme)	T52 + T60 (same as #1)	T54
#3 (Wills electronic-wills + RON)	T56 (eIDAS QES) + T63 (OpenID4VCI VC)	T54; T58 (ID&V for executor); T2 (VC infra)
#4 (Texas + Florida boundary)	T52 + T60 + T56	T54; T58
#5 (AssetDiscoveryProvenance)	T59 (Open Banking + HMRC) + T60 (HMLR + DVLA)	T62 (semantic search)
#6 (AssetDiscoveryChannelScheme)	T58 (ID&V) + T59 (Open Banking)	—
#7 (KeyManagementContext)	T55 (pgsodium + KMS)	T46 (XTDB EVICT crypto-shredding); T54 (DPoP key rotation)
#8 (SolicitorRuleAuthorshipCredential)	T63 (OpenID4VCI VC + Bowtie)	T54 (auth); T2 (VC + DID + KERI infra)

For future scorecards beyond §2.2 1-8, build similar per-decision T-file maps as part of pre-authoring.

Rule 7 — Define questions as we reach them, NOT enumerate upfront (locked Monday 27 April 2026)

Anti-pattern: pre-enumerating all design-section questions upfront (e.g., “§2 module-sequencing / §3 primitive placement / §4 substrate sovereignty / §5 commercial-moat / §6 labelling”) then asking them sequentially.

Why this fails:

• Cascade fragility: each answer reshapes downstream questions; pre-enumerated framings go stale immediately when an upstream answer flips (exactly what happened with Q3 §1 flip from A→B which invalidated the §2-§6 framing I’d already presented and Rich-confirmed)
• False discipline: pre-enumeration looks rigorous but actually substitutes prior-knowledge framing for question-discovery; the research has its own answer to “what are the actually-open architectural decisions at this stage” that I don’t see if I lock in my framing first
• Anti-recalculation: violates feedback_decision_analysis_one_at_a_time (“RECALCULATE next based on actual answer”) because the next question is already pre-committed

Correct methodology:

1. After each Rich-confirmed answer, survey the research corpus afresh for what the next-highest-knock-on open question is given the new locked-state
2. Apply Rule 6 (search routine) BEFORE composing the next question
3. Surface ONE next question (or a small set of 2-3 candidates) — not an enumerated §N list
4. Let Rich’s answer shape what comes after

Boundary test (pre-question):

• “Did I survey the research AFTER the last Rich-confirm, or am I working from a pre-confirm enumeration?”
• “Is my next question still relevant given what was just locked, or has the upstream answer reshaped it?”
• “Have I checked closed/partially-closed status — does this question still need asking, or did upstream research close it?”

Example (Monday 27 April 2026): After §1 flipped A→B (4-tier), I tried to re-ask the pre-enumerated §2 question (module-sequencing parallel-pilot count). Rich called this out: “all questions in sections 2 and later are to be treated as open.” Correct response: discard pre-enumeration; Explore-survey research; identify NEW highest-knock-on question (turned out to be Q1 commercial licensing or Q2 jurisdictional launch — neither of which matched the pre-enumerated §2 framing).

Companion to existing locked memories:

• feedback_decision_analysis_one_at_a_time — recalculate next based on actual answer (parent rule)
• feedback_scorecards_one_at_a_time_optimal_sequence — sequence by knock-on; one question per turn (parent rule)
• feedback_reframe_beats_reweight — when scorecard stalls, reframe (orthogonal — applies WITHIN a question)

This rule extends the parent rules to question-DISCOVERY, not just question-SEQUENCING.

Rule 6 — Run a research-search BEFORE composing alternatives (locked Monday 27 April 2026)

Before writing any “Question:” block / multi-choice prompt / “or do you want X?” alternative:

1. Identify the topic-keyword (e.g., “Keycloak”, “triple-store”, “deployment-tier”)
2. Run search:

   grep -li "<keyword>" ~/off-github/library/projects/inherit/T*.md
   grep -li "<keyword>" ~/off-github/library/projects/inherit/spike-*/*.md ~/off-github/library/projects/inherit/s*/*.md 2>/dev/null
   grep -li "<keyword>" ~/testatetech/docs-strategy/docs/superpowers/specs/2026-04-26-spike-*.md
   ls ~/off-github/library/indexed/ | grep -i "<keyword>"

3. Read the matched files; extract the actually-evaluated alternatives
4. List those (with verbatim citations) — NOT alternatives composed from prior knowledge

If no research evaluated the topic, explicitly tag the alternative as “speculative — not yet researched” so Rich can choose to commission research before answering. Never present prior-knowledge alternatives as if they were research-grounded.

Worked example — §4 closing-question slip + correction (Monday 27 April 2026)

The slip

§4 Substrate sovereignty stack closing question Q1 read: “Is Cloud-IAM Scaleway-EU the correct procurement choice for the auth-substrate convenience tier (per S-7), or do you want an alternative (e.g., Keycloak self-host on Hetzner / OVH)?”

I named “Hetzner / OVH” from training-data prior knowledge of EU-region cloud providers. T54 was already loaded into context — I did not consult it before naming alternatives.

The correction

T54 §1 verbatim: “EU-self-hostable on customer infrastructure or via EU-based managed providers (cloud-iam.com, loginfactor.com)”. The actually-evaluated alternative was loginfactor.com, not Hetzner/OVH.

The pattern

Body content was research-grounded; alternatives-generation in closing question slipped. The discipline must extend equally to both. Closing-question alternatives ARE decision-bearing — they shape which path Rich confirms.

Other slips in same closing question (caught by Rich’s “double check” prompt 2026-04-27)

• Called Oxigraph “optional triple-store” when T67 §Architecture-state implications #1 confirms RDF substrate is LOCKED Phase-1 per arch-state §3 + Shape-X locks (A-1..A-25)
• Surfaced “2-tier convenience-vs-sovereign” as alternative to T55’s 4-class deployment ladder when T55 doesn’t propose 2-tier — I composed it from prior knowledge

Anti-patterns

• ❌ “Library evidence (T56 + Florida EWA + Texas Estates Code) supports comprehensive Apache-core scope” — names T-file but doesn’t quote it
• ❌ Scoring c6 = 9 (high library evidence) when I haven’t actually opened the T-file
• ❌ Citing T-file findings from session memory of when I first dispatched the round, not from rereading the persisted file
• ❌ Skipping T-file read because “I remember what’s in it” — session memory degrades over compaction; T-files are the durable evidence
• ❌ Reading T-file AFTER finalising option set — option set was constructed without that evidence
• ❌ Composing closing-question alternatives from training-data prior knowledge instead of grounding them in research (locked Monday 27 April 2026 after Phase 2 §4 design closing-question slip — I named “Hetzner / OVH” as Keycloak-managed-provider alternatives when T54 actually names “cloud-iam.com, loginfactor.com”; called Oxigraph “optional” when T67 confirms RDF substrate is LOCKED Phase-1 per arch-state §3). The discipline applies to alternatives-generation, not just claim-substantiation. Boundary test for closing questions: every alternative I name in a multiple-choice closing question must trace to a specific T-file / spike artefact / memory citation that explicitly evaluated it. If not, re-read the relevant research and re-compose alternatives from the actual evidence.

Boundary test (v2 — Monday 27 April 2026)

Before declaring any decision-bearing answer complete, run TWO checks:

1. Claim-substantiation check: have I quoted at least 2 specific findings (with > blockquotes + location refs) from primary T-files OR closed-spike artefacts? If no — re-read and add quotes before output.
2. Alternatives-generation check: for every alternative I named in any closing question / multi-choice prompt, can I cite the T-file / spike / indexed-book that evaluated it? If no — re-read the relevant research and replace the alternative, OR tag it explicitly as “speculative — not yet researched.”

Both checks must pass before output. If either fails, the answer is incomplete.

This boundary test applies to:

• Formal scorecards (original 2026-04-26 scope)
• Brainstorming Q&A where I propose options + score them (e.g., the Q2 organising-principle scorecard pattern)
• Design-section presentation during brainstorming-skill flow (body AND closing questions)
• Spec authoring (option-F.md v2.0 pattern; design-doc authoring)
• Critique / recommendation outputs that influence Rich’s decisions
• Stage 2C per-option scoring (when Phase 2 reaches that stage)

Note specifically: spike artefacts count as primary evidence at the same level as T-files. Closed spikes (S-1 through S-12 as of 2026-04-27) are quotable; closing-bundle, findings.md, and spec-side decision-doc files are typical entry-points.

Spike artefact path-map (verified 2026-04-27)

Spike artefacts live in TWO locations:

Research outputs at ~/off-github/library/projects/inherit/:

• S-2 cedar-temporal-rule-sdk: s2-cedar-temporal-rule-sdk-2026-04-26/
• S-3 Mopsa SV-COMP: spike-s3-2026-04-26/
• S-5 + S-11 path-b-extraction: path-b-extraction-2026-04-25/
• S-9 IAS CRDT walkthrough: s9-ias-crdt-2026-04-26/
• S-10 pgcrypto+KMS: s10-pgcrypto-kms-2026-04-25/
• S-12 catala-explain: spike-catala-explain-2026-04-26/ + catala-explain-smoke-test-2026-04-26/
• Closing bundle: spike-completion-2026-04-26/
• Status snapshot: spike-status-snapshot-2026-04-26.md

Decision docs at ~/testatetech/docs-strategy/docs/superpowers/specs/:

• S-1 synthetic-corpus: 2026-04-26-spike-s1-synthetic-corpus-methodology.md
• S-3 Mopsa: 2026-04-26-spike-s3-mopsa-tooling-validation.md
• S-4 Catala bundle: 2026-04-26-spike-s4-catala-bundle-measurements.md
• S-7 Keycloak procurement: 2026-04-26-s7-keycloak-procurement-decision.md ⚠ NOT in off-github/library/; the path I tried earlier (s7-keycloak-procurement-decision-2026-04-26/) does NOT exist
• S-8 JurisdictionalSubmission playbook: 2026-04-26-jurisdictional-submission-playbook.md
• S-10 pgcrypto+KMS spec: 2026-04-26-spike-s10-pgcrypto-kms-substrate.md
• S-11 Path B’ quality-spotcheck: 2026-04-26-spike-s11-path-b-quality-spotcheck.md
• Master inventory: 2026-04-26-spike-inventory-v2.md

S-6 LinkML CI substrate: not under off-github/library/; lives in ~/testatetech/code-inherit-v2/ as in-repo CI gates (3 gates: linkml-generator-matrix + ROBOT-build + IRI-verify per arch-state v2.78).

Relationship to existing memories

• Companion to feedback_always_check_library_indexed_first — same active-evidence discipline applied to T-files instead of indexed books
• Compounds with feedback_always_save_scorecards — the scorecards we save should be evidence-grounded, not just architecturally-grounded
• Compounds with feedback_always_display_full_scorecard — full scorecard display includes the library-evidence section; that section needs verbatim quotes, not just T-file names
• Reinforces feedback_scorecards_one_at_a_time_optimal_sequence — single-question discipline gives time per scorecard for proper T-file reading; batched scorecards force shallow grounding
• **Triggers re-author of plan-from-the-beginning §2.2 decisions 1-3** — those scorecards locked α-class options without active T-file grounding; Rich directed re-author 2026-04-26 same date as discipline lock