MC-30: Sync the pipeline-records schema

[touchdownllc]

In plain English

This PR carries two byte-identical schema syncs to docs/design/schemas/pipeline-records.schema.json, both documented in Database-entity-details.md:

1. Fact-run identity — fact_runs gains two digest columns so the landing side can tell a corrected fact run from one it already landed. Tracked as MC-30; producer change nachos-ai-poc-3#346 (issue #345).
2. base_nachos_score — score_records gains the base NACHOS methodology tier as a first-class landed field (it was reachable only inside the open dimensions blob). No producer emit change; the matching pipeline-side contract update is filed as nachos-ai-poc-3#349.

---

1. Fact-run identity

Why

A fact-run header carries mode, model, prompt_version, status, cost_cap_hit and the run counts. Nothing the landing side dedups on covered any of it: ingestion_runs.run_id is derived purely from the ingestion inputs, and the per-(state, lens) release_id covers scored records.

That gap was observed, not theorised. Correcting fact_run.mode from "api" to "llm" (MC-24 §8.8) changed 135 fact-run headers while every identity the loader compares stayed byte-identical. The load concluded the run was already landed and skipped the correction.

What changes

Two digests, added to $defs.fact_artifact_header and $defs.fact_run (both properties and required), with three new supporting $defs and a top-level x-fact-identity block:

• observations_digest — sha256 over the observation rows. What was extracted.
• fact_run_digest — sha256 over the identity-recipe version, every non-volatile header field, and observations_digest. The run, and the dedup key.

Dedup fact runs on fact_run_digest. Equal means the held row is current, skip. Different means re-land, including when ingestion_run_id and the snapshot digests are unchanged — the case that broke. Comparing the pair separates a header-only correction (observations equal, run digest moved) from changed data (both moved).

The digest does not cover scored_at or the token/cost/cache counters. Those describe the occurrence, and a cache-warm replay of identical facts reports $0 and different token counts without being new data. The carve-out, the recipe, and the ordering tiebreak are published in the x-fact-identity block so both sides agree on exactly what the digest covers.

---

2. base_nachos_score — the base half of the NACHOS score

adjusted_nachos_score is already first-class in score_record_fields, but the base NACHOS score — the raw pre-adjustment methodology tier (0–3) — sat only inside the open dimensions block (dimensions.nachos_score.value). So the base half of the base/adjusted headline required a JSON dig while the adjusted half was a plain column. That's a contract miss for a core scored value.

Added to $defs.score_record_fields.properties as ["integer","null"], 0–3, mirroring complexity_score. The landing transform derives it from dimensions.nachos_score.value the same way documentation_gap is derived — no producer emit change, since the value is already emitted inside dimensions.

Distinct from complexity_score. nachos_score (pipeline src/poc3/score/rules.py, Phase F) is the NACHOS methodology tier that feeds adjusted_nachos_score; complexity_score is the business_logic_complexity comprehension-cost signal surfaced for the analyst's Complex Business Logic column. Same input facts, different rubric — they coincide on ~99% of rows but diverge where the methodology rules differ (e.g. tier_0_natural_key_format scores a state key-format to tier 0; tier_3_concatenation scores concatenation tier 3): 238 / 24,990 rows in release r-37334d4a830f060d.

---

Files

• docs/design/schemas/pipeline-records.schema.json — byte-identical to the pipeline's docs/contracts/pipeline-records.schema.json at nachos-ai-poc-3#346, plus base_nachos_score in score_record_fields.
• docs/design/Database-entity-details.md — the two fact_runs digest columns (+ a Fact-run identity section), and the new base_nachos_score row in the score_records field table.

Note on enforcement

The two copies of this schema aren't gated by CI on either side yet — MC-18 (the contract test) is still open, and the pipeline repo has no equivalent of its transport contract-drift job. So this sync is currently a manual discipline. A drift job on the pipeline side is filed as nachos-ai-poc-3#347; the base_nachos_score producer-copy update is nachos-ai-poc-3#349; MC-18 remains the landed-row half.