Coframe: A Column-Native Framework for Constructively-Correct Analytics¶

A position statement. This article describes what Coframe is, the problem it addresses, and the specific claims it makes — confined to claims that are defensible and stated at their true strength. It does not claim to have invented the conditions of correct aggregation, nor to supersede the semantic layer as a category. It situates Coframe against established work and states plainly what is borrowed, what is generalized, and what is new.

The problem¶

Analytical questions are answered, today, by composing operations over tables: choose tables, join on keys, filter, aggregate, project. The query author carries the correctness burden. Different join choices, filter placements, and grain decisions produce different results — sometimes silently wrong ones. Fanout from a one-to-many join double-counts a measure; summing a semi-additive measure (inventory, balances) across the wrong dimension produces a meaningless total; a pre-aggregated rollup table silently diverges from the detail it was derived from after an ETL change. The database engine does not prevent these; its guarantee is that the query as written executes per the operators' semantics, not that the result is what the business needed.

Semantic layers relocate part of this burden by defining metrics centrally and exposing them so consumers query named measures without writing the underlying SQL. This is a real improvement in consistency. It does not, by itself, provide structural guarantees: the correctness of cross-grain rollups, dimensional conformance, and pre-aggregate/detail coherence still depends on how the metric was defined and on data the layer does not verify.

As AI agents become primary consumers of analytical data, the cost of a plausible-but-wrong answer rises. An agent that emits SQL guesses at joins, grains, filters, and windows, and each guess can be wrong differently. The industry consensus, which Coframe shares, is that agents need a governed layer rather than freedom to guess. Coframe's contribution is a particular kind of governance: structural, verifiable, and architecturally distinct from the prevailing approach.

What Coframe is¶

Coframe is the Analytic Layer for analytical data — a peer to the Semantic Layer category (Looker, dbt MetricFlow, Cube, AtScale, Snowflake Semantic Views, Databricks Metric Views) but distinct in substance. Where the Semantic Layer centralizes what metrics mean, the Analytic Layer guarantees that derivations of those metrics are structurally correct, through declared structural commitments, verified integrity conditions, and a graded verification regime (A/AA/AAA). The two layers are complementary peers in a modern data stack, not competing implementations of the same concept.

Architecturally, Coframe is a column-native framework for answering analytical queries against a curated, structurally-committed collection of columns — an Analytic Collection (AC) — drawn from one or more backend tables.

The word "column-native" is meant precisely. The column — a name, an anchor (the coordinates its values are keyed by), and the values — is the only first-class object in the framework. Schemas and tables are emergent groupings of columns, not primitives: every schema-level property is derived from per-column declarations (ColumnSpecs). The query processing contains no table operation. It reduces to a small set of operations over individual columns:

deduplicate — when a column's anchor is coarser than a table's row grain;
reduce — apply an operator to a single column across an anchor;
fill-up — broadcast a coarser column's values across a finer grain;
collect — arrange aligned columns into the output.

Cross-schema combination is performed by aligning columns on their shared coordinates and collecting them — not by a join. There is no JOIN in the query model because there are no tables to join. A query is not a sequence of operations; it is a description of the desired output as a set of lightweight ColumnSpecs (a Frame — the shape of the output, independent of its data). An AC is, accordingly, a collection of columns, not a collection of tables.

What makes a collection of keyed columns tractable is that anchors are not arbitrary keys but positions in a shared coordinate space — dimension families organized by functional-dependency edges. This shared space is what makes columns commensurable and is the precise boundary of the framework's applicability: Coframe's guarantees hold to the extent that a shared coordinate space can be laid over the data. Relational and dimensional data carry that space essentially pre-built, which is why they are the framework's domain.

Two kinds of correctness, kept separate¶

Coframe is precise about a distinction the field often blurs.

Grammatical correctness. A constructed result is grammatically correct when it is what the query denotes under the rules of the grammar: the operator matches the operand type, the metric family resolves to a single source, the navigation path through the coordinate space is valid, and no fanout is possible. This is rule-based and mathematical. Once a query passes the rules, the constructed result is correct in the same sense a well-typed expression is correct — not approximately, not probably. Coframe's design makes incorrect queries inexpressible rather than merely flagged: there is no fanout because there is no join to express it; there is no cross-time sum of a time-blocked measure because the rules give it no legal form. This is the inverse of SQL's permissiveness — SQL has few structural rules, so the errors are legal; Coframe has many, so the errors are ungrammatical. The cost of this is real and acknowledged: more rules narrow the set of expressible queries. Coframe accepts that cost in exchange for the guarantee.

Integrity. A grammatically-correct construction still rests on premises about the data: that declared functional dependencies hold, that grain columns are unique, that a pre-aggregated table actually equals the rolled-up detail. Integrity is whether those premises hold. An integrity failure yields a correct construction over false premises — wrong data, not a wrong query. Coframe treats this as a separate discipline with its own process, and surfaces three ways a premise can earn trust: author assertion (declared and trusted), affirmation by processing code (the pipeline that produced the data provably computed it correctly), and data attestation (the premise is tested by aggregating the detail and comparing to the pre-aggregate). The three differ in strength and in cost.

A third sense of correctness — whether a result matches the user's intent — Coframe does not address. That bridge, from query to intent, is the proper work of a semantic layer. Coframe operates at the grammar layer: it matches operations to queries by rule. It is explicit that it does not interpret what a user means.

What Coframe claims, at true strength¶

Coframe makes the following claims and no stronger.

1. It removes the table and the join from the analytical stack. This is an architectural claim, and it is the central one. The benefit is not only that business users avoid writing joins (semantic layers offer that too) but that no table operation exists anywhere in construction — so whole classes of error (fanout, double-counting) are not caught but unexpressible. The cost is a deliberately narrow scope: operations that require referencing other rows of the assembled result — window analytics such as period-over-period comparison, ranking, running totals, and cumulative sums — fall outside the column-spec model and are not part of the core framework. (Some measures that superficially resemble these, such as share of a coarser total, are in fact expressible, because their companion value is a coordinate-cell aggregate reached by navigation rather than a computation across assembled rows; see claim 7.) Coframe states the window boundary as a category, not a defect, and does not claim to answer questions it cannot construct correctly.

2. It separates the operational-rules layer from the named-measure layer. Prevailing semantic layers fuse them: a metric is its operational definition. Coframe keeps aggregation rules at the structural layer, applied generically to any column that satisfies them, and leaves naming as a thin, customizable surface. Two consequences follow:

Open, query-time composition. Because the safety rules attach to a column's structure (its anchor and its identity-preserving reducer) rather than to a pre-blessed named metric, any column may participate in any grammatically-valid expression at the output grain. The composable surface is not limited to compositions someone declared in advance.
Cheap, contextual multiplicity. Because an AC is derived entirely from per-column declarations and is detached from physical tables, ACs are inexpensive, incremental, and scoped to purpose. An organization can build many ACs over the same backend — department-specific, project-specific, internal-facing, or agent-facing — in which a term like revenue may legitimately resolve to a different, individually-rigorous definition per context. This is a deliberate alternative to the "one canonical definition for the whole company" posture. It is the right choice when an organization's reality is many legitimate context-specific meanings rather than one negotiated meaning; it places on the organization the corresponding responsibility to reconcile those meanings where reconciliation is needed.

3. It provides trustworthy query acceleration. Coframe's construction algorithm (referred to internally as Multi-Table Invariance, MTI) enumerates the equivalent ways to construct a query's result — from detail, or from any verified pre-aggregated sibling, or across schemas — and selects an efficient one. Because the constructions are equivalent (given partition-invariant reducers and verified structure), any selection is correct, so selection is free to optimize. This is the soundness condition for serving a query from a materialized rollup instead of from detail — the established problem of answering queries using materialized views. Coframe pairs it with attestation: where aggregate-aware systems assume a rollup equals its detail and route to it for speed, Coframe verifies the equality and only then treats the rollup as a safe substitute. The result is acceleration with a correctness guarantee, rather than a trade of one for the other.

4. It generalizes semi-additivity. The additive / semi-additive / non-additive (holistic) taxonomy of measures is long established and Coframe claims no originality for it. Coframe's encoding — a per-measure block set naming the dimension families along which a reducer must not be applied — generalizes the established notion in two specific ways: it does not privilege the time dimension (the blocked directions are arbitrary dimension families, so non-temporal semi-additivity is handled by the same mechanism), and it applies to arbitrary monoidal reducers, not only additive ones (a block can constrain a sketch-merge or an extremal reducer that has no additive character). This generalization follows from treating aggregation algebraically: a reducer is partition-invariant when its value space, operator, and identity form a commutative monoid — a framing under which numeric sums and sketch merges (HyperLogLog, theta, t-digest) are the same kind of object, and the safe-direction constraint generalizes uniformly across them.

5. It operationalizes necessary conditions for correct aggregation that it did not invent. The integrity conditions Coframe verifies — grain uniqueness, functional-dependency validity, cross-schema value consistency, and pre-aggregate/detail coherence under the declared operator — are necessary for any correct analytical aggregation, regardless of the tool computing it. They are properties of the data and the question, not of Coframe. Coframe's contribution is to uncover them as a closed checklist derived from the structure, unify their checking under one model rather than scattering it across ad-hoc tests, and operationalize them into a standing, phased verification process that publishes a verification status the construction process consults. Because the checklist is derived from the column declarations, it is scoped to exactly the conditions the structure makes load-bearing for answerable queries.

6. It makes missingness a first-class column coordinate, enabling principled treatment selection. Each column carries, alongside its value-anchor, a missingness anchor — the set of coordinates on whose values its being-missing depends (the self-marker included, for value-dependent missingness). The familiar MCAR / MAR / MNAR classification is a derived, lossy summary of this set, which Coframe does not claim to have originated; the contribution is the placement. Because missingness is a per-column coordinate that travels through aggregation, the framework can select missing-value treatment as a joint function of the operator and of whether the missingness-determining coordinates survive into the output grain: when a rollup retains those coordinates, the mechanism is neutralized and skipping is unbiased; when it coarsens them away, skipping would bias the result. Coframe Core uses a single conservative rule — skip when an unbiased result is achievable, otherwise propagate (mark the result as carrying missingness) — and defers imputation and bias-tolerance, which require human judgment, to a Pro tier. This is a treatment-selection and honesty discipline, not statistical inference under missingness: the framework declines to silently return a skip-biased number, but it does not claim to correct for missingness. The contribution is that operator-and-measure-sensitive treatment, which is awkward to express when missingness lives only on the measure side or only on the operator side, falls out naturally when missingness is a coordinate the construction can reason over.

7. It makes the grain of a weighted average explicit, and refuses it when ambiguous. A weighted average depends on the grain at which the values and their weights are paired: the enrollment-weighted average of school-level test scores is not the enrollment-weighted average of district-level scores, because weighting does not commute with regrouping. This is well known in principle and almost universally left implicit in practice — in SQL the grain is whatever table the query happened to read, chosen silently by the FROM clause; in most tools it is whatever the engine found convenient. Two analysts can compute "the same" weighted average, with identical formulas, and get different numbers, with no error in anyone's arithmetic — the disagreement lives entirely in an unstated premise. Coframe makes the weighting grain a required part of the measure: when it is uniquely determined the framework infers it, and when it is ambiguous the framework refuses the measure and asks the author to declare the grain, rather than returning one of several possible answers. The result is a weighted average that is reproducible and defensible. The claim here is narrow and precise: Coframe does not assert that the industry computes weighted averages wrongly — for any given declared grain the arithmetic is right — but that leaving the grain implicit makes the result unverifiable and irreproducible across contexts, and that this, like the join and the rollup, is a silent premise the framework converts into a stated, checkable one. (The same treatment extends to related measures whose value depends on a second grain — shares of a coarser total, indices to a base — though weighted average is the sharpest case.)

What this enables: substrate for the analytical-agent layer¶

The seven claims above describe what Coframe is. This section describes what its structure enables — specifically, a class of AI-powered analytical work that has been structurally blocked on existing substrates and is unblocked by the substrate Coframe provides.

The pattern is recognizable from adjacent AI deployments. Each wave of useful AI work has, on inspection, depended on a substrate suitable for LLM composition. The conversational-agent wave of 2022–23 used text — the LLM's native medium — and had no substrate dependency beyond the conversation itself; cultural impact was wide and commercial transformation narrow. The coding-agent wave that followed depended on a richer substrate that had been built over decades for other reasons: a file system, version control, a process model, a language server protocol, a small set of well-defined operations (read, edit, run, search). The agents arrived to make use of that substrate; productivity gains, revenue, and category-defining companies followed.

The analytical-agent equivalent has, until now, lacked a comparable substrate. SQL is too open-ended for an LLM to compose safely — the cost of a wrong join or a subtly-wrong rollup is silent and serious, and the database engine offers no constructive check. Semantic layers are too rigid — their named-metric catalogs constrain the LLM to a fixed list of compositions that have to be defined in advance, and questions outside the list cannot be answered without bypassing the layer (and re-introducing SQL's correctness problem). Text-to-SQL approaches have made the surface easier to address without making the answers more trustworthy. The substrate prerequisite for an analytical agent — bounded enough to enumerate, structured enough to refuse wrong answers, expressive enough to compose new ones — has not been available.

This is what Coframe's structure supplies. The AC is bounded: the analytical universe is enumerable as a finite set of dimension families, metric families, anchors, reducers, and their derived variants. The resolver refuses dubious queries, so structurally-wrong constructions are caught at construction time rather than deferred to result inspection. The verification levels (A / AA / AAA) signal where trust is grounded in data attestation versus carried as an unverified premise, so an agent's answer can carry its epistemic posture, not just its numeric value. Composition over the substrate is open-ended at query time (claim 2) yet bounded at the structural level (claim 1), giving an LLM both the freedom to construct new analyses and the structural rails to construct only correct ones. The result is the first analytical substrate suitable, in the sense the coding-agent substrate has been suitable, for an LLM-driven harness above it.

A harness built on this substrate — Coframe terms it the AC Analyst — stands to do for analytical work what coding harnesses have done for software engineering. The architectural pattern is recognizable: a small, deliberate tool surface (introspect families, profile columns, propose queries, execute, narrate); structurally-bounded reasoning (the AC's grammar limits what can be expressed, the resolver enforces what is well-formed, the verification regime grounds trust); observable, reproducible operation (every Frame the agent returns carries the Frame-QL that produced it and the verification level the result inherits); refusal in place of guessing (dubious queries are surfaced as structured errors the agent reacts to rather than smoothed over). The substrate makes the harness possible; the harness makes the substrate accessible to consumers who would not otherwise query it directly. The pairing — Coframe's substrate plus a high-quality analyst harness above it — is what allows analytical work to move from "answer pre-defined questions on a dashboard" to "engage with a domain-aware analytical partner that helps the user form the right question and then constructs it correctly." Coframe's reference implementation of this harness ships as part of the framework; Chapter 12 of the Coframe Core manual specifies its surface (thirteen tools, four-tier context model, the bounded turn loop, the ANALYST.md author memo, the deterministic eval framework).

The claim here is appropriately narrow. Coframe does not assert that the analytical-agent transition is imminent, inevitable, or that it will accrue to any particular vendor. Claims about adoption rates, market timing, and competitive dynamics are strategic and belong in their own discussion. The position-level claim is structural: if an analytical-agent layer comes to occupy the role for analytical work that coding-agent harnesses now occupy for software engineering, a substrate with Coframe's properties is the prerequisite the agents will need to be trustworthy at scale. The same design choices that make Coframe's queries verifiably correct for human authors are the choices that make them composable, refuse-able, and trustworthy for LLM authors. The structural fit is not incidental; it is the inverse of the silent-premise problem the framework was built to address.

What Coframe does not claim¶

In the interest of stating its position truthfully, Coframe disclaims the following:

It does not claim to have invented additivity, semi-additivity, summarizability, or the conditions of correct aggregation. These are established in the data-warehousing literature and practice; Coframe builds on them.
It does not claim that "queries against a model rather than tables" or "do not let the system guess" are original to it. These are shared with the semantic-layer category, which has converged on the same motivations.
It does not claim to replace the semantic layer or to be a generalization of it. Coframe is a peer category — the Analytic Layer — answering a different question (is the derivation structurally correct?) than the semantic layer answers (what does the metric mean?). The two coexist in a modern data stack as complementary layers, not as competing implementations of the same layer. Where Coframe differs internally from semantic layers is in keeping structural rules separate from naming rather than fusing them into a metric — a decomposition that pays out as the open, query-time composition described in claim 2.
It does not claim to address intentional correctness (result-matches-user-meaning); that is the semantic layer's role.
It does not claim to answer analytical questions that require operating across rows of the assembled result — genuine window analytics such as ranking, period-over-period comparison, running totals, and cumulative sums; these are outside its core scope by construction. (Measures whose companion is a coordinate-cell aggregate, such as share-of-total and weighted average, are within scope — see claim 7.)
It does not, in its current form, claim a solved treatment of time-varying dimensions (slowly-changing dimensions, reorganizations, bitemporality), which remain the most demanding case for any framework whose guarantees rest on functional dependencies.

Relationship to established work¶

Coframe sits in a lineage it acknowledges:

The summarizability literature (Lenz and Shoshani, and successors) characterizes when an aggregate can be correctly computed from a coarser level. Coframe operationalizes the checking of these conditions against a live warehouse.
The aggregable-properties line of work (Simon, Amann, Liu, Gancarski) governs aggregation correctness by per-attribute properties describing which operators may aggregate an attribute along which dimensions, and uses them to refuse incorrect queries. Coframe's per-column block sets are in this family; what Coframe adds is the table-free, column-native query model, the generalization to arbitrary reducers, and the embedding in a construction algorithm rather than a query checker.
Aggregate awareness (Looker, Cube, Holistics) routes queries to pre-aggregated tables for performance. Coframe adds the verification these systems omit: it attests that the rollup equals the detail before treating it as a safe substitute.
Materialized-view query rewriting is the established problem whose soundness condition Coframe's construction algorithm instantiates.
The missing-data literature (Rubin's MCAR / MAR / MNAR classification, 1976; Little and Rubin) supplies the vocabulary for missingness mechanisms. Coframe does not originate the taxonomy; it treats missingness as a per-column coordinate and uses the rollup's effect on that coordinate to select a principled treatment, rather than performing statistical inference under missingness.
The contemporary semantic-layer ecosystem (the dbt Semantic Layer / MetricFlow, Cube, AtScale, Snowflake Semantic Views, Databricks Metric Views) and the Open Semantic Interchange initiative share Coframe's governance motivation and pursue interoperable, define-once metric definitions. Coframe differs in decomposition (grammar plus thin naming) and in posture (contextual multiplicity rather than canonical singularity), and can be positioned as a verification-and-acceleration complement to these rather than a replacement.

Summary¶

Coframe is a column-native analytics framework that (1) removes the table and the join from the query model, making whole classes of aggregation error inexpressible rather than merely detectable; (2) separates grammatical correctness, which it guarantees by rule, from data integrity, which it verifies as a distinct discipline with three warrant levels; (3) provides query acceleration that is provably safe by pairing equivalence-based plan construction with attestation of pre-aggregate/detail coherence; (4) generalizes semi-additivity to arbitrary monoidal reducers over arbitrary dimension families; and (5) operationalizes the necessary conditions of correct aggregation — conditions it surfaces and unifies but does not claim to have invented.

These same structural properties have a forward-looking consequence: they constitute the substrate prerequisite an LLM-driven analytical harness needs to be trustworthy. The boundedness, refusal of dubious constructions, and verification-level inheritance that make Coframe's queries verifiable for human authors are what make them composable and trustworthy for an LLM analyst-on-top. The substrate makes the analytical-agent layer possible in a way the open-ended SQL substrate and the rigid named-metric substrate have not.

Its scope is deliberately bounded: it addresses the grammar layer, not user intent; it constructs frame-shaped output from a shared coordinate space, not arbitrary analytics over arbitrary data; and it leaves window analytics and time-varying dimensions to other layers or to future work. Within that scope, its contribution is architectural and integrative rather than theoretical: a different, disciplined decomposition of the analytical stack that buys correctness guarantees, trustworthy acceleration, and structural fitness for the analytical-agent layer as consequences of its design.