Feature status
A precise availability matrix for current, preview, and planned Tarski platform surfaces.
This page separates shipped contracts from roadmap direction. “Specified” means a machine-checked public contract exists; “available” means the named release exposes it. Do not design a production dependency around “planned”.
Current and next-preview contracts
| Surface | Availability | Minimum version |
|---|---|---|
| Hosted installer and preview channel | Available | installer metadata 0.5.9-preview.7+ |
| Underscore entity-name query normalization | Next preview | tarski 0.5.9-preview.8 |
| Cloud automation credentials and shadow endpoint smoke | Next preview | tarski 0.5.9-preview.8 |
| Reactive declared-query subscription SDK | Next SDK release; local/hosted conformance-gated | @tarski/client 0.8.0 |
| Write-policy payload and delegated-actor bindings | Next preview | tarski 0.5.9-preview.8 |
| Fixture write-policy attempts with expected denials | Next preview | tarski 0.5.9-preview.8 |
| One-shot timer simulator and canonical fire envelope | Next preview | tarski 0.5.9-preview.8 |
| Runtime schedule and blob client operations | Next preview/SDK release | tarski 0.5.9-preview.8, @tarski/client 0.8.0 |
| Platform-builder delegated tokens and lineage provisioning | Preview; capability-discovered | tarski 0.5.9-preview.8, @tarski/client 0.8.0 |
| TypeScript app-contract codegen | Next preview | tarski 0.5.9-preview.8 |
| Fixture world export/import/compare | Next preview | tarski 0.5.9-preview.8 |
Until those artifacts are published, source or documentation on main is not an
installable production contract. The release pages and registry are authoritative.
Planned agent-context surfaces
The following requests are accepted product direction but are not V1 runtime capabilities:
- a first-class, batched judge harness that can amortize model calls across proposals;
- backend-owned ranked/windowed ambient context slices such as recent-N messages;
- dynamic cross-lineage projection import discovery for account-level “Home” views.
Current patterns remain explicit:
- model a judge as a declared reviewer agent whose LLM output returns as observation evidence, and batch only in your application/provider contract;
- derive bounded ranking with finite relations/aggregates or pass a deliberately bounded context projection;
- declare cross-lineage projection imports statically and pin every source identity, or compose independently authorized query results in the client.
No runtime should advertise these planned items through capability discovery. A client that asks for one must receive a typed unsupported state rather than a silent fallback.