Establish phased research program with evidence and validation gates

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9

research/plan/ResearchProtocol.md

@@ -0,0 +1,66 @@
+# Research protocol
+
+Status: working method · 2026-09-24
+
+## Research unit
+
+A unit is a question, an evidence set and a recorded conclusion. Before reading,
+state the question, current hypothesis, assumptions and what would contradict it.
+Use [SourceReview](../../templates/SourceReview.md) for extraction and
+[ArchitectureWalkthrough](../../templates/ArchitectureWalkthrough.md) for application.
+
+## Evidence handling
+
+1. Prefer original publications, standards, research papers, official documentation
+   and identifiable implementations. Secondary surveys help discovery; trace their
+   substantive claims to primary evidence where possible.
+2. Record author/publisher, title, exact URL or bibliographic locator, publication
+   date/version and access date. Mark unavailable information as unknown.
+3. In each source review, assign local claim labels (C01, C02, …). Cite claims by
+   file path plus label. Separate source statements, our interpretations and tests.
+4. Cite sections, pages or repository revisions. Paraphrase accurately; keep any
+   quotations short and attributed. A source being listed is not evidence of review.
+5. Record conflicts and negative cases. Multiple sources repeating the same origin
+   are not independent confirmation. An unavailable source stays pending.
+6. Update `research/catalog/SourceCatalog.md` with the review path and state:
+   queued, extracted or reviewed. These are research workflow labels, not pattern
+   evidence maturity. Do not invent publication details to fill a template.
+
+## Pattern synthesis
+
+Extract problem, context, competing forces, recurring configuration, dynamics,
+resulting context, consequences and failure modes before assigning a pattern name.
+Compare candidates against existing ones: retain, merge, split, reject or defer,
+with reasons in `research/catalog/PatternCandidateCatalog.md`.
+
+A draft promoted into `patterns/` must satisfy the schema agreed in FEP-WP-0002,
+include at least two competing forces, evidence locators, a justified relation to
+another pattern, a failure case and an explicit maturity. Cite two contrasting
+applications where available; otherwise retain hypothesis status and state the gap.
+A framework feature alone does not establish recurrence. A directory named `canon`
+does not confer evidence maturity on its contents.
+
+## Generativity test
+
+Hold the application brief fixed. Record each architectural decision, forces,
+applicable alternatives, chosen patterns and resulting context. Then vary one
+constraint (for example offline operation or independent deployment) and explain
+which decisions change. Compare with a plain architecture narrative written without
+the pattern catalog. If the language adds only renamed labels, revise it.
+
+Record quality constraints at the start and throughout the walkthrough: accessibility,
+security, privacy, recovery and performance must influence earlier decisions too.
+The existing sequence's late quality step is a hypothesis to challenge.
+
+## Review and stopping rules
+
+For every gate, record reviewer, date, artifacts, checks, counterevidence and outcome
+(pass, revise or defer) in `research/reviews/`. A review passes only if references
+are traceable, examples resolve their metadata references, and another reader can
+follow the reasoning. Distinguish synthetic scenarios from observed systems.
+
+Stop broad source collection when the bounded question has sufficient evidence to
+support or reject the current hypothesis; record remaining uncertainty. Do not
+stretch source claims to meet a pattern-count target. Preserve superseded conclusions
+through Git history and link the replacement. Reopen a conclusion when new evidence
+invalidates a stated assumption.