Coframe Naming Discussion¶

A verbatim record of the chat exchange exploring the naming of Coframe, Coframe-jr, the editions structure, the domain question, and the broader family-of-frameworks vision.

Participants: HW (project lead), CL (Claude).

Turn 1 — HW asks for an evaluation of the Coframe / Coframe-jr naming¶

Now, can you think about the naming of Coframe and Coframe-jr (by the way, jr and not Jr). Given your understanding of the architectural vision of Coframe as a full-stack Analytical Data Platform, and framework design and future commercial perspective, the connection with potential industry standard for algebraic data processing, the etimology of Coframe (Column-Operation-Frame), please evaluate the naming choice -- as we still have time before we settle on it.

Turn 2 — CL evaluates the naming¶

This is the right time to think hard about this. Let me work through it as honestly as I can — both what works about the name and what doesn't, then what alternatives might be stronger and what the considerations are for choosing.

What "Coframe" is doing right now¶

Let me first acknowledge what the name has going for it, because the answer isn't "rename" — it's "evaluate carefully."

The etymology has substance. Column–Operation–Frame is a real semantic compression: column-level governance is the framework's central commitment, operations (the operator catalog) are the structural substrate, frames are the query unit. The name encodes the architecture's primitives. That's more than most product names do.

It's distinctive. "Coframe" doesn't collide with prominent existing things in the analytical data space. It's googleable; it's pronounceable; it's a single word; it's six characters. Mechanical naming criteria pass.

The "co-" prefix is generative. Co-frame, co-author, co-operate, co-locate. The prefix carries collaborative and structural connotations that fit a tool meant to bridge engineers, analysts, and AI agents.

It's one word and one syllable cluster. Compare to "MetricFlow" or "Cube.dev" or "AtScale" — Coframe is shorter and more compact. That matters for command-line tools, package names, and conversation.

The Frame-QL naming carries cleanly. "Frame query language" rolls off the tongue once you've internalized "frame." If the product had been called "Manifold" or "Stratum," the query language naming would be awkward.

What's working less well¶

Now the harder side. Several issues are worth surfacing.

The etymology is private. Column–Operation–Frame is not what anyone reading the name will infer. They'll guess "co-frame" (collaborative frame), or they'll guess at "frame" without the co-. The C-O-F decomposition is invisible. This isn't fatal — most product names have private etymologies — but it means the name carries no semantic load to a new reader. The name doesn't teach anything. Compare:

"dbt" → data build tool. Tells you what it is.
"Looker" → looking at data. Tells you what it does.
"Snowflake" → metaphor; opaque but memorable.
"Cube" → OLAP cube association; teaches by analogy.
"Apache Arrow" → arrow as in directional/fast; metaphor.
"Coframe" → ?

For a tool whose central thesis is precisely about column-level structural governance, the name burying that connection feels like a missed opportunity.

The mathematical "coframe" already exists, and the connotation is wrong. This is the issue I'd push hardest on. In differential geometry, a coframe (or coframe field) is a dual basis to a frame field — a set of one-forms that diagonalize against tangent vectors. It's a real, well-defined mathematical object. Practitioners coming from physics, ML theory, or mathematical CS will recognize the term and have an existing mental model attached to it.

The problem: that existing mental model isn't what your framework is doing. A geometric coframe is about measuring a tangent space; your Coframe is about organizing analytical structure. The metaphors don't align. A reader with mathematical background will either be confused (expecting differential-geometric content) or will think the name is a stretch. A reader without that background gets nothing from the connection.

There's also a search/SEO consideration: "coframe" returns differential-geometry results today. Establishing your project against an existing technical term is harder than establishing it against an empty one.

"Coframe-jr" has aesthetic problems specifically. I want to address this directly because you flagged it. The lowercase-jr-with-hyphen pattern (vs. Jr. or JR or junior) is unusual in software product naming. The closest pattern I can think of is academic author names ("Smith Jr."), where the convention is title-cased with a period. Lowercase "jr" without period reads as either a typo or an affected stylization. It will be miscapitalized constantly. It will be auto-corrected. It will produce "coframe-jr" / "Coframe-Jr" / "Coframe-JR" / "Coframe Jr" / "Coframe junior" inconsistencies in third-party writing about the project, and you'll spend years fighting them.

More substantively: "Junior" framing implies a less mature version of the same thing. That's exactly not what Coframe-jr is — it's a focused version, a first-step version, an open-source version. The name suggests "not the real one yet," which undercuts adoption. Engineers evaluating tools for production use will hesitate at "the junior version." The technical reality is that Coframe-jr has the full grammar-layer thesis with a smaller surface area; the name connotes immaturity rather than focus. That's a substantive marketing problem, not a minor one.

The Jr/full split has commercial confusion built in. Beyond the aesthetic issue, the dual naming creates an ongoing communication tax. Every piece of writing about the project has to clarify whether it's discussing Jr, full, or both. "Coframe" by itself is ambiguous — is it the framework as a whole, or just the full version? The manual handles this by carefully saying "Coframe (the full version)" but that's a long phrase to repeat. People reading shortcuts will collapse the distinction and conflate the two.

A cleaner pattern in commercial open-source software is one project name, two distribution editions: Postgres + Postgres Enterprise; Elasticsearch + Elastic Cloud; Redis + Redis Enterprise; GitLab Community Edition + GitLab Enterprise Edition. The base product has one name; the commercial extension has a qualifier. "Coframe" + "Coframe Pro" or "Coframe" + "Coframe Enterprise" reads more cleanly than "Coframe-jr" + "Coframe."

The standards-aspiration adds a constraint the name should serve. If the framework is going to define an industry-recognizable verification regime — the levels conversation we just had — the name needs to work as a standard's reference. "Coframe Verification Levels" or "Coframe Level AAA" or "Coframe Conformance" need to read right. Coframe works fine for this — it's compact and adjective-able. Coframe-jr conformance doesn't — the "-jr" undermines the gravitas. If you anticipate the verification regime traveling beyond the product, the base name carries that weight; the Jr name doesn't.

What name-design considerations apply¶

Let me lay out the criteria a stronger name would need to satisfy, before suggesting alternatives.

Teaches something. The best technical product names carry semantic load — even private/metaphorical load — that helps someone remember what the thing does. "dbt" / "Snowflake" / "Apache Spark" all do this differently. "Coframe" mostly doesn't.

Doesn't fight existing terminology. Avoiding collision with established mathematical or technical terms reduces friction. The differential-geometry coframe is real and unrelated.

Travels well across registers. The name needs to work in: a manual (formal), a README (informal), a marketing deck (commercial), a research paper (academic if you ever write one), a regulatory filing (bureaucratic), a Slack message (casual), a CLI command (terse). "Coframe" mostly travels; "Coframe-jr" travels poorly in formal/academic registers.

Works as adjective and noun. "A Coframe AC" / "the Coframe verification regime" / "Coframe-conformant" / "Coframe Level AAA" — yes, this works. Single-word names usually adjective cleanly.

Decomposes into a product family. The name plus a qualifier should read naturally for editions, modules, certifications, levels. "Coframe Core" / "Coframe Enterprise" / "Coframe Cloud" / "Coframe Verified" — yes, mostly works.

Encodes the central thesis. The framework's thesis is grammar-layer separation, column-level governance, and structural verification. A name that even hints at one of these is doing more work than a name that's purely decorative.

Alternatives worth considering¶

Let me think aloud about candidate names with real tradeoffs. I'm not advocating any of these — I'm stress-testing the space.

Names that lean on the column-level governance thesis.

Columnar — too generic; collides with columnar storage formats. Colspec — too on-the-nose; reads as a technical spec rather than a framework. Column (alone) — too generic to claim. Anchor — captures the entity-anchoring principle (E in the (E,M) declaration). One word. Distinctive. Carries a "ground-truth, stable" connotation that fits the structural-rigor posture. Possible collision with Anchor modeling (a niche data-modeling approach) — worth checking. As a name for the standards regime ("Anchor Conformance Level AAA"), it reads well. Anchored — past-participle form. Less common as a product name but distinctive.

Names that lean on the grammar-layer thesis.

Grammar — too generic; not claimable. Syntax — collides with too many things. Lattice — captures FD-DAG / partial-order structure. One word. Mathematical resonance (lattice theory). Used elsewhere (Lattice the HR product) but in a different domain. Reads well in standards: "Lattice Level AAA." The concept-fit is decent: an analytical model is structurally a lattice of dimensions and metrics, with the FD-DAG providing the partial order. Stratum — captures layered/grain-structured analytical data. Single word. Distinctive. "Stratum AC" / "Stratum-conformant" / "Stratum Level AAA" all read well. Slightly esoteric but in a way that's defensible. Substrate — your own word from the article ("a grammar-layer substrate"). Has the right connotation. Used elsewhere generically. Probably not a product name on its own.

Names that lean on the verification/structural-rigor posture.

Attest — verb form; captures the verification-as-foundation. "Attest Framework" / "Attest Level AAA." Distinctive. Possibly too specific (might not generalize beyond verification). Verified / Verifier — too generic. Coherent / Coherence — captures the cross-schema metric coherence theme. Possibly too thematic.

Names that lean on the family/genealogy vocabulary.

Genealogy — too long, too on-the-nose. Lineage — collides with data lineage tooling. Genus — biological-taxonomy resonance with the family vocabulary. Distinctive. Latin-rooted feels academic. "Genus Level AAA" is unusual but memorable.

Names that compress more than one of these.

Quanta — "discrete units of analytical observation." Distinctive. Possibly too generic. Sema — short for semantic but with deliberate distance from "semantic layer" terminology. Distinctive. Probably too short; might collide with too many things. Axiom — captures the principles-based foundation. "Axiom Framework" / "Axiom Conformance Level AAA." Strong gravitas. Possibly oversells (the framework is principle-based, not axiomatic in the Hilbert sense, and a critic might needle that). Used elsewhere. Schema — too generic; cannot be claimed.

Composite or invented names.

Coframe itself was an invented compression. Other inventable patterns: combine a substantive root (anchor, stratum, lattice, axiom) with a structural prefix or suffix. Anchorframe, Stratumql, Latticesem. Most of these read as awkward portmanteaux. Inventing names is hard; inheriting recognized roots is usually cleaner.

The Jr/full naming specifically¶

Let me address this independently because it's a separable problem from the base-name question.

If you keep "Coframe" as the base, the cleanest editions naming would be one of:

Coframe (base, open-source) + Coframe Pro (commercial). "Pro" is widely understood, doesn't connote immaturity, doesn't require explanation. Mechanical and slightly tired but it works.

Coframe Core (open-source) + Coframe Enterprise (commercial). This is the GitLab/Elastic pattern. "Core" is positive — it's the foundational piece — and "Enterprise" tells the buyer who the commercial edition is for. Reads well in technical docs.

Coframe Open (open-source) + Coframe (commercial, shorter name). Inverted pattern: the unqualified name is the commercial one; the qualified name is the open source. This is the Elastic / Confluent pattern roughly. Defensible if you expect the commercial product to be the dominant brand. Risky if the open-source community feels like a second-class citizen of its own project.

Coframe Foundation (open-source) + Coframe Platform (commercial). Foundation/Platform is a clean architectural metaphor — the foundation supports the platform. Less familiar than Core/Enterprise but technically expressive.

I'd push hardest against keeping "Coframe-jr" specifically. The hyphen-lowercase-jr formatting is fragile, the "junior" connotation undermines adoption, and the convention is unusual enough that most third-party writing will get it wrong. Whatever the base name turns out to be, the qualifier should be a recognizable software-product convention.

Three options, in increasing order of disruption:

Option 1: Keep "Coframe," fix the Jr naming.

This is the lowest-effort path. "Coframe" the project name; "Coframe Core" (or "Coframe OSS") for the open-source edition; "Coframe Pro" or "Coframe Enterprise" for the commercial edition. The base name's etymology (Column-Operation-Frame) is preserved. The geometric-coframe collision and the doesn't-teach-anything concerns remain — but they're survivable, and many successful products live with similar naming friction.

Specific things this fixes immediately: the lowercase-jr pattern issue; the "junior implies immature" connotation; the pluralization confusion in writing about the project. It does not fix the deeper "Coframe doesn't teach what it is" issue, but that's a tradeoff against the cost of a full rename.

Option 2: Keep "Coframe," but treat it as a transitional name and watch the field.

Plan to revisit naming at v1.0 release based on adoption signals. If practitioners are using "Coframe" naturally and the geometric-coframe collision hasn't surfaced as a real problem, ratify the name. If you find yourselves in conversations that keep needing to explain "no, it's not the differential geometry thing," that's a signal the collision is biting and a rename should happen before the v1.0 commitment ossifies.

This option costs you almost nothing now and gives you optionality. The risk is path-dependence: every month of usage makes a rename harder, and "wait and see" can become "too late to change."

Option 3: Rename now, before v1.0.

If the standards aspiration is real — if the framework's verification regime might genuinely become an industry-recognizable thing — then a name that travels better, teaches more, doesn't collide with established terminology, and decomposes cleanly into editions is worth the cost of changing now. The cost is real (rebranding internal artifacts, the manual, GitHub identifiers, social presence) but it's smaller now than it'll be at any future point.

If I were doing this: I'd probably pick Anchor as the base name (preserving Anchor-modeling-collision check first) or Stratum (more distinctive, slightly esoteric). The query language becomes Anchor-QL or Stratum-QL. The standards become "Anchor Conformance Level AAA" or "Stratum Level AAA." The editions become "Anchor Core" / "Anchor Pro" or "Stratum Foundation" / "Stratum Platform."

Of those, Anchor has stronger thesis-alignment (E-anchoring is a foundational principle), more gravitas, better adjective behavior ("anchored ACs," "Anchor-conformant"), and clearer standards positioning. Stratum has stronger distinctiveness and slightly stronger architectural metaphor (analytical data is stratified) but is more esoteric.

My actual take¶

You asked for a thorough evaluation, so let me give it directly: the "Coframe" name is okay, the "Coframe-jr" name is a real liability, and the standards aspiration changes the calculus.

If you weren't talking about industry standards, I'd say: keep "Coframe," fix the Jr naming to "Coframe Core" + "Coframe Pro," ship v1.0, and revisit naming only if specific friction surfaces. That's Option 1 territory.

But you are talking about industry standards, and that changes things. A standard's reference name carries weight that a product's name doesn't have to. "Coframe Conformance Level AAA" reads okay; "Coframe-jr conformance" reads poorly; and the geometric-coframe collision becomes a real friction point if the standard travels into mathematically-literate audiences (academic CS, ML theory, formal-methods communities) where the collision will be noticed and discussed.

So my actual recommendation is: at minimum, fix the Jr naming now, regardless of what you do with the base name. The lowercase-jr-with-hyphen pattern has no upside and many downsides. Move to "Coframe Core" / "Coframe Pro" or whatever editions naming feels right.

Then, separately and with more deliberation: take a hard look at whether "Coframe" itself is the name that should anchor a potential industry standard for analytical data verification. The etymology is private, the geometric-term collision is real, and the name doesn't teach. A name like Anchor or Stratum would do more work for the standards-aspiration story without sacrificing the Coframe architecture's thesis.

If the project's ambition is to define a category, name it like it's defining a category. If the ambition is to be a useful tool in an existing category, "Coframe" is fine. The name follows the ambition.

What's pulling at you most about this — the Jr-specific aesthetic concern that started the question, or the broader question of whether "Coframe" itself is the right anchor for the level of ambition we've been discussing?

Turn 3 — HW likes Coframe Core / Coframe Pro and asks about the website¶

I like the Coframe Core / Coframe Pro combo, what about the website name dedicated to Coframe Core -- say coframe-core.io or coframe.io (by the way, the latter is taken already)?

Turn 4 — CL on the domain question¶

Good — the editions naming is settled. Now the domain question, which has more depth than it looks.

The constraint shapes the answer¶

coframe.io being taken is significant. That's the cleanest, most Schelling-point address for the project, and you can't have it. Everything downstream is a workaround for that fact.

Quick check on what's there: do you know what coframe.io currently hosts? It matters whether it's a parked domain (potentially acquirable), an active product (permanent collision risk), or a defunct project (potentially negotiable). The strength of your competing claim to "Coframe" depends partly on whether the existing site is using it for an analytical-data-related purpose or for something orthogonal. Worth a check before committing to alternatives, because if it's parked or for sale, acquisition cost might be lower than you'd expect and is almost certainly worth the long-term clarity.

Assuming you can't get coframe.io, here's how I'd think through the alternatives.

`coframe-core.io` is workable but has costs¶

The instinct here is sound — make the URL match the product edition. But three issues:

The base project deserves the unmodified URL, not the edition. When someone hears "Coframe" and types it, they should land on the project, not on the open-source edition specifically. coframe-core.io reads as the website for Coframe Core specifically, which is correct for that edition but wrong as the project's primary address. If you later want a unified project page that covers both Core and Pro (which you'll want, for the commercial sales path and for explaining the editions to evaluators), coframe-core.io is structurally wrong as the umbrella.

Hyphenated domains are weaker than unhyphenated. Practical consequences: people misremember whether to type the hyphen ("was it coframecore.io or coframe-core.io?"), the hyphen breaks in spoken communication ("coframe dash core dot io" is awkward), and it generally signals "I couldn't get the cleaner name." Workable, not ideal.

It commits to the editions split being permanent. If you ever consolidate, rename, or restructure editions (which open-source projects often do over years), the URL is now wrong. Domain commitments outlast naming decisions and should be made at the more stable level of abstraction — the project — not the more volatile level — the editions.

What I'd consider instead¶

Several options, in rough order of preference:

coframe.dev. Probably the strongest alternative. The .dev TLD is now well-established for developer tools, encrypted-by-default (HTTPS required), and signals "this is for engineers" without requiring further explanation. dbt uses getdbt.com as a workaround for similar constraints; many newer dev tools default to .dev (Deno at deno.dev, Bun at bun.sh, etc.). The audience self-selects, and the TLD does signaling work that you'd otherwise have to do with the URL itself.

The downside: .dev does anchor the project as developer-tooling rather than analytics-tooling. Coframe spans both — engineers author ACs, analysts and AI agents query them. .dev slightly leans toward the engineering side at the expense of the analyst side. For a project whose primary author audience is data engineers, that's probably fine.

coframe.org. If the project is positioning toward an industry standard (which we discussed), .org carries gravitas that .io and .dev don't. Standards bodies, foundations, and reference implementations live at .org addresses. WCAG is at w3.org; OpenTelemetry is at opentelemetry.io but the standard documents live elsewhere; PostgreSQL is at postgresql.org.

The downside: .org historically connotes nonprofit/foundation, which doesn't fit a project with an active commercial track. The connotation has weakened (many open-source projects with commercial backers use .org) but it hasn't disappeared. If Coframe's positioning is explicitly "open-source project with commercial extensions, not a foundation," .org may be a slight mismatch.

coframe.io via acquisition. Worth pricing seriously before ruling out. Domain acquisition costs vary wildly — anywhere from $500 (parked, motivated seller) to five-figure (active small-business use) to six-figure (high-traffic established site). For a project planning v1.0 ship and aspiring to standards positioning, paying mid-four-figures to lock in the canonical URL is potentially worth it. Use a domain broker; they usually negotiate at a discount to what direct outreach yields.

If coframe.io is parked (no real site, just registrar placeholder), this is realistic. If it's an active product or a passion project of someone unwilling to sell, this is a dead end.

coframe.app. Less common than .io or .dev but increasingly recognized for application-tier products. Slightly leans toward "this is software you use" rather than "this is a framework you build with." Fits Coframe's positioning okay but not great — Coframe is more framework than app.

Project-prefix patterns: getcoframe.com, usecoframe.com, tryitcoframe.com. These are common workarounds. They work but feel transparently like workarounds — every reader processes "oh, they couldn't get coframe.com so they prefixed it." dbt uses getdbt.com and survives, but it's not free of friction. I'd avoid this pattern if .dev or .org alternatives exist.

Adjacent-suffix patterns: coframehq.com, coframeio.com. Worse than the prefix patterns, in my view. coframehq.com reads as "this is a company, here's its HQ" — more about the business than the project. Avoid.

How the editions map to URLs¶

Here's the cleaner structure I'd advocate, regardless of which TLD you pick:

coframe.dev (or .org) — the project's umbrella. Explains what Coframe is, links to both editions, hosts the manual, hosts the article, hosts whatever standards documents emerge.

coframe.dev/core — the Core edition: open-source, install-from-PyPI, link to GitHub, getting-started.

coframe.dev/pro — the Pro edition: features, pricing/contact, enterprise positioning.

docs.coframe.dev — versioned documentation. Redirects from coframe.dev/docs. Lives separately because docs typically have their own deployment cadence and tooling (Mintlify, Docusaurus, ReadTheDocs, etc.).

The point: one domain anchors the project, with the editions as paths under it. This is what GitLab does (gitlab.com covers Community Edition and Enterprise Edition both), what Postgres does (postgresql.org covers core and ecosystem), what Elastic does (elastic.co covers OSS and commercial).

coframe-core.io would force the editions split into different domains, which isn't necessary or desirable. If Coframe Core needs more visibility than a path, it gets a path with prominent navigation, not its own domain.

A specific recommendation¶

If coframe.io cannot be acquired at reasonable cost: register coframe.dev.

Reasoning: it's the strongest available signal for a developer-tools project; it's clean (no hyphen, short, memorable); it aligns with where modern dev-tooling projects increasingly land; and it leaves .org available for a future standards-body URL if the verification-levels regime crystallizes into something formal. You could imagine coframe.dev as the project, and a future coframe-standard.org (or similar) as the standards-specification site, with the two cross-linking. That separation actually helps with the standards-positioning question we discussed — keeping the implementation and the standard at different addresses signals that the standard isn't just a Coframe product feature.

If you want to keep options open further: register coframe.dev, coframe.org, and a .com redirect (whatever's available — getcoframe.com or coframehq.com) defensively. The marginal annual registration cost is trivial; the marginal optionality is real. You can decide later which is canonical.

Now to the hard question worth asking: should the canonical URL constraint be one of the inputs that decides whether "Coframe" is the right base name at all?

We talked through whether to rename. The fact that coframe.io is taken — that you cannot have the most natural URL for the project — is one more cost on the "Coframe" side of the ledger. Not a decisive cost, but worth weighing. If you'd been able to get coframe.io cleanly, the geometric-coframe collision and the etymology-is-private concerns would matter less; the URL would do unifying work that the name itself doesn't. With the URL fragmented across .dev or .org or workarounds, those concerns matter slightly more.

I'm not flipping my recommendation — I still think Option 1 (keep "Coframe," fix the Jr naming) is the right answer if you don't want to take on a rename now. But the URL constraint is a small additional piece of evidence that the base name has friction the project will live with for a long time.

What's the status of coframe.io currently? If you haven't checked recently, that's the first piece of information that would sharpen the rest of this decision.

Turn 5 — HW reports domain status and asks for further brainstorm¶

coframe.io is a parked domain, no active product. However, both .io and .dev are taken, parked. What about .is?

Also, I do like to brain-storm again and see if there could be a better name. Similar to how I get coframe, which is finding critical components of the framework and combine ... I want to also explore the functioning feature space and combine, things and data algebra layer, analytical data platform etc..

Turn 6 — CL brainstorms further¶

Two threads here. Let me handle the practical one first — .is and the domain situation — then settle into the brainstorm, which is the more interesting question.

On `.is` and the parked-domain situation¶

.is is Iceland's ccTLD, increasingly used by US/EU tech projects for the wordplay potential ("it.is", "this.is", "what.is"). It's not regionally restricted — anyone can register. Recognizable enough that engineers won't be confused. But "coframe.is" doesn't carry wordplay (compare: "what.is" or "data.is" land jokes; "coframe.is" doesn't), so you're using .is purely as a TLD-of-last-resort rather than for its semantic affordance. That weakens the choice. Workable, not strong.

Before committing to .is, the better play with three parked .io/.dev/.com domains is acquisition outreach on coframe.io. Parked domains are usually held by speculators who'll sell at a price; the typical range for a parked single-word .io with no commercial activity is low-to-mid four figures, sometimes lower with patient negotiation through a broker. For a project positioning toward an industry standard with v1.0 ship coming up, paying $2-8K to lock the canonical URL is almost certainly worth it. Try acquisition first; treat .is as the fallback if acquisition fails.

The order I'd actually run: try coframe.io acquisition (broker, anonymized) → if too expensive or unresponsive, try coframe.dev acquisition (parked, same logic) → only then fall back to .is or other alternatives. Two acquisition attempts cost you maybe $300 in broker fees and 4-6 weeks of patience; the upside is the right URL forever.

But you raised a different question, which is the more interesting one. Let me actually engage with the brainstorm.

Brainstorming a better name¶

Your method — find the critical components, combine them — is the right method. "Coframe" came from Column-Operation-Frame; that's a clean compression of three primitives. Let me try to enumerate the candidate components first, then explore combinations that compress them differently.

What the framework actually does, decomposed¶

There are several axes I can compress along, and they suggest different name shapes.

The structural primitives: - Column — the unit of governance - Anchor / entity-set — what columns observe (the E in (E,M)) - Family — the cross-anchor sibling structure - Genealogy / DNA — the operational lineage - FD-DAG — the dimensional dependency structure - Frame — the query unit

The functional capabilities: - Verify / Attest — the structural-rigor posture - Resolve — query resolution against the AC - Govern — column-level governance - Query — natural-language and Frame-QL - Compose — multi-AC composition (in full)

The domain and positioning: - Analytical data / analytics - Algebra — the data algebra angle you mentioned - Platform / framework / substrate - Grammar / grammar layer - Semantic (in tension with — you separate from semantic layer)

The audience-facing affordances: - AI-native / agent-native - Multi-grain / cross-grain - Schema-blind (queries don't reference schemas) - Family vocabulary

Candidate compressions¶

Let me try several different compression strategies, generating names that come from genuinely different starting points.

Family of 1: compressions from data algebra.

The "algebra" framing has real substance. The framework's MTI theorem is fundamentally an algebraic claim about partition-invariant reducers being monoid homomorphisms; the FD-DAG is a partial-order structure; the family genealogy is essentially a labeled DAG with operator edges. "Algebra of analytical data" is what the framework formalizes, and that's a hook worth pulling on.

Algeb — too on-the-nose, too clinical, doesn't say "data."
Algebr — same problem.
Algra — invented, AL-gra, "algebra without the bra." Distinctive, short, hard to spell from hearing.
Algedra — invented blend (algebra + ledger?). Awkward.
Algos — Greek root. Used elsewhere; collides with "algorithm."
Algen — algebraic genealogy. Distinctive. Short.

The trouble with algebra-rooted names: most readers don't think "algebra" when they think "analytics," and the connection has to be taught. Algebra is the theoretical foundation; it's not usually what users name in their domain. Worth weighing.

Family of 2: compressions from anchor / entity-set.

The (E, M) paired declaration is foundational. Every column declares what entities it observes; that's the (E) anchor. The framework's reasoning is anchor-relative.

Anchor — single word, distinctive, strong gravitas. "Anchor Conformance Level AAA" works. Possible collision with Anchor modeling (a Lars Rönnbäck data-modeling approach from ~2004, modest adoption — worth a real check, but I think it's small enough not to block use). Probably the leading single-word candidate.
Anchored — past-participle, action-completed connotation. Less common but distinctive.
Anchorage — geographic resonance (Anchorage, Alaska). Collision risk too high.
Mooring — synonym for anchor; less common; carries similar connotation. "Mooring Framework" — possible but more obscure.

Family of 3: compressions from grain/lattice/structure.

The framework's reasoning is fundamentally about navigating a structure of grains under a partial order (the FD-DAG). That suggests lattice-theory vocabulary.

Lattice — captures the FD-DAG / partial-order structure cleanly. Used by Lattice (HR product) but in a different domain. Mathematical resonance. "Lattice Conformance" reads well.
Stratum — captures stratification by grain. Singular. "Stratum AC" / "Stratum Pro." Slightly esoteric but defensible.
Strata — plural form. Less product-name-shaped.
Tier — collides with too many things; too generic.
Grain — collides with woodworking, photography, agriculture; too generic.
Manifold — mathematical resonance (differential manifolds), captures "structured space." Used elsewhere (Manifold the ML platform). High collision.

Family of 4: compressions from verification / attestation.

The structural-rigor posture is a real differentiator. Names emphasizing verification put that front and center.

Attest — captures the verification posture. Verb-as-name pattern. "Attest" or "Attest Framework."
Verify — too generic.
Veritas — Latin "truth"; connotation right but used by Veritas Software (legacy backup company, still active). High collision.
Axiom — captures principles-based foundation. Used elsewhere (Axiom logging product). High collision.
Theorem — captures the MTI-theorem foundation. Distinctive. "Theorem Framework" is unusual but striking.

Family of 5: compressions from the family/genealogy vocabulary.

The family/sibling/cousin distinction is one of the framework's most original conceptual contributions.

Genus — biological taxonomy resonance. Distinctive, Latin, somewhat academic. "Genus Framework" or just "Genus."
Lineage — collides directly with data-lineage tooling.
Kin — short, distinctive, captures the sibling/cousin structure. "Kin Framework." Possibly too informal.
Phylum — too obscure.
Family — too generic, can't be claimed.

Family of 6: invented compressions like Coframe.

If Coframe came from Column-Operation-Frame, what other compressions of components are possible?

Coalign — Column-Anchor-Align. Captures alignment of columns to anchors. Distinctive.
Anchorflow — Anchor + the flow of derivation. Cleaner sound. Maybe too close to "MetricFlow."
Frameworx / Algeworx — too try-hard.
Stratum-QL as the query language — points back to whatever the framework is named.
Cograin — Column-Grain. Compresses the column-and-grain duality. Distinctive. Pronounceable.
Anchora — invented, anchor + something. Distinctive but invented-sounding.
Algora — invented, algebra + something. Has had some prior product use; check.
Lexora — too detached from the framework.

Family of 7: compressions from grammar / structural separation.

The grammar/semantics separation is the framework's central thesis.

Grammar — too generic, can't claim.
Syntax — collides everywhere.
Lexeme — too obscure, too linguistic.
Construct — too generic.
Schema — too generic, collides with too many things.

Family of 8: compressions emphasizing AI-nativeness.

This is positioning rather than substance, but worth surfacing.

Cognate — co-thinking; collides with linguistics-cognate. Distinctive though.
Reasonframe — too long, too on-the-nose.
Native — too generic.
Agent — collides with too many things.

I'd avoid this family — naming for current positioning ages badly.

Stress-testing the strongest candidates¶

Let me push harder on the names that survive initial filtering, by running them through the criteria we discussed earlier.

Anchor. - Teaches? Yes — "anchor" carries the right intuition immediately. Anchored data, stable foundation, structural ground. - Collides? Anchor modeling exists but is small; financial-anchoring is a different domain; "anchor stores" is retail. Survivable. - Travels? "Anchor manual," "Anchor framework," "anchor-conformant," "Anchor Level AAA," "Anchor-QL." All read clean. - Adjective? "Anchor-conformant," "Anchored AC." Yes. - Domains? anchor.io and anchor.com certainly taken (common word). anchorframework.io? Worse than coframe-core. Tradeoff: better name, harder URL. - Standards-naming? "Anchor Conformance" / "Anchor Verified" / "Anchor Level AAA." Strong. - The risk: common-English-word names can be hard to claim and hard to search for. "Anchor framework" returns generic results.

Stratum. - Teaches? Partly — the layer/stratum metaphor works once you connect it to grain stratification, but most readers won't make that jump unaided. - Collides? Stratum exists as a brand in education and some other niches but no major data-tooling collision I know of. - Travels? "Stratum AC," "Stratum Pro," "Stratum Level AAA," "Stratum-QL." Reads well. - Adjective? "Stratum-conformant" works. "Stratified ACs" works as descriptor. - Domains? Likely some availability — stratum.dev may be findable. - Standards-naming? "Stratum Conformance" reads more technical, less colloquial. - The risk: slightly esoteric. Engineers parse it; non-engineers may stumble.

Lattice. - Teaches? Yes for mathematically-literate readers; partial for others. Captures FD-DAG / partial-order structure. - Collides? Lattice the HR product is real and well-funded. This is a real problem in the search/SEO sense, even if the domains are different. - Travels? "Lattice AC," "Lattice-QL." Fine. But every conversation will involve "no, not the HR one." - Verdict: I'd rule out for the collision alone.

Algen / Algebr / Algra. - Teaches? Partially — invokes algebra without being literal. - Collides? Less likely; these are invented. - Travels? Awkward to spell from hearing. "Algen-QL" reads okay; "Algra-QL" is awkward. - Verdict: Invented compressions usually need more phonetic strength than these have.

Genus. - Teaches? For readers who know biological taxonomy, it suggests classification structure. Otherwise opaque. - Collides? Some scientific software uses "Genus"; not analytics-tooling. - Travels? "Genus framework," "Genus AC." Reads okay; slightly academic. - Adjective? "Genus-conformant" works. "Generic" has a different meaning so don't shorten. - Domain? genus.dev worth checking. - Risk: slightly precious; might read as too academic.

Theorem. - Teaches? Strongly — invokes mathematical certainty, formal verification. - Collides? Theorem exists as a brand for some legal/research products; check for data-tooling collisions. - Travels? "Theorem framework," "Theorem-conformant," "Theorem Level AAA." Strong gravitas. - Risk: sets very high expectations. The framework better deliver theorem-quality reasoning, which actually... it does, given MTI is a literal theorem. This might fit better than initially obvious.

A different angle: two-word and compound names¶

I've been focused on single-word names but worth considering compounds:

Datalattice — data + lattice. Works around the Lattice collision. Reads okay.
Anchorql — anchor + query language. Awkward.
Stratumql — same issue.
Anchor Algebra — two words. "Anchor Algebra Framework." Strong thesis statement; long.
Grain Algebra — same shape, slightly clearer for analytics.
Coframe itself was a one-word compound. "Anchorgrain"? "Strataframe"? Most read as forced.

Compounds usually feel less landed than well-chosen single words.

My honest take after this exercise¶

If I had to recommend a single name based on this exploration, the strongest candidates are:

Anchor — strongest thesis-alignment, strongest standards-positioning, strongest gravitas. Risks: common word, domain unavailability, mild Anchor-modeling collision.
Stratum — strong distinctiveness, decent thesis-alignment via grain stratification, better domain availability. Risks: slightly esoteric, less immediately graspable than Anchor.
Coframe (kept) — the name you have, with Coframe Core / Coframe Pro editions. Risks remain (geometric-coframe collision, private etymology, fragmented domain situation), but the cost of a rename is real and you've already invested in the name.
Theorem — interesting wild card. Captures the structural-rigor posture and the MTI-theorem foundation directly. Probably has fewer collisions than Anchor. Sets high expectations but delivers on them.

Beyond the top recommendations, I'd flag two things to think about.

The "doesn't teach" cost is real but bounded. Most successful product names eventually become decoupled from their etymologies. "dbt" doesn't immediately say "data build tool" to a new reader; people learn it. "Snowflake" doesn't say "warehouse"; people learn it. After enough usage, names become referential rather than descriptive — they refer to the thing rather than describing it. So the "Coframe doesn't teach" critique matters most in early adoption (where new readers need scaffolding) and matters least once the project has critical mass (where the name carries learned meaning). If you keep "Coframe," that adoption-friction is real but it's a one-time cost, not a permanent one.

The standards-positioning cost is real and not bounded. Unlike adoption-friction, standards-positioning concerns compound over time. If "Coframe Conformance Level AAA" needs to land in academic CS, formal-methods, or regulatory contexts where the geometric-coframe collision will be noticed, that's an ongoing cost every time the standard is referenced in a mathematically-literate setting. This is the strongest argument for actually doing a rename: not because Coframe doesn't work as a product name, but because it's measurably weaker as a standard name than Anchor or Theorem would be.

If you're seriously committing to the standards-aspiration, the calculus tilts toward rename. If standards is more "we'd like to" than "we will," staying with Coframe is fine.

A specific suggestion¶

Spend 30 minutes doing this: 1. Run Anchor through a serious due-diligence check — Anchor modeling collision severity, domain availability across .io / .dev / .com, trademark search in software, search-result analysis for "Anchor framework analytics." 2. Same for Stratum. 3. Same for Theorem. 4. Then decide between (a) Coframe + acquire coframe.io, (b) Anchor + acquire anchor.dev or similar, (c) Stratum + register stratum.dev if available.

The right answer depends on what those due-diligence checks return. I have priors but they're not reliable enough to substitute for actual research on each.

Want me to push harder on any of these — generate more candidates, stress-test one of the leading three more rigorously, or think about the rename-cost calculation more carefully? The brainstorm has more room if you want to keep going.

Turn 7 — HW raises the broader-data-shapes consideration¶

Let me add another twist. The way I see it, coframe is a clearly focused on relational structured data -- table, dataframe -- the most popular data (rectangular) data form that human consume today, in industrial sitting. However, the full natural scope of data is MUCH broader, and philosophically, data is at the very root of phenomena existence. Just in the area of database today, structural data is bigger than relational data model (key-value store, graph, object ...). My sense of the coframe foundation is that it is extensible to all of structural data model, its underlying concepts has clearly going beyond the relational and tabular data. I think there is a possibility that I am going to extend coframe further into a broader framework, that goes beyond "column" and "frame", but "operator" may stay. At that point, coframe will be a member of a family spec. Thought?

Turn 8 — CL on the family-of-frameworks reframing¶

This changes the problem in an important way, and I think you're seeing something real. Let me work through what you're suggesting and what it implies for naming.

The intellectual claim is substantive¶

You're saying that the framework's foundational concepts — anchored observation, structural commitment, family genealogy under operator-induced derivation, partition-invariance, integrity verification, the grammar/semantics separation — generalize beyond rectangular data. And I think you're right. Let me stress-test that for you, because if the claim is real, it's a much bigger claim than the current Coframe positioning makes.

The relational specifics in Coframe are: schemas as virtual tables; ColumnSpec as the unit of declaration; FD-DAG as the dimensional structure; family-name as a column-level concept; Frame-QL as a tabular query language. The relational specifics are implementations of more general concepts.

The general concepts are: an observation anchored to an entity-set, with a missingness signature; operations that take a predecessor observation to a successor with a well-defined relationship between their anchorings and their identities; a genealogy of observations linked by operations; structural relations (identical / sibling / cousin) that emerge from genealogy and govern substitutability; partition-invariance as the algebraic property determining when navigation across anchorings is name-preserving; integrity verification as the framework's commitment that declared structure matches attested data.

None of these concepts require rectangularity. They require: - Some notion of observation (a thing that has a value and an anchoring). - Some notion of anchor (the entity-set the observation is about). - Some notion of operation (a transformation taking observations to observations). - A genealogy that records lineage. - A way to verify structural commitments against the underlying data.

In a graph-data setting: nodes and edges become entities; node properties and edge properties become observations anchored at nodes/edges; graph algorithms (PageRank, centrality, shortest-path) become operators with well-defined input/output anchoring relationships. Partition-invariance translates: SUM-of-edge-weights-over-paths is partition-invariant the same way SUM-of-revenue-over-rows is.

In a key-value or document setting: documents are entities; document fields are observations; aggregations across documents are operators; the FD-DAG generalizes to whatever dependency structure the document schemas exhibit.

In a tensor / multi-dimensional-array setting: array indices are anchors; array elements are observations; reductions along axes are operators; partition-invariance is well-known there (sum-along-axis is partition-invariant; mean-along-axis is not).

In a time-series / event-stream setting: events are entities; event properties are observations; windowing operators are anchored transformations; partition-invariance over time-windows is exactly what makes streaming aggregations compose.

So yes — the framework's grammar layer generalizes. Coframe's specific contribution is the relational instance of the grammar layer; the broader framework would be a grammar layer for structured data of any shape. That's a meaningfully bigger claim and a meaningfully bigger thing to be naming.

What this implies for naming¶

Now the naming problem looks different. We're no longer naming "an analytical data platform"; we're potentially naming "a family of structural-verification frameworks for different data shapes, with the relational-tabular instance being the first member." That's a different scope, and the names that fit each scope are different.

You named the structural insight directly: the foundational concepts go beyond column and frame, but operator stays. Operator is the load-bearing concept across all data shapes — wherever there's structure, there are transformations between structures, and the well-formedness of those transformations (with their anchoring relationships, partition-invariance, identity-preservation) is what the framework reasons about. Anchor is also load-bearing — every observation is anchored at something, regardless of whether the something is a row, a node, a document, or a tensor index.

So the family-level name — the name of the broader framework — should anchor on what's universal across data shapes. The member-level name — the name of the relational instance — can keep referencing relational-specific primitives.

This is actually a very clean architectural move. Let me sketch what it might look like.

A two-tier naming structure¶

Tier 1: the family. A name for the broader framework, the one that articulates "grammar-layer structural verification for structured data of any kind." This is the name that would carry the standards-aspiration and the long-term intellectual claim.

Tier 2: the members. Names for specific instances of the framework over specific data shapes. The relational/tabular instance is one member. Future members might be graph-instance, document-instance, tensor-instance, event-stream-instance.

Compare to how Apache Arrow works: Arrow is the columnar memory format; Arrow Flight is the network protocol; Arrow Compute is the compute layer; Arrow Dataset is the file abstraction. Each has its own name; they're all under the Arrow family. Or how Kubernetes has Pods, Services, Deployments, ConfigMaps — each named for its concept; they all live under the Kubernetes family.

For Coframe's potential family structure, the question is: what's the family name (Tier 1), and how do the members (Tier 2) relate to it?

Generating candidate family names¶

The family name needs to express what's universal across data shapes. Let me try several angles.

Angle 1: name the universal primitive — operator.

If "operator" is the load-bearing concept, the family could anchor on it.

Operandi — Latin "by means of, of operation." Distinctive, gravitas, slight academic feel. "The Operandi family." Has prior product use; check.
Operon — biology term (gene-regulation cluster); collision risk.
Operad — actual mathematical term for "abstraction of operator composition." Operad theory is exactly the math behind compositional operations on structures. Highly thesis-aligned for a mathematically-literate audience. "The Operad framework." Possible too academic; operadically the right name.

Angle 2: name what operators act on — anchored observation.

Anchor — single word, strong gravitas. Could work as the family name with members like "Anchor Tabular," "Anchor Graph," etc.
Anchora — invented variant.
Observatory — captures the observing-of-data theme. Used elsewhere.

Angle 3: name what the framework produces — structural verification.

Attest — captures the verification posture. Family: "Attest Tabular," "Attest Graph."
Verify — too generic.
Theorem — captures the verification-as-mathematical-claim posture. Family: "Theorem Tabular," "Theorem Graph." The naming asks each member to deliver theorem-quality guarantees, which is the right discipline.

Angle 4: name the abstract structure being reasoned over — algebra / category.

This is where the philosophical depth of your claim lives. Coframe's foundations are essentially category-theoretic (operations as morphisms between observations; functoriality of partition-invariant operators; genealogies as labeled DAGs which are diagrams in a category).

Algebra — too generic to claim.
Categora — invented from category. Distinctive.
Functor — actual category-theory term; too narrow as a name.
Morphism — same problem.
Calculus — captures formal reasoning. "The Calculus framework." Used in many domains.
Structure — too generic.

Angle 5: name the methodological commitment — grammar.

You've used "grammar layer" as the framework's central thesis. A grammar-rooted family name works across data shapes — every structured-data formalism has a grammar.

Grammar — too generic.
Grammatica — Latin/Italian; distinctive.
Lexicon — collides with linguistics; not quite right.
Syntactica — invented; awkward.

Angle 6: name the philosophical move — naming what was already there.

You've articulated "discovery rather than invention" — the framework names structural facts that data-and-metadata already have. That's a deep claim and could anchor a name.

Datum — singular of data; clean Latin root; "the irreducible observation." "Datum Framework," "Datum Tabular," "Datum Graph." Reads well.
Phenomena — your own word from "data is at the very root of phenomena existence." Too long, too philosophical.
Substrate — your word from the article. Generic but defensible.

Angle 7: invented compressions of multiple universal primitives.

Following the Coframe construction (Column-Operation-Frame), invent a compression of universal-across-shapes primitives.

Operans — Latin participle, "operating." Distinctive.
Anchora — anchor-derived.
Strata — already considered.
Algorithma — too on-the-nose.
Operate (verb-as-name) — too generic.

Stress-testing the strongest family-name candidates¶

Let me push on the candidates that survive initial filtering.

Operad. This is genuinely the most thesis-aligned candidate I've generated. Operads in mathematics (Stasheff, May, etc.) are exactly the abstraction of "operations of various arities composing in well-defined ways," which is precisely what Coframe's operator catalog formalizes for analytical data. The family relationship: an operad is a structure for composing operations; "Operad" as the family name says "this is a framework that's fundamentally about operator composition over structured data." Members would be: Operad Tabular (Coframe), Operad Graph, Operad Stream, Operad Tensor. Each member instantiates the operad-abstraction over a specific data shape.

The risks: very academic-sounding. Most data engineers will not have encountered operad theory. The name is teach-by-doing rather than teach-on-first-encounter. But for a framework with industry-standard aspirations and serious theoretical depth, that academic register may be exactly right — it signals "this is the rigorous one." Compare to how Coq, Lean, Agda named themselves: deliberately academic, and the audience self-selects.

Datum. Cleaner than Operad in some ways. Latin root, recognizable, captures the "irreducible observation" abstraction that's universal across data shapes. Datum Tabular, Datum Graph, Datum Stream all read well. Risk: "Datum" might be claimed in software somewhere; check needed. Less theoretically loaded than Operad but more accessible.

Anchor. I had this as the strongest single-word candidate before. As a family name, it works: Anchor Tabular (formerly Coframe), Anchor Graph, Anchor Document, Anchor Stream. The "anchor" concept genuinely generalizes across data shapes — every structured-data formalism has anchors (rows in tables, nodes in graphs, documents in document stores, indices in tensors). Strong thesis-alignment without the academic register of Operad.

Theorem. As a family name, this becomes a quality commitment: every member of the Theorem family delivers theorem-quality structural guarantees. Theorem Tabular, Theorem Graph. Strong gravitas. Risk: every member has to actually deliver, or the name becomes ironic.

Attest. Family captures the verification posture. Attest Tabular, Attest Graph. Action-noun form is unusual but workable. Less thesis-rich than Operad or Anchor.

My honest take¶

Of those, my preference order for the family name is:

Anchor — universal-across-shapes thesis, strong gravitas, reasonably accessible, no academic register barrier. The Anchor-modeling collision is the main risk; needs due-diligence.
Operad — most theoretically deep, most academically credible, most aligned with the actual mathematical foundation of the framework. Risks pricing out non-academic adopters at first encounter.
Datum — cleaner accessibility than Operad, decent thesis-alignment, less rich than Anchor.

The choice between Anchor and Operad is the choice between accessibility-first and rigor-first positioning. Both can work. They lead to different audiences and different rates of adoption.

Actually, let me push one more direction. There's a synthesis worth considering.

A different synthesis: name the family for the relationship, not the entity¶

I've been generating names that invoke either what's being operated on (anchor, datum, observation) or what does the operating (operator, operad, operandi) or what's being verified (theorem, attest). But there's a third option: name the family for the relationship the framework formalizes — the bond between operations and the structures they preserve.

In linguistics, syntax/semantics is the standard split, and you've used "grammar" for the structural-verification layer. The deeper concept is grammar of structured observation — what well-formed transformation-of-structure looks like.

Syntactic / Syntagma — too linguistic.
Grammar — too generic.
Codex — captures both "structured artifact" and "rule-set." Has meaning ("the codex of well-formed analytical operations"). Used elsewhere.
Canon — captures "the rules of well-formedness." Distinctive, gravitas. Religious-text connotation may be wrong.
Form — too generic.
Schema — too generic.

Or names that capture what the framework gives you (rather than what it operates on):

Bedrock — foundation-layer connotation. Generic.
Keystone — the load-bearing piece. Distinctive.
Compass — the navigation metaphor (across grains, across schemas). Used elsewhere heavily.

None of these synthesis names land as cleanly as Anchor or Operad. Useful brainstorm dead-end; rule out and move on.

On the Coframe-as-member position¶

If you go this route — family name + Coframe as the tabular member — there's a question of whether to keep Coframe as the tabular-member name or rename even that.

Argument for keeping: Coframe (Column-Operation-Frame) is precisely the tabular-data compression. Column is tabular-specific (graphs don't have columns; documents don't have columns in the same way). Frame is tabular-specific. The name correctly identifies its scope as the relational/tabular instance. Promoted to family-member status, "Coframe" is a clean and accurate name for that specific member.

Argument for renaming Coframe too: if the family name is doing serious work (Anchor, Operad, etc.), the tabular member's name should harmonize with it rather than compete. Anchor Tabular would replace Coframe; Operad Relational would replace Coframe. The family naming creates parallel structure across members, and an off-key member name disrupts that.

I'd actually lean toward keeping Coframe as the tabular member, with a family name above it. Here's why: Coframe is genuinely accurate for its scope (Column-Operation-Frame is the relational primitives), it's already invested-in, and naming consistency across family members is less important than naming accuracy per member. Different members can have different naming flavors as long as the family name unifies them.

So a possible structure:

Anchor (or Operad, etc.) — the family.
Coframe — the tabular/relational member of the family.
(future) Graphframe or Knotframe or whatever — graph member.
(future) Streamframe or Eventframe — event-stream member.
(future) Docframe or similar — document-store member.

Notice: the "-frame" suffix could become a family-member naming convention if you wanted parallel structure. Coframe (column-frame), Graphframe (graph-frame), Streamframe (stream-frame). The "frame" then becomes the universal concept (the unit of analytical scoping), and the prefix specifies the data shape.

Or alternatively, "frame" is too tabular-bound (it suggests rectangular framing) and a different unifying suffix is wanted. I find I'm unsure here without more thought — what's the natural noun for "scope of analytical reasoning" that works across tabular, graph, document, stream? Frame leans tabular; Scope is generic; Field leans physics; Region is generic; Locus is interesting (Latin "place"); Domain is loaded with mathematical meanings.

Given the broader vision you've articulated, I think the right move is:

Hold the rename decision open. The brainstorm has identified that the naming problem is bigger than "what should we call Coframe?" — it's "what should we call the family, and where does Coframe fit within it?"
Do due-diligence on Anchor and Operad as candidate family names. Anchor for the accessibility-first path; Operad for the rigor-first path. Trademark check, domain check, search-result analysis, prior-use review. The choice between them shapes the project's audience and positioning over years.
Decide whether Coframe stays as the tabular-member name or gets renamed for family-consistency. This is a smaller decision than the family name and can wait until the family name is settled.
Don't ship v1.0 with Coframe-jr. Whatever you decide on the family-name question, the lowercase-jr-with-hyphen pattern needs to go before v1.0. Coframe Core / Coframe Pro is a clean intermediate step that doesn't commit you on the family-name question.
Consider drafting a one-page "Vision" document that articulates the family-of-frameworks claim. Not for publication yet — for your own clarity, and for any collaborators or early advisors. Writing it down would force the question of what's-universal-vs-relational into specific language and would pressure-test whether the family-claim is as substantial as it currently feels.

The shift you're describing — from "Coframe is an analytical data platform" to "Coframe is the relational member of a family of structural-verification frameworks for structured data" — is a meaningful escalation of scope. The naming should follow the scope, and if the family-of-frameworks claim is the right level of abstraction, the family name is what carries the standards-aspiration weight, not the relational-member name.

One last thing worth raising: if you're seriously thinking family-of-frameworks, the verification levels we discussed earlier should also be defined at the family level, not at the Coframe level. "Anchor Conformance Level AAA" or "Operad Conformance Level AAA" — defined once at the family layer, applicable to any member instance over any data shape. That's a cleaner standards-positioning than tabular-specific levels would be, and it's consistent with what universal mathematical structure the family is claiming.

Want to push on this direction? The questions worth chasing are: (1) Anchor vs Operad as the family name — which audience do you want to target? (2) What other concrete data-shape members do you anticipate, and do they affect the family-name choice? (3) Should you write down the family-of-frameworks vision now, or hold it as a private intuition until v1.0 ships and Coframe-tabular has traction?

Turn 9 — HW adds the entity primitive¶

I should mention that there is another term that will stay: "entity". Entity manage the "key" space, and "family" manage the "value" space, and "operator" manage the operational linkage.

Turn 10 — CL on the entity-family-operator triple¶

This is a significant addition. Let me work through what it changes.

What you've just said is a complete picture¶

Three universal primitives, each managing one orthogonal aspect of structured data:

Entity — the key space. What an observation is about. The thing being identified.
Family — the value space. What's observed about entities. The thing being measured or attributed.
Operator — the operational linkage. The transformations that take observations to observations, with well-defined relationships between their entity-anchorings and their family-membership.

This isn't a list of three concepts. It's a complete decomposition of what structured data observation requires. Every act of structured observation has a what-is-this-about (entity), a what-am-I-recording (family/value), and — when you compose observations or derive new ones — a how-are-these-related (operator). You can't have structured data observation with fewer than these three primitives. You don't need more.

This is a substantially different and stronger claim than "Coframe is a framework." It's: these three primitives are the foundation of any structural-verification regime over any data shape, and the relational/tabular instance is one application of the framework these primitives generate.

That's a category-defining claim. And it dramatically clarifies the naming problem.

Why this changes the family-name question¶

The family name should now name this triple — the (entity, family, operator) structure — or one of its constituents that pulls the others into view.

Looking back at my earlier candidates with this new understanding:

Anchor — names the entity primitive specifically. It pulls "what's anchored where" into view but doesn't telegraph that there's also a family/value space and an operator linkage. It privileges one of the three. Workable but partial.

Operad — names the operator primitive (and operadic composition implies the structures being operated on). Pulls operator into view; entity and family are implicit. Partial in a different direction.

Datum — names the unit-of-observation, which is closer to the triple (a datum is an entity-with-a-value), but doesn't telegraph operator.

None of these names the triple itself. They each pick one corner.

But you've now told me there are three corners, and they're the framework's actual foundation. So the name should ideally either:

Name the triple as a whole — the relationship among entity, family, and operator.
Name the framework's claim — that this triple is sufficient for structural verification of any data shape.
Name one corner that, in your specific framework, is the load-bearing one — and accept that the other two are implicit.

Working through the triple-naming option¶

Let me try compressions of the three primitives themselves.

Direct compressions of E-F-O / entity-family-operator:

EFO — three-letter acronym. Mechanical, lacks character, hard to pronounce as a word.
Efrome — invented blend. Awkward.
Trifold — captures three-foldness. Generic.
Trine — three-as-one. Too religious-connoting.
Triad — captures three-component-structure. "The Triad framework." Distinctive. Possibly used elsewhere.
Triality — invented. Distinctive but precious.

Names that capture the triple's relationship rather than its components:

The three primitives don't sit independently — they're related by structural rules (entity anchors family; operator transforms family observations while respecting entity-relationships; partition-invariance is a property of the operator-family pair; etc.). The relationship has structure.

Codex — captures structured rule-set governing relationships. "The Codex framework." Has prior use in software.
Schema — too generic.
Calculus — captures formal reasoning over a rule-set. "The Calculus framework." Used in many domains but distinctively.
Algebra — captures the operational-relationship structure. Generic.
Structure — too generic.

Names from category theory or related foundations:

If your three primitives are entities, families, and operators, that's almost exactly the structure of a category with structure preserved by morphisms: entities-as-objects (with families-as-attributes-of-objects), operators-as-morphisms. The verified structural relationships are the framework's commitment to functoriality.

Categora — invented from category. Distinctive.
Functor — too narrow.
Topos — actual category-theoretic concept (a type of mathematical universe with rich internal logic). Has gravitas. Highly academic. "The Topos framework."
Sheaf — actual mathematical object (data attached to topological structure). Has gravitas. Very academic.

Names that capture the universal-across-shapes ambition:

Manifold — already noted; collision risk.
Universal — too generic.
Substrate — generic but defensible.
Foundry — captures generative-foundation; metaphorical. Used elsewhere.
Forge — similar metaphor.

A different approach: what if the name is one of the three primitives?¶

You're committed to keeping "operator," and "entity" and "family" are now also fixed terms. What if the family name is simply one of the three primitives elevated to name-status?

This is the boldest move. It says: one of these three primitives is so foundational that it names the entire framework. Each option has a different effect:

Family. Names the value-space primitive. Already heavily used in your vocabulary (family-name, family-root, family-DAG, sibling, cousin). If the framework is named Family, the existing family-vocabulary becomes self-referential — "the family vocabulary in the Family framework." Risk: "family" is a generic English word; name searches are nearly impossible.

Entity. Names the key-space primitive. The word has gravitas in databases (entities, ER diagrams, entity-relationship modeling). Risk: collision with too many things; ER modeling is a standard concept and "Entity framework" is Microsoft's ORM.

Operator. Names the operational-linkage primitive. Operator framework — clean, technical, captures one foundation. Risk: collides with Kubernetes Operators (significant collision; "operator pattern" is a major Kubernetes concept). Probably ruled out.

None of these works as a clean family name due to collisions. But the impulse — that one of the three primitives could carry the whole — is interesting.

The mathematical version of this might be: a name for the structure that combines all three. In category theory, a fibration combines base-objects (entities) with fibers-over-objects (families) with morphisms (operators) in exactly the right way. Fibration is too academic but the structural fit is striking.

Recasting the brainstorm given the triple¶

Let me try once more, with the triple in mind from the start.

What I want a name to do, ideally: - Telegraph that there are three primitives, not one - Capture the universal-across-shapes claim - Sit comfortably as both a family name and a standards-anchor - Adjective cleanly

Strong candidates that survive this lens:

Triad — directly names the three-fold structure. "The Triad framework," "Triad Conformance Level AAA," "Triad-conformant data." Pulls all three primitives into view by virtue of naming them as a triad. Possibly the cleanest fit. Risk: "triad" has crime/music/medical connotations that need check.
Codex — names the structured rule-set. Doesn't directly invoke three primitives but invokes the governing structure over them. "The Codex framework" reads well. Latin gravitas. Has some prior software use; needs check.
Operad — still in the running; the operadic structure is exactly the right mathematical abstraction for "operations on structured data composing in well-defined ways." The fact that operads are formally about morphisms (operators) acting on objects-with-attributes (entities-with-families) makes Operad more fitting than I gave credit before. Operad-conformant ACs over relational data; Operad-conformant graphs would be the graph member. The mathematical structure of an operad genuinely captures what your three-primitive framework formalizes.
Categorica / Categoria — invented from category. Less academic than Topos or Sheaf. Distinctive. Captures the categorical-structure-preserving thesis.
Anchor — still strong as accessibility-first option. Names entity but pulls family and operator implicitly through usage.

My honest revised take¶

With the triple now articulated, Triad has moved up considerably. Here's why:

It names the three-primitive structure directly. The framework's foundation is exactly a triad of (entity, family, operator); the name is the foundation.
It scales across data shapes: a relational triad over (rows, columns, aggregations); a graph triad over (nodes, properties, traversals); a document triad over (docs, fields, transformations). Each member of the family instantiates the triad differently.
It's accessible. "Triad" is a common word; engineers don't need to learn it. Compare to Operad which requires educating an audience.
It carries gravitas without being academic. "The Triad framework" sounds substantive; "Triad Conformance" reads as a serious standard.
It harmonizes with your existing vocabulary. Entity, Family, Operator — each is one corner of the Triad. The name reinforces the conceptual structure rather than competing with it.

The risks: "triad" has connotations (crime: Triad organizations; music: chord triads; medical: certain syndromes). Trademark and domain due-diligence needed. Most of the connotation collisions are in different domains and probably survivable, but they need checking. triad.dev / triad.io may both be taken given the word's commonness.

If Triad survives due-diligence, the architectural picture becomes:

Triad — the family. The framework's universal grammar layer for structured-data observation. Foundation: the (entity, family, operator) triple.
Coframe — the relational/tabular member of the Triad family. Coframe instantiates the Triad over rectangular data, with columns as entity-family unions and frames as the query unit.
Coframe Core — open-source edition of Coframe.
Coframe Pro — commercial edition of Coframe.
(Future) — graph-, document-, stream-, tensor- members of the Triad family, each with its own name following whatever convention you settle on.

The standards-positioning becomes naturally cleaner: Triad Conformance Level AAA — defined once at the family level, applicable to any member instance. "This data is Triad-conformant at Level AAA" is a substantive, transferable claim across data shapes.

The deeper observation¶

What you've articulated with the entity-family-operator triple is closer to a foundational specification than to a product framework. It's the kind of thing that — if rigorously developed — could function as a reference standard the way relational algebra did for relational databases, or type theory did for programming languages, or category theory does for abstract structure-preserving reasoning.

The naming should match that level of ambition. Triad (or Operad, or Codex) is a name for that level of thing. Coframe is a name for the implementation of that thing for a specific data shape. These are appropriately different naming registers — the foundational thing should sound foundational; the implementation should sound implemented.

If you take this seriously, the writing-down task I mentioned in the previous turn becomes more important: a one-page "what is the Triad?" document that articulates the triple, the universality claim, the verification regime, and the relationship between the family-level abstraction and the member-level implementations. Not for publication. For clarity. For your collaborators. For the sharpening of the claim that "Coframe is the relational member of the Triad family."

If the document writes itself well, the naming follows. If it doesn't write itself, the framing needs more work before naming can settle.

What I'd actually recommend¶

Sit with "Triad" for a few days. Not to commit. To see whether it feels true. The right family name will feel like it was always going to be that name. The wrong one will feel like work.
Run due-diligence on Triad and Operad in parallel. Trademarks, domains, prior software use, search-result quality. They're the two strongest candidates for different reasons (Triad: accessible, three-primitive-naming; Operad: theoretically deepest, mathematically precise).
Draft the family-vision document. Even just two paragraphs. The triple, the universal claim, the verification-as-standards-anchor, the relational-member-as-first-instance. Writing forces clarity. If after writing it the family name still feels right, ratify. If not, iterate.
Keep Coframe Core / Coframe Pro for the relational-member naming. That edition naming is settled and works regardless of family-name choice. Don't relitigate.
Defer the family-name commitment until v1.0 release of Coframe Core. The family name becomes load-bearing when the second member starts being designed; before that, holding it open costs nothing. You can ship Coframe Core v1.0 with implicit-family-name and formalize it when you start drafting the graph member or the document member.

The one thing I'd resist: collapsing the family-name decision into the Coframe-rename decision. They're separate questions. The family name is new and names something genuinely new (the universal-across-shapes claim). The Coframe-rename question is whether to rename the relational member given the family above it. It's possible the answer is "family = Triad; relational member stays Coframe." That's a coherent position.

So — does Triad sit well, or does it feel like the wrong fit for what you're trying to capture? The triple of (entity, family, operator) is so foundational to what you've built that I'd want to know whether Triad matches the conceptual weight you feel for it, or whether it's too clinical, too geometric, too crime-novel-coded, or otherwise off-key.

Turn 11 — HW reflects on Coframe's place and the AI-agent-consumer angle¶

That is right, even with Triad exist, coframe can still be a member of a family with its distinctive focus on the most popular data form today. Coframe itself can gradually and naturally extending to all columnars data forms, to mutliple diverse backend data engines (foundamentally, it require the engine to be able to host a columnspec / or a data series spec, that has (name, entity) and responds to operator. Even key-value stores can join the play. Coframe may stay for a long time, because its longivity is connected to the tabular data output form, which will stay longer than tabular data as input.

However, the AI Agent as consumer may open up to a broader set of queries that deviate from tabular data significantly.

Turn 12 — CL on the input/output asymmetry and the AI-agent-as-consumer scope¶

You're seeing something important that I want to make sure I'm tracking correctly, because it has architectural consequences. Let me play it back and then push on what I think you're really saying.

The asymmetry you're naming¶

There are two tabular-data questions in the framework, and they're separable:

Tabular as input. What shape the source data is in: rectangular tables, dataframes, columnar parquet. This is what dominates today's analytical infrastructure but isn't logically necessary for the framework — your column-spec abstraction (name, entity, operator-response) generalizes to any backend that can host a data-series-spec, including key-value stores, document stores, graph stores' property tables, time-series stores, even tensor stores with appropriate projections.

Tabular as output. What shape the result of an analytical query takes: a row-set, a frame. This is what humans and BI tools and dataframes consume. This is the form that has staying power because human cognition prefers rectangular outputs even when the underlying data isn't rectangular.

The asymmetry is striking. Coframe doesn't actually require input tabularity; it requires only that the backend can expose data-series with (name, entity) declarations and respond to operators. But Coframe's Frame-QL output is structurally tabular — frames are row-sets, the BY-clause produces grouped tables, results stream as DataFrames. Coframe is output-tabular by design.

That's the connection to longevity you named. Tabular outputs are how humans (and most current AI agents, because they were trained on tabular data and tabular conventions) consume analytical results. Even when the underlying data is graph-shaped or document-shaped or tensor-shaped, the analytical answer tends to be presented rectangularly: "here's a table summarizing what you asked." So a framework whose query output is tabular has staying power proportional to the staying power of tabular cognition — which is much longer than the staying power of tabular storage.

This is a genuinely subtle architectural insight. It says: Coframe's bet is on output-tabularity, not input-tabularity. And that bet is more durable than it first appears.

What this implies architecturally¶

If Coframe stays for a long time because output-tabularity has staying power, then Coframe's natural evolution is deeper input flexibility, fixed output shape. The growth direction is:

More backend types — first relational engines, then key-value, then document stores, then graph property-tables, then potentially time-series and tensor backends.
More source data shapes hosted under the column-spec / data-series-spec abstraction — anything that can answer "what's the (name, entity) of this series, and how does it respond to operators?"
Same Frame-QL output — rectangular, family-named, BY-clause-grained, navigable by human analysts and AI agents that expect tabular results.

Coframe becomes the framework that says: whatever your data lives in, if you can expose it as a column-spec, your analytical output is a verified frame. That's a coherent and ambitious scope. It's also notably not "Coframe over rectangular data only."

This is much bigger than I think the current Coframe-Jr manual lets on. The manual reads as if Coframe is a relational/tabular framework with a defined operator catalog. But the actual architecture — column-spec as a backend-neutral declaration, the data-API protocol as a thin abstraction, operators reasoning over series rather than tables — is already almost backend-shape-agnostic. The manual just doesn't articulate that as a forward-looking claim.

Where the AI-agent-as-consumer angle changes things¶

Now your second observation, which is the one I want to push hardest on. AI agents as analytical consumers don't have the same tabular bias humans do. A human analyst wants results in a table because their cognition is built for spatial-grid reasoning over comparisons. An AI agent can consume any structured representation that's well-formed — graphs, trees, JSON, embeddings, free text with structured citations.

This means the AI-agent consumer audience may open up a class of analytical queries that don't have natural tabular outputs:

"Walk the customer-influence graph from these seed customers and tell me which paths matter."
"Cluster these documents semantically and tell me which clusters are growing."
"Trace the causal-attribution path from this anomaly back through the system."
"Find the subset of features that, together, explain the outcome variance."

These aren't tabular queries. The natural answer to each isn't a frame; it's a structured answer of the right shape for the question — a path, a clustering, a graph, a feature-set with weights. AI agents can consume any of these natively; humans struggle to consume them without summary-into-tables.

So your insight has a sharper edge: the AI-agent consumer audience expands the universe of legitimate analytical queries beyond tabular outputs, which means a framework that can serve AI agents fully might need non-tabular query capabilities Coframe doesn't have.

That's where the family-of-frameworks idea earns its keep. Coframe stays output-tabular and serves the long-tail of human-and-tabular-trained-AI analytical consumption. But other family members — let's say a hypothetical Pathframe for graph-traversal queries, or Clusterframe for unsupervised-structure queries, or Causaframe for causal-attribution queries — would serve the AI-agent-consumer queries that don't fit Coframe's output shape.

Each member instantiates the (entity, family, operator) triad over different output structures, not just different input shapes. The triad is the unifying foundation; the output structure is what differentiates the members.

The architectural picture this paints¶

I want to lay this out explicitly because it's a substantive escalation of the framework's scope.

Triad (the family). Universal grammar layer for structured-data analytical observation. Foundation: (entity, family, operator) triple. Provides: structural-verification regime, conformance levels, integrity-condition catalog, the family-genealogy model, partition-invariance reasoning. Output-shape-agnostic at the foundation level.

Coframe (member). The Triad instance for tabular-output analytical queries. Input-shape-flexible (any backend exposing column-specs / data-series-specs); output-shape-fixed (frames). Serves the human-analyst audience and the tabular-trained-AI-agent audience. Long-lived because output-tabularity is durable.

Future members. Triad instances for other output shapes: - Graph-output: results are subgraphs, paths, or graph-structured. - Tree-output: results are hierarchical (taxonomy, decision-tree, tree-decomposition). - Set-output: results are clusters, sets, or unstructured groupings. - Distribution-output: results are statistical distributions or probability surfaces.

Each member shares the Triad foundation (the entity-family-operator triple, the verification regime, the conformance-level structure) but specializes its output shape and the operators relevant to that shape.

This is actually a cleaner architecture than I had been working with. The family-of-frameworks pattern doesn't just generalize across input data shapes (which is interesting but somewhat incremental); it generalizes across output structures, which is where the real diversity of analytical questions lives. The AI-agent consumer is what makes this growth direction worth taking seriously, because AI agents can consume non-tabular outputs that humans typically can't.

What this means for naming¶

A few things now clarify.

Coframe is appropriately scoped. Column-Operation-Frame names exactly the right thing: a tabular-output framework over series-style inputs. It doesn't overclaim. It doesn't misclaim. Its scope is real and durable. The geometric-coframe collision and the doesn't-teach concerns I raised earlier are still real but they're less concerning given that Coframe is a member of a larger family rather than the umbrella name.

The family name carries the universal claim. This is where Triad (or whatever family name lands) does its work. The family name has to support the claim that the (entity, family, operator) triad generalizes across output structures, not just input shapes. Triad still works for this, possibly works better for it — the triad is exactly what's universal across output shapes; the output-shape-specific naming sits on top.

Long-form naming becomes natural. "Coframe, the tabular-output member of the Triad family of analytical-data-grammar frameworks." This sentence makes sense. It positions Coframe accurately, names the family, and signals that other members are conceivable. Compare to trying to position Coframe as the umbrella — which forces awkward phrases like "Coframe (the framework) versus Coframe-tabular (the relational instance)."

Coframe Core / Coframe Pro stays clean. The editions naming is internal to Coframe-the-tabular-member. Core / Pro doesn't need to scale across other family members; each future member can have its own editions structure. Coframe Core / Coframe Pro is an edition-split for one specific member, not a pattern that has to apply universally.

The thing I want to push on¶

Your observation suggests that the framework's real natural scope is bigger than the Coframe-Jr manual currently articulates. The manual says: "Coframe is for tabular analytical data." Your architectural intuition says: "Coframe is for tabular-output analytical queries over any input that can host a column-spec, and there's a family of frameworks of which Coframe is the tabular-output member."

These are two different framings, and the second is more accurate to what you've built.

The question — and this is where I want you to push back if I'm overstepping — is whether the manual should articulate the broader claim now, or whether the broader claim should stay implicit until you have concrete plans for a second family member.

Argument for articulating now: intellectual honesty about what the framework actually is; the (entity, family, operator) triple genuinely is universal, and saying so up front anchors the verification regime at the right level of abstraction; the standards aspiration is more credible if the universal claim is explicit; future-readers (especially AI-agent operators thinking about analytical infrastructure) can see what the framework supports.

Argument for staying implicit: the v1.0 deliverable is concretely the tabular member; making big claims about a family-of-frameworks before the second member exists risks vaporware critique; the manual is currently honest about what's implemented vs. what's planned, and adding a "and the framework generalizes to..." section without an implementation feels speculative.

My instinct: split the difference. Articulate the family-claim briefly and precisely in a forward-looking section of the manual — not as a roadmap commitment, but as an architectural-intent statement. The (entity, family, operator) triple is named as universal; Coframe is positioned as the tabular-output instance; the door is left open without promising specific future members. This costs little and gains a lot — particularly for the standards-aspiration story, where the verification regime needs to be defined at the family level to be transferable, and the manual is the natural place to plant that flag.

Something like a §1.5 or §2.7 of the manual: "Coframe in the broader framework family. Coframe-Jr is the tabular-output member of a broader framework family whose foundation is the (entity, family, operator) triple. The triple generalizes across input data shapes (relational, columnar, key-value, document, graph property-tables) and across output structures (the tabular-output instance is Coframe; future members may serve graph-output, tree-output, set-output, or distribution-output queries). The verification regime and conformance levels defined in this manual apply at the triad-family level; Coframe-Jr is one instantiation. This manual specifies Coframe-Jr; the family-level specification is forthcoming."

Three paragraphs. Plants the flag. Doesn't overclaim. Honors the family-of-frameworks intuition without committing to specific future members.

A concrete question for you¶

I've been generating possibilities. You're closer to the actual intuitions and have built the thing. Three questions whose answers would sharpen what comes next:

Does "tabular-output member" feel like the right characterization of Coframe's place in the family? I've been working with that framing for the last few paragraphs. If your intuition is different — say, Coframe is "the relational-input member" or "the row-set member" or "the structured-rectangular member" — that changes what the family looks like and what other members might be.
Are there concrete future members you've been quietly thinking about, or is the family idea purely architectural? If you've been imagining a graph-output member, the family-name decision should accommodate that. If the family is still abstract, the family-name has more room.
How load-bearing is the AI-agent-consumer angle in your thinking? I've taken it as a substantial driver of the family-of-frameworks ambition. If it's actually peripheral and the family idea would exist anyway, the framing should be different. If it's central, the family-name should signal AI-agent-readiness somehow.

The naming and architecture want to settle on one coherent picture, and the picture depends on your answers to these. I'd rather ask than guess.

Turn 13 — HW answers the three questions¶

my reply:

yes

You understand the vision of the bigger architecture correctly, however, stay on the coframe scope is important, and let's build coframe the way best for coframe scope.

the vision for building a grounded framework for AI-agent as consumer is what I think my unique contribution - and I should really focus on that. However, remember #2, so I consider this is separate track of work

Turn 14 — CL on the implications of separating tracks¶

Good. That clarifies the priorities and lets me give you sharper guidance. Let me work through the implications of those three answers.

What your three answers settle¶

The picture is clean now:

The family architecture is real and you understand it. That's an intuition you hold privately and design Coframe coherently with. It's not a v1.0 deliverable.
Coframe stays scoped. Build it for tabular-output excellence, not for family-leadership.
AI-agent-as-consumer is your unique contribution. It's a separate workstream that deserves its own focus.

This is a discipline statement: don't let the bigger vision distort the smaller deliverable. That discipline matters. Many projects fail because the founders built scaffolding for the bigger thing and the smaller thing never shipped. You're explicitly resisting that, and that's right.

The family-of-frameworks idea becomes background context for naming and for keeping the architecture clean — not a thing the manual has to articulate, not a thing that gates v1.0, not a thing that affects current decisions about Coframe.

What this changes about the naming recommendation¶

This significantly simplifies the naming problem. Let me revise.

If the family idea is held privately and Coframe stays as the deliverable, then:

The family name doesn't need to be settled now. Triad, Operad, Datum — none of these need to be ratified before v1.0 of Coframe ships. The family name becomes a problem to solve when (and if) you start designing a second family member. That's likely years away. Meanwhile, the family-of-frameworks remains an architectural intuition you hold while building Coframe, ensuring you don't accidentally couple Coframe to relational-specific assumptions in ways that would later be hard to undo.

Coframe's name is fine. The earlier critiques (geometric-coframe collision, private etymology) were calibrated for "Coframe is the umbrella." They're significantly weaker for "Coframe is one focused member that may eventually have siblings." A specific-member name doesn't need to carry universal weight. The Column-Operation-Frame etymology is exactly right for Coframe's actual scope — tabular-output queries over series-input — and the name's tabular connotation is a feature, not a bug, when the scope is correctly understood.

The Coframe Core / Coframe Pro editions naming holds. That's settled.

The lowercase-jr-with-hyphen still has to go. That fix is independent of the family question and remains warranted.

Domain choice can be made for Coframe specifically. Not for the family. Acquire coframe.io if available at reasonable cost; otherwise pick a single clean alternative for Coframe and stop optimizing. The family will get its own URL when and if it materializes.

So the naming recommendation simplifies to:

Coframe stays as the project name.
Coframe Core (open-source) and Coframe Pro (commercial) replace Coframe-jr / Coframe.
Pursue acquisition of coframe.io; if unavailable at reasonable cost, register coframe.dev (as a fallback .is if both .io and .dev fail).
The family name and family-level standards positioning are deferred until a second family member is concretely planned.

That's the whole naming question, settled. The brainstorming was useful for sharpening why Coframe is the right name given the right scoping, but the conclusion ends up close to the starting point with much more clarity about why.

On the AI-agent-as-consumer separate track¶

You said this is your unique contribution and a separate track. Let me reflect what I think you're saying and check whether I'm getting it right, because I want to make sure the separation is doing the right work.

There are two distinct things you've articulated:

Coframe-as-an-analytical-data-platform. Tabular-output analytical queries with structural rigor, the family vocabulary, the four-rule filter, the verification regime, MTI as theorem. This is what the manual specifies and what v1.0 ships. AI agents are one consumer of Coframe, alongside human analysts and BI tools. The framework's structural commitments make it well-suited for AI agents (the dubious-query mechanism, the family vocabulary, the no-silent-incorrectness posture), but Coframe doesn't require AI agents to make sense.

A grounded framework for AI-agent-as-consumer. A separate intellectual project that treats the AI agent as the analytical consumer of first concern and asks: what does an agent need from analytical infrastructure to ground its reasoning structurally? This goes beyond Coframe's scope because (as you noted earlier) AI agents can consume non-tabular outputs and may want analytical operations that don't fit Coframe's frame. The agent-grounded framework draws on Coframe but isn't reducible to it.

If I'm reading you right, the two tracks have different scopes:

Coframe is "an analytical data platform with rigorous structural verification, useful for AI agents among other consumers."
Your agent-consumer framework is "the principles and architecture for analytical infrastructure designed agent-first," which would presumably encompass Coframe-style analytical querying plus whatever else agents need (graph traversal, semantic clustering, causal attribution, etc., as I mentioned in the previous turn).

Track 1 ships Coframe Core v1.0 in the timeframe the platform design specifies (~24-30 weeks). Track 2 is research and architecture work that informs a future broader framework — possibly the family-of-frameworks we discussed, possibly something else entirely. Track 2 doesn't have a v1.0 deliverable in the same sense; it's foundational thinking.

Is that approximately the split you're holding? If so, two implications worth stating:

The Coframe manual should not try to do Track 2's work. This means the AI-agent-as-consumer chapter in the Coframe manual (Chapter 12, the MCP server) should specify Coframe's specific affordances for AI agents — direct mode, dialogue mode, family-vocabulary exposure, coherence-posture propagation — and stop there. It shouldn't articulate a general theory of AI-agent analytical consumption. That theory is Track 2 and lives elsewhere.

Track 2 deserves its own writing space. When you're ready, separate documents — design notes, position papers, eventual specifications — that articulate the agent-grounded framework as its own intellectual project. These can reference Coframe as a concrete instance of agent-friendly infrastructure, but they shouldn't be Coframe documentation. The audience and purpose are different.

This separation has a side benefit. Track 1's success doesn't depend on Track 2's progress, and vice versa. Coframe Core ships, gets adoption, builds a community, generates revenue (via Coframe Pro), establishes the verification-levels regime within tabular-output analytics. Track 2 evolves in parallel — through writing, through prototypes, through engagement with AI-agent infrastructure projects — without being held to Coframe's release timeline. If Track 2 eventually crystallizes into a broader framework with multiple members, Coframe is positioned as the relational/tabular member of that framework. If Track 2 takes longer or evolves differently, Coframe remains valuable on its own terms.

What I'd suggest concretely going forward¶

Given the clarity of priorities, here's what I'd actually do.

For Coframe (Track 1):

Lock the editions naming at Coframe Core / Coframe Pro. Update the manual, platform design, and article accordingly. The previous v0.7 manual changes I produced still stand; just substitute "Coframe Core" for "Coframe-Jr" wherever it appears, and relabel the manual as the "Coframe Core Manual" or "Coframe Core Reference Manual."
Pursue domain acquisition of coframe.io. Use a broker, anonymized inquiry, target $2-5K range. If unsuccessful within reasonable timeline, fall back to coframe.dev (acquire if parked) or .is as third option.
Continue executing the platform-design v0.6 phasing. The substantive technical decisions — the attestation default, the verification levels (when you draft them), the v1.0 scope — are settled; ship.
Define the verification levels (the Bronze / Silver / Gold or A / AA / AAA discussion from earlier) as Coframe-specific for v1.0. They can be reframed as family-level later if and when the family emerges; for now, they're Coframe Conformance Levels and that's appropriate scope.

For Track 2 (AI-agent-as-consumer):

Start a separate writing space. Not for publication; for clarity of your own thinking. A folder of design notes, position papers, sketches.
Write a foundational position paper — maybe 5-10 pages — that articulates: what does an AI agent need from analytical infrastructure to be a structurally grounded consumer rather than a stochastic guess-maker? What are the failure modes of current AI-agent-analytics integrations? What architectural commitments would address them? The (entity, family, operator) triple is part of this, but so are: provenance, refusal-as-first-class, verification-of-claims, structured-disambiguation-protocols, calibrated-confidence-on-results.
Treat Coframe as one case study in this position paper, not as the answer. Coframe demonstrates what tabular-output agent-grounded analytics looks like; the broader framework would specify the principles that any agent-grounded analytical infrastructure should honor, of which Coframe is one instantiation.
Engage with AI-agent infrastructure projects (Anthropic's MCP, OpenAI's function-calling, agent frameworks like LangGraph) to test your principles against real systems. The agent-as-consumer field is moving fast; your principles need to engage with where it's actually going.

This separation lets each track move at its right pace. Coframe ships on engineering timelines; the agent-grounded framework develops on intellectual timelines. They feed each other but don't gate each other.

A small reflection¶

What you've articulated — "the vision for building a grounded framework for AI-agent-as-consumer is what I think my unique contribution" — is a much sharper self-understanding than most founders manage. It identifies what's yours specifically in a space crowded with analytical-tooling vendors and AI-agent-framework vendors. Coframe is a beautiful concrete realization of that vision in one specific scope. But you're right that the vision itself — the principles for agent-grounded analytical infrastructure — is the thing that would be more broadly influential if articulated rigorously.

That said, the discipline of "stay on the Coframe scope when working on Coframe" is exactly right for shipping. The vision can wait its turn. v1.0 of Coframe Core is the proof-point that gives the broader vision credibility; without the proof-point, the vision is just a position paper.

So: ship Coframe Core. Hold the broader vision privately. Write Track 2 in the spaces between. The naming question, with all that context, is genuinely settled.

Anything else you want to push on? I think we're at a natural stopping point on naming; the remaining open questions (how exactly to articulate verification levels, whether to pursue coframe.io acquisition or fall back, what to do with Track 2 first) are smaller and more tactical.

End of naming discussion. Captured at user request.

Coframe Naming Discussion¶

Turn 1 — HW asks for an evaluation of the Coframe / Coframe-jr naming¶

Turn 2 — CL evaluates the naming¶

What "Coframe" is doing right now¶

What's working less well¶

What name-design considerations apply¶

Alternatives worth considering¶

The Jr/full naming specifically¶

What I'd actually recommend¶

My actual take¶

Turn 3 — HW likes Coframe Core / Coframe Pro and asks about the website¶

Turn 4 — CL on the domain question¶

The constraint shapes the answer¶

coframe-core.io is workable but has costs¶

What I'd consider instead¶

How the editions map to URLs¶

A specific recommendation¶

Turn 5 — HW reports domain status and asks for further brainstorm¶

Turn 6 — CL brainstorms further¶

On .is and the parked-domain situation¶

Brainstorming a better name¶

What the framework actually does, decomposed¶

Candidate compressions¶

Stress-testing the strongest candidates¶

A different angle: two-word and compound names¶

My honest take after this exercise¶

A specific suggestion¶

Turn 7 — HW raises the broader-data-shapes consideration¶

Turn 8 — CL on the family-of-frameworks reframing¶

The intellectual claim is substantive¶

What this implies for naming¶

A two-tier naming structure¶

Generating candidate family names¶

Stress-testing the strongest family-name candidates¶

My honest take¶

A different synthesis: name the family for the relationship, not the entity¶

On the Coframe-as-member position¶

What I'd actually recommend at this point¶

Turn 9 — HW adds the entity primitive¶

Turn 10 — CL on the entity-family-operator triple¶

What you've just said is a complete picture¶

Why this changes the family-name question¶

Working through the triple-naming option¶

A different approach: what if the name is one of the three primitives?¶

Recasting the brainstorm given the triple¶

My honest revised take¶

The deeper observation¶

What I'd actually recommend¶

Turn 11 — HW reflects on Coframe's place and the AI-agent-consumer angle¶

Turn 12 — CL on the input/output asymmetry and the AI-agent-as-consumer scope¶

The asymmetry you're naming¶

What this implies architecturally¶

Where the AI-agent-as-consumer angle changes things¶

The architectural picture this paints¶

What this means for naming¶

The thing I want to push on¶

A concrete question for you¶

Turn 13 — HW answers the three questions¶

Turn 14 — CL on the implications of separating tracks¶

What your three answers settle¶

What this changes about the naming recommendation¶

On the AI-agent-as-consumer separate track¶

What I'd suggest concretely going forward¶

A small reflection¶

`coframe-core.io` is workable but has costs¶

On `.is` and the parked-domain situation¶