Harness Runtime

Three research workers helped design this repository. Terrarium returned a verified receipt for every run. I rejected every answer.

One worker narrowed the project to Terrarium maintenance. Another invented descriptions of Deja and Unsurf. The third proposed commands that do not exist. The receipts still mattered: they correlated each result with the task that produced it. They could not establish whether the result was correct.

That failure exposed the boundary this repository documents. An agent needs more than instructions and tools. The system around it has to preserve task identity, apply authority, contain execution, test the actual claim, and leave evidence the next run can interpret.

Harness Engineering explains how context and tools shape agent output while the worker remains fixed. Harness Runtime asks a related implementation question:

What must cross each runtime boundary so task identity, authority, and evidence survive when the model, tool, runner, or interface changes?

The answer is a Markdown contract you can apply to one real job.

intent
  |
  v
context -> capability -> authority -> execution -> proof
   ^                                                |
   +---------------- continuity <-------------------+
          interruption may yield at any boundary
                           |
                     retire or repeat

The Contract

A harnessed job records nine fields:

• Outcome: the observable condition the job must make true.
• Context: the smallest current information that can change a decision.
• Capability: the operations available to the worker.
• Authority: which identity may cause which effect, where, and for how long.
• Execution: where work runs and how it is bounded, cancelled, and recovered.
• Proof: evidence at the boundary of the actual claim.
• Continuity: what the next run may recover, with provenance and freshness.
• Interruption: when a human must decide and what they need to know.
• Retirement: when the loop or machinery should stop existing.

Copy HARNESS.md into a project and fill it in for one representative job. An unanswered field identifies a boundary to inspect. Expanding the prompt does not repair a missing authority or proof boundary.

Four Ideas Behind the Contract

This contract connects four patterns from earlier experiments:

Pattern	Runtime consequence
Experiment, then notebook, then repository	Start with a falsifiable claim. Preserve proven, disproven, and unresolved results. Extract software only after repeated receipts earn a stable interface.
Liquid Primitives	Models, prompts, source, docs, and runners may be replaced. Intent, authority, data constraints, and proof have to survive the replacement.
Terraloops	A recurring driver carries state across time, delegates bounded work, verifies returned receipts, and deletes itself at a binary stop gate.
Airlock	Speculation can fan out across isolated workspaces. Integration, proof admission, and promotion remain explicit gates. Candidates deploy to previews with no live traffic before caller-owned promotion.

The first pattern explains why this repository contains a documentation contract and one construction case instead of a new runtime package. One case can expose a boundary. It cannot earn a universal schema.

ARCHITECTURE.md maps these patterns onto speculation, integration, release, continuity, and retirement.

What the Failed Runs Changed

The three rejected answers produced three rules for the contract.

Retrieved Context Remains Advisory

The workers claimed to have inspected source files, but some citations pointed to paths that did not exist. Retrieved context can guide the next inspection. Live code and systems remain authoritative for mutable facts.

The Runtime Applies Authority

A tool describes how to cause an effect. The execution boundary decides whether a specific identity may cause that effect within a resource scope and time window. When possible, the runtime should apply credentials without placing them in the model trajectory.

Proof Matches the Claim

A correlated receipt established that each research task ran. I tested the workers' claims against the source repositories. These artifacts answer different questions, so the contract records them separately.

CASE-STUDY.md contains the run IDs, dispositions, concrete failures, limits, and construction receipt. case-study/REPRODUCE.md provides a repeatable version of the test.

Accountable Delegation

One trajectory owns integration and the final outcome. It may delegate bounded questions when independent work can add evidence.

                    +-- investigator
accountable owner --+-- competing attempt --> verify --> integrate --> prove
                    +-- adversarial critic

Each child returns a claim and an execution receipt. The owner inspects the artifacts, resolves disagreement, and closes the job against the original outcome. Parallelism supplies evidence; it does not distribute final ownership.

Reference Decomposition

I derived the contract while working with existing projects and operating patterns. They illustrate separate boundaries rather than a required stack.

Boundary	Example implementation	Mechanism
Context and continuity	Deja	Repository-scoped, bounded, cited memory with explicit trust and handoffs
Delegation and receipts	Terrarium	Bounded jobs and run-correlated provenance receipts
Capability-scoped execution	Lab	Explicitly granted I/O inside a V8 isolate
Claim-specific proof	Gateproof	Local loops that observe state, act, then assert the result
Preview and promotion gating	Airlock	Content-addressed candidates, parallel checks, source-bound proof, and an explicit promote effect

Their current guarantees differ, and this repository does not claim they already operate as one integrated product. ARCHITECTURE.md maps the responsibilities and trust boundaries.

Apply It to One Job

Start with a repeated job rather than a control plane.

1. Choose an observable outcome and binary stop gate.
2. Fill in HARNESS.md using the current worker and environment.
3. Run a baseline.
4. Find the earliest handoff that loses intent, authority, or evidence.
5. Change the smallest boundary that owns the failure.
6. Rerun under equivalent conditions.
7. Keep, revise, or remove the intervention.

Only extract software after multiple jobs require the same operation. Repeated need may justify a receipt validator, authority envelope, or context projection. This repository supplies no universal schema or runtime package because the current case has not earned either one.

Current Evidence Boundary

The case establishes that three correlated Terrarium runs completed and that source inspection rejected their answers. It does not measure whether parallel work improved quality, speed, or cost. It also does not show that this contract improves outcomes across a task cohort.

The next experiment is to apply HARNESS.md to two unrelated repeated jobs, hold each stop gate fixed, change one boundary, and compare the observed outcomes.

The three receipts stayed green. The three answers stayed rejected. The contract keeps both facts visible.

Lineage and Attribution

This work is an implementation-oriented response to Ryan Lopopolo's Harness Engineering, especially its work on just-in-time context, whole-job ownership, explicit authority, real-environment proof, and continuous maintenance.

Harness Engineering is © its contributors and licensed under CC BY 4.0. This repository identifies the source, links to the original material, and develops a distinct runtime-contract framing.

This repository is also licensed under CC BY 4.0.