Data, computation and policies

Transit organizes application data around explicit definitions, versioned snapshots, derived computations and operations whose outcomes can be inspected. Start with what the application needs to store and compute, then choose the interfaces that implement that lifecycle. Durable execution, write-ahead change streams and connectors supply the ordering, activation, publication and recovery mechanisms underneath it.

The local quickstart demonstrates this model with a Table you create, query and evolve through the console.

From data to decisions develops the proposed application experience through stories about enriched resources, shared evidence, branching within a realm and controlled publication by humans and agents. Its availability table distinguishes that direction from the operations below. The observation and feedback loop explains the product target: useful evidence before a decision and inspectable consequences afterward, so applications can revise their understanding.

This page connects existing data owners and their contracts. The shared model below is a way to reason about them; Transit does not yet expose every data kind and computation through one declarative catalog or automatic scheduler. See the system model for the formal state-space and plane-separation analysis.

Choose a data representation

Representation	Meaning	Definition and access
Table	Typed records with declared columns, nullability, defaults and optional primary keys	A configured catalog owns names (CatalogId), immutable schemas (DefinitionId), row publication and schema evolution; use SQL or typed catalog callers
Key-value resource	Keys and values whose encoding is selected by the application	Native client/resource operations; a query additionally needs an explicit decoder and projection
Document	Structured maps, lists and collaborative text with accepted revisions and explicit conflicts	Document services and callers own initialization, edits and reads; queries select an accepted projection

Choose the representation for the meaning of the data. A Document field can be missing or conflicted; an ordinary Table cell is a typed value or SQL NULL; a foreign or semi-structured field can fail conversion without aborting an entire scan. The shared query model preserves all five cell states—value, null, missing, type_error and conflict—rather than choosing an arbitrary successful value. Data types and the Document model define these distinctions, and the query-engine account explains how logical types, physical codecs (such as FSST, COMP-3 and EBCDIC) and collations (COLLATE) remain orthogonal.

A data object's identity (CatalogId), its human name, its immutable definition (DefinitionId) and the worker currently handling its writes are separate. Table and column identities survive renaming; dropping and recreating a name produces a different object. A saved operation or retained reader keeps its original binding. Define application data at the granularity it needs; a row does not require its own worker or durable process.

See Tables, KV resources and Documents for their exact mutation, ownership and lifetime rules.

Describe definitions, data and dependencies separately

A schema describes how to interpret rows. A query definition describes a computation and its sources. Published data is the accepted value or revision that an operation produced. Keeping these distinct makes questions such as “which schema did this result use?” answerable after later changes.

Dependencies connect that meaning: a query binds source identities and schemas; a prepared mutation binds its original Table and metadata; a maintained result records its source revision vector. They also constrain safe change. Table DROP RESTRICT checks explicitly registered dependencies, while applications must register the relevant records. It does not discover every external reader.

A complete declaration should make its data kind, interpretation, dependencies, permissions and requested execution lifetime clear. How it becomes usable is specific to its owner. Compiling an offline definition validates it without creating data, starting a worker or granting access.

Choose a computation lifetime

Lifetime	What the caller asks for	What survives and what to inspect
Interactive	Execute a finite query against fresh source snapshots	A logical session and bounded cursor; inspect complete rows and source evidence, then close it
Captured	Execute a frozen query with recoverable progress and retained results	The original accepted request, input basis, progress and verified result; inspect its recorded outcome after disconnect or worker loss
Maintained	Publish successive complete results as source history advances	The definition, recorded source vectors, completed revisions and deltas; inspect the last complete result and any stopped or pending successor

Supported operators and callers differ by lifetime. The console executes finite interactive queries and has explicit captured query operations. Typed Zig owners also support captured and maintained relational queries. Maintained activation and wakeups require an authenticated host; there is no automatic SQL materialized view service. Each recorded source basis is currently recomputed with the finite relational executor. The query reference owns these profiles and their budgets.

Reading a query definition starts no work. Named relational publication, authorization and activation are separate operations. Changes to a name cannot relabel an already accepted query. Named definitions retain that attribution.

Govern access and lifetime

Policies answer who can use an object, what work may run, and how long data and history remain available. They have distinct owners:

• Authorization: database, schema and Table privileges govern catalog data; native resource rights and execution ownership have their own checks. A name, cached schema or old snapshot does not preserve a revoked permission.
• Retention: accepted history is retained without expiry by default. An explicit supported policy can permit expiry; disk pressure cannot consent to deletion on the application's behalf.
• Execution budgets: reads, compute, staging and result delivery have bounded work and memory. A valid definition can still require a larger allowed budget or an unsupported operator.

Use security, role and schema administration and retention and capacity for configuration and exact controls. SQL query sessions do not apply the authorization compiler's administrative plans. Cross-owner policy and catalog operations do not form one atomic transaction.

Inspect whether a declaration is being fulfilled

Compare the requested definition with the evidence its owner exposes. A useful observation identifies the object and definition revision, the data basis, the operation or query identity, and the meaning of its outcome.

Question	Current evidence or interface	How to interpret it
Is my Table, KV, Document or computation published with the intended shape?	Console SHOW TABLES and DESCRIBE, catalog lookup, or inspectLifecycle (defined, published, pending, complete, unavailable)	A published or complete lifecycle state and definition digest establish publication; pending indicates in-flight provisioning/DDL or a computation whose upstream source revision advanced
Will my DDL or mutation intent succeed before I submit it?	Catalog previewDdl / TableClient.preview (admissible, unchanged, rejected)	Validates authorization, name/object conflicts, expected revisions, schema evolution work (metadata, validate_rows, rewrite_rows) and blocking RESTRICT dependencies without mutating state
Did my write or schema change apply?	Direct idempotent TableClient.apply, console statement result, or catalog operation outcome	Admission, processing and the terminal applied/rejected/cancelled outcome are separate; apply drives inline or multi-part uploads and continuations idempotently
What does this object depend on, what depends on it, and which policies govern it?	Catalog dependents, dependencies and policyReferences	dependents and dependencies expose the object-level dependency graph filtered by caller inspection rights; policyReferences reports authorization domains, capacity limits and retention while redacting internal authorization object IDs when the caller lacks SELECT (read) privilege
Which data did this query read?	The query's bound schema and source snapshots; complete result coverage	Independently captured resources need not represent one global or causal snapshot
Is a declared computation or maintained result up to date?	Catalog inspectComputation (fresh, source_available, source_revision, current_source_revision) and the typed owner's completed source vector	Completeness and freshness are relative to the recorded upstream revision; if the source schema evolves (current_source_revision != source_revision), fresh becomes false and the computation lifecycle transitions to pending until re-evaluated; if the upstream source is dropped, source_available becomes false and the state becomes unavailable
Can this caller still inspect or use the result?	Current authorization at metadata and result disclosure	A retained result or permission checked at admission does not authorize later disclosure

These observations are available through their owning interfaces; a single catalog-wide declaration health view is not provided. Board presents its configured inspection/query/application views. The interface map locates the relevant APIs and contracts.

If a result is delivered in pages, wait for successful completion before installing it as a complete replacement. A maintained consumer similarly applies a complete revision or delta and saves its position together. Partial delivery cannot establish a complete relation or justify skipping missing history.

Understand change and history

Table schema evolution validates existing rows before publishing a successor. Readers keep their original schema and cut until their read lifetime ends. Complete Table snapshot-and-tail capture preserves transaction boundaries, including updates, deletes and schema changes. Coalesced watch notifications instead tell a viewer to refresh; they do not contain every intervening change. See Table change capture and reactive views.

A retained data revision, a schema revision, a source progress position and a storage checkpoint answer different questions. Current resource snapshots and history do not expose general historical SQL, writable branches or arbitrary cross-resource transactions. The historical-read reference and query consistency model specify those limits.

Declarations and current interfaces

The product direction is to describe data, computation and policies together, then inspect their lifecycle through consistent public operations. The current interfaces provide different portions of that experience:

Declaration	Available today	Remaining public lifecycle
Tables and schemas	Table CREATE/ALTER/DROP, non-mutating preview, direct idempotent apply, column physical encoding ($\epsilon$) and collation ($\kappa$) descriptors, and DML through configured catalog callers; schema administration through explicit typed plans	Broader constraints, transaction sessions and other operations retain their documented SQL limits
KV and Documents	Client/service provisioning and access; SQL definition compilation (Declaration.compile) lowered to shared two-phase DeclarativeCatalog creation, rename, RESTRICT drop, and lifecycle inspection	Direct console SQL DDL routing and multi-resource atomic provisioning
Named captured/maintained relations	Immutable definitions, catalog ComputationSpec registration with upstream source_object/source_revision freshness tracking (inspectComputation), separate authorization and explicit activation through typed Zig owners	SQL view/subscription adapters and automatic service-managed scheduling
Connections, connector sources and sinks	Recorded connector operations and explicit application source bindings	Executable SQL declarations and shared dependency administration
Permissions and retention	Native authorization, selected SQL administration plans, policyReferences inspection with read-privilege redaction, and explicit supported retention policies	One declaration/reconciliation surface covering all data kinds and computations

The SQL capability inventory identifies executable, offline and grammar-only statements. The lifecycle gaps above describe product direction, not additional accepted syntax. Custom workers and connectors remain extension points for application behavior; external dispatch always requires its own authorized recorded operation.