Collection runtime

The collection runtime is the host-side engine behind every read and write: the query compiler and the write pipeline. Neither runs tenant code, except where a declaration attaches a body.

Reads

A read decodes its where, select and orderBy strictly against the collection’s exposure, conjoins the caller’s grant scopes, substitutes field masks into every predicate, and compiles to one SQL statement; relations crossed by a filter or a sort become joins or subselects in that statement. There is no default page size: a read states limit or all.

The write pipeline

Every write passes the same steps:

1. Decode the input against the collection’s allowlist.
2. Judge the caller once against the grant: the scope on the stored row and on the result, and the writable fields.
3. Run the collection’s transform over the batch, in a guest isolate.
4. Apply the per-state to and edit rules.
5. Route approval from the grant that admitted the write.
6. Commit in one transaction, one statement per shape: idempotency, the revision check, sequences, roll-ups, check, noOverlap, history, approval stamps and queued runs.

Outcomes

The pipeline answers committed, pendingApproval, refused, conflict or unknown. A refusal is a business answer, never an exception.

History

Every committed change writes one revision per row, with only the changed fields and its cause (direct, cascade, derived, seed, hold, restore or erased). History is always on and pruned by the platform, never across the restore point of an open approval.

Seeds

Seed rows enter through their collection’s write pipeline in seed mode, which restores rows as given.