How refinement works
Follow bounded evidence through a model decision, critique, and host validation.
Refiner evidence
The fast Refiner runs after a completed turn, outside the foreground response path. It receives a bounded evidence packet, not unrestricted account history.
Included evidence
- The request and user-visible result.
- Normalized tool failures, retries, recovery, validation, and follow-ups.
- Short event excerpts and artifact diagnostics.
- The immutable Harness sources loaded for that run.
- Eligible memory, prompt, Skill, and Agent targets.
Excluded evidence
The packet excludes secrets, raw credentials, unrestricted connected-app data, unbounded transcript archives, and unrelated private workspace content.
Evidence is scoped by host authorization and byte/time/cost bounds. A missing
signal can be recorded as an observability gap instead of silently becoming
no_action.
Refiner decisions and routing
The Refiner model decides whether evidence is meaningful, whether recovery still reveals a reusable defect, what layer owns the problem, and whether a small change can help materially different future tasks.
Possible outcomes
| Outcome | Meaning |
|---|---|
no_action | Evidence is weak, isolated, resolved, or not reusable. |
| Memory | A durable owner-scoped fact or preference. |
| Prompt | A broad execution behavior adjustment. |
| Skill or Agent | A reusable workflow or role change. |
| Runtime or product | A capability defect outside Harness content. |
| Taskset | Controlled measurement is needed. |
| Training | A model-policy limitation may exist, subject to separate gates. |
Deterministic host code enforces authorization, bounds, identity, schemas, safe paths, application, rollback, and approvals. It does not force a route from keywords, tool names, error strings, or a fixed number of occurrences.
Refiner critique and validation
Every proposed Harness mutation receives a second model critique before host validation. The critique can generalize an edit, route it elsewhere, or reject it when it copies task-specific facts, names, outlines, transient paths, or an isolated workflow.
Host validation
The host then checks the parts that must be deterministic:
- schema and content identity;
- target authority and safe paths;
- exact edit and release-base compatibility;
- activation and runtime validation; and
- atomic application or rollback.
Invalid decisions fail closed to no_action or a recorded validation failure.
The system documents observable outcomes and receipts, not a model's private
reasoning.
Continue with Releases and rollback.