QAI Research Domains

qai-research-domains is the field-constraint layer of the QAI research stack.
It defines what counts as rigorous, reviewable, and publishable work inside specific disciplines, so generic research workflows become domain-correct across applied, computational, clinical, and social-science settings.

Core boundary with qai-research-core

The repositories are complementary and intentionally non-overlapping:

Repository	Primary role	Typical outputs
qai-research-core	Universal research reasoning	study plans, schema drafts, QA plans, analysis logic, reviewer-style critiques
qai-research-domains	Field-specific constraints and expectations	domain assumptions, variable/endpoint norms, confounder logic, reviewer attack patterns, publication expectations

Rule of separation

• If guidance is method-agnostic, it belongs in core.
• If guidance changes by discipline, it belongs here.

Domains are constraint systems, not topic notes

In this repository, a domain package is a working research constraint system that encodes:

• construct definitions and boundary conditions
• variables, measures, and endpoint expectations
• confounders and validity threats specific to the field
• schema/provenance requirements that affect downstream analysis
• reviewer objections that commonly determine acceptance vs rejection
• publication framing norms used in mature papers

Independent use vs integrated use

Use independently

A domain folder can be used as a standalone lab guide for:

• protocol design reviews
• dataset and metadata specification
• internal manuscript pre-review
• graduate trainee onboarding

Use with qai-research-core

Apply domain constraints to core outputs at each stage:

Core output	Domain modification	Practical effect
experiment-design draft	add field confounders, endpoint definitions, validity constraints	stronger causal/interpretive discipline
dataset-schema-designer draft	add domain metadata, timing/unit/provenance requirements	fewer downstream QA and analysis failures
dataset-qa logic	add field-specific integrity checks	earlier detection of domain-breaking data issues
analysis framing	add domain interpretation limits and tradeoffs	reduced overclaiming and better inference quality
reviewer-mode critique	apply field reviewer attack patterns	better pre-submission resilience
writing outputs	align argument and evidence to domain publication norms	higher publishability signal

Who this repository is for

• Students learning how to design domain-correct studies
• Graduate researchers converting methods knowledge into publishable protocols
• Faculty and lab leads standardizing internal research quality
• Interdisciplinary teams needing explicit translation across fields

Supported domains

Current production domains:

• biomechanics
• biomedical-engineering
• bioinformatics
• business-analytics
• clinical-research
• computer-science
• computer-vision
• data-science
• education-research
• environmental-science
• epidemiology
• human-computer-interaction
• machine-learning
• neuroperformance
• neuroscience
• public-health
• rehabilitation
• statistics

See DOMAINS_INDEX.md for operational domain comparisons.

Required domain pack anatomy

Every production domain includes:

1. README.md — scope, user profile, and core-integration map
2. ontology.md — concept relationships, measures, ambiguities, interpretation boundaries
3. study-design-guide.md — design patterns, confounders, endpoints, validity threats
4. schema-guide.md — data model, metadata, timing/units/provenance, validation logic
5. reviewer-lens.md — realistic reviewer critiques and evidence thresholds
6. publication-norms.md — argument structure, figure/table norms, maturity signals

Repository layout

qai-research-domains/
├── shared/    # templates for consistent domain authoring
├── domains/   # production domain packs
└── examples/  # cross-domain specializations and QAI-aligned research scenarios

Extending the repository

1. Start from shared/ templates.
2. Build a complete six-file domain pack.
3. Encode assumptions, confounders, schema constraints, and reviewer logic explicitly.
4. Ensure recommendations are operational and field-credible.
5. Keep clear separation from qai-research-core.

See CONTRIBUTING.md for quality gates.