dsh-harbor-evolution 0.5.0 → 0.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,61 @@
1
+ # Evaluator Upgrade Workflow
2
+
3
+ Load this reference when the user wants to improve score reliability or change Evaluator, Rubric, Judge, reward semantics, or meta-evaluation.
4
+
5
+ ## Clarify the evaluator objective
6
+
7
+ Inspect `harbor_eval_result view=governance` and representative Trial evidence first. Resolve:
8
+
9
+ 1. Which false positives, false negatives, disagreements, or calibration failures matter.
10
+ 2. Who owns the independently maintained GT, its source kind and provenance, and how adjudication works.
11
+ 3. Which meta-metrics define improvement: RCR, precision/recall, bias, variance, calibration, latency, or cost.
12
+ 4. The allowed Evaluator/Rubric/Judge mutation surface and budget.
13
+ 5. The approval owner for adopting new score semantics.
14
+
15
+ Do not use the Candidate Agent to author its own GT. Do not infer GT from the current Evaluator output.
16
+
17
+ ## Create a new immutable evaluator identity
18
+
19
+ Show the current identity, source, proposed diff, and expected semantic impact. Create new files and increment component plus Evaluation Stack versions. Never edit a historical Evaluator, Rubric, Judge identity, or old Job artifact in place.
20
+
21
+ Use the `harbor-dsh-evaluator/v1` Descriptor as the implementation boundary:
22
+
23
+ - `kind=script` for deterministic code, rules, or local models.
24
+ - `kind=llm-as-judge` for a model-backed judge; keep credentials out of source and identity artifacts.
25
+ - Both kinds consume `evaluation-input/v1` and return `evaluation-result/v1` with Descriptor-declared Criterion ids and score values.
26
+ - Every Criterion also requires non-empty `reason` and `recommendation` strings. Missing fields invalidate the evaluator result; Reporter never fabricates them.
27
+ - `editable_files` is the exact source allowlist used by the Workbench and `harbor_evaluator_update`.
28
+
29
+ Call `harbor_evaluator_inspect` to capture the active digest. After explicit approval, `harbor_evaluator_update` requires the expected file digest plus new Evaluator and Stack versions, copies the whole bundle to a new version directory, and switches the active Stack. It never launches evaluation or Gate.
30
+
31
+ Treat changes to any of these as reward-semantic changes requiring a new Context and fresh Agent baseline:
32
+
33
+ - Evaluator source or digest.
34
+ - Rubric source or digest.
35
+ - Judge provider, model, version, or parameters.
36
+ - Evaluation Contract metric meaning or hard requirements.
37
+
38
+ ## Meta-evaluate before adopting
39
+
40
+ Rotate roles:
41
+
42
+ - Candidate: the new Evaluator/Rubric/Judge version.
43
+ - Dataset: independently maintained examples with provenance-bearing GT and disagreement metadata.
44
+ - Evaluator: deterministic comparison between evaluator decisions and GT.
45
+ - Reporter: RCR and accepted diagnostic slices.
46
+ - Gate: explicit human-approved adoption decision.
47
+
48
+ Use the same GT set, repeat policy, and measurement procedure for old and new evaluator Candidates. Report coverage, invalid measurements, aggregate metrics, disagreement slices, latency, cost, and representative errors. Do not select only favorable runs.
49
+
50
+ GT is not synonymous with human labeling. It may be human, programmatic, consensus-based, produced by a separately pinned model, or imported from an external standard. Require explicit provenance and independence from the Candidate evaluator in every case. Use `harbor_ground_truth_init` to create the versioned draft and `harbor_evaluator_meta_evaluate` to calculate ESF, SCE, and RCR from repeated observations.
51
+
52
+ ## Re-baseline Agent progress
53
+
54
+ After the evaluator Candidate passes its explicit Gate:
55
+
56
+ 1. Update Evaluation Stack identity.
57
+ 2. Preview Context v2 and confirm old Agent Jobs are no longer comparable.
58
+ 3. Run the current Champion Agent as a fresh baseline under the new evaluator.
59
+ 4. Compare later Agent Candidates only against Jobs sharing the new Context digest.
60
+
61
+ Adopting an evaluator does not mutate, promote, deploy, or publish an Agent automatically.
@@ -19,6 +19,8 @@ Resolve every value before calling `harbor_evolution_init`:
19
19
 
20
20
  Also establish diagnostic metrics, min/max thresholds, non-regression metrics, mutation surface, repeat policy, and promotion owner. The initializer creates a minimal Policy; update its explicit placeholders before a formal Gate.
21
21
 
22
+ If the Evaluator itself will be optimized, separately establish Ground Truth id/version, source kind (`human`, `programmatic`, `consensus`, `model`, or `external`), provenance, owner, Criteria, case population, and adjudication rule. Do not hide these semantics inside the Agent Dataset identity. Use `harbor_ground_truth_init` only after they are accepted.
23
+
22
24
  ## Generated layout
23
25
 
24
26
  ```text
@@ -70,8 +72,17 @@ evaluation_contract:
70
72
  - { id: reward, label: Overall reward, direction: maximize }
71
73
  - { id: valid_search_rate, label: Valid search rate, direction: maximize }
72
74
  - { id: citation_accuracy, label: Citation accuracy, direction: maximize }
75
+ hard_requirements:
76
+ - { id: input_integrity }
77
+ - { id: agent_completed }
78
+ - { id: integration_valid }
79
+ - { id: renderer_valid }
80
+ - { id: judge_completed }
81
+ - { id: artifact_schema_valid }
73
82
  ```
74
83
 
84
+ The validity requirements answer whether a quality score is admissible. They are separate from metric thresholds. Infrastructure and evaluation failures may retain raw verifier output for audit, but must emit `score.valid=false` and never enter Population aggregates.
85
+
75
86
  Do not duplicate Evaluator logic inside each Task. Reference one Stack Evaluator from task metadata when task-specific routing is needed.
76
87
 
77
88
  ## Dataset rules
@@ -118,3 +129,5 @@ Show the user:
118
129
  5. Doctor findings and Context preview.
119
130
 
120
131
  Start with a baseline. Do not create Candidate v2 until baseline evidence supports one controlled hypothesis.
132
+
133
+ The first completed Job should produce `trial-lifecycle.json`, `trial-events.jsonl`, Trial Assessment v2 files, `artifact-registry.json`, Population Report v2, and Optimization Report v2. Treat missing 0.6 capabilities on older Jobs as read-only historical limitations, not synthetic defaults.