Once a table is aligned and a definition is a rule, Metric and Dimension have no work left, and concept_mappings has a new source. 0035 decisions 4 and 5.
The two classes retire
ensure_concept_types goes. They were admitted by #231 to stop exploration from silently producing nothing; the record's revision note on 0009 says why that fixed the symptom and kept the mistake. No exploration inserts a class without a proposal.
Existing bases have entities of these classes — twelve real concepts and twenty-eight column names on the wide bench base. The column names are #553's leftovers and go with it. The concepts become what they are under the record: an attribute of a real class, or a rule.
A definition is a rule, and a shared convention is one rule others read
GMV is sum(Order.paid_amount) where Order.is_valid. Order.is_valid ← status ∈ {paid, shipped, done} ∧ ¬is_test is written once and read by GMV, net sales, order count, refund rate (0030). This is where "test orders don't count" lives — a condition on an attribute, with a name, changed in one place. On the wide corpus the absence of that one sentence moved chat from 17 of 18 right answers to 1 of 18 (#520).
The unit lives on the attribute (relation_types.unit), the conversion on the alignment (#555). 0032 noted nothing checks units when an expression is written; this gives units a place to come from.
concept_mappings is rendered, not dropped
Its status, revisions, audit stream and page (0011 §2–3) are the review flow this still needs, and the benches (#501, #520) read it and score it as they do today. What changes is where a row comes from: rendered from a rule, the table it aligns to (#554), the column expressions and the source's dialect, into the sql column it has now. A rendered row names the rule it came from; a hand-edited one does not, and the two stay distinguishable. #552 (bulk confirm, external) touches the page only and is unaffected.
derived (0011 §1) was for "conversion rate = orders / visits"; under the record that is a rule reading two rules and the flag has no meaning. Kept until rendering exists, dropped with the consolidating migration.
Not in this issue
Where a rule over aligned attributes executes. 0032 refused aggregation on the graph because the graph is open-world; a database table is closed-world, so sum(Order.paid_amount) is honest there — but that is another executor. Rendering a row for chat to use does not need it. Building it is the record's largest open question and gets its own issue when it is time.
Once a table is aligned and a definition is a rule,
MetricandDimensionhave no work left, andconcept_mappingshas a new source. 0035 decisions 4 and 5.The two classes retire
ensure_concept_typesgoes. They were admitted by #231 to stop exploration from silently producing nothing; the record's revision note on 0009 says why that fixed the symptom and kept the mistake. No exploration inserts a class without a proposal.Existing bases have entities of these classes — twelve real concepts and twenty-eight column names on the wide bench base. The column names are #553's leftovers and go with it. The concepts become what they are under the record: an attribute of a real class, or a rule.
A definition is a rule, and a shared convention is one rule others read
GMV is
sum(Order.paid_amount) where Order.is_valid.Order.is_valid ← status ∈ {paid, shipped, done} ∧ ¬is_testis written once and read by GMV, net sales, order count, refund rate (0030). This is where "test orders don't count" lives — a condition on an attribute, with a name, changed in one place. On the wide corpus the absence of that one sentence moved chat from 17 of 18 right answers to 1 of 18 (#520).The unit lives on the attribute (
relation_types.unit), the conversion on the alignment (#555). 0032 noted nothing checks units when an expression is written; this gives units a place to come from.concept_mappingsis rendered, not droppedIts status, revisions, audit stream and page (0011 §2–3) are the review flow this still needs, and the benches (#501, #520) read it and score it as they do today. What changes is where a row comes from: rendered from a rule, the table it aligns to (#554), the column expressions and the source's dialect, into the
sqlcolumn it has now. A rendered row names the rule it came from; a hand-edited one does not, and the two stay distinguishable. #552 (bulk confirm, external) touches the page only and is unaffected.derived(0011 §1) was for "conversion rate = orders / visits"; under the record that is a rule reading two rules and the flag has no meaning. Kept until rendering exists, dropped with the consolidating migration.Not in this issue
Where a rule over aligned attributes executes. 0032 refused aggregation on the graph because the graph is open-world; a database table is closed-world, so
sum(Order.paid_amount)is honest there — but that is another executor. Rendering a row for chat to use does not need it. Building it is the record's largest open question and gets its own issue when it is time.