Preflight
What problem are you trying to solve?
I maintain Loop Platform, an open-source, contract-driven delivery pipeline with independently replaceable Spec Compiler, Maker, Checker, and Delivery stages.
Its deterministic checks (security, runtime, E2E, and acceptance checks) remain the release gate. I would also like to consume Better Harness as an evidence-backed process-quality signal: for example, whether task understanding, validation evidence, delivery safeguards, and learning capture are sufficiently observable for one delivery run.
The current downstream prototype, ProcessChecker, can inspect Better Harness output experimentally. However, an external orchestrator cannot safely infer a stable report location, output contract, task binding, or unavailable-evidence state. This risks associating a stale or unrelated report with a delivery run.
The problem is therefore not how to replace deterministic tests. It is how an external pipeline can reliably consume Better Harness evidence for one specific task episode.
What would success look like?
A delivery pipeline can reliably record Better Harness results for one task without guessing which report belongs to that task.
For a completed run, the externally consumable result should make it possible to determine:
- whether Better Harness evidence was available, partial, unavailable, or complete;
- which task/workspace/run the evidence belongs to;
- the findings, their evidence references, and their scope;
- whether the result is suitable for advisory use, human review, or a pipeline-defined gate.
A documented supported integration path would be sufficient. It could document an existing machine-readable interface, output contract, or task/evidence binding mechanism; this request does not require a particular API design.
Where would this be used?
The initial consumer is the Checker stage of Loop Platform, especially in non-interactive delivery runs:
Spec Compiler → Maker → deterministic validation → Better Harness process analysis → delivery policy
This would be used with:
- Qoder or other host-native Makers that may have session evidence;
- API-based Makers, such as DeepSeek API, that have no host-native transcript but can provide task metadata, Spec/acceptance hashes, validation outcomes, deployment outcomes, and trace events;
- CI/CD or scheduled autonomous delivery workflows that need parser-safe, task-scoped results.
Examples or evidence
Prototype consumer:
Example scenario:
- A Maker generates an application from a requirement and structured acceptance contract.
- Deterministic security, runtime, unit, and E2E checks pass.
- The pipeline wants Better Harness to assess the available task/process evidence for this specific run.
- If session evidence is absent—for example, for a direct API Maker—the result should remain explicitly unavailable or partial rather than being treated as a passing Better Harness analysis.
Anything else?
Non-goals:
- I am not asking Better Harness to depend on Loop Platform.
- I am not proposing Better Harness as a replacement for deterministic tests.
- I am not requesting a new public schema in the first phase.
- I am not proposing automatic repair or release without an explicit policy and approval boundary.
I am willing to contribute a small, tested follow-up after maintainers advise on the appropriate boundary. Possible contributions include a redacted fixture, an end-to-end integration example, a case study, or documentation for the recommended external-consumer path.
Preflight
What problem are you trying to solve?
I maintain Loop Platform, an open-source, contract-driven delivery pipeline with independently replaceable Spec Compiler, Maker, Checker, and Delivery stages.
Its deterministic checks (security, runtime, E2E, and acceptance checks) remain the release gate. I would also like to consume Better Harness as an evidence-backed process-quality signal: for example, whether task understanding, validation evidence, delivery safeguards, and learning capture are sufficiently observable for one delivery run.
The current downstream prototype, ProcessChecker, can inspect Better Harness output experimentally. However, an external orchestrator cannot safely infer a stable report location, output contract, task binding, or unavailable-evidence state. This risks associating a stale or unrelated report with a delivery run.
The problem is therefore not how to replace deterministic tests. It is how an external pipeline can reliably consume Better Harness evidence for one specific task episode.
What would success look like?
A delivery pipeline can reliably record Better Harness results for one task without guessing which report belongs to that task.
For a completed run, the externally consumable result should make it possible to determine:
A documented supported integration path would be sufficient. It could document an existing machine-readable interface, output contract, or task/evidence binding mechanism; this request does not require a particular API design.
Where would this be used?
The initial consumer is the Checker stage of Loop Platform, especially in non-interactive delivery runs:
Spec Compiler → Maker → deterministic validation → Better Harness process analysis → delivery policy
This would be used with:
Examples or evidence
Prototype consumer:
Example scenario:
Anything else?
Non-goals:
I am willing to contribute a small, tested follow-up after maintainers advise on the appropriate boundary. Possible contributions include a redacted fixture, an end-to-end integration example, a case study, or documentation for the recommended external-consumer path.