Skip to content

Domain-general, config-declared research dimensions

ADR-0003: Domain-general, config-declared research dimensions

Section titled “ADR-0003: Domain-general, config-declared research dimensions”

Accepted

A research harness fans out across “dimensions” of inquiry. The template must research anything — software architecture, regenerative agriculture, K-12 publishing — without the engine carrying a fixed domain vocabulary. The question is where the dimensions a session analyzes come from (harness.config.json dimensions[], the dimension-analyst agent).

The prior generation hardwired a market-research taxonomy into the engine, which made the tool unusable outside that one domain.

  1. The core must be domain-general; no domain taxonomy may be hardwired.
  2. A clone should change its research lens by editing one file, not the engine.
  1. The orchestrator and the dimension-analyst must read dimensions, not embed them.
  2. The default set should be sensible but fully overridable.

Description: Embed a fixed set of dimensions (e.g. market-research dimensions) directly in the engine.

  • Advantages: Zero configuration for the one domain it targets.
  • Disadvantages: Couples the engine to a domain and reproduces the prior system’s central limitation.
  • Risk Assessment: technical low; schedule low; ecosystem high.

Description: Read dimensions from harness.config.json dimensions[]; parameterize the dimension-analyst by a dimension id resolved at run time.

  • Advantages: dimensions[] is the single control surface; the default ships technical, landscape, trajectory, each with a description, and a clone replaces them wholesale; the analyst resolves methodology (a pack skill if pack-provided, else general web research) rather than a fixed taxonomy.
  • Disadvantages: A misconfigured dimensions[] yields a thin or skewed run.
  • Risk Assessment: technical low; schedule low; ecosystem low.

Option 3: Per-session free-form dimensions

Section titled “Option 3: Per-session free-form dimensions”

Description: Invent dimensions ad hoc at run time with no manifest declaration.

  • Advantages: Maximally flexible per run.
  • Disadvantages: Nothing is declarative or reviewable; the goal contract and the manifest lose a stable reference, undermining verifiability.
  • Risk Assessment: technical medium; schedule low; ecosystem medium.

Adopt Option 2: config-declared dimensions. Dimensions are read from harness.config.json dimensions[]. The orchestrator fans out one dimension-analyst per declared dimension, and the goal schema’s dimensions[] references those same ids. The shipped default (technical, landscape, trajectory) is illustrative, not canonical.

  1. The harness is domain-general and re-targeted by editing one manifest array.
  2. The goal contract, orchestrator, and analysts agree on dimension identity by config, not by code.
  1. The quality of a run depends on how well the clone declares its dimensions.
  1. The shipped defaults serve as an example only and are expected to be replaced.

Config-declared dimensions keep the engine domain-general while making the research lens a one-file edit. The dependence on good configuration is inherent to a domain-general tool and is mitigated by shipping a sensible default set and schema validation of the manifest.

  • Date: 2026-06-23
  • Source: harness.config.json, schemas/goal.schema.json

Status: Compliant

FindingFilesAssessment
Dimensions declared in the manifestharness.config.json (dimensions[])compliant
Goal schema references dimension idsschemas/goal.schema.json (dimensions[])compliant
Manifest validated by schemaharness.config.schema.jsoncompliant

Summary: Dimensions are declared in harness.config.json and referenced by the goal schema; the manifest is schema-validated.

Action Required: None