Physical Planning

Application meaning does not prescribe one database or process topology. The runtime selects a physical plan that satisfies correctness and operational requirements.

Possible realizations

The same logical information may appear as:

• transactional rows or key-value cells;
• columns and secondary indexes;
• logs and incremental dataflow state;
• browser or edge replicas;
• search documents and vectors;
• analytical aggregates;
• compiled functions, workers, or services.

These are generated artifacts, not independent authorities.

Inputs to the planner

The planner uses semantic dependencies, invariants, authority boundaries, workload observations, and objectives such as latency, freshness, durability, privacy, locality, and cost.

Changing an index or moving computation does not change a function result or the identity of a stored field.

Governed optimization

Physical planning is uncertain. Every plan must be inspectable, measurable, reversible, and optionally pinned. Escape hatches for SQL, native code, or external stores need explicit contracts so the compiler can retain correctness and deployment guarantees.