Order Workflows Across Seven Runtimes

Use the same order workflow to compare business behavior across languages, then develop each ecosystem's integration separately. Page counts and identical code structure are not the acceptance criteria.

Start with a tutorial

Choose Java, Rust, TypeScript, Python, Go, C# / .NET or Swift to learn startup, a full Order read, an atomic edit and bounded pages with the existing native example open. Use the API usage guide for lookup and the coverage matrix for remaining writing work. The rest of this page records shared business contracts and evidence boundaries.

For the next business step, use the advanced mutation tutorial matrix. It links each language's explicit deletion, status-transition and version-conflict recipes, with the native transaction/error differences and expected readback.

For language-local query walkthroughs, choose an Order query tutorial. They explain the export/insights fixtures, continuous plans, retained IDs and provider summaries using the existing qualified applications.

Verified on 2026-10-28: 7/7 sustained concurrency and resource-release checks. The finite soak uses four retained workers per runtime, at least 120 seconds of mixed load, 13,951 total operations, 77 database snapshots and 49 writer probes. Native transaction, connection and request-task release is checked through drain, cooldown, recovery and provider shutdown. The exact lifecycle runtime builds and all pending-release markers remain retained.

Verified on 2026-10-28: 7/7 request lifecycle checks on Order model revision 1.2.0. The lifecycle receipt records 315 independent SQLite checkpoints and 147 lock probes, with native cancellation, provider statement faults, real COMMIT failures and same-provider recovery. Java needs the new JDBC workspace fix and remains RELEASE PENDING for this lifecycle scope; its earlier published passes remain unchanged.

Verified on 2026-10-28: 7/7 stock reservation checks on model revision 1.2.0. The stock receipt records 47 reservation requests and 56 independent SQLite checkpoints per language (392 total), including 42 synchronized two-process race rounds. It proves Order/inventory rollback after a late receipt INSERT failure, oversell prevention and scoped idempotent replay using local evidence only.

The retained buyer/tenant isolation receipt remains 7/7 on model revision 1.1.0, with 46 probes and 50 checkpoints per language (350 total). The 119/119 core scenario receipt on the original model and School baseline also remain retained regression evidence. These are distinct model revisions and execution scopes.

Retained core suite: 119/119 native scenarios and 7/7 SQLite databases. Each language passes the same seventeen Order cases. The final two core cases cover retained ID-set pagination and filtered order summaries; the suite also reruns all fifteen previous cases. The P2 retained-ID and summary receipt binds executable sources, validation code, runtime identities, actual store events, provider SQL, process barriers and 106 independent database checkpoints per language (742 total). Concurrent cases still repeat three times: 49 rounds and 98 worker processes across seven languages. Subchecks, pages and rounds do not increase the seventeen-case count.

The 56/56 first-flow receipt, 77/77 concurrency receipt, 91/91 complete P1 receipt and 105/105 pagination receipt and their sources remain unchanged. The original three-order fixture, nine-order pagination fixture and new ten-order fixture use separate SQLite databases and exactly the same KSML model.

The retained core stage used local evidence only: the unchanged model's hash matches its retained zero-error evaluation, generated libraries are reused, and 140 scoped Assist responses were rendered and tested by the local generator. The discovery manifest and model review record this boundary. That stage made no fresh successful online evaluation or online Assist claim. The isolation revision is evaluated, generated and queried with the local generator; its local discovery manifest retains zero-error evaluation, 14 generated targets and 182 scoped Assist responses. The stock revision has its own local discovery manifest, with zero-error evaluation, 14 generated targets and 343 scoped Assist responses. No model transmission or online generation is used.

Go, TypeScript, Rust, Python and .NET use workspace runtimes and remain RELEASE PENDING. The retained core, isolation and stock suites use published Java and Swift runtimes. The new lifecycle scope adds the Java JDBC workspace fix pending release; Swift retains its published pass. The existing School pagination fixes are required for the Rust, Python and .NET acceptance checks added here; their published failures remain in the retained pagination receipt. Go and TypeScript retain their previous qualifications. TypeScript's nullable generator fix, console guides, Rust nullable Assist, pagination Assist, Java empty-list append and stock append Assist fixes remain pending generator deployment. The original model/Assist receipt remains unchanged; its original inputs are archived separately.

The School advanced suite remains a separate 238/238 regression baseline. Its pending-release markers remain attached to its recorded runtime versions. Older Order Search and context-bound editing articles provide design context, but their results do not certify this new model.

One small business model

Download the complete KSML model, fixture, and acceptance expectations.

Object	Role in the workflow
commerce_platform	Domain root and common fixture identity. It does not, by itself, enforce tenancy.
order_status	Constants DRAFT (1001), CONFIRMED (1002), CANCELLED (1003).
customer_order	Order number, buyer reference, status, currency, total, nullable note and timestamps.
order_item	Parent order, SKU, product label, quantity, unit price, line total and timestamps.

customer_order is the business Order and order_item is its line item. Business objects receive generated IDs; tests locate them by order number and by SKU within the order. buyer_reference is an opaque fixture identifier, not authenticated identity or an authorization policy.

The original fixture uses integer USD cents: Notebook costs 1250, Pen costs 450. Application code validates quantity and computes line_total_minor = quantity * unit_price_minor and total_minor = sum(line_total_minor). These are acceptance requirements; declaring fields does not prove that the generator enforces the arithmetic. The first fixture excludes tax, discounts, shipping charges and currency conversion.

The nullable order_note="string()?" declaration deliberately retains evaluation warning KSML-BUSINESS-002, which prefers a representative string. Concrete values belong in the fixture: text, SQL NULL and empty text. The two optional suggestions concern status colors and progress, which this native workflow does not use. Read the final evaluation report.

First flow: edit a draft order

All seven implementations use a native console and real SQLite for this first acceptance flow. HTTP, Apple UI and browser/TFP integration have separate gates.

1. Explicitly initialize schema through the complete Runtime Module. Seed three DRAFT orders through generated audited mutations; each has two items and total 3850 cents. No SQL seeding or substitute repository is permitted.
2. Read the three orders with stable ordering and complete bounded item lists. For edits, find one order by business key and bound the query to detect duplicates. Every query declares comment and purpose.
3. Run the four note probes below as independent read-only scenarios. Use the generated expression API and retain its native error evidence.
4. Fully reload the order and items before mutation. The reduced projection used for the NotLoaded check must never become a mutation target.
5. Change Notebook quantity from 2 to 3. Save its line total 3750 and the order total 5100 with an audit reason in one provider transaction. Use the native transaction contract discovered for that language; several independent saves are not evidence of atomicity.
6. Reject quantities 0, -1, 1.5 and 101 before saving. Load at most 101 items and reject more than 100 before computing a total, so a truncated preview cannot silently become the entire order. Prices are nonnegative integer cents bounded by the fixture; all arithmetic must remain exact and within its limits.
7. Read the committed result in a fresh native process. An independent read-only SQLite check compares row counts, relations, every business field and versions. The edited order and Notebook advance from version 1 to 2; Pen and other orders remain unchanged. Only updated entities may advance their update timestamps.

Query projection and stored note	Expression result	Null-only default
Selected, Leave at reception	Value containing that text	Preserve the text
Selected, SQL NULL	Loaded Null	Return No note
Selected, empty string	Value containing empty text	Preserve empty text
Not selected, regardless of stored value	NotLoaded with missing field path	Still NotLoaded; no fallback

The captured Assist specifies native exceptions for Java, TypeScript, Python, .NET and Swift, and panics for Rust and Go. Negative checks must identify the missing-field failure rather than accepting any nonzero exit. Isolate probes so one panic cannot suppress the remaining results. See each language's expression response in the Assist ledger.

The rollback control clones the seeded database, independently commits a newer item revision, then attempts an older order/item edit. Provider logs must show an order UPDATE before the stale item UPDATE fails. The database oracle requires all order fields and timestamps to roll back while retaining the competing item revision. Busy, locked and timeout errors cannot count as optimistic conflicts. Java, TypeScript, Python, Go, .NET and Swift save one loaded graph; Rust saves the order and item inside one explicit provider transaction.

An item's omission from an edited projection does not authorize deletion. The removal controls and state matrix below verify this boundary and the rule that only DRAFT orders permit item editing.

Expired versions and concurrent writes

These three P1 scenarios use the same model and seeded orders. Each round starts from a separate SQLite backup of the verified seed. Workers change only the order note, so the oracle can compare amounts, items, relations and unrelated fields exactly.

1. Start two native processes. Each loads one complete order with a bounded Q query, comment and purpose, retaining the original version. A reduced projection is never a mutation target. Each process atomically publishes its PID, target, note and version.
2. Wait for both ready files. Require distinct PIDs and version 1, then independently inspect SQLite to prove neither worker wrote before release.
3. For stale-order, release B and verify its committed note at version 2 in SQLite before releasing A. A must report a native optimistic conflict; every field and timestamp of B's committed result must remain unchanged.
4. For concurrent-same, release both workers with one barrier file. Exactly one saves successfully and one reports an optimistic conflict. For concurrent-distinct, use two order numbers; both must commit with their own note and version 2.
5. Require the audited provider UPDATE, then compare all persisted rows. Only the winning order's note, version and update timestamp may change. Launch a fresh native process to read the complete graph and check SQLite once more to prove readback is inert.

Both concurrent cases run three independent rounds. Workers have a 45-second barrier limit and never reload or retry a write after release. Busy, locked and timeout errors fail the case; they cannot stand in for optimistic conflicts. This is a bounded SQLite concurrency check, not a sustained stress test or certification of another provider.

Read the three-case acceptance catalog, read-only database oracle, execution notes and 35 scoped Assist responses.

Explicitly remove a line

Each language runs three controls against separate copies of the verified seed:

1. Omission is not deletion. Load all order scalars with a filtered Notebook-only child preview. Save only the order note with an audit reason. The independent oracle requires both original items, their versions and every item field to remain.
2. Explicit removal is atomic. Fully reload the order and all bounded items, validate quantities and prices, then mark SKU-PEN for deletion using the generated deletion API. Recompute the remaining total as 2500 cents and save total and removal in one provider transaction. The order advances to version 2; Pen remains in SQLite at version -2. A fresh normal query sees only Notebook; a fresh deleted-only query returns Pen with its negative version.
3. A stale deletion rolls back the total. Independently advance Pen's label and version, then attempt removal using the original item version. The provider log must show the order UPDATE before the failing item UPDATE. Every order field and timestamp must roll back, while the independently committed Pen remains at version 2.

For removal, Java and Rust use explicit native provider transactions and save the order before the item. TypeScript, Python, Go, .NET and Swift save one loaded graph. Java's initial graph-save attempt rejected the stale deletion before issuing the order UPDATE; that attempt is retained and does not count as rollback evidence. The final Java example obtains the native TransactionExecutor from the runtime registry attached to its trusted context. It does not rely on framework annotations.

Every control has an independent database check before mutation, after mutation and after a fresh-process read. Soft deletion retains row identity and relationships; unrelated orders, item amounts and timestamps must remain unchanged.

Apply an order status transition

The application checks the complete loaded order and its original version before calling a generated status constant setter and an audited save. The model declares the constants; application code enforces this transition matrix:

Current status	To DRAFT	To CONFIRMED	To CANCELLED
DRAFT	Reject	Commit	Commit
CONFIRMED	Reject	Reject	Commit
CANCELLED	Reject	Reject	Reject

All nine pairs are executed. Repeated transitions deliberately reject without writing. Three additional probes reject an unknown target and call the actual item edit operation on CONFIRMED and CANCELLED orders. Each rejected operation must emit no order/item UPDATE and preserve every persisted field and timestamp exactly. Accepted transitions change only status, version and update timestamp; item values, totals and other orders remain unchanged. A fresh native process reads each outcome, followed by another independent SQLite check.

The twelve state probes and three removal controls are subchecks within two cases, so this stage adds 14/14 language/case cells. See the acceptance catalog, read-only oracle, execution notes and 92 scoped Assist responses. These states have no payment, refund or stock side effects in this fixture.

Bounded order search

The pagination cases keep the same KSML model and use a separate fixture of nine orders and 27 items. Eight orders belong to BUYER-EXPORT; one belongs to BUYER-CONTROL to detect filter leakage. Each order has Notebook, Pen and Sticker items. Stored totals are 3950 or 5200 cents, deliberately creating ties. Seed data still goes through the generated audited API; the independent SQLite oracle only reads it.

The pages-bounded phase filters by buyer and orders by total, then ID. It accepts offsets at least zero and limits from 1 to 3 orders. Each parent includes at most one item preview, ordered by SKU then ID. The preview retains its own item identity and amount; the order retains its full stored total. Summing that preview would produce the wrong order amount.

Ten probes check the first and middle pages, the two-row partial page, an empty tail, an offset beyond the end, a filter matching nothing, a repeated first page, and three invalid bounds. Empty tails still report the filtered total 8; the empty filter reports 0. Negative offsets, zero limits and limits above three are rejected before any order SELECT. The SQL oracle checks ordering, relations, preview limits, amounts and exact filtered totals independently.

Continuous order export

The pages-export phase uses one context per sequence, a trusted namespace and a 300-second cursor TTL. Every query declares its purpose and requests an exact count. Pages contain at most three orders. A bounded loop stops on an empty page and fails if it would exceed ten pages. This fixture is exported in four queries: 3, 3, 2, 0 rows.

Sequence	Acceptance
Ascending ID	Export all eight matching orders exactly once; observe FIRST_PAGE, two CURSOR_SEEK plans and an empty-tail CACHE_MISS.
Descending ID	Export the same eight identities in reverse order with the same plan progression.
Missing cursor	Start a fresh context at offset 3, observe CACHE_MISS, then recover to CURSOR_SEEK at offset 6.
Composite sort	Sort by total then ID; retain the native explanation for offset fallback on both pages.
Changed predicate	Read the export buyer, then query the control buyer at offset 3 in the same context; require CACHE_MISS, no rows and exact total 1.
Process restart	Start another native process and export all eight again from a fresh first page, with no duplicate or missing IDs.

These six sequences produce 18 pages per language: seven cursor seeks and eleven offset fallbacks. Plans come from the runtime's own observation API, and the logs must contain the corresponding SQL ID boundary for every seek. A provider SELECT COUNT must count the whole filtered set on every page, excluding the cursor boundary. A trace entry that merely mentions count() cannot satisfy this check.

Composite-sort reason names differ: Java reports ORDER_NOT_SINGLE, Rust, Python and Go report ORDER_NOT_SEEKABLE_ID, and TypeScript, .NET and Swift report UNSUPPORTED_QUERY_SHAPE. A planner may report FIRST_PAGE before inspecting the sort on offset zero. The receipt retains the actual reason; DISABLED and a misreported FIRST_PAGE at a nonzero offset fail acceptance.

The P2 catalog, read-only page oracle and execution notes define these two cases. Every sequence is followed by a complete SQLite snapshot: rows, versions, relations and timestamps must remain identical. The stage adds 14/14 language/case cells and 126 database checkpoints to the retained 13-case suite. It verifies export over a fixed dataset; snapshot-consistent export during concurrent writes, continuous-cursor expiry and larger export budgets need separate cases. Retained-ID lifecycle checks are covered separately below.

API discovery retains 84 scoped Assist responses and a tested generator supplement for the pagination APIs omitted by the published Assist service. The supplement renders this exact Order model in all seven languages and remains pending deployment.

Retain IDs for random page access

The new fixture has ten orders and thirty items: eight USD orders for BUYER-EXPORT, one USD buyer control and one EUR currency control. DRAFT, CONFIRMED and CANCELLED are all represented. Seeding uses generated, audited mutations. All reads filter by buyer and currency, sort by total then ID and return at most three orders. One trusted context and store serve each sequence.

Sequence	Required native behavior
Random jumps	Offsets 6, 0, 3, 9, 0: build once, then hit the same ordered ID set four times; the empty tail retains exact total 8.
Empty predicate	Retain an empty set, then hit it; exact total remains 0.
Capacity overflow	Set maxIds=4: observe ID_SET_FALLBACK_LIMIT_EXCEEDED and lower bound 5, retain no partial set, and obtain exact total 8 from a separate provider count.
Predicate isolation	Change to the control buyer in the same context and namespace: build a separate one-ID set, then hit the original set when returning to the export buyer.
Expiry	Use a one-second TTL, wait at least 1.3 seconds in real time, and rebuild the same query key.
Explicit invalidation	Invalidate the actual observed key between a hit and the next query; require a new build.

The receipt records the actual keys, complete ordered IDs, store reads/builds/hits, wait duration and invalidation. Nonempty hits must issue provider SQL using the retained identities. Empty hits may return without issuing SQL. The overflow lower bound never substitutes for the filtered exact count.

Java, Rust, Python, Go and .NET wrap the runtime's in-memory store for observation. TypeScript uses an application-owned store implementing the public runtime protocol, including TTL and invalidation. Swift delegates retention and TTL to its native store; its public protocol lacks explicit invalidation, so an application-owned adapter removes the delegate for the observed key. These two lifecycle adapters are part of the examples, not claims about default runtime invalidation APIs.

This check exposed a .NET query-key collision: ToString() on compound expression lists lost their operands. The workspace repair serializes the typed condition tree, including nested AND/OR and list values. It also protects continuous pagination, which uses the same key builder. The repair record retains the failing run, source patch, package identity and targeted runtime tests. The repair remains RELEASE PENDING; the older .NET receipt is unchanged. The new Swift example also publishes worker readiness via a closed temporary file and atomic rename after a partial-file read was observed in the retained concurrency regression.

Summarize the same filtered orders

The insights-summary phase applies the same buyer, currency and minimum total predicate to rows, provider aggregates, exact counts and both status-facet variants. It executes provider GROUP BY status, COUNT and SUM(total_minor) with at most four aggregate rows, plus a separate one-row overall aggregate. Native group-field names are mapped into the shared report without recalculating aggregates in application code.

Probe	Expected count and amount
Export buyer, USD	8 orders, 35350 cents; all three statuses present.
Export buyer, USD, minimum 5000	3 orders, 15600 cents; DRAFT is an empty bucket.
Control buyer, USD	1 CONFIRMED order, 3950 cents.
Export buyer, EUR	1 DRAFT order, 3950 euro cents; USD orders are excluded.
Missing buyer	Count 0, provider SUM is null, all status buckets are zero, matched-only buckets and rows are empty.

All-bucket facets include every status constant; matched-only facets omit zero buckets. Parent rows cap at three, with one item preview per parent ordered by SKU then ID. Exact totals and aggregates cover the entire filtered set, not just the page or preview. The EUR fixture is an isolation control; no currency conversion or cross-currency total is claimed.

Six retained-ID sequences and five summary probes are subchecks within two cases per language (14/14 new cells). Every sequence is checked by an independent, read-only SQLite oracle and followed by a complete database snapshot. All fields, identities, relationships, versions and timestamps must remain unchanged. Read the acceptance catalog and execution notes for the exact bounds. These fixtures do not establish authorization or snapshot consistency under concurrent writes.

Buyer and tenant isolation

Follow the seven-language isolation tutorial matrix for the model upgrade, native context/session seam, scoped APIs and troubleshooting.

The isolation model revision 1.1.0 adds commerce_platform.tenant_key. An order belongs to its tenant through customer_order.commerce_platform; an item inherits ownership through its order. This revision leaves the original model and all dated Order receipts intact. The exact revised model passes local evaluation with 0 errors, 1 accepted nullable-note warning, 2 optional suggestions and no skipped rules.

The fixture contains two tenants, two buyers in each tenant, two orders per buyer and two items per order: 8 orders and 16 items. Both tenants reuse BUYER-A and BUYER-B. All four scopes reuse ORD-SHARED-001 and ORD-SHARED-002, so a business key or buyer predicate alone cannot identify an authorized order. Status constants are a shared global catalog.

Server-owned session	Tenant	Buyer	Visible orders / amount
ACTOR-A	TENANT-A	BUYER-A	2 / 7700 USD cents
ACTOR-B	TENANT-A	BUYER-B	2 / 7700 USD cents
ACTOR-C	TENANT-B	BUYER-A	2 / 7700 USD cents
ACTOR-D	TENANT-B	BUYER-B	2 / 7700 USD cents

An application-owned facade uses a trusted session record alongside the native server-owned UserContext; it constructs the scope explicitly rather than rebinding a native tenant/actor for each session. Every Order query includes both the resolved tenant root and the session's buyer, before provider execution. The facade accepts only declared business request fields. Tenant, buyer, actor, permissions, policy and context in request JSON are rejected before any provider SELECT or mutation. Missing or unknown sessions fail the same early gate. The fixture also has a read-only actor whose writes are rejected before provider access.

These examples use a server-owned synthetic session registry. A production application supplies authenticated membership at that seam. The facade owns the query and mutation entry points; this is application authorization, not automatic SQL row-level security for arbitrary raw Q or direct database access. A duplicate or missing trusted tenant key fails closed instead of selecting a tenant arbitrarily.

The public operations and their acceptance checks are:

• Lists, detail and business keys: return only the current tenant/buyer rows, with at most two parents and a bounded owned-item load. The seeded orders each have two items; detail/edit operations reject an item-list overflow. Explicit page terminals provide exact filtered totals. Order IDs belonging to another buyer or tenant, and nonexistent IDs, all return the same NOT_FOUND shape.
• Item access: resolve the authorized parent first and locate the item inside that parent's complete bounded item list. Foreign-parent and cross-parent item IDs return NOT_FOUND; no unscoped item lookup supplies business data.
• Summaries: native provider COUNT and SUM use the identical tenant/buyer predicates. Every scope has count 2 and total 7700; results are checked against independent SQL rather than sums of loaded pages.
• Retained IDs: one server context and trusted fixed namespace query sessions A, B, C, A. Plans must be BUILD, BUILD, BUILD, HIT, with the correct distinct order identities and exact totals. These pages omit unloaded child fields; ordinary list/detail probes verify children separately. TypeScript retains its application-owned implementation of the public store protocol.
• Writes: allow only an order note or owned item label. The note command uses complete scoped Order state; Python, TypeScript, Go and .NET explicitly reload scalars without children before saving, while Java, Rust and Swift keep their recorded parent-save semantics. Forbidden identity, buyer, tenant, status, amount, version or unknown patch fields fail before provider access. Foreign IDs cannot write. Each allowed edit changes exactly one permitted field, its version and update timestamp; fresh native reads and SQLite compare every unrelated field, row and relationship.
• Bounds and unknown input: reject zero, negative, over-limit, fractional, null, boolean and string limits, and unknown filter input before querying.

The catalog has 45 request probes plus one four-step cache sequence per language. The two successful writes also receive fresh-process readbacks. Every operation has an independent read-only SQLite check, giving 50 checkpoints per runtime and 350 total. The repeated probes do not inflate this single P2 scenario's 7/7 language/case count.

Local generation exposed and repaired stale graph-save contracts in Python, TypeScript, .NET and Go: root mutation intent, session ownership, transaction-scoped callbacks and acceptance of the authoritative committed version. The TypeScript relationship Assist now names the actual filterByCommercePlatform API. Repairs are applied to generator templates and regenerated; emitted domain source is never hand-edited. Read the source-bound discovery manifest, generator patch and execution notes. These generator repairs remain pending deployment. Java and Swift retain published-runtime passes; the five workspace runtime qualifications remain pending release, including the .NET condition-key repair from the previous receipt.

Download the isolated executable facade for Java, Rust, TypeScript, Python, Go, C# / .NET, or Swift.

The commands below resume the recorded, locally generated workspace. Its Python virtual environment, Node dependencies/lockfile, Swift checkouts and local runtime archives were populated from the retained core artifacts. Use the same recorded native toolchains and source identities. A newly generated workspace also needs those offline dependencies provisioned before build.

The exact local evaluation/generation command is recorded in the discovery manifest. Its final comparison run writes final-local-generation/; all generated file hashes match the active verified workspace. Static evidence replay below does not require provisioning a new native workspace. Both native stages use the same explicit runtime overrides:

npm run verify:order:isolation -- --stage build \
  --output artifacts/order-isolation/2026-10-27 --cache-dir artifacts/school/2026-10-27 \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /path/to/teaql-rs-with-pagination-fix \
  --python-runtime /path/to/teaql-python-with-pagination-fix \
  --dotnet-runtime /path/to/teaql-dotnet-with-condition-key-fix

npm run verify:order:isolation -- --stage verify \
  --output artifacts/order-isolation/2026-10-27 --cache-dir artifacts/school/2026-10-27 \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /path/to/teaql-rs-with-pagination-fix \
  --python-runtime /path/to/teaql-python-with-pagination-fix \
  --dotnet-runtime /path/to/teaql-dotnet-with-condition-key-fix

The runner uses existing local runtime archives and populated dependency caches. It supports build/verify, with no online evaluation, Assist or generation step. To replay retained evidence without rerunning native programs:

npm run evidence:order:isolation -- --check
npm run check:order-contract
npm run test:order-contract

Reserve stock with an order

The stock model revision 1.2.0 adds Inventory, immutable StockReservation receipts and a tenant reservation_sequence. The earlier Order 1.0.0, isolation 1.1.0 and School models and receipts stay separate. This stage uses local evaluation, generation, Assist and cached dependencies throughout; no model was sent online.

The fixture has two tenants, two buyers per tenant and four single-item orders per buyer. Their quantities are 4, 4, 6 and 5. The shared target SKU starts with 5 units in TENANT-A and 11 in TENANT-B; a second SKU in each tenant provides unrelated-row controls. Money remains USD minor units, and reservation changes neither prices nor order items.

Atomic reservation contract

A server-owned session supplies tenant and buyer. The writable request contains only requestKey, orderNumber, sku and integer quantity (1–10). Queries scope orders by tenant and buyer, inventory by tenant and SKU, and receipts by tenant, buyer and request key. Each query has bounded results, comment and purpose. The command loads full scalars and independently validates the complete bounded single-item list; it never saves a child preview as a complete order.

One audited provider transaction:

1. Advances the tenant sequence with its original optimistic version.
2. Changes the owned order from DRAFT to CONFIRMED.
3. Moves the requested quantity from available inventory to reserved inventory.
4. Inserts a receipt containing the order/inventory references and canonical order number, SKU and quantity.

Java and Rust use the native explicit transaction capability to guarantee that write order. Python, TypeScript, Go, .NET and Swift save one generated tenant graph containing only the changed order, SKU inventory and new receipt. Every participating writer uses the tenant version gate. This deliberately serializes reservations per tenant, including different SKUs; it is a correctness example with no fine-grained SKU locking or throughput claim.

Replays and conflicting requests

Before checking the order state or remaining stock, the facade checks a receipt for the session's tenant and buyer. An exact replay returns its persisted ID without writes, including after a process restart. Reusing the key with a different order, SKU or quantity returns IDEMPOTENCY_CONFLICT. A new key cannot reserve an already confirmed order. The same key under another buyer cannot replay a foreign receipt; the same key in another tenant can reserve that tenant's inventory independently.

Only a genuine native optimistic conflict triggers another attempt, with fresh full reads and at most three attempts. The fresh read returns either the stored receipt or current stock. SQLite busy, locked and timeout failures never count as optimistic conflicts. Java classifies its message-less ConcurrentModifyException by its native exception type and retains that class in the recorded conflict reason.

Rollback and concurrency evidence

A separate test-only fault installer adds a SQLite trigger that rejects the receipt INSERT with STOCK_RESERVATION_TEST_ABORT. Native SQL must show the earlier tenant, order and inventory UPDATEs before that failed INSERT. The read-only oracle then compares all domain rows, versions and timestamps with the initial snapshot. Removing the trigger and retrying the same key succeeds, proving the failed request did not leave a receipt or reserve stock. Identity allocation counters can consume IDs on a failed attempt and are outside the domain snapshot.

For each language, three oversell races and three duplicate races start two independent native processes. Each atomically publishes its observed versions and available quantity before the parent releases the barrier. A database checkpoint while both wait proves no early writes.

Race	Required native outcomes	Required persisted result
Two different orders request 4 units from stock 5	One RESERVED; the other gets one real version conflict, reloads and returns OUT_OF_STOCK	Available 1, reserved 4, one confirmed order and one receipt
Two identical requests share a key	One RESERVED; the other gets one real version conflict, reloads and returns REPLAY with the same receipt ID	Stock, tenant sequence and order advance exactly once

The catalog also covers invalid input and forged scope, absent targets, mismatched lines, insufficient stock, exact depletion, repeat requests and key scoping. Each runtime executes 47 reservation requests and 56 independent SQLite checkpoints, including bootstrap and seed checks. The seven-language receipt records 7/7 stock cells, 392 checkpoints and 42 synchronized race rounds / 84 worker processes. These probe counts do not inflate the one shared business scenario.

The existing runtime qualifications remain: Java and Swift use published runtimes; Go, TypeScript, Rust, Python and .NET are WORKSPACE PASS — RELEASE PENDING. The local Java generator repair for immutable empty child lists and the append API Assist improvements remain pending generator deployment. See the discovery manifest, generator patch, execution notes and source-bound receipt. Failed builds and preliminary validation attempts remain in the evidence archive.

Runnable applications: Java, Rust, TypeScript, Python, Go, C# / .NET and Swift.

Reproduce against the retained locally generated workspaces and recorded cached runtime artifacts, using the same toolchains as the receipt:

npm run verify:order:stock -- --stage build \
  --output artifacts/order-stock/2026-10-27 --cache-dir artifacts/school/2026-10-27 \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /private/tmp/teaql-school-tools/teaql-rs-pagination \
  --python-runtime /private/tmp/teaql-school-tools/teaql-python-pagination \
  --dotnet-runtime /private/tmp/teaql-school-tools/teaql-dotnet
npm run verify:order:stock -- --stage verify \
  --output artifacts/order-stock/2026-10-27 --cache-dir artifacts/school/2026-10-27 \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /private/tmp/teaql-school-tools/teaql-rs-pagination \
  --python-runtime /private/tmp/teaql-school-tools/teaql-python-pagination \
  --dotnet-runtime /private/tmp/teaql-school-tools/teaql-dotnet
npm run evidence:order:stock -- --check

This evidence covers native SQLite and a complete single-SKU line. Multi-SKU allocation, partial fulfillment, reservation expiry/release, restocking, reservation cancellation, production authentication and writers outside this facade require separate cases. This stock receipt proves late-statement rollback. Request cancellation and native COMMIT cleanup are verified in the lifecycle scope, with finite sustained load in the resource-release scope. Process crashes and cross-provider behavior remain unverified.

Cancellation, provider and commit failures

The lifecycle receipt adds 7/7 checks using the exact retained Order 1.2.0 model and stock fixture. It reuses their source-bound local evaluation, generated libraries and Assist; this stage performs no fresh generation or model transmission. The command still reserves stock through scoped generated Q/E queries and audited mutations.

Each runtime executes 11 independent native runs: one cancellation before admission, one successful control, and three repetitions each of in-transaction cancellation, provider statement failure and COMMIT failure. Each process keeps its provider and context state alive for a fresh recovery request.

Mode	Actual fault and required result
Before admission	A native cancellation signal stops the request before provider SELECT/DML. A subsequent request on the same provider commits successfully.
Successful control	The transaction commits once; a subsequent same-provider request returns the same persisted receipt without another reservation.
Cancellation after writes	After the real tenant, Order and inventory UPDATEs, cancel at an awaited checkpoint before receipt insertion. Require rollback of every domain row, version and timestamp.
Provider statement failure	A test-only SQLite trigger rejects the receipt INSERT with ORDER_PROVIDER_TEST_ABORT, after earlier business writes. Remove it only after rollback and resource checks.
COMMIT failure	After all writes and receipt insertion, hold an independent SQLite SHARED reader lock under DELETE journal mode. Release the native COMMIT attempt and require a real locked/BUSY error, rollback and cleanup.

The commit case uses the provider's real COMMIT. No application exception stands in for a commit failure, and SQLite BUSY is never treated as an optimistic version conflict or silently retried.

Native cancellation boundaries

Runtime	Mechanism exercised
Java	Interrupt the request thread at the checkpoint, propagate CancellationException, and clear the interrupted status after cleanup before recovery.
TypeScript	AbortController / AbortSignal aborts an awaited driver checkpoint.
Python	Cancel the child asyncio task; preserve CancelledError through graph cleanup and await the task.
Rust	Tokio selection drops the running request future; the SQLite transaction guard rolls back and releases its lease on Drop.
Go	Cancel the transaction's native context.Context; preserve context.Canceled through graph cleanup.
C# / .NET	Cancel an awaited checkpoint through CancellationTokenSource; retain the native cancellation exception.
Swift	Cancel a child Task at the awaited mutation checkpoint, propagate CancellationError, then await that task before recovery.

These are cooperative cancellation checks after database writes. They do not certify arbitrary SQL interruption, active-cursor cancellation or HTTP disconnect wiring. Swift retains its value-type UserContext and the same actor executor; other runtimes record native context/provider reference identities.

Independent rollback and resource checks

The parent waits for an atomically published ready file and verifies the native PID. While the transaction is open, the read-only oracle sees the original full snapshot and an independent BEGIN IMMEDIATE probe reports SQLITE_BUSY. For the commit case, a separate reader process acquires its SHARED lock before the parent releases the native COMMIT attempt.

After failure returns, while the original native process is still alive:

1. Compare every domain row, version and timestamp against the original fixture; no reservation receipt may remain.
2. Release the controlled reader, then require another independent writer probe to acquire and release its lock successfully.
3. Remove the provider trigger when applicable and permit recovery.
4. Reuse the same provider and retained context state to freshly read and commit the same request once. The successful control instead replays its receipt.

The oracle uses SQLite mode=ro. The separate fault setup and lock probe installs/removes the trigger and tests lock admission; it never changes domain rows. Across seven runtimes there are 315 database checkpoints, 147 independent lock probes, 77 native run processes and 21 controlled reader processes. Application tasks are awaited or dropped before recovery. These checks measure transaction locks and provider reuse, with no claim about unobserved pool sizes, goroutine counts or physical connection closure.

Python closes its transaction connection when COMMIT fails, so its later cleanup attempt can report an already closed connection. Go can report an already finished transaction during rollback after a failed commit. Both still have to preserve the original error, release the lock, leave storage unchanged and pass the same-provider recovery check.

Java JDBC repair and release qualification

Published Java 1.555-RELEASE fails this new COMMIT/resource control. A checked SQLException from COMMIT bypasses the old rollback catch, and restoring auto-commit fails while the reader holds its lock. The independent oracle stays locked, while the same pool can incorrectly replay a dirty receipt. After process shutdown the independent database snapshot has no receipt. The evidence proves leaked transaction/pool state; it does not claim an erroneous durable commit. The published failure and exact inputs remain preserved alongside the passing workspace run.

The workspace JDBC repair catches COMMIT SQLException, attempts rollback while retaining cleanup exceptions as suppressed failures, clears the transaction ThreadLocal and closes the operation-owned connection without explicitly enabling auto-commit. See the runtime patch and three regression tests. The retained released JAR is overlaid with the compiled workspace JDBC classes in an isolated Maven cache; the runner checks their hashes in the actual executable. Generated dependency declarations and domain sources remain unchanged.

Java lifecycle: WORKSPACE PASS — RELEASE PENDING. Earlier Java School, core Order, isolation and stock receipts keep their narrower published-runtime passes. Go, TypeScript, Rust, Python and .NET retain their existing pending-release marks; Swift passes this lifecycle scope on its recorded published runtime. Existing generator-deployment qualifications remain attached to their earlier evidence.

Sources: Java, Rust, TypeScript, Python, Go, C# / .NET and Swift. Read the catalog, local evidence manifest and execution notes for exact scope.

For the retained local workspace and cached toolchains:

# Rebuild and test the isolated Java JDBC workspace artifact from local inputs.
python3 scripts/order-faults-java-runtime.py
npm run verify:order:faults -- --stage build \
  --output artifacts/order-faults/2026-10-28 --cache-dir artifacts/school/2026-10-27 \
  --java-runtime ../teaql-java \
  --java-package artifacts/order-faults/2026-10-28/java-runtime/package.json \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /private/tmp/teaql-school-tools/teaql-rs-pagination \
  --python-runtime /private/tmp/teaql-school-tools/teaql-python-pagination \
  --dotnet-runtime /private/tmp/teaql-school-tools/teaql-dotnet
npm run verify:order:faults -- --stage verify \
  --output artifacts/order-faults/2026-10-28 --cache-dir artifacts/school/2026-10-27 \
  --java-runtime ../teaql-java \
  --java-package artifacts/order-faults/2026-10-28/java-runtime/package.json \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /private/tmp/teaql-school-tools/teaql-rs-pagination \
  --python-runtime /private/tmp/teaql-school-tools/teaql-python-pagination \
  --dotnet-runtime /private/tmp/teaql-school-tools/teaql-dotnet
npm run evidence:order:faults -- --check

These commands require the retained generated workspaces and recorded cached artifacts. SQLite COMMIT BUSY under rollback-journal mode does not certify WAL, other providers, crashes, network loss or ambiguous outcomes after commit. Three repetitions per fault are bounded checks. The separate sustained-load evidence covers finite concurrency and resource release; external audit/event delivery still needs its own evidence. All prior School and Order receipts remain unchanged.

Sustained stress and resource release

The sustained-load receipt adds 7/7 finite SQLite soak checks on the unchanged Order 1.2.0 model. Each runtime keeps four native worker processes alive, each reusing its own provider/context and owning at most one request at a time. The load phase lasts at least 120 seconds, with 480 requests per worker on a 250 ms admission schedule. A slow round extends the measured duration; requests are not discarded or silently retried to maintain a throughput target.

Each request fully reloads one tenant-scoped Order and its complete bounded single-item list. A successful transaction writes the same unique token to Order.order_note and OrderItem.product_name. It preserves all amounts, quantities, statuses, inventory, reservation receipts and other tenants. Java and Rust use one explicit native transaction; the other five use an audited Order graph save. Four processes contend on one shared Order and also update worker-specific Orders. The initial shared read barrier forces native optimistic conflicts; busy, locked and timeout errors never count as version conflicts.

Every twelve load requests mix one native cooperative cancellation after the Order UPDATE, one item-provider trigger failure after the Order UPDATE, and ten normal attempts. Failed requests use separate BUYER-B Orders so each cancellation and provider fault reaches its intended write checkpoint. Those Orders must remain exactly unchanged through drain and cooldown. Recovery then commits five fresh requests per worker using the same providers.

Phase	Per-runtime work	Evidence required
Detector calibration	One held transaction, then native cancellation	Independent reader sees seed data; writer probe is blocked; task/transaction/lease gauges are positive; cancellation restores the seed and releases the lock.
Warmup and priming	40 successful edits and 12 requests covering all error paths	Measure the resource baseline after success, cancellation, provider exceptions and conflicts have loaded their normal runtime resources.
Sustained load	1,920 requests across four retained workers	Exactly 160 cancellations and 160 provider failures; 1,600 normal attempts yield commits or genuine optimistic conflicts. Preserve every request outcome and native error.
Drain and cooldown	Four idle samples per worker over four seconds	No active request or transaction, no leased connection, bounded resource plateau, unchanged database and an available writer lock.
Recovery	20 successful edits	Same provider processes still commit complete Order/item pairs.
Close	Explicit native shutdown or proven provider lifetime end	Connections released, request executors/tasks finished, native process exits successfully, storage stays unchanged and a new writer can acquire the database.

This is 1,993 business operations per runtime (13,951 total), including calibration, warmup, priming and recovery. They are operation counts, not new business scenario counts. There are 77 independent read-only database snapshots and 49 writer-lock probes. Full snapshots are reconciled with the committed request ledger: versions must be consecutive, every final token must belong to the last successful transaction, and failed tokens cannot survive in an Order or item. The final SQLite files are retained as compressed evidence.

Runtime	Native resource observations and release proof
Java	Hikari total, active and waiting connection gauges; joined request executor tasks; executor termination and explicit pool close.
Go	sql.DB.Stats() open, idle and in-use connections; joined request goroutines; native goroutine and FD counts; explicit DB.Close().
Rust	Actual SQLite is_autocommit() state; completed or cancelled/dropped request futures; provider references dropped, exclusive connection ownership recovered and native Connection.close() succeeds.
TypeScript	BetterSqlite3 inTransaction and open; settled request promises; Node active resource categories and FD counts; explicit driver close.
Python	Actual aiosqlite handle state through weak references; joined asyncio tasks; thread and FD counts. No open request connection may remain at an idle checkpoint.
C# / .NET	Native connection state with Pooling=False; native transaction disposal; joined request tasks; FD counts; disposed connection reports Closed.
Swift	Native transaction boundaries plus independent lock probes; joined Tasks; weak actor reference becomes nil after the provider scope ends. The recorded SDK closes its SQLite handle in deinit.

All runtimes record actual OS FD counts. The warmed plateau permits at most eight additional descriptors; Go goroutines and Python threads permit at most two above their warmed counts, and Node active resource categories permit at most two per category. Go samples after a fixed 5 ms quiescence, with native goroutine stacks retained for larger observations. These thresholds and the raw samples are bound to the catalog and receipt. There is no forced garbage collection or hidden retry.

Go's native database/sql cancellation can auto-rollback before the explicit rollback runs. The observer recognizes native errors.Is(sql.ErrTxDone) only for a cancelled request, records the transaction as terminal, and preserves the original error. It still requires unchanged storage, zero in-use connections, writer-lock release and same-provider recovery. This changes the test observer, not the runtime or its existing release qualification.

Release qualifications remain unchanged: Java, Go, TypeScript, Rust, Python and .NET use the exact lifecycle workspace builds and remain RELEASE PENDING; Swift uses the same published 0.3.1. Java's earlier School/core/isolation/stock published passes, its published COMMIT-cleanup failure, all historical Order receipts, and existing generator deployment markers stay attached to their original scopes.

Measured load results on the recorded local host (1,920 load requests each):

Runtime	Load seconds	Committed edits	Version conflicts	Largest FD increase from own warmed baseline
Java	120.002	1071	529	1
Rust	120.000	1034	566	0
TypeScript	120.001	1099	501	0
Python	120.003	1000	600	0
Go	120.000	1108	492	0
C# / .NET	160.060	1168	432	0
Swift	120.001	1000	600	0

Each row also includes exactly 160 native cancellations and 160 provider failures. The .NET phase took longer than the minimum under this schedule; these observations include the local harness and SQL logging and are not capacity comparisons. All four workers in every runtime reported zero open connections after shutdown.

Read the seven executables: Java, Rust, TypeScript, Python, Go, C# / .NET and Swift. The oracle, separate test setup, local discovery manifest and execution notes define the scope.

Reuse the retained generated workspaces and cached runtime artifacts; no online model evaluation, Assist request or fresh generation is involved:

npm run verify:order:stress -- --stage build \
  --output artifacts/order-stress/2026-10-28 --cache-dir artifacts/school/2026-10-27 \
  --java-runtime ../teaql-java \
  --java-package artifacts/order-faults/2026-10-28/java-runtime/package.json \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /private/tmp/teaql-school-tools/teaql-rs-pagination \
  --python-runtime /private/tmp/teaql-school-tools/teaql-python-pagination \
  --dotnet-runtime /private/tmp/teaql-school-tools/teaql-dotnet
npm run verify:order:stress -- --stage verify --profile soak \
  --output artifacts/order-stress/2026-10-28 --cache-dir artifacts/school/2026-10-27 \
  --java-runtime ../teaql-java \
  --java-package artifacts/order-faults/2026-10-28/java-runtime/package.json \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /private/tmp/teaql-school-tools/teaql-rs-pagination \
  --python-runtime /private/tmp/teaql-school-tools/teaql-python-pagination \
  --dotnet-runtime /private/tmp/teaql-school-tools/teaql-dotnet
npm run evidence:order:stress -- --check

--profile smoke is a development check and cannot produce a formal PASS receipt. This finite SQLite soak checks bounded resource retention under this workload. It does not establish maximum throughput, shared-context thread safety, absence of all heap/RSS leaks, other database behavior, HTTP abort wiring, external event delivery or crash recovery. The separate real COMMIT-failure receipt remains the authority for COMMIT cleanup.

Shared scenario priorities

The eight P0 cases, five P1 cases and first four P2 cases are verified: 119/119 language/case cells, including 14/14 P2 cells added in this stage. The child-conflict rollback remains a required control within draft-edit, so it does not inflate that count. Buyer/tenant isolation now has its own 7/7 receipt on model revision 1.1.0. Stock reservation adds another 7/7 receipt on model revision 1.2.0, with 392 SQLite checkpoints. Request cancellation, provider statement faults and COMMIT failure now have a separate 7/7 lifecycle receipt. Sustained stress now has a separate 7/7 finite-soak receipt with native resource release checks; other providers and ecosystem integrations still need their own evidence. The original catalog is retained as first-flow evidence; the two P1 catalogs and the pagination, insights, isolation, stock, lifecycle and sustained-load catalogs update the corresponding rows through validated receipts.

Priority	Shared business scenario	Acceptance boundary	Model	Status
P0	Draft order with two items	Load one full order and its complete bounded item list; verify stable business keys, exact quantities and USD total 3850.	v1	7/7 PASS
P0	Loaded note value	Selected order_note evaluates to Leave at reception; a null-only default preserves it.	v1	7/7 PASS
P0	Loaded database null	Persist SQL NULL, select order_note, observe Null and apply the default No note; empty text is not null.	v1	7/7 PASS
P0	Unselected note	Omit order_note from a minimal projection; both evaluation and null-only default report NotLoaded with the missing field path.	v1	7/7 PASS
P0	Loaded empty text	Persist and select an empty string; both evaluation and null-only default preserve the empty string.	v1	7/7 PASS
P0	Edit a draft item and total	Reload full order and item state; change Notebook quantity 2 to 3, line total to 3750 and order total to 5100 in one provider transaction.	v1	7/7 PASS
P0	Reject invalid quantities	Reject zero, negative, fractional and over-limit quantities before save; compare the entire unchanged persisted snapshot.	v1	7/7 PASS
P0	Read committed edit after restart	A new process reads the exact order and item versions; an independent read-only SQLite oracle checks all persisted fields and unaffected rows.	v1	7/7 PASS
P1	Reject an expired order version	Both native processes read version 1; commit B first, then reject A as an optimistic conflict. Preserve every field and timestamp of the authoritative winner.	v1	7/7 PASS
P1	Roll back a multi-entity edit	Prove an order write precedes the failing stale item write; all earlier writes and timestamps roll back.	v1	Draft-edit gate; no extra case count
P1	Concurrent edits to one order	Two processes reach the same barrier with version 1; release together, require exactly one commit and one optimistic conflict. Busy, locked and timeout failures never qualify.	v1	7/7 PASS
P1	Concurrent edits to different orders	Two processes reach the same barrier on distinct version-1 orders; both commits succeed and each order retains its own note. All items, amounts and unaffected rows remain unchanged.	v1	7/7 PASS
P1	Explicit line removal	A filtered projection never deletes omitted items. Explicitly soft-delete SKU-PEN with order total 2500 in one transaction; retain tombstone version -2, reject stale deletion with full rollback, and verify fresh normal/deleted-only reads.	v1	7/7 PASS
P1	Confirm and cancel an order	Verify all nine DRAFT/CONFIRMED/CANCELLED pairs: allow only DRAFT to CONFIRMED or CANCELLED and CONFIRMED to CANCELLED. Reject repeated states, unknown targets and edits outside DRAFT; preserve amounts, items and unrelated rows.	v1	7/7 PASS
P2	Bounded order search	Nine orders with repeated totals; filter eight, sort by total then ID, cap parents at three and child previews at one, verify exact totals, repeatability, empty tails and invalid bounds without writes.	v1	7/7 PASS
P2	Sequential order export	Export all eight filtered orders in both ID directions using one context per sequence. Verify native cursor seeks, counted cache-miss/composite-sort/predicate fallbacks and fresh-process restart; no duplicate, missing or mutated rows.	v1	7/7 PASS
P2	Jump within an order result set	Retain the eight matching USD order IDs in total/ID order; verify random jumps, empty sets, capacity overflow lower bounds, buyer isolation, real TTL expiry and explicit key invalidation with native plans and store events.	v1	7/7 PASS
P2	Order summaries and empty buckets	Provider status counts and USD totals, matching/nonmatching status buckets and bounded item previews share buyer, currency and minimum-total filters; compare all output and unchanged storage against independent SQLite.	v1	7/7 PASS
P2	Buyer and tenant isolation	Server-owned sessions constrain list, detail, item access, provider count/sum, retained IDs and audited edits by tenant root and buyer; reject forged identity, forbidden fields, invalid limits and foreign IDs with unchanged unrelated rows.	Isolation v1.1.0	7/7 PASS
P2	Atomic inventory reservation, oversell prevention and idempotency	Reserve one complete single-SKU Order with a tenant version CAS; atomically confirm the Order, move available stock to reserved and insert a scoped receipt. Verify late-insert rollback, fresh-process replay, payload mismatch rejection and synchronized oversell/duplicate races.	Stock v1.2.0	7/7 PASS
P2	Request cancellation, provider and commit failures	Cancel before admission and after real Order/inventory writes; abort a late provider statement; force native COMMIT failure with a held reader. Verify full rollback, independent lock release and a same-provider retry. Bounded repetitions; sustained stress is separate. Separate sustained-load receipt: four retained workers, 120 seconds, atomic Order/item edits, rollback, bounded resource plateau, drain, cooldown, recovery and native provider shutdown.	Stock v1.2.0	7/7 PASS

Inventory reservation is covered by the stock revision above. Production membership, tenant lifecycle, reservation release and multi-SKU allocation need their own acceptance cases.

Runtime-specific practice

These are planned integrations, selected from the advertised target list. Target availability is not proof of a working integration. Begin with the common native flow, then add the process, request and resource lifetimes relevant to each track. Do not require every language to reproduce every framework example.

Runtime	Ecosystem example to develop	Advertised candidate target	Additional acceptance focus
Java	Spring service order editing	java-web-spring-boot	HTTP validation and service boundaries; verify provider enlistment before claiming framework transactions.
Rust	Async order command handler	rust-web-axum	Typed transaction scope, ownership of modified entities and request cancellation.
TypeScript	Order API and client projection	typescript-web-hono	Request validation, async error propagation and loaded-null versus unselected JSON fields; browser/TFP is a separate gate.
Python	Batch order import and export	python-app-console	Per-record validation, bounded batches and partial failure reporting; API integration can follow separately.
Go	Concurrent order handler	golang-web-gin	Request context lifetime, optimistic conflict classification and cancellation without leaked workers.
C# / .NET	Order application service	dotnet-web-aspnet	Dependency-injection scope, async lifetime and cancellation with exact provider transaction evidence.
Swift	Local order draft editing	swift-app-console	Native async reads and local SQLite draft state; Apple UI and TFP client integration each require separate evidence.

Evidence and release boundaries

The School column comes from its transaction receipt. It is historical evidence retained alongside the new Order work, not an inherited Order result. In particular, the five workspace qualifications remain visible.

Runtime	Order native / SQLite	Order runtime qualification	Retained School advanced qualification
Java	17/17 core PASS · 1/1 isolation PASS · 1/1 stock PASS · 1/1 lifecycle PASS · 1/1 soak PASS	Published runtime PASS (core/isolation/stock) · Lifecycle WORKSPACE PASS — RELEASE PENDING · Soak uses same workspace	Published runtime PASS
Rust	17/17 core PASS · 1/1 isolation PASS · 1/1 stock PASS · 1/1 lifecycle PASS · 1/1 soak PASS	WORKSPACE PASS — RELEASE PENDING	WORKSPACE PASS — RELEASE PENDING
TypeScript	17/17 core PASS · 1/1 isolation PASS · 1/1 stock PASS · 1/1 lifecycle PASS · 1/1 soak PASS	WORKSPACE PASS — RELEASE PENDING · nullable generator fix pending deployment	WORKSPACE PASS — RELEASE PENDING
Python	17/17 core PASS · 1/1 isolation PASS · 1/1 stock PASS · 1/1 lifecycle PASS · 1/1 soak PASS	WORKSPACE PASS — RELEASE PENDING	WORKSPACE PASS — RELEASE PENDING
Go	17/17 core PASS · 1/1 isolation PASS · 1/1 stock PASS · 1/1 lifecycle PASS · 1/1 soak PASS	WORKSPACE PASS — RELEASE PENDING	WORKSPACE PASS — RELEASE PENDING
C# / .NET	17/17 core PASS · 1/1 isolation PASS · 1/1 stock PASS · 1/1 lifecycle PASS · 1/1 soak PASS	WORKSPACE PASS — RELEASE PENDING	WORKSPACE PASS — RELEASE PENDING
Swift	17/17 core PASS · 1/1 isolation PASS · 1/1 stock PASS · 1/1 lifecycle PASS · 1/1 soak PASS	Published runtime PASS	Published runtime PASS

Earlier stages attempted published dependency builds first. This stage reuses those recorded artifacts and adds the .NET condition-key repair locally. The first-flow repair record and complete P1 repair record, together with the pagination repair record and retained-ID and summary record, distinguish generator, runtime, application and verification-harness failures; all unsuccessful attempts remain in the native evidence directory. In particular:

• TypeScript's nullable KSML note generated a setter accepting only string. The generator patch adds null only to optional scalar types. The regenerated CustomerOrder is the only changed TypeScript domain source in that retained supplement.
• TypeScript 0.3.1 passes the earlier eleven cases, but the deleted-only query returns an empty list even though SQLite retains Pen at version -2. The complete P1 receipt's publishedFailures entry preserves the failed build/verification pair and raw log. The existing School workspace fix also passes all seventeen current cases, with packed artifact, source identity and actual Node resolution recorded. Release remains pending.
• Go 0.3.1 lacks the ID-allocation methods required by the generated library. The workspace module path, commit, dirty source hash and actual resolution are recorded in the receipt. Its existing release-pending marker remains.
• The generated console instructions were absent for four languages and used the wrong language in Go. A fingerprinted generator supplement supplies those instructions and the TypeScript model until deployment.
• Rust's nullable update Assist now explicitly converts Option into Value. Swift reloads the saved order identity before linking items because the original value-type entity still carries its temporary ID. Neither requires an Order runtime patch in the historical thirteen P0/P1 cases.
• The published Rust runtime misreports FIRST_PAGE for a fresh context starting at offset 3; the required native reason is CACHE_MISS. Published Python lacks continuous_page_plan, and .NET fails compilation because ContinuousPagePlan is absent. These three failures are indexed in the retained pagination receipt's publishedFailures. The existing School workspace fixes pass the earlier fifteen cases and remain pending release.
• Published list-page Assist omits the optional cursor API. The local generator supplement renders and tests the exact Order model in seven languages; its source fingerprints and test log are retained. Deployment remains pending.

The earlier 91/91 receipt still records published passes for Rust, Python and .NET over its narrower thirteen-case scope. The current seventeen-case receipt uses five explicit workspace runtimes, matching the retained School qualifications. Neither receipt changes the other's version-specific conclusion.

The original online discovery also records a service inconsistency: services advertises inference, but the captured invocation returns HTTP 400 with “Invalid or unsupported scope requested.” This remains open. That stage’s model evaluation and scoped Assist calls succeeded independently; no automatic business enforcement has been inferred from that failed request.

Run the examples

Download the current seventeen-case sources: Java, Rust, TypeScript, Python, Go, C# / .NET, and Swift. The previous eight-, eleven-, thirteen- and fifteen-case sources remain at /examples/order/native/, /examples/order/p1/native/, /examples/order/p1-complete/native/ and /examples/order/p2-pages/native/.

The new runner adds insights-retained and insights-summary to the earlier native phases. It reuses an existing exact-model generated workspace, the recorded runtime archives and populated local toolchain/dependency caches. It supports build and verify; it does not evaluate, generate or request online Assist. Build and verification refuse changed model/library/source fingerprints. A fresh checkout without these local artifacts can replay the retained evidence, but cannot reproduce this offline native run until the required artifacts are present.

Use the Java/Maven, Rust, Node.js, Python, Go, .NET and Swift toolchains recorded in build.toolchain. Python 3 runs the independent database oracle for every language. The following commands use this receipt's workspace layout; supply the recorded runtime checkout paths and toolchain environment on your machine:

npm run verify:order:insights -- --stage build \
  --output artifacts/order/2026-10-27 --cache-dir artifacts/school/2026-10-27 \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /path/to/teaql-rs-with-pagination-fix \
  --python-runtime /path/to/teaql-python-with-pagination-fix \
  --dotnet-runtime /path/to/teaql-dotnet-with-condition-key-fix

npm run verify:order:insights -- --stage verify \
  --output artifacts/order/2026-10-27 --cache-dir artifacts/school/2026-10-27 \
  --go-runtime ../teaql-golang --typescript-runtime ../teaql-ts \
  --rust-runtime /path/to/teaql-rs-with-pagination-fix \
  --python-runtime /path/to/teaql-python-with-pagination-fix \
  --dotnet-runtime /path/to/teaql-dotnet-with-condition-key-fix

Use identical overrides for build and verify. --language can select one language. Java and Swift use their recorded published artifacts. Go, TypeScript, Rust and Python reuse the earlier source identities; .NET is repacked from the repaired workspace into an isolated local feed, with actual installed DLLs verified against the package archives. No generated domain source is edited by hand.

The documentation gates replay stored evidence and its exact fingerprints:

npm run check:order-contract
npm run test:order-contract
npm run evidence:order:insights -- --check
node scripts/write-order-evidence.mjs --check
node scripts/write-order-p1-evidence.mjs --check
node scripts/write-order-completion-evidence.mjs --check
node scripts/write-order-pages-evidence.mjs --check

These gates do not rerun native programs. The verify:order:insights runner executes all seventeen cases; earlier runners retain their narrower scopes. New builds and attempts use separate insights-build.json, insights-verification.json and timestamped logs, preserving unsuccessful attempts. The evidence writer refuses to overwrite a dated receipt. Future runs require a new dated record.

The original catalog, concurrency catalog, complete P1 catalog, pagination catalog and insights catalog drive this page's tables through their validated receipts. Run npm run sync:order-docs after a reviewed update. CI rejects missing cases, stale tables, changed evidence or qualifications, false store hits, incorrect ID sets or counts, currency leakage, incorrect facets or previews, and writes during read-only scenarios.