We have been repairing and dogfooding the `CRYPTO / PROTOCOL VENTURE COHORT` pipeline, specifically the V0.3.1 cohort and the V0.3.2B token-judge evidence repair.
Hard constraint: **NO NEW IDEAS** for the repair work. Only reprocess the existing six former V0.3.1 survivors.
Implemented strict Sol Token Utility Judge evidence validation.
Required non-empty fields now enforced:
-`argument_for_native_token`
-`argument_against_native_token`
-`external_collateral_counterfactual`
-`native_token_removed_breaks`
-`native_token_removed_explanation`
-`material_improvements_over_USDC_ETH`
-`native_asset_costs_and_risks`
-`final_rationale`
Behavior now:
- Rejects incomplete Sol judge response.
- Retries incomplete judge response up to 3 attempts.
- Raises `ValueError` after exhausted retries.
- Does **not** fall back to deterministic/heuristic classification when Sol produced an incomplete response.
- Normalizes Sol response when `external_collateral_counterfactual` appears nested under `counterfactual_analysis`.
- Uppercases `utility_scores` keys during normalization.
- Persists `final_rationale` in token metadata as well as `TokenUtilityAssessment.rationale`.
-`crypto_score_row()` now reuses persisted `token_utility_assessment` instead of calling the token judge again.
- Final Sol IC prompt was compacted so it returns usable JSON.
Rationale invariants now checked:
- Every `TOKEN_OPTIONAL` rationale must explain why ETH/USDC/external collateral is preferable despite claimed degradation.
- Every `TOKEN_ESSENTIAL` / `TOKEN_STRONGLY_JUSTIFIED` rationale must explain what protocol-specific property cannot be reproduced economically enough with ETH/USDC/external collateral.
- The code does not automatically promote due to material degradation.
## Latest Six-Proposal Results
Before/after classifications from V0.3.2B:
| Company | Before | After | Score | Final IC Decision | Final IC Score | Required Field Gaps |
Important nuance: `Compute Clearance Network` became `TOKEN_STRONGLY_JUSTIFIED`, but final cohort finalists remain `0`. It is not automatically promoted to finalist.
No local Guard training/evaluation was run. The local machine is unsuitable and the user explicitly required Spark-only execution.
Spark connectivity is confirmed (`ssh spark hostname` returned `Inceptal`), but read-only inspection found no `ForgeGuard` directory under `/workspace`, `/home`, or `/opt`. Do not run training until a Spark ForgeGuard checkout path is provided or explicitly synced, then register it with `--spark-working-directory` and verify it.
Dataset curation result:
-`79` imported JSON artifacts
-`49` blocked
-`30` warning-only
-`0` approved training datasets
- Decision: `NO_TRAINING_DATASET_APPROVED`
Important curation facts:
- Summary JSON files are non-training artifacts.
- Candidate/provisional corpora are blocked.
-`full_source_c4_guard_candidate_v12` is explicitly candidate-only and has not been trained.
- The Qwen 3B verified pilot has 88 records and a claimed EVMBench exclusion, but stays `WARNING` pending record-level provenance/schema/coverage and contamination verification.
- No Spark baseline/canary/overnight program is permitted yet.
- All existing Guard data, including legacy holdouts, is authorized as a curation source by user mandate.
- Former holdouts can enter a new training version only after source-hash re-splitting produces new validation and regression manifests.
- Existing benchmark suites must be replaced/versioned before comparisons if their old holdout sources are used for training.
- Source data is never overwritten; every output is a new immutable `DatasetVersion`.
Spark Guard location:
-`/home/daniel/forgeguard`
- Active data root inspected: `/home/daniel/forgeguard/project/data`
The first bad recursive Spark inventory created `227,137` null-record-count DB rows from individual evidence JSON objects. Those malformed local DB rows were purged. The importer now accepts only explicit manifest paths; it does not recurse through evidence stores.
- Strict repair requires Solidity pragma, parseable JSON output with `findings`, and excludes `c4_invalid` records.
No Guard model training was started. The next required milestone is to deploy/sync Artifex state to Spark, register a new evaluation suite version using the v02 validation/regression manifests, run the fresh base-model baseline on Spark, then create the first actual training canary.
