Answered in ink.

Structured Query AI — the governed, read-only structured-data tool for AI agents. A question becomes a typed, policy-checked plan; the plan runs on a deterministic engine; the answer returns with hashes that replay it.

One surface covers files and live databases alongside 4,778 read-only compute capabilities across 445 modules — medians to options pricing.

stats.median · finance.npv · option_pricing.black_scholes_call

There is no per-query cold start. The query plane runs in-process — sub-millisecond on typical files.

Compute provisions once: the first-ever call downloads and initializes the signed runtime in about 110 seconds. After that the daemon stays warm and resident, and a warm compute call measures 0.83–0.93 ms.

finance.npv = 0.83–0.93 ms (warm) · first provision ≈ 110 s

The signed runtime ships for Apple-silicon macOS and x64 Linux. On Windows, a managed-compute call returns a structured, named error rather than crashing.

The query plane runs anywhere. So do the self-hosted and hosted modes, since compute is posted to a remote engine. Node 20 or newer; Python 3.10 or newer.

darwin-arm64 · linux-x64 · node ≥ 20 · python ≥ 3.10

Yes. By default SQAI installs the pinned bundle covering the whole exposed surface. Name only the modules you need and the build service compiles a signed, sha256-pinned bundle for that subset, cached by filter hash.

Filtered daemons get their own socket and port, so they never collide with the full one.

SQAI_RUNTIME_MODULES → POST /v1/runtime/build · sha256-pinned

The agent tools never throw. Errors come back as structured output with a status and a code that names the denial — a policy denial, an unknown capability, a missing seed.

For everything beneath the tools, one command checks the install, the runtime, and cross-language parity in a single pass.

output.status === "error" · sqai doctor --parity --json

Yes — by construction, not by permission. The model authors typed intent, never SQL; SQAI validates it against a hash-pinned capability contract, applies your policy, and only then executes.

Of 4,778 capabilities, 4,574 are exposed: only those that are read-only and deterministic, or deterministic when seeded. The 204 that fail the test — including every write — are absent from the packaged surface. No setting can reach what was never shipped.

read_only && (deterministic || deterministic_when_seeded)

Register your sources in code and hand the model the tool set — exactly three tools. One lists what exists, one previews a plan without running it, and one executes against the read-only surface.

A read-only database role is a flag someone can unset. A surface compiled without write capabilities is not.

sqai.tools() → listSources · explainQuery · queryData

You don't filter the SQL. You stop generating it.

String filters and read-only flags guard a language that can always express a write — and prompt-injected SQL arrives in the model's output, past your input sanitizer. SQAI's model writes a typed plan in a grammar with no write forms: DELETE is not rejected, it is unwritable.

kind: "query" | "computation" · version: "1"

No. Policy is fixed in code when you create the client and checked in-process before every execution. The tool schemas carry no allow-list field of any kind, so there is nothing for a prompt to reach.

An explicit allow-list can only narrow. Naming a capability outside the eligible surface still fails — the packaged surface is the ceiling.

policy_denied_source · policy_denied_field · policy_denied_function

Yes — for humans, never for models. The unguarded runtime lives behind a separate import that bypasses contract, policy, and seed checks, and it is never exposed to the agent tool set.

An engineer can opt out deliberately. An agent cannot reach it with any input.

import { getUnsafeRuntime } from "@thyn-ai/sqai/unsafe"

In the default local mode, nothing. The query plane resolves in-process and the compute runtime is a signed daemon on your machine. The one outbound call is the first-use download of the runtime bundle — engine code, not your rows.

Point an environment variable at a self-hosted or hosted engine and plans are posted there instead, with credentials encrypted and no data copied.

local: in-process · self_hosted: SQAI_ENGINE_URL · api: SQAI_API_KEY

In-process with no key: CSV, TSV, JSON, in-memory rows, and SQLite — plus Excel and Parquet in Python. Through an engine: PostgreSQL, MySQL, Oracle with a bundled Thin-mode driver, SQL Server, Snowflake, BigQuery, ClickHouse, Redshift, object stores, Redis, Neo4j, Elasticsearch, REST APIs, and Git repos.

Every source presents the same typed shape, so downstream code cannot tell a CSV from Snowflake. Sources are immutable once registered.

SqaiSource { fields, typed_fields, row_count, schema_revision }

Never. SQAI is not a model and trains nothing — there is no learning loop to feed. In local mode your rows never leave the machine at all.

The only model in the loop is the one you bring, and it sees at most 25 rows per result. Anything larger is truncated — declared, never silent — with the full value held under an opaque result id that expires after 15 minutes.

maxRowsToModel 25 · maxCellsToModel 250 · maxBytesToModel 32,000

Deterministic within the declared execution scope — 64-bit floats, a single thread, a pinned runtime — and every result records that scope rather than overclaiming.

The canonical serializer is conformance-locked across both SDKs, so the same computation returns the same number and byte-identical hashes in TypeScript and Python.

finance.npv(0.1, [-1000, 300, 420, 560, 680]) = 505.020148896933computation_hash b74f67d0… · TS ≡ PY

By never letting it do the arithmetic. Ask a model for a 200-row total and you get a plausible number — with no signal that it is wrong.

With SQAI the model only chooses the computation; the engine computes it. In our accuracy A/B, the same model went from 0 of 16 to 16 of 16 on quantitative questions the moment the engine did the computing.

accuracy A/B: 0/16 → 16/16

Yes — that is what the hashes are for. Every result carries a plan hash, an invocation hash known before execution, a computation hash known after, and a determinism envelope recording runtime version, platform, precision, and seed.

Re-run the invocation within the same scope, months later, and the hash matches byte for byte. If the underlying schema moved, you get a named schema-revision mismatch instead of silently different numbers.

run1 b74f67d0d7a594aa7ac91f6291612452aa8ccdf603351ebc8d801a6fddd91bc8run2 b74f67d0d7a594aa7ac91f6291612452aa8ccdf603351ebc8d801a6fddd91bc8identical: true

No. Local mode is zero-config — no key, no account, no card. The runtime provisions itself on the first compute call.

Signing in is optional and uses a device code; it issues an offline license that moves a signed token, never your data. Keys exist only to point at a different engine.

sqai login → RFC 8628 device code · WDJB-MJHT

Local development and managed compute are free — there is no license check anywhere in the SDK.

Paid tiers gate machines, seats, and commercial rights, never compute features. Developer: free, one device, non-commercial. Pro: $25 a month, three devices, commercial use, async jobs, webhooks, audit trail. Team: $99 a month, ten devices, adds role-based access and seats.

Developer $0 · Pro $25/mo · Team $99/mo