A result schema that renders itself

The problem — the schema stores reasoning, so the UI has to reverse-engineer it

Four things make the current score.json hard to use and hard to read:

Net: 14 keys per signal + 4 redundant top-level blocks — and none of it is chip-ready.

1Principle — two layers, store only what varies

Everything else (a Strengths/Concerns view, contribution points, the "type→effect" legend) is derived at render from these two layers — never stored twice.

2The new per-candidate shape

// score.json — per candidate
{
  "resume_hash": "…", "position_id": "…", "ctx_hash": "…",   // plumbing
  "fit_score": 7, "bucket": "weak", "confidence": "medium",
  "summary": "Strong reject — UX designer; none of the 8 mandatory QA skills; 2.5 yrs vs a 5-yr bar.",
  "signals": [
    {
      "family": "required_skill_match",   // → joins the static def for label/type
      "score": 0.03,                       // 0–1 (was sub_score)
      "confidence": "high",
      "show": "chip",                     // chip | detail | hidden       ★ scorer decides
      "headline": "0 / 8 required skills",// ≤6 words → chip label + hover title ★NEW
      // note: chip COLOUR is derived at render from score + type — not stored
      "explanation": "All 8 mandatory skills absent; entire skill set is UX/Product Design.",
      "evidence": [ { "source": "resume · skills",
                       "quote": "Product Thinking, Visual Design… no QA skills" } ]
    }
    // …one per family (14)
  ]
}

Per-signal: 14 keys → 7, and four of them (headline · explanation · evidence · show) are the render inputs. Top level: 4 redundant blocks → one summary sentence.

3Every field maps to one thing on the card

The scorer decides, the FE renders. show and headline are written by the scorer (applying the confidence + missing-≠-negative rules once), so the client never re-derives display logic. Colour is the one thing the FE computes — from score + the static type, never from a stored label. That's what kills the old mislabel bug (state:"positive" on a red flag): a number can't be mislabelled the way the state enum was, so we store neither state nor tone.

4Worked example — the same candidate, rendered directly

Deepanshi (UX designer, Fit 7 · weak) under the new schema. The scorer marked 3 signals show:"chip" — all confident negatives; the other 11 are detail or hidden. education_certs is hidden: a bare degree is table stakes — everyone has one, so it earns no signal (only a real, role-relevant certification would).

…and the hover for each (drawn straight from the fields; colour derived from score+type)

No modal — headline→title, explanation→body, evidence→rows, show→visibility; colour is computed from score+type, not stored.

5What we remove, and why it's safe

6Rollout

Contained to the scorer step — no consumers today except the local viewer.

• Update the score prompt + schema (steps/step07_score.py, lib/schemas.py): emit headline · explanation · show per signal; drop the removed keys (incl. tone); emit one summary. education_certs ignores a bare degree — only a role-relevant certification scores.
• Keep the static family layer as the single source for label · type · effect · what_we_extract (already FAMILY_META); weight stays in context.json.
• Bump STEP_VERSIONS["score"] to re-score the 10 sample candidates into the new shape.
• The report FE reads the fields verbatim — no display logic in the client.