Make the OpenPond Refiner Yours

Most teams already have an agent that works sometimes. The hard part is figuring out what went wrong, deciding whether the fix belongs in a prompt, Skill, Agent, runtime, eval, or model, and making that improvement without learning noise from one customer conversation.

OpenPond Refiner is the review agent for that job. After a Work turn finishes, the host gives it a bounded packet of authorized traces, failures, recoveries, artifacts, grades, and the Harness source that was actually active. Refiner then returns one of three structured outcomes:

no_action when the evidence does not support a durable change;
route when the owner is runtime, product, Taskset, or training;
propose for one exact memory, prompt, Skill, or Agent change.

A proposal still goes through critique, deterministic admission, validation, and host activation. Refiner does not silently rewrite production from an error string.

What the default Refiner does

The default Review Profile is intentionally broad and product-neutral:

{
  "schemaVersion": "openpond.refinerReviewProfile.v1",
  "id": "openpond.default",
  "version": "1",
  "name": "OpenPond default review",
  "objective": "Find the smallest reusable change that improves future work without learning task-specific facts.",
  "instructions": [],
  "allowedProposalRoutes": ["memory", "prompt", "skill", "agent"],
  "allowedExternalRoutes": ["runtime", "product", "taskset", "training"]
}

With no product-specific instructions, the default Refiner concentrates on a few general questions:

Is the evidence supplied by the host strong enough to support a reusable correction?
Did one deterministic mechanism cause the failure, or did the same problem recur across materially independent incidents?
What is the smallest layer that can prevent the problem next time?
Does the issue actually belong to the agent, or should it be routed to the runtime, product, Taskset, or training system?

Ordinary successful work, one-off customer facts, and high token use by itself do not justify an update. When a change is justified, the default Refiner can propose a precise create, update, or delete operation against memory, prompts, Skills, or Agents. This gives you a useful reviewer out of the box without pretending that OpenPond already knows the success criteria of your product.

Harness and Refiner are separate releases

The Harness is what acts: its instructions, Skills, Agents, memory, tools, and dependencies. Refiner reviews evidence and proposes a future Harness.

That creates an important boundary. A Work turn pins two identities:

Work turn
  ├─ Harness H1: acts on the task
  └─ Refiner R1: reviews the completed evidence
                    │
                    └─ may propose Harness H2

Later authoring turn
  └─ may create Refiner R2

R1 never updates R1 while it is reviewing. Refiner releases, activation, and rollback live beside Harness releases, not inside them. Receipts record both, so a team can reproduce which acting policy and which reviewing policy produced an outcome.

Extend Refiner with a Review Profile

The Refiner Core owns the safety invariants: evidence admission, privacy, ownership routing, structured output, validation, and immutable activation. A Review Profile adds the objective and behavioral instructions that matter for your product.

The canonical source is deliberately small JSON:

{
  "schemaVersion": "openpond.refinerReviewProfile.v1",
  "id": "acme.review",
  "version": "1",
  "name": "Acme review",
  "objective": "Find the smallest reusable correction supported by the trace.",
  "instructions": [
    {
      "id": "pdf-completion",
      "text": "Treat a failure that prevents reading a requested PDF as material review evidence."
    }
  ],
  "allowedProposalRoutes": ["memory", "prompt", "skill", "agent"],
  "allowedExternalRoutes": ["runtime", "product", "taskset", "training"]
}

This is prompt policy, not a growing TypeScript framework or a severity rules engine. Add the smallest instruction that explains what your reviewer should understand.

In OpenPond Work, invoke the bundled Skill directly:

$openpond-refiner-authoring Treat failures that prevent reading a requested PDF as material review evidence.

The bundled openpond-refiner-authoring Skill inspects the current profile, preserves unrelated instructions, writes a validated immutable release, and records the exact transition. Personal imperative changes can activate immediately. Draft requests and review-gated environments can create a release without moving the active binding. Settings shows the active Core and Profile, the actual instructions, release history, and rollback.

Because this uses the normal $skill-name path, Refiner authoring is not a special mode or a separate slash command. The authoring Skill can evolve like the rest of your Harness while the Core continues enforcing the review boundary.

Use it from the open-source Harness

The same profile contract and prompt composition are public in @openpond/harness:

import {
  authorLocalHarnessRefinementWithModel,
  defineReviewProfile,
} from "@openpond/harness/refiner";

const reviewProfile = defineReviewProfile(profileJson);

const decision = await authorLocalHarnessRefinementWithModel({
  evidence,
  stream: yourProviderStream,
  signal: new AbortController().signal,
  reviewProfile,
});

The contracts are also available from openpond-sdk/refiner. You control the model stream and the evidence you admit, while the Refiner returns the same structured no_action, route, or propose decision used by OpenPond.

That gives you a portable adoption path: start with the default reviewer, add the success criteria your product actually needs, turn recurring failures into evals and Harness changes, and only then move toward continuous updates or a model trained for your work.