[Aschenbath]

Why

Exploration currently creates Metric/Dimension entities and proposes aggregate SQL even though a schema does not contain the business definitions. #554 and ADR 0036 instead ask which class a table represents, which class owns each column, and how a stored value becomes an attribute value.

What changes

• Exploration records one complete table proposal, including new vocabulary, existing property bindings, conversions and explicit exclusions. It creates no ontology or graph rows. The existing expression compiler turns column text into trees before saving.
• A versioned whole-table decision rechecks the schema and ontology. Declarations, table/column bindings, queued alignment work and the decision commit together. Re-exploration preserves human decisions; stale reviews and the old status-only endpoint cannot bypass adoption.
• Per-conversion input bindings let different flattened owners reuse an attribute without confusing their raw columns. Vocabulary used by an adopted alignment is protected from deletion; unmounting removes its active bindings.
• Data mapping gains an English/Chinese table review surface. The wide truth file and mappings.mjs --alignments score table classes, column ownership, relation roles and exclusions. Manual SQL definitions remain available; rendering definitions and retiring the legacy classes stay with Metric and Dimension retire, and a mapping is rendered from an alignment and a rule #556.

Migration 0108 leaves 0107 available for the reserved #1097 work; the CLI schema count is 98. The proposal origin is exploration, keeping schema proposals out of the question agent's outcome statistics.

How it was checked

• Formatting, all-target Clippy, workspace build and workspace tests passed: 1,481 tests passed, 6 existing opt-in tests ignored. PostgreSQL/pgvector was migrated first, with UTOPIA_TEST_REQUIRE_DB=1 and UTOPIA_TEST_REQUIRE_PDFTOTEXT=1.
• Five database integration tests exercise a scripted model with the real schema reader, cold start, actual expression evaluation, a failed final write rolling everything back, duplicate decisions, stale versions, rejected proposals, unmounting, schema drift and separate raw bindings for a reused attribute. The adoption fixture uses a one-connection pool.
• Frontend build/style/type checks and 235 tests passed; the structural scorer's Node test passed.
• Chromium with synthetic API responses: English and Chinese layout, viewer controls, failed-decision retention, and successful adoption sending the proposal version and removing it from Pending.

Draft for live-model acceptance: the wide corpus has not been run against a real model here. The scripted tests prove the write path, not vocabulary quality or conversion accuracy. The structural scorer uses explicit key alternatives and needs human interpretation for other valid vocabulary. Source DDL is checked before adoption but is not locked across the external database. Editing/reopening a decided alignment, SQL rendering and executing aligned rules are outside this cut.

Refs #554; implements the table-alignment portion of ADR 0036.

Before review

• Every commit is signed off
• Formatting, Clippy and workspace tests pass
• Frontend build and tests pass
• Store SQL was exercised against PostgreSQL
• Migration number and CLI schema count checked
• UI strings are in both languages
• Contract and implementation are documented in ADR 0036

[WaylandYang]

Thank you for this. It follows #554 closely and the write path is sound: one proposal per table, adoption in one transaction with the version check and the schema re-read, and class and property creation made transactional along the way.

We ran the wide corpus against a real model (deepseek-v4-flash, thinking off, empty ontology, a new base each run), which the description says is still missing:

• As submitted, 4 runs: 0 of 14 each time. The model returned both tables and both were dropped, e.g. Invalid signature for shop_name. The prompt never names the allowed datatypes, so the model writes string, integer, boolean, datetime.
• With one sentence added listing text, number, date, bool, 5 runs: still 0 of 14. The six-column dw.dim_shop was accepted in 3 of them. The 55-column dw.dwd_ord_dtl, the table the truth file scores, was dropped every time, each time for one different flaw: an undeclared property (id, shop_id), an omitted or omitted_reason field written inside a column item, an expression outside the supported forms.

So before review:

1. A table should survive one flawed line. One bad item among fifty columns loses the whole table. Please repair what can be repaired, or return the errors to the model once and ask again. All-or-nothing belongs to the person's adoption, not to parsing.
2. Record every drop reason. The run keeps one example per reason and not the reply, so we had to replay the prompt by hand to find the first cause.
3. Run mappings.mjs --fresh --corpus wide --alignments with a real model, several times, and put the numbers in the description.

For the review after that: make the new foreign keys (kb_id, id) and register them in the export integrity check as #1178 did; enqueue through the store's job function; fold the scorer's test into lib.test.mjs, the only script test CI runs; keep migration 0108 here and move #1131 to 0110.

One more thing. Once this lands, nothing reads an adopted alignment until #556. Would you like to take #556 next? If not, we will do it ourselves, so please say either way. #1131 is also still waiting on the split.

Thanks again for the work on this.