A portable contract for agent systems.

Document contract.

A .ohm file is a declarative UTF-8 document. YAML is the human-authoring representation; after parsing, its content converges to a shared normalized model. The format is not an executable, a language model, or implicit authorization to run scripts.

schemaVersion

Version of the data contract. It does not identify YAML or JSON syntax.

manifest

Harness identity, version, description, declared license, and taxonomy.

graph

Participants (nodes) and explicit relationships (edges), referenced by stable identifiers.

content

Embedded artifacts such as prompts, agents, skills, hooks, commands, and scripts.

runtime

Execution preferences, CLI, environment, and secret references. Credentials do not belong in the document.

validation

Metadata and profiles used for structural verification and controlled simulation.

YAML anchors and aliases do not represent topology. Cycles in the data graph do not, by themselves, grant repetition semantics: loops require an explicit contract for conditions, budgets, timeouts, cancellation, per-iteration state, and human intervention.

Minimal example.

The example below demonstrates structure 1.0.0. The empty graph and multiline prompt are declarative data; no content is executed when the file is opened or validated. The license field belongs to the example and does not declare the application's license.

# OHM in YAML 1.2 — declarative contract.
schemaVersion: "1.0.0"
manifest:
  id: hello
  name: Hello
  version: "0.1.0"
  description: Minimal Open Harness Model example.
  license: MIT
  tags: []
graph:
  nodes: []
  edges: []
content:
  prompts:
    objective: |-
      Describe the objective of the work.
      Define the evidence required to accept the result.
  agents: {}
  skills: {}
  hooks: {}
  commands: {}
  scripts: {}
runtime:
  preferred: api
  cli: null
  env: []
  secrets: []
validation:
  mockProfile: default

Layered validation and explicit authority.

Structural conformance is necessary but insufficient. OpenHarness separates four layers: safe syntax parsing; normalized-model validation; deterministic execution eligibility; and operational outcome evaluation. This separation prevents a probabilistic decision from being mistaken for a security guarantee.

JSON Schema and domain invariants verify structure, references, and known limits. Deterministic gates retain authority over objective policies—permissions, signatures, dependencies, tests, budgets, timeouts, and release criteria. Human approval remains mandatory at the impact points defined by the process.

A structurally valid document does not prove instruction quality, provider availability, script safety, runtime equivalence, or production fitness. Each implementation must declare its capabilities, restrictions, and conformance evidence.

Probabilistic decisions are advisory, not sovereign.

Classifiers and specialized models can reduce latency and cost for well-bounded semantic decisions, such as suggested routing, context classification, and prioritization. They do not replace deterministic controls when a rule can be expressed and tested directly.

Laya is being evaluated in shadow mode: it produces advisory evidence without blocking execution, lowering severity, altering findings, or authorizing releases. On the desktop, experimentally, it can also choose at the chat front door between answering directly and starting the harness; below 0.80 confidence, or without Laya available, the model-based triage decides. In that role it has no authority over gates, human decisions, or merge. Any future promotion requires a representative labeled dataset, predefined metrics, false-negative analysis, confidence limits, safe fallback, and reversibility. Training for OpenHarness-specific cases remains possible, but does not remove this validation protocol.

The current OHM contract does not define a normative system_one_evaluator field or delegate gate authority to Laya, LLMs, or other classifiers.

Scope and maturity.

OHM uses YAML 1.2 for authoring and retains JSON in API and execution contracts. Legacy JSON documents remain relevant for compatibility. Canonical serialization targets determinism after normalization without promising textual identity or preservation of comments and input style.

The ability to represent a graph is distinct from the ability to execute it. Loop semantics, complete portability, cross-tool round trips, and operational equivalence require their own contracts and tests; they are not automatic consequences of the format choice.

OHM is an evolving OpenHarness technical proposal. It is not yet an independent standard, but it is explicitly intended to pursue broad adoption, interoperability across tools, and, as it matures, open and independent governance.

The manifesto presents the institutional principles guiding that evolution.