Seven-Runtime Contract

TeaQL's seven runtimes use idiomatic host-language APIs, but they implement one model-driven application contract. Language tiers influence promotion and routine investment; they do not change the semantic contract.

For the current per-language evidence, read the Cross-language Conformance Status. That page is generated from a pinned, committed conformance snapshot and keeps design state separate from executable evidence.

Application lifecycle

Every generated application follows the same sequence:

1. Create and configure the provider or data service.
2. Create the trusted application context.
3. Install the generated passive Runtime Module.
4. Explicitly reconcile schema at a startup, test, migration, or administrative boundary.
5. Execute generated Q, E, and Mutation APIs using context.

Installing a Runtime Module must not create tables or seed data. Ensure Schema is context-scoped because the context owns routing, authority, policy, and the installed module. The language-native entry points are:

Runtime	Application shape
Java	context.ensureSchema()
Rust	context.ensure_schema().await?
TypeScript	await context.ensureSchema()
Swift	try await context.ensureSchema(module)
Python	await context.ensure_schema()
.NET	await context.EnsureSchemaAsync()
Go	generated lib.EnsureSchema(context)

Provider methods that receive low-level schema descriptors are internal SPI; they are not an alternative application API.

Query and result contract

• Generated Q APIs expose typed filters, relations, projection, ordering, aggregation, facets, and bounded pagination.
• Non-empty comment and purpose express query intent before execution.
• List and page terminals return typed entities through the runtime's SmartList, including applicable result metadata.
• Loaded null and not-loaded are distinct states.
• Language-native APIs may exceed the portable TFP subset. A native PASS must not be copied into the TFP column automatically.

Exact generated method names come from the model-aware Assist output. Do not translate a Java method into another language by intuition or form plurals in a template.

Mutation contract

• Create, fully loaded update, and deletion use the generated Mutation lifecycle and a trusted context.
• Every mutation carries an audit reason.
• Checker and context-derived Fix run before the first provider mutation.
• Deletion is an intent in the same graph save lifecycle, not an invented physical-delete shortcut.
• One graph has one isolated Mutation Ledger; a shared context must not merge pending changes from independent graphs.
• A successful save returns the authoritative persisted typed entity and version.

Identity and bootstrap

Portable Entity IDs and aggregate-root Business IDs are different contracts. Entity ID allocation is aligned across seven runtimes. Business ID generation has a narrower current evidence boundary; consult the matrix before presenting it as a cross-language capability.

Root records and constants are installed through explicit schema/bootstrap work. Repeated execution must be idempotent, and the ID allocation floor must remain ahead of model-defined identifiers.

Runtime-owned and application-owned responsibilities

The runtime owns generated semantics, policy hooks, mutation planning, Checker/Fix integration, and provider-neutral contracts. The application owns credentials, trusted identity, tenant and permission inputs, provider lifecycle, telemetry exporters, and operational schema-change policy.

Optional telemetry is no-op by default and must not replace audit delivery. Localization catalogs are installed explicitly. Unsupported infrastructure is not considered supported merely because a third-party SDK exists for a language.

Evidence boundary

Use the narrowest accurate state:

• Design implemented: the approved API/behavior exists.
• Executable PASS: retained tests passed for the stated version and environment.
• Published PASS: a clean consumer passed using released artifacts.
• Supported: maintainers published an explicit scope and lifetime.

Package discovery alone proves none of the later states. For current package coordinates, use Latest Versions; for dated provider execution, use the Runtime and Database Matrix.