Skip to content

Status

This page reflects the current state of Coframe Core's implementation. Updated whenever the implementation progresses.

Last updated: 2026-05-13


Package state

Coframe Core is organized as five packages plus a meta-distribution. The current state of each:

Package State Notes
coframe-core Pre-alpha, in progress Types, errors, package scaffold landed. ColumnSpec, AC loader, structural integrity in flight.
coframe-connect Pre-alpha, scaffold only Backend protocol stub. Real protocol definition pending.
coframe-polars Pre-alpha, scaffold only PolarsBackend stub. Real implementation pending.
coframe-duckdb Pre-alpha, scaffold only DuckDBBackend stub. Real implementation pending after Polars.
coframe-mcp Pre-alpha, scaffold only MCP server stub. Out of scope for current vertical slice.
coframe (umbrella) Pre-alpha Meta-distribution. pip install coframe[polars] works once individual packages reach functional state.

Current focus

The current implementation slice targets a working DQ (Data Quality / Structural Verification) pipeline end-to-end on a real public retail dataset, with documentation hosting at coframe.tech.

This means: get from schema.init YAML → loaded AC → integrity-condition verification → a published verification level (A / AA / AAA) on a real-world AC.

What's in this slice

  • The grammar layer (Manual Chapters 2–4): foundations, ColumnSpec, AC authoring workflow.
  • DQ verification machinery (Manual Chapter 7): integrity conditions I0–I10, per-DNA-edge attestation, verification-level computation.
  • One reference backend (Polars) implementing the four Backend methods DQ needs.
  • A real-dataset walkthrough using publicly available retail data.

What's out of this slice (intentionally)

  • Frame-QL parsing and query resolution (Manual Chapters 8–9).
  • The full MCP server surface (Manual Chapter 11).
  • The natural-language coframe.dialogue layer.
  • The DuckDB backend's authoring CLI.
  • Coframe Pro features (custom operators, multi-backend, SCAs, recursive hierarchies, sensitivity analysis, etc.).

These land after the DQ slice is solid.


Stable surface vs. informational at v1.0

Per the Platform Design, v1.0 has both semver-governed and informational-but-documented surfaces.

Semver-governed at v1.0: - AC YAML format - Frame-QL grammar - Backend protocol - MCP capability surface - Operator catalog identifiers

Informational-but-documented at v1.0: - AC Verification Levels (A / AA / AAA) — taxonomy and grounding-source classification. Stable-surface promotion is targeted for v1.x after field experience. - coherence_posture field shape on MCP query results.

Early adopters making integration decisions against the verification levels should expect that v1.x may refine specific edge cases — though the high-level commitment to three monotonically-stronger levels is firm.


Roadmap

Following the Platform Design's eight-phase plan, in rough chronological order:

  1. Phase 0 — Monorepo scaffold, workspace, package layout.
  2. 🔄 Phase 1 — Catalog: types, ColumnSpec, name_map, AC YAML loader, structural integrity (I0/I1/I2/I7/I8/I9).
  3. Phase 2 — Backend protocol: coframe-connect surface, source bindings, entry-point discovery.
  4. Phase 3 — Reference backend: Polars implementation of Backend (read_columns, compute_qm, attest_dna_edge, query execution stubs).
  5. Phase 4 — DQ pipeline: data-dependent integrity (I3, I4, I5, I6), per-DNA-edge attestation (I10), verification status emission, level computation.
  6. Phase 5 — Frame-QL: parser, resolver, MTI, four-rule filter, dubious-query mechanism.
  7. Phase 6 — Authoring toolchain: discovery, profiling, FD-candidate testing, LLM-assisted naming, review CLI.
  8. Phase 7 — MCP server: capability surface, coframe.dialogue integration.
  9. Phase 8 — Documentation polish, worked example ACs, tutorials.

How to follow / engage

  • Project repository: (coming soon — repo go-live is part of the Phase 0 push)
  • Documentation: this site.
  • Inquiries: see About.