[GabeBolton]

Follows the #81 restructure, so the design record stops contradicting the issues.

I had written that the analysis pipeline's highest-value output is a diff rather than an inventory. That is half right, and the wrong half matters.

The diff is the right reviewer-facing output. But computing it in the scanner would mean two things I do not want:

• Giving a component that holds model API keys and source-code access read rights on the compliance database.
• Making any change to the fingerprint definition a re-scan of every codebase, rather than a re-derivation over data already held.

So the scanner emits raw attributes — column name, type, question text, source location — and the register derives the fingerprint and computes the diff. The scanner stays dumber and more stable, which matters most for the component that will be iterated on constantly early on.

Also recorded: a definition change is a mass re-review event

Widen the fingerprint definition and every field's fingerprint moves at once, so every inherited assessment lands in the "changed" branch — thousands of records demanding human review because someone added a field to a tuple.

The definition is therefore versioned, and the version that produced each stored fingerprint is recorded, so the register can distinguish "these diverged because the definition changed" from "these diverged because the data did". Without that, the first definition change reads as a compliance emergency.

Issues restructured to match

• Assessment reuse: derive fingerprints, compare, and gate on the diff #81 narrowed to comparison and the gate, retitled
• Ingest suggestions from the analysis pipeline #69 payload settled as raw attributes rather than a computed fingerprint
• Export the producer contract, derived from config #68 contract gains the required attributes and the definition version
• Static-analysis pipeline (separate repository) #71 narrowed, and my earlier framing corrected there

🤖 Generated with Claude Code