Planning Hub¶

Status: Shipped product docs describe ETLantic 0.41.0; CP3 is gate-ready / released incubation. CP1/CP2/CP3 ≠ production multi-tenant (0.43).

ETLantic's planning documents describe intended outcomes, dependencies, and release gates. They are not a substitute for current product documentation.

Use the right source of truth

To learn what ETLantic 0.41 can do now, use Capabilities, the CLI reference, and the Python API reference.
To understand release order, use the main roadmap.
To evaluate CP3 gate evidence, use the 0.41 exit gate, ADR-018, release notes, and tests.
To evaluate CP2 gate evidence, use the 0.40 exit gate, ADR-017, release notes, and tests.
To evaluate CP1 gate evidence, use the 0.39 exit gate and ADR-016.
To evaluate connectivity gate evidence, use the 0.38 exit gate.
To understand why a boundary exists, use architecture decisions.

No proposed interface becomes public API merely because it appears in a plan. A capability is available only when the current-version documentation says it is available and its release gate has passed.

Portfolio at a glance¶

Status is relative to the 0.41 CP3 gate-ready line. Prior CP2 evidence remains in 0.40; CP1 evidence remains in 0.39; connectivity evidence remains in 0.38.

Plan	Status	Current boundary	Next horizon or gate
Main roadmap	Current sequence	0.41 CP3 gate-ready; 0.40 CP2 prior	EXIT_GATE_0_41; next CP4 at 0.42
0.41 implementation plan	Gate-ready milestone	Durable submission, leases, state, replay, previews	EXIT_GATE_0_41
0.40 implementation plan	Previous / gate-ready	Registry records, revisions, isolation profiles, histories, OpenLineage	EXIT_GATE_0_40
0.39 implementation plan	Previous / gate-ready	Identity, API, durable submit, SSE, landing submitter, optional SQLModel	EXIT_GATE_0_39
0.38 implementation plan	Previous / gate-ready	Connector protocols, landing-zone modes, reference providers, conformance	EXIT_GATE_0_38
Forward implementation plans	Planned release program	Shared entry/done contract and implementation-grade plans for 0.39–0.52	0.41 CP3 gate-ready
0.37 implementation plan	Previous milestone	Removals, testing graduation, acceptance 1–21, security matrix, freeze, rehearsal	EXIT_GATE_0_37 gate-ready
0.36 implementation plan	Gate-ready / previous	Joint compatibility burn-in closed in-tree	Immutable docs residual on 0.36
Adoption, connectivity, and operations	Planned program	Connectivity gate-ready in 0.38; testing graduated in 0.37	Continues through 0.52
Landing-zone file connector	Gate-ready (0.38 + 0.39 composition)	Snapshot + incremental in 0.38 Preview; continuous submitters in 0.39 (outside core)	CP1 submitter bridge landed
ADR-015: Connector protocols	Accepted	Protocol ids, entry points, capabilities, plan/runtime split, reference set	Maintenance
ADR-016: Control-plane identity	Accepted	Identity vocabulary, non-enumeration, durable accept, SSE cursor shapes	CP1 prior
ADR-017: Registry and isolation	Accepted	Directory records, revisions, isolation profiles, metadata-only histories	CP2 prior
ADR-018: Durable submission and state	Accepted	Outbox, leases/fencing, effects, preview non-authority	CP3 gate-ready
Multi-tenant control plane	Planned program; CP3 gate-ready	0.38 thin reference ≠ control plane; CP1–CP3 incubation	Incubation 0.39–0.42; graduation gate 0.43
User interface and experience	Partially shipped, cross-cutting	CLI and generated read-only artifacts exist; interactive, IDE, and hosted phases remain planned	Incremental; hosted work follows control-plane gates
ETL reliability and recovery	Partially shipped, living plan	Public models, providers, and local CLI operations exist; managed and advanced capabilities remain planned	Delivery objectives and governed erasure in 0.42; bounded dynamic control, DLQ, and schema registries in 0.46
Schema drift and evolution	Partially shipped, living plan	File-backed history, inspection, comparison, impact, and acknowledgement workflows exist	Registry-backed history at 0.40
SQLModel integration	Partially shipped; CP2 persistence open	The optional contract-to-SQLModel bridge exists; reference registry stores incubate with 0.40	Request-scoped CP stores
FastAPI integration	Thin reference shipped; CP1/CP2 in progress	The optional thin adapter is not the durable control plane; CP routes grow under 0.39–0.40	Incubation 0.39–0.42; graduation gate 0.43
Local scheduler and Prefect	Local MVP shipped	The built-in scheduler and optional local Prefect path exist; deploy and serve workflows remain open	Graduate only with deployment, recovery, and parity evidence
Portable transformations	Shipped record with follow-up work	Authoring, planning, conformance, and first-party compilers exist; support remains operation- and backend-specific	Expand only through the published compiler matrix and conformance gates
Versioned tabular interchange	Gate A shipped record	Polars↔Pandas Gate A exists; DataFusion Gate B remains experimental	Gate B graduates only after its explicit criteria pass
ContractModel upgrade	Historical review baseline with active follow-ups	The original review targeted ContractModel 0.1.2; ETLantic 0.36 requires ContractModel 0.2.x	Revalidate remaining proposals against the current upstream API
TransformationModel incubation	Proposed incubation	No TransformationModel package or API is shipped	Post-foundation 0.52 incubation
Medallantic roadmap	Current companion sequence	Medallantic tracks ETLantic matching minor	Matching-minor joint release

Forward implementation sequence¶

The roadmap defines outcomes; these documents define workstreams, ordering, evidence, and release gates. Read the shared forward delivery contract first.

Program	Phase implementation plans
Control plane	0.39 · 0.40 · 0.41 · 0.42 · 0.43
Intelligence and execution	0.44 · 0.45 · 0.46 dynamic control + streaming · 0.47 · 0.48
Adoption and incubation	0.49 · 0.50 · 0.51 · 0.52

Status vocabulary¶

Plans use these terms consistently:

Planned program — approved direction and sequencing, but no current availability claim.
Proposed incubation — an idea with explicit graduation gates; its package and interfaces are not shipped.
Partially shipped, living plan — some documented outcomes are current, while later work remains open. The plan must identify the boundary.
Shipped record — historical implementation rationale and acceptance evidence. Current user documentation owns the supported interface.
Historical review baseline — analysis of an older dependency or product state. It can inform follow-up work but cannot describe the current API on its own.

Authority and ownership¶

When documents disagree, use this order:

Current-version capabilities, API reference, CLI reference, and package documentation define shipped behavior.
The main roadmap defines release sequence and cross-program dependencies.
A domain plan defines its own scope, decisions, non-goals, and graduation gates.
Accepted architecture decisions lock architectural boundaries.
Exit gates, release notes, and tests provide evidence for shipped claims.

Plans never override security boundaries. In particular:

plans, reports, and generated artifacts must not contain resolved secrets or source rows;
production profiles must explicitly allowlist plugins;
schema history stores fingerprints and metadata, never source data;
bronze, silver, and gold vocabulary remains in Medallantic rather than ETLantic core.

Choose a path¶

Evaluating ETLantic¶

Read the roadmap summary, then inspect only the relevant portfolio row above. Verify every needed feature against Capabilities.

Implementing a planned capability¶

Read the main roadmap milestone, the owning domain plan, related architecture decisions, the phase implementation plan, and the most recent exit gate. Treat code examples in plans as illustrative until the public reference documents them.

Maintaining the portfolio¶

Update the plan status, roadmap, capabilities page, release notes, and exit-gate evidence together when availability changes. Do not silently convert future language into a shipped claim.

Plan document contract¶

Every active plan should make these items easy to find:

status relative to the current release;
current shipped boundary and authoritative current documentation;
intended outcome and non-goals;
ownership and dependency boundaries;
milestones or workstreams;
security and data-handling requirements;
measurable acceptance or graduation gates;
required documentation, tests, and operational evidence;
open decisions and a trigger for the next review.

New plans should use this contract. Existing plans retain their detailed historical material, but their opening status block is the authoritative summary.