# Research Standards

**The Curiosity Lab**

Version: 0.1  
Status: Working Draft  
Path: `/governance/03-Research-Standards.md`

---

## 1. Purpose

This document defines the research standards for The Curiosity Lab.

Its purpose is to ensure that the programme remains rigorous, honest, practical and traceable.

The Research Charter defines how the programme behaves.  
The Programme Plan defines how the programme executes.  
This document defines how the programme judges quality.

These standards apply to all research papers, literature reviews, architecture notes, ontology proposals, MVP experiments and public-facing claims.

---

## 2. Core Standard

The Curiosity Lab values accuracy above agreement.

No conclusion should be accepted because it is elegant, appealing, convenient or consistent with an existing preference.

Every claim should be proportional to the evidence supporting it.

Every hypothesis should remain open to revision.

Every design decision should remain open to challenge.

---

## 3. Honesty Contract

The programme adopts the following honesty contract.

### 3.1 No flattery

Ideas should not be described as “brilliant”, “groundbreaking”, “revolutionary” or equivalent unless there is clear evidence to justify that judgement.

Most early ideas should be treated as hypotheses.

Enthusiasm is permitted.

Inflation is not.

---

### 3.2 No placating

Agreement should not be used to maintain conversational comfort.

If an idea appears weak, unsupported, impractical, overcomplicated or premature, this should be stated clearly.

---

### 3.3 No false certainty

The programme should avoid presenting uncertain ideas as established conclusions.

Where confidence is limited, the limitation should be explicit.

---

### 3.4 No artificial balance

Objectivity does not require treating all ideas as equally plausible.

If one theory is better supported than another, this should be stated.

If evidence is weak, this should be stated.

If evidence is absent, this should be stated.

---

### 3.5 No research theatre

Research should not be performed merely to create the appearance of rigour.

Every research activity should have potential implications for the framework, architecture, ontology, MVP or validation model.

---

## 4. Evidence Categories

All major claims should be classified using one of the following categories.

### 4.1 Established Evidence

A claim supported by substantial evidence, usually from multiple credible sources or well-established theory.

Example:

> Analogical reasoning can support understanding by mapping relationships between domains.

---

### 4.2 Supported Interpretation

A reasonable interpretation of available evidence, but not itself directly proven.

Example:

> If analogical reasoning supports understanding, then analogy may be useful as a first-class relationship type in the information architecture.

---

### 4.3 Working Hypothesis

A testable proposition that appears plausible but requires validation.

Example:

> Users may explore more deeply when content journeys include meaningful cross-domain analogies.

---

### 4.4 Design Decision

A practical choice made to support the programme, even where direct evidence is incomplete.

Example:

> The MVP will represent analogies as explicit entities rather than embedding them only inside article text.

---

### 4.5 Speculation

An exploratory idea with limited or no current evidence.

Example:

> Music theory may provide transferable structural principles for curiosity-oriented information architecture.

Speculation is allowed, but it must be labelled clearly.

---

## 5. Confidence Levels

Every major principle, hypothesis or architectural proposal should be assigned a confidence level.

### High Confidence

Supported by strong evidence, repeated findings or established theory.

### Moderate Confidence

Supported by credible evidence, but with limitations, competing interpretations or unresolved questions.

### Low Confidence

Plausible but weakly supported.

Requires further research or validation.

### Speculative

Interesting but currently unsupported.

May be useful for exploration, but should not guide architecture without further evidence.

---

## 6. Required Traceability

Every major research-derived principle should be traceable through the following chain:

```text
Evidence
   ↓
Interpretation
   ↓
Design Principle
   ↓
Information Architecture Implication
   ↓
Ontology Implication
   ↓
MVP Experiment
   ↓
Validation Result
```

If a principle cannot yet be traced through the full chain, its missing links should be recorded.

Incomplete traceability is acceptable.

Hidden traceability is not.

---

## 7. Research-to-Architecture Standard

A research finding becomes architecturally relevant only when it can answer at least one of the following questions:

- What entity does this suggest?
- What relationship does this suggest?
- What pattern does this suggest?
- What user journey does this suggest?
- What recommendation rule does this suggest?
- What uncertainty does this introduce?
- What experiment could test it?

If a finding cannot answer any of these questions, it may still be interesting, but it is lower priority for the programme.

---

## 8. Architecture-to-MVP Standard

An architectural proposal becomes MVP-relevant only when it can answer at least one of the following questions:

- What user behaviour would this influence?
- What curiosity journey would this support?
- What hypothesis would this test?
- What data would this generate?
- What feedback would this capture?
- What decision would this help us make?

If an architecture proposal cannot be tested, observed or experienced, it should remain provisional.

---

## 9. Citation Standards

The Curiosity Lab should use credible sources wherever possible.

### Preferred sources

1. Peer-reviewed journal articles
2. Scholarly books
3. Recognised technical standards
4. Academic conference papers
5. Institutional publications
6. Practitioner literature where clearly identified

### Citation expectations

Research documents should include:

- full references;
- inline citations where appropriate;
- distinction between primary and secondary sources;
- clear attribution of theories, terms and models.

### Unsupported claims

Unsupported claims are allowed only when clearly labelled as:

- working hypothesis;
- design assumption;
- speculation;
- observation;
- open question.

---

## 10. Research Register Standard

The Research Register records what has been learned from each source.

It is not merely a bibliography.

Each entry should include:

```text
Citation
Domain
Research Type
Central Claim
Key Findings
Relevance to The Curiosity Lab
Design Implications
Computational Implications
Limitations
Confidence
Notes
```

The Research Register should become the programme’s evidence memory.

---

## 11. Bibliography Standard

The bibliography records sources.

The Research Register records interpretation.

Both are required.

The bibliography should preferably be maintained in:

```text
/references/Bibliography.bib
```

with a readable companion file:

```text
/references/Reading-List.md
```

---

## 12. Research Debt

The Curiosity Lab explicitly tracks research debt.

Research debt includes:

- claims requiring stronger evidence;
- assumptions not yet tested;
- missing literature domains;
- weak references;
- unresolved contradictions;
- speculative analogies;
- unvalidated architecture decisions;
- MVP experiments not yet performed.

Every major research document should include a section titled:

```text
Research Debt
```

Research debt is not failure.

Unrecorded research debt is failure.

---

## 13. Known Weaknesses Standard

Every major document should include a section titled:

```text
Known Weaknesses
```

This section should identify limitations honestly.

Examples:

- limited primary literature reviewed;
- over-reliance on synthesis;
- insufficient counter-evidence;
- incomplete architecture implications;
- no validation data;
- speculative terminology.

A document that identifies its weaknesses is more trustworthy than one that conceals them.

---

## 14. Contradictory Evidence Standard

The programme should actively seek contradictory evidence.

For each significant hypothesis, researchers should ask:

- What would falsify this?
- Who disagrees?
- What evidence weakens this?
- Under what conditions does this fail?
- Is this field already better explained by existing theory?

Contradictory evidence should be recorded rather than ignored.

---

## 15. Anti-Confirmation Bias Standard

The Curiosity Lab should not search only for evidence that supports its preferred ideas.

When reviewing literature, each research paper should attempt to identify:

- evidence supporting the hypothesis;
- evidence weakening the hypothesis;
- alternative explanations;
- competing frameworks;
- limitations of applicability.

---

## 16. Practicality Standard

Research must remain connected to practical application.

The programme adopts the following rule:

> **No research without implementation potential.**

This does not mean every source must immediately produce a feature.

It means every research direction should plausibly influence one or more of:

- framework design;
- information architecture;
- ontology;
- experience patterns;
- MVP experiments;
- validation strategy.

---

## 17. Output Standard

Every working session should aim to produce at least one tangible artefact.

Examples:

- working paper;
- research register entry;
- bibliography update;
- architecture notebook entry;
- pattern catalogue entry;
- ontology update;
- MVP experiment definition;
- diagram;
- status update.

Discussion is valuable only when it leaves a useful trace.

---

## 18. Document Lifecycle

Documents should not wait for perfection before being committed.

The programme uses the following lifecycle:

```text
v0.1 — Core structure established
v0.2 — Evidence expanded
v0.3 — Critical review added
v0.4 — Architecture traceability added
v0.5 — MVP implications added
v0.9 — Internally stable
v1.0 — Baseline version
```

Version numbers should reflect maturity, not length.

---

## 19. Working Practice Review

The programme should review its working practice every four weeks or after a major milestone.

The review should ask:

- Are we producing artefacts or only refining ideas?
- Are we reviewing enough primary literature?
- Are hypotheses being challenged?
- Is architecture becoming clearer or more complex?
- Is the MVP still tied to research?
- Are we moving the programme forward?
- What should we stop doing?

The purpose of review is correction, not ceremony.

---

## 20. Over-Refinement Control

The programme recognises over-refinement as a risk.

After a document reaches a useful v0.1 state, it should not be revisited unless one of the following conditions applies:

1. New evidence changes it.
2. Architecture depends on changing it.
3. MVP validation challenges it.
4. Scheduled review recommends revision.
5. A serious gap is identified.

Otherwise, move forward.

---

## 21. Language Standard

Research writing should be:

- clear;
- precise;
- proportionate;
- traceable;
- honest about uncertainty.

Avoid:

- exaggerated claims;
- promotional language;
- unnecessary jargon;
- vague enthusiasm;
- unsupported novelty claims;
- excessive metaphor where precision is required.

Metaphor may be used as a tool for explanation, but not as a substitute for evidence.

---

## 22. Novelty Standard

The Curiosity Lab does not claim novelty prematurely.

Before describing any idea as original, the programme should ask:

- Has this already been proposed?
- Is there existing terminology?
- Is this a new idea or a synthesis?
- Is the novelty conceptual, architectural, computational or experiential?
- What evidence justifies the claim?

Synthesis may be valuable without being wholly original.

---

## 23. Pattern Standard

A pattern should not be accepted because it is aesthetically appealing.

A candidate pattern should be assessed against:

- evidence;
- recurrence across domains;
- explanatory value;
- design usefulness;
- computational representability;
- testability.

Patterns may be labelled as:

- observed;
- supported;
- emerging;
- speculative;
- rejected.

---

## 24. Ontology Standard

Ontology entities should not be created casually.

A candidate entity should answer:

- What does this represent?
- Why is it not merely an attribute?
- What relationships does it support?
- What user experience does it enable?
- What research supports it?
- How might it be tested?

Candidate entities should be labelled as provisional until validated through use.

---

## 25. MVP Experiment Standard

Every MVP experiment should include:

```text
Experiment Name
Research Question
Hypothesis
User Journey
Variant(s)
Expected Behaviour
Data to Capture
Success Criteria
Failure Criteria
Research Implication
Architecture Implication
```

An experiment is useful if it teaches the programme something, even when the result is negative.

---

## 26. Status Tracking Standard

`STATUS.md` should track the health of the programme.

It should include:

- artefacts completed;
- artefacts in progress;
- sources reviewed;
- research register entries;
- pattern catalogue entries;
- ontology entities;
- experiments designed;
- experiments conducted;
- current risks;
- next artefacts.

The purpose of status tracking is to reveal drift.

---

## 27. Decision Record Standard

Major decisions should be recorded.

A major decision includes:

- change of research direction;
- new core hypothesis;
- ontology restructuring;
- MVP scope change;
- rejection of a major idea;
- adoption of a new framework.

Each decision should record:

```text
Decision
Date
Context
Options Considered
Reasoning
Evidence
Consequences
Review Trigger
```

A future `/governance/Decision-Log.md` may be created if required.

---

## 28. Review Questions for Every Document

Before a document is considered complete for its current version, it should answer:

1. What question does this document address?
2. What evidence does it rely on?
3. What is established?
4. What is speculative?
5. What changes in the architecture?
6. What changes in the MVP?
7. What remains unknown?
8. What should be reviewed next?

---

## 29. Minimum Standard for v0.1

A v0.1 document must contain:

- clear purpose;
- current research question;
- core structure;
- initial claims or hypotheses;
- known weaknesses;
- next steps.

A v0.1 document does not require complete evidence.

It does require intellectual honesty.

---

## 30. Minimum Standard for v1.0

A v1.0 document should contain:

- mature literature grounding;
- clear citations;
- competing viewpoints;
- architecture implications;
- MVP implications where relevant;
- known weaknesses;
- research debt;
- confidence levels;
- review history.

Version 1.0 means the document has become a reliable baseline.

It does not mean final truth.

---

## 31. Closing Standard

The Curiosity Lab exists to investigate whether information environments can cultivate curiosity through meaningful connection.

That investigation requires ambition.

It also requires discipline.

The standards in this document exist to protect both.

The programme should remain open, practical, sceptical and useful.

It should produce ideas only in proportion to evidence.

It should produce architecture only in proportion to understanding.

It should produce software only in proportion to research value.

And it should continually ask whether each output serves the mission:

> **Leave every person slightly more curious than you found them.**