Proposed specificationSource-located exemplarH3

Joint harness-policy evolution

Adapt runtime structure and policy together.

JOIN POINTcoadaptive_training_loopRECORD STATUSCandidate · v0.1.0

UML class view

The proposed contract drawn as participant roles, received calls, and numbered dependencies.

Object interactions

The same roles and calls as a class collaboration and a numbered message sequence.

Object interaction diagram for Joint harness-policy evolution, showing role collaboration and a numbered message sequence — FIG. E06 / OBJECT INTERACTIONS
Open full SVG Download PDF

Pointcut

Where the mechanism applies. All four dimensions belong to the proposed match, not just its vocabulary.

Context: Runtime harness and model policy can both change.
Trigger: An evolution round evaluates task behavior and proposes changes to either or both.
Structure: Task interface, harness representation, policy representation, and joint evaluator.
Effect: The selected pair is evaluated as a pair with attribution for harness and policy changes.

Protected contract

The obligation that clients, operators, and auditors should be able to rely on.

Requires: Policy and harness variants are versioned jointly.
Ensures: Results identify the evaluated pair and separate objective contributions where possible.
Invariant: A policy gain is not reported as a harness gain without an ablation.
Violation: Failed candidates or incompatible pairs are excluded with reason.

Negative control

Retraining only the model with a fixed harness is not joint evolution.

Variation & lifecycle

The hot spot is admitted only where the protected semantics survive.

Permitted variation

Curated pairs, coevolution, alternating optimization, and ablation controls.

Test obligation

Test pair compatibility, harness-only, policy-only, joint, and transfer.

Evolution question

Did research move from separate optimization to paired variants?

Prompt + code design

An illustrative prompt and a small design sketch for the proposed contract. Names and APIs are invented; this is not a repository excerpt.

PROMPT SKETCH

Version policy and harness variants as a pair. Every result must identify the evaluated pair, and separate each objective's contribution where the design permits.

CODE DESIGN / PYTHON

def evaluate_pair(harness, policy, suite):
    result = suite.run(harness=harness, policy=policy)
    return PairResult(
        harness_version=harness.version,
        policy_version=policy.version,
        metrics=result.metrics,
        ablations=suite.ablate(harness, policy),
    )

Illustrative design sketch. A score without the pair identity cannot support a joint-evolution claim. This example is a teaching aid, not implementation evidence or a conformance claim.

Detection & matching

The frozen rule that retrieves this record, the canonical source exemplar, and the control that should stay unmatched.

Join point: coadaptive_training_loop
Source locator: Chen et al.
Lexical cue: (?i)\b(?:joint[_-]?evolution|evolve\w*\s+(?:harness|policy)|policy[_-]?evolution)\bFrozen expression, v0.1.0. A match is a retrieval cue, not a confirmed implementation.
Aliases: coevolution, jointoptim, harnesspolicy, policyevolution
Canonical exemplar: mingju-c/HarnessForgeHarnessForge_4B/evolved_pairs/pairs.yaml:1Support: README.md:15
Negative control: Retraining only the model with a fixed harness is not joint evolution.

Scope-anchored review. pohe-agent analyze <repo> --pattern E06 anchors the cue to its enclosing declaration and checks a separate operational signature for all four pointcut dimensions. Missing roles and negative-control risks remain visible; a structural match is not E2/E3. Calibration report ↗

Repository files

Up to five public files retrieved by the frozen cue and pinned to the audited commit. A match is a place to inspect, not a confirmed implementation.

01mingju-c/HarnessForgeHarnessForge_4B/evolved_pairs/pairs.yaml:1CANONICAL SOURCE

Evidence & provenance

Each layer answers a different question. Do not substitute retrieval for review.

Source-located exemplar

A concrete source anchor is available for this proposed record. It is one exemplar, not evidence that all repositories—or every contract field—conform.

Review boundary: this candidate and its specification come from an AI-assisted study. Independent human validation remains open.

ANY-EVIDENCE FAMILY COVERAGE1/36

2.8% of repository families in the frozen panel have at least one current cue, historical cue, or canonical source layer. This is not confirmed prevalence.

Current lexical-cue repositories: 1 / 41

Canonical source anchormingju-c/HarnessForge 8bef9488c35aHarnessForge_4B/evolved_pairs/pairs.yaml:1

Supporting surfaceREADME.md:15

Curated harness-policy pairs.

Exploratory retrieval cue Regex / v0.1.0

(?i)\b(?:joint[_-]?evolution|evolve\w*\s+(?:harness|policy)|policy[_-]?evolution)\b

This expression is a discovery instrument only. A match is a retrieval cue—not a confirmed implementation, pointcut match, or contract proof.