> ## Documentation Index
> Fetch the complete documentation index at: https://docs.obversa.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# What is a domain-specific harness?

> The loop, tools and rules around a model for one job, written as a workflow with named roles, a review that sends work back, and a person at the gate.

You can answer this with a file. A domain-specific harness is the loop, the
tools and the rules that make a general model useful for one job: insurance
intake, a research desk, a company's own integrations. The model is the
same one everyone has. The harness is the part that is yours, and most of
it is process: what runs first, what checks it, what happens when the check
fails, and who signs at the end.

The file below is `examples/teams/feature-delivery.ts`. The phrase comes
from the observation that products built on a model end
up owning the process around it rather than the model. What that process
looks like in code is a workflow:

```ts theme={null}
import { claude } from '@obversa/engine-claude-cli';
import { codex } from '@obversa/engine-codex';
import { run } from '@obversa/runtime';
import { fromFile, person, stage, workflow } from '@obversa/teams';

/**
 * A feature, delivered the way a team delivers one. The roles are named once;
 * every stage is a small block of nouns: who does it, what it writes, who
 * reads it, where a red result goes back to. Inference happens only where a
 * role is named; every other stage is a command or a person.
 */
const team = workflow('feature-delivery', {
  brief: fromFile('briefs/triple.md'),
  options: { timeout: '10m' },

  roles: {
    analyse: claude('claude-sonnet-4-5'),
    implement: codex('gpt-5.6-luna'),
    'research-review': [codex('gpt-5.6-luna')],
    'code-review': [claude('claude-sonnet-4-5')],
    approve: person('Ship this change?'),
  },

  stages: [
    stage('research-context', {
      agent: 'analyse',
      writes: 'team-output/research-context.md',
      desc: 'Read the workspace and write down what the change touches.',
      gate: 'The context note is in the workspace and a reviewer has accepted it.',
      reviewedBy: 'research-review',
      retry: 3,
    }),

    stage('research-requirements', {
      agent: 'analyse',
      writes: 'team-output/research-requirements.md',
      desc: 'Turn the brief and the context note into requirements, one REQ-n per line.',
      gate: 'The requirements note is in the workspace and a reviewer has accepted it.',
      reviewedBy: 'research-review',
      retry: 3,
    }),

    stage('plan', {
      agent: 'analyse',
      writes: 'team-output/plan.md',
      desc: 'Write an executable plan from the requirements, one check per REQ-n.',
      gate: 'Every requirement has a check in the plan.',
      reviewedBy: 'research-review',
      retry: 3,
    }),

    stage('tests-first', {
      agent: 'implement',
      writes: 'test/triple.test.mjs',
      desc: 'Write the declared test files from the accepted plan before any implementation exists.',
      gate: 'Every declared test file exists and covers the plan.',
      reviewedBy: 'code-review',
      retry: 3,
    }),

    stage('implement', {
      agent: 'implement',
      writes: 'src/triple.mjs',
      desc: 'Write the code to the plan and the tests.',
      gate: 'The source file exists.',
      retry: 3,
    }),

    stage('test', {
      run: ['node', '--test', 'test/triple.test.mjs'],
      desc: 'Run the tests; a red run goes back to implement with the output.',
      gate: 'The test command exits 0.',
      sendsBackTo: 'implement',
    }),

    stage('review', {
      panel: 'code-review',
      agree: 1,
      desc: 'Read the change and the test result against the plan.',
      gate: 'At least one reviewer has accepted the change.',
      sendsBackTo: 'implement',
    }),

    stage('approve', {
      input: 'approve',
      desc: 'Put the verified change in front of a person.',
      gate: 'A person has said yes.',
    }),

    stage('close', {
      agent: 'analyse',
      writes: ['team-output/evidence.md', 'team-output/learning.md'],
      desc: 'Write the evidence of the run and what was learned, from the record alone.',
      gate: 'Both notes are in the workspace.',
    }),
  ],

});

const result = await run(team);
console.log(JSON.stringify(result.outcome, null, 2));
```

## The three parts, and where each lives

| part                      | in the file above                                                          |
| ------------------------- | -------------------------------------------------------------------------- |
| The tools and the engines | The roles: which engine takes which job.                                   |
| The rules                 | The stages in order, the files each may write, the brief.                  |
| The checks                | A review role that sends work back with findings, and a person at the end. |

## Things that catch people out

* **It is not an agent.** Claude Code, Codex and the others are the
  agents, each with its own inner loop. The harness for a job drives them.
  See [what is an agent harness](/glossary/agent-harness).
* **The person is part of the harness.** A job that ends in a human
  decision writes that decision in as a role, so the run pauses there; the
  answer arrives through the callbacks client.
* **The record is the audit.** Every step is written as it happens, so the
  run can be read back later. See [how a run is recorded](/recording/how-a-run-is-recorded).

## Where to go

[Domain-specific harnesses](/use-cases/domain-specific-harnesses) for the
use case in full; [a feature team, as a file](/workflows/feature-team) for
a recorded run.