Ford's entity layer — data-structure plan

The data types and structures underneath "the engine that gets smarter every time we send it something" (Shawn, 8/4 call). Written 2026-08-10 against Ford's migrations 0001–0039 and the live Data Engine spine (SPINE-SCHEMA.md, shipped 2026-08-08). One-page visual: ford-entity-layer.html.

What changed since the 8/4 call

The question this initiative was circling — where does "the Bessemer report characterized this company as X" live? — got answered by the Data Engine build. The spine is live in the Webster database: a fleet mention store (doc X mentions entity Y, with passage, page locator, as-of, extractor, confidence), a typed tag vocabulary with a per-app crosswalk, relationship edges, entity/merge proposals, and people as first-class registry entities. Terminal and Podcast already post to it (merged, flags off).

So the answer to "data structures within Ford" is mostly not new Ford tables. It is wiring Ford to the engine, plus two small local pieces. A Ford-local assertion ledger, alias table, or people table would rebuild organs the engine now owns — one per app is exactly the disease the engine was built to cure.

The imbalance in Ford (still real)

Ford's document side has structural provenance — datapoints cannot exist without a source artifact and page; conflicting readings stay visible; portfolio rows keep verbatim receipts. Ford's entity side has none of it: atlas.companies is one flat row of last-write-wins scalars. No characterization survives with its source, "Acme" and "Acme Inc" coexist, public and private companies are indistinguishable, and the bridge's registry_id is still a hardcoded null.

The plan — four pieces, in order

1. registry_id — resolve Ford's companies against the registry

Add one nullable, indexed uuid to atlas.companies — the exact field the bridge contract already promises ("populated when Webster's resolve API lands; nothing else changes"). The resolve API is now live, so this is a column + a backfill, not speculation:

• Resolved companies link to their spine entity; unresolved names flow into the engine's entity_proposals queue (propose-then-approve, as designed).
• Ford's duplicate rows surface as engine merge proposals instead of needing a Ford-local alias table. If matcher precision still hurts after resolve lands, a local alias cache is a follow-up, not a foundation.
• Ford already holds engine credentials (the /admin/engine proxy shipped in atlas #59), so connectivity exists today.

2. Ford becomes a spine writer — the Bessemer ask, delivered

Ford's ingest already extracts everything needed: artifact_companies mentions with pages, market-map company grids (0039), newsletter stories (0035), free-text sectors. The adapter posts, per ingested document:

• Mentions → webster.mentions — company/person, verbatim passage, {page: n} locator, the document's date as as_of, versioned extractor.
• Characterizations → webster.tag_assignments — on the doc and on the entity, with salience + confidence. "Bessemer put this company under vertical AI · insurance ops, p. 14" is one tag assignment with provenance; every future report stacks another reading onto the same entity.
• Free-text sectors ride the crosswalk: alias what matches, queue the rest as vocabulary proposals — this is precisely the one question already gating the engine work in NOW.md, and Ford inherits whichever answer Shawn gives there.

Same shape as Terminal #68 / Podcast #46: merged behind a SPINE_WRITE flag defaulting off. This is Phase 2 "Ford adapters" of the Future AI plan, already anticipated by the engine brief.

3. listing_status — private vs public (Ford-local, legitimately)

• listing_status on atlas.companies — private | public | acquired | dissolved, default private — plus ticker, exchange.
• Computed by code, never asserted by a model (fleet rule 2): the transitions come from ipo_listings — which finally gets a real join back to the registry row — and filings. A report claiming a company went public lands as a spine mention; the flag flips only on code-verified evidence.
• Gives ingest the private/public split from the 8/4 call and the Companies registry a private-only filter. This one stays local because it is Ford's research-room view, not fleet identity.

4. People — feed the registry, don't build a rival

No Ford people table. firm_people rows (name, role, bio, roster status — already harvested per research pass) become input to the engine's people extraction, which is already item 4 on the engine's own next-list. Ford displays people through the engine, the way /admin/engine already reads queue data through the session-gated proxy.

What stays thin on purpose

• Company-vs-LP classification. Ford's audience mechanism (five fixed values, deterministic assignment) already separates lp-research from companies-bd and stays as-is. Linking an LP letter to the actual LP entity is engine work (LP Flow wiring is Phase 2 item 3), not Ford schema.
• Taxonomy design. No new ontology anywhere. The engine's controlled vocabulary + crosswalk is the fleet taxonomy; Ford's curated sectors tree remains its local view; external taxonomies inform both through tag assignments, never by overwriting.
• The curated row. Assertions and tags never write into atlas.companies scalars. Layer, never merge — the fleet's rule between apps, applied inside Ford.

Sequencing

All Ford migrations: additive, PR'd, DB changes route to Shawn by fleet rule 6. M1 and M2 need a spine write token for Ford set in its deploy env.

Open with Shawn

1. Green-light M1 (registry_id + resolve backfill) — smallest step, unlocks everything else.
2. The vocabulary call already gating the engine (alias-what-matches vs auto-create) — Ford's free-text sectors inherit the same answer.
3. Michael's access to SKO70SV/slw-webster (and slw-ford, slw-dewey) — required for the engine-side people work; not required for M1–M3, which are Ford-app-only.