Research protocol

How we turn the domain map into an actual knowledge base, one sprint at a time. The protocol is designed to be repeatable, to produce artefacts rather than impressions, and to make its own gaps visible.

The unit of work: a research sprint

One sprint takes one sub-domain (for example W7, pool water demand) and moves it from unknown to a documented state. A sprint is finished when the domain brief is updated and the open questions have been written down — not when we feel informed.

  ┌─ 1 SCOPE ─────────────────────────────────────────────────┐
  │  pick the sub-domain, write 3–7 key questions             │
  └───────────────┬───────────────────────────────────────────┘
                  ▼
  ┌─ 2 SWEEP ─────────────────────────────────────────────────┐
  │  find sources across ALL tiers, in parallel;              │
  │  log each in the source registry before reading deeply    │
  └───────────────┬───────────────────────────────────────────┘
                  ▼
  ┌─ 3 CAPTURE ───────────────────────────────────────────────┐
  │  one source note per source: extract numbers, method,     │
  │  conditions, limits, bias                                 │
  └───────────────┬───────────────────────────────────────────┘
                  ▼
  ┌─ 4 SYNTHESISE ────────────────────────────────────────────┐
  │  update the domain brief: KNOW / ASSUME / DON'T KNOW      │
  │  write solution cards for each candidate intervention     │
  └───────────────┬───────────────────────────────────────────┘
                  ▼
  ┌─ 5 CHALLENGE ─────────────────────────────────────────────┐
  │  attack the synthesis: what's missing? what's vendor      │
  │  claim dressed as fact? what contradicts?                 │
  └───────────────┬───────────────────────────────────────────┘
                  ▼
  ┌─ 6 CONVERT ───────────────────────────────────────────────┐
  │  open questions → measurement backlog, next sprint,       │
  │  or content backlog                                       │
  └───────────────────────────────────────────────────────────┘

1 — Scope

Write the key questions first, before searching. Good key questions are answerable with a number or a decision, and bad ones are topics.

• Bad: “Pool water use.”
• Good: “How much water does a typical uncovered 8×4 m pool in Mallorca lose per year, and what fraction of that is evaporation versus backwash versus splash-out versus leakage?”
• Good: “At what point does a pool cover pay for itself in water and energy, and what does that depend on?”

Three to seven questions. If there are twenty, the sub-domain is too big — split it.

2 — Sweep: search every tier in parallel

The failure mode is finding three sources of the same kind and stopping. Deliberately sweep across different kinds of source, because each is blind to what the others see:

Log each source in the source registry when you find it, not after reading it. A found-but-unread source is useful information.

Stop the sweep when two consecutive search angles return nothing new — not when you run out of patience.

3 — Capture

One source note per substantive source. Extract rather than summarise:

• The numbers, with units and the conditions they were measured under.
• The method used to obtain them.
• The limits — sample size, geography, date, what it does not cover.
• The bias — who paid, what they sell, what they want you to conclude.

A source note that contains no numbers and no method is usually a signal that the source was an opinion piece. Record it as such and move on.

4 — Synthesise

Update the domain brief. Its spine is three sections, and the third is the most valuable:

• What we know — with evidence tier and source reference on every claim.
• What we assume — plausible, unverified, and flagged as such, with what would verify it.
• What we don’t know — named explicitly. This section should grow during a sprint, not shrink. A brief with an empty “don’t know” section is not finished; it is incurious.

Where the research surfaces candidate interventions, write a solution card for each. Where it surfaces something we will need to measure, write a metric definition.

5 — Challenge

Before closing the sprint, attack your own synthesis. Explicitly ask:

• Which search angle from step 2 did I skip?
• Which claim rests on a single source? On a single vendor source?
• Where did two sources disagree, and did I quietly pick one?
• What number did I carry forward without checking its conditions?
• What in here is true of Spain or Europe generally but might not be true of Mallorca?
• If this brief is wrong, what is the most likely reason?

Findings from the challenge either get fixed or get written into “what we don’t know”.

6 — Convert

Every open question is routed somewhere, not left floating:

• Measurable at Site Zero → the measurement backlog. This is the highest-value route: it converts an unknown into Tier A evidence we own.
• Answerable by more desk research → scoped as a future sprint.
• Answerable only by doing → flagged for the next real project on a site.
• Interesting to others → content backlog.

Cadence and rhythm

A suggested rhythm rather than a rule:

• One sub-domain sprint at a time. Depth before breadth (principle 4).
• Alternate desk and site. A desk sprint, then a week installing or reading meters. Field work corrects desk work faster than more desk work does.
• Review the map quarterly. Re-score priorities; the map should change.
• Re-read the oldest brief every quarter. Facts decay, particularly regulation, prices and grants.

Where things live

docs/knowledge/
  domain-map.md          the map (what we need to know)
  research-protocol.md   this file (how we find it out)
  source-registry.md     tiers, source inventory, and where to look
  domains/               one brief per sub-domain     — W7-pool-water.md, ...
  sources/               one note per source          — 2026-xx-<slug>.md
  templates/             the four artefact templates

Solution cards, metric definitions, baselines and case studies get their own directories once there are enough of them to need one. Do not create empty folders in advance.

Working with AI assistance on research

A practical note, since much of this research will be done with an assistant in this repository:

• Never let a generated number into a brief without a source. Plausible-sounding figures are the primary failure mode. If a claim cannot be traced to a registered source, it belongs in “what we assume”, not “what we know”.
• Use assistance for the sweep and the extraction, where breadth and tedium are the constraint, and keep the synthesis and the challenge deliberate.
• Ask for disagreement explicitly. “Find sources that contradict this” is a more useful instruction than “research this topic”.
• Local specificity is where general models are weakest — Mallorcan permitting, local prices, which installer does good work. Treat those as fieldwork, not lookup.