frontend-patterns/research/plan/ResearchProtocol.md

# 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.

## Evolution record at cycle close

Register a bounded question with the [learning-cycle template](../../templates/LearningCycle.md)
before execution. Follow the [evolution method](../evolution/README.md): append the
outcome (including corroboration or inconclusive results), record effort or explicit
unknowns, update affected evidence profiles, and run `make evolution-report
evolution-check evolution-test`. Capture a snapshot at the review boundary after
candidate changes are committed. Preserve superseded conclusions and failed trials.

Research milestones close bounded work; the language keeps learning. Compare returns
only across prospective cycles with comparable stream/protocol/question scope and
effort accounting. Review at least three such cycles before discussing a trend; that
review is not proof of a plateau. Do not pool historical assertion or citation counts
as discoveries. Human validation, independent recurrence and demonstrated usefulness
remain separate obligations from metadata correctness.