Non-goals

What tflo deliberately does not do, and why. This is the complement of deployment shapes — it spells out the boundary so contributors can argue about it instead of re-discovering it.

A feature request that conflicts with one of these does not necessarily mean "no" — it means "explain how this change is compatible with the stated reasoning, or argue why the reasoning should change." Each non-goal corresponds to a deployment shape or architectural property that tflo optimizes against in favor of its primary value prop: embeddable, edge, WASM, typed signals.

Streaming SQL

tflo's public interface is a Rust DSL (Iterator::tflo(...)). A SQL parser would inflate WASM binaries, push type-checking from compile-time to deploy-time, and introduce a foreign-language boundary in every pipeline. Engines that lead with SQL (Flink SQL, ksqlDB, RisingWave) are the right tool when SQL is the requirement. tflo is not in that lane.

Distributed runtime / job manager

tflo does not implement a JobManager / TaskManager / scheduler of its own. The supported scale-out path is Kafka consumer groups via KafkaShardRouter — the host's existing Kafka infrastructure provides partitioning, ownership transfer, and rebalance. Beyond that, the supplement pattern applies: host tflo inside Flink, Beam, or Kafka Streams and let the host own scheduling, scaling, and savepoints.

Exactly-once via two-phase commit

End-to-end exactly-once delivery requires either (a) transactional sinks coordinated with checkpoint barriers (Flink's approach) or (b) idempotent sinks with at-least-once delivery and deduplication. tflo commits to (b). The Deduplicator<K> primitive makes idempotent-sink behavior a first-class helper rather than per-user prose. Two-phase commit lives in the host engine when needed.

Cross-shard / global watermark aggregator

tflo's watermark is intentionally per-key. Cross-key alignment ("emit the joint signal only after every sensor has reported up to T") is a host-framework concern. Implementing a global watermark coordinator inside tflo would couple it to a shared-coordination primitive that doesn't fit the embeddable + WASM positioning. When cross-key event-time alignment is required, host tflo inside Flink or Beam.

Savepoints distinct from checkpoints

Flink distinguishes checkpoints (periodic, machine-managed) from savepoints (manual, human-named, used for deploys and disaster recovery). tflo provides only checkpoints today. A savepoint API can be added later if a real user need surfaces; it would be a thin layer over Checkpointer::commit with a named-key convention.

Processing-time mode

tflo is event-time-only. Watermarks advance based on input timestamps, never wall-clock. This is a feature, not a gap: the typed Computed = Result<f64, Absent> semantics depend on deterministic, event-time-driven evaluation. A processing-time mode would create two parallel semantic universes in one engine — a maintenance burden with no compensating user benefit for the deployment shapes tflo targets.

no_std / bare-metal MCU

Listed as aspirational in deployment shapes. The current codebase depends on std collections (HashMap, BinaryHeap, Vec) in keyed execution; lifting that requires a parallel no_std-compatible storage layer. Revisit only with a credible MCU use case and a contributor prepared to do the storage-layer work.