The Unified Persistent Pipeline

Unlike traditional tools that split "Dev" and "Build" into two different worlds, Ionify uses a single, deterministic pipeline across the entire lifecycle.

Source Files
→ Native Resolver (Rust-powered module resolution)
→ Dependency Publication Layer (One Dependency Authority)
→ Persistent Dependency Graph (The source of truth)
→ Hybrid Transform Engine (OXC primary, SWC fallback)
→ CAS Storage (Content-Addressable Storage)
→ Unified Output (Dev Server or Production Bundler)

The goal is not just to execute faster. The goal is to avoid rediscovering the same project knowledge every time the engine runs.

Development and production are not the only consumers of this pipeline. CI is a consumer too.

A CI run with no cache rebuilds from zero. A task-level output cache improves this only in whole-task units: an unchanged task replays its stored output, but any change to a task's inputs is a full cache miss that rebuilds that project from scratch — there is no partial reuse inside the unit. Because Ionify keys authority to fine-grained identities rather than whole tasks, a run re-establishes only the invalidated identities and consumes the rest. A small change costs a small amount of work, not a full project rebuild.

Build once, reuse forever — including compression

Compression is part of the build, not a separate post-step. Ionify stores compressed artifacts in CAS under their content identity, so they are compressed once and reused. When something changes, only the invalidated parts are re-established and re-compressed — the rest are consumed as-is. Nothing re-compresses the whole output because one module moved.

Within a runner that persists its `.ionify/` state, this reuse — including compression — carries across runs. Sharing verified work across separate machines is the role of Cloud CAS (in progress); cross-machine reuse is not claimed until it ships.

The Theory of Build Authority

Build Authority is not a feature. It is a theory, and the architecture below is its implementation.

The theory is founded on one motivating axiom, made achievable by three structural principles, from which two behaviours emerge as consequences.

Everything on this page — the dependency authority, the styling and production authorities, canonical identity, the shared graph and CAS — exists to make those principles real.

One Dependency Authority

Ionify does not treat dependencies as temporary pre-bundle outputs.

Dependencies are analyzed once, published as canonical artifacts, and consumed through the same contract across development and production.

This is the foundation of Ionify’s Dependency Publication Layer.

Instead of every subsystem independently rediscovering dependency behavior, Ionify publishes:

Export ABI Manifest: the declared export surface of optimized dependencies.
Export Surface Hash: a deterministic identity for dependency export behavior.
Singleton Ownership: one owner for shared dependencies across the build plan.
Fail-Closed Resolution: dependencies never silently fall back to raw `node_modules` hydration.
Symmetric Re-Export Handling: import and re-export misses follow the same ownership authority.
Chunk Identity Includes Dependency ABI: production chunk identity folds in the dependency ABI state, so chunks cannot reuse stale dependency assumptions.

This means the dev server, production bundler, vendor packs, federation layer, and future cloud storage can all consume the same dependency authority.

Pre-bundling creates optimized files.

Ionify publishes dependency contracts.

The Styling, Production, and Readiness Authorities

Dependency knowledge is not the only category that needs an owner. Ionify runs the same Single Ownership discipline across the rest of the lifecycle.

CSS Authority (CSSA) owns styling knowledge — CSS artifact identity, content demand, CSS dependency freshness, module tokens, and artifact restoration. Because styling output can depend on non-CSS source content, plugin configuration, and pipeline settings, CSSA fails closed when completeness is uncertain rather than narrowing its inputs from partial state.

Production Artifact Publishing (PAP) owns production publication. During idle time — before a production build is ever requested — PAP publishes verified production contracts, and optionally chunk artifacts, into `.ionify`. It does not emit `dist`; it establishes production authority ahead of the build. When a production build or deploy later runs, it consumes and verifies that published authority instead of re-deriving it, so production knowledge is reused rather than reconstructed.

Production Readiness Authority (PRA) owns deploy-readiness. It writes and validates a deploy-readiness record over plan proof, chunk manifest hash, dist output proof, compression proof, engine identity, dependency identity, and configuration identity — so readiness is a verified record, not a folder scan.

Each is one authoritative publisher for its category. Everything downstream consumes these publications rather than re-deriving them.

🦀 Rust-Native Core

Ionify handles performance-critical operations—including dependency resolution, graph management, parsing, bundling, and artifact planning—inside a native Rust core.

This lets the engine maintain stable performance as project structure and dependency counts grow, because reuse is driven by identity rather than by re-scanning the whole project.

Rust is not used as a thin acceleration layer. It is part of the engine’s architectural foundation.

🧠 Persistence-First Design

Ionify does not just "cache" files. It persists the structure and history of the project.

Persistent Graph: dependency relationships survive restarts, branch changes, and dev/build transitions.
Content-Addressable Storage (CAS): transformed modules and build artifacts are stored by content identity.
Immutable Artifacts: existing artifacts are never mutated. New inputs create new identities.

If the code, configuration, and dependency ABI have not changed, Ionify can reuse valid work instead of repeating it.

Reliability Through Version Isolation

Ionify avoids "mystery stale cache" behavior through explicit identity boundaries.

versionHash: locks graph and transform artifacts to a specific engine/configuration state, including parser settings, defines, and relevant build options.
depsHash: partitions optimized dependency sessions so dependency changes do not invalidate unrelated source transforms.
abiHash: captures the export behavior of published dependencies so production chunks cannot reuse stale dependency assumptions.

Together, these identities allow Ionify to reuse aggressively without guessing.

Reuse is safe because identity is explicit. When an identity cannot be proven, Ionify fails closed and re-establishes the knowledge rather than trusting whatever sits on disk.

There is an honest limit here. A stable identity proves that the included inputs did not change. It does not prove that every relevant input was included — that is Invalidation Completeness, and it is the central design problem these identity boundaries exist to manage.

Hybrid Transformation Strategy

Ionify uses a hybrid transformation engine to balance speed and ecosystem resilience.

OXC: the primary fast path for modern JavaScript and TypeScript transformation.
SWC: a compatibility fallback for edge cases that require broader ecosystem coverage.

Both engines live inside the same pipeline. Developers do not choose between speed and resilience; Ionify routes work through the appropriate path automatically.

Traditional tooling often has a split-brain problem: the dev server and production bundler may resolve, transform, optimize, or interpret dependencies differently.

Ionify is designed around a stricter rule:

Dev and build must consume the same dependency boundary.

That means dependency artifacts created for development are not a separate temporary world. They become part of the same dependency authority used by production planning.

This reduces an entire class of bugs where something works in development but breaks after deployment because production rediscovered dependency behavior differently.

From Execution to Authority

Because Ionify persists dependency structure, transform history, artifact identities, and dependency ABI metadata, the engine can observe patterns that traditional stateless bundlers discard.

Ionify can reason about:

which modules change most often,
which transforms cost the most,
which dependencies own shared runtime behavior,
which artifacts are safe to reuse,
where production chunks depend on dependency export surfaces,
how project structure evolves over time.

This is the foundation for Ionify Analyze, Cloud CAS (in progress), and Authority Federation.

Ionify does not just run your build.

It owns the truth it builds.