StateVec separates canonical state change from external effects.

That sentence sounds simple, but it changes where complexity belongs.

In the core server path, StateVec wants the smallest possible responsibility set:

command
  -> deterministic execution
  -> canonical commit
  -> replication
  -> recovery

Everything else is an effect of committed state.

SQL audit rows are effects. Query models are effects. Market data views are effects. Account and order query services are effects. Risk views are effects. Publication is also an effect.

The verified projector architecture gives those effects a disciplined place to live.

The roles

There are three important roles in this architecture.

leader / standby
  canonical state change

readonly projector
  verified materialization of committed transactions

projector plugin
  plugin-owned sink, read model, query service, or publication path

The leader and standby own canonical state. They ingest commands, execute deterministic business logic, commit ordered transaction results, replicate them, and recover canonical state.

A readonly projector consumes the canonical transaction stream after replication and materializes a local projected transaction stream. It does not decide transaction validity. It does not mutate canonical state.

A projector plugin consumes the projected stream and owns its own output: SQL tables, search indexes, query services, market data views, risk projections, or publication records.

The verified projected stream

The key boundary is the verified projected stream.

Each projected transaction carries the information a derived system actually needs:

  • transaction sequence;
  • command identity;
  • committed status;
  • deterministic record deltas;
  • deterministic events;
  • schema identity;
  • transaction hash.

The stream is host-owned and local to a readonly node. It is not canonical state and it is not the runtime recovery source of truth.

Its job is different: it is the input boundary for projectors.

Before a readonly node appends a projected transaction, it replays or materializes the canonical transaction with the loaded runtime schema. It then compares the deterministic output evidence with the canonical transaction hash.

If verification fails, the projected stream does not advance.

That gives downstream effects a stronger base than ordinary event forwarding:

projector input = committed transaction + verified deterministic materialization

Projectors own effects

A projector plugin owns its sink.

For a SQL audit explorer, the sink may contain transaction rows, record-delta rows, event rows, schema identity, and a durable projected frontier.

For a publication projector, the sink may be a Kafka topic or another publication transport, plus a durable publication frontier.

For a query service, the sink may be a database, search index, in-memory read model, or application-specific serving layer.

The important rule is that the projector owns its durable frontier. Host status may observe that frontier, but the host's cached value is not recovery truth for the projector.

That keeps the boundaries honest.

readonly_applied_tx_seq          canonical readonly apply frontier
projector_stream_tail_tx_seq     host-owned verified stream frontier
last_projected_tx_seq            plugin-owned durable sink frontier
last_published_tx_seq            publication-projector durable publication frontier

Those numbers are related, but they are not the same thing.

Materialized is not published. Published is not canonical. Projected is not served unless the plugin frontier says it is served.

Publication as a projector

Publication used to look like something the leader should do.

The leader sees the transaction result. The result contains events. Downstream systems need events. So the first design naturally puts publication near the leader.

The projector architecture changes that.

Publication is an external effect derived from committed state. It belongs beside SQL mirrors, query models, market data, and risk projections.

verified projected stream
      |
      +--> SQL record-delta explorer
      +--> market data projector
      +--> account/query projector
      +--> risk projector
      +--> publication projector

The publication projector consumes the same verified projected stream as other projectors. It publishes only after readonly materialization has succeeded and the committed transaction evidence matches.

That creates verified publication:

published record = effect derived from verified canonical execution

The mechanism depends on the same execution model described in Power of Speculative Execution: make the transaction input and output explicit, commit the result as a durable unit, and allow replay/materialization to verify it later.

Failure containment

This architecture reduces the failure surface of the canonical server.

The leader does not need to carry every sink's transport behavior, retry policy, queue pressure, and publication status in the canonical hot path.

Projectors still need serious engineering:

  • bounded queues;
  • durable frontiers;
  • idempotent sink writes;
  • gap detection;
  • rebuild tools;
  • schema compatibility checks;
  • lag and readiness status.

But that complexity sits behind the effect boundary.

If an optional projector fails, canonical state remains safe and the projector becomes degraded or disabled. If a required projector falls behind, readiness can degrade or stall according to its configured policy. The point is not to ignore projector failure. The point is to keep projector failure from silently corrupting canonical truth.

Rebuild and gaps

Projectors are not allowed to lie about history.

Some projectors are contiguous-only. A SQL record-delta explorer is one example: if it misses transaction 76108, the final canonical snapshot cannot reconstruct the missing historical delta rows. Publication is another example: a skipped range becomes externally visible.

For those projectors, missing history must be rebuilt from a trusted source, restored from a valid projector recovery point, or reported as rebuild-required.

This is why the verified projected stream is durable and ordered, and why projector frontiers are explicit.

The system should be able to say:

  • canonical state is recovered to tx N;
  • the projected stream is verified through tx S;
  • this projector sink is durable through tx P;
  • the missing range is P + 1 .. N;
  • the operator must rebuild, restore, or disable the projector.

That is operationally much better than serving a derived view that looks current but is missing history.

Why this is faster

The architecture was motivated by correctness, but it also helps performance.

A narrower canonical server does less work on the hot path. The leader focuses on deterministic execution, commit, replication, and recovery. External effects scale through readonly projectors.

This does not make effects free. It moves effect work to the right place.

The clean path is:

canonical path:
command -> execution -> commit -> replication

effect path:
verified projected stream -> projector-owned sinks

When the boundary is clean, the implementation often becomes faster because the system stops mixing unrelated responsibilities.

The architecture summary

StateVec's verified projector architecture is built around one principle:

Canonical servers own truth. Projectors own effects.

The verified projected stream connects them. It is derived from canonical history, checked by deterministic replay/materialization, and delivered to plugins that own their own sinks and frontiers.

That gives the system a practical path to SQL explorers, query services, market data, risk views, and verified publication without making the leader responsible for every external surface.

The companion story, When Publication Became a Projector, explains how this architecture emerged from the SQL record-delta explorer work.