How SazAI is built: what we decided, and what it rests on

Built on published format standards

Each format is read by its published standard

SazAI is the substrate the products run on: multi-tenancy, authentication, lineage, orchestration, the agent layer, usage metering and versioned decisions, built once. The engine reads each format by its published standard (ECMA-376 and ISO/IEC 29500 for Office, ISO 32000 for PDF, ISO 8601 for dates), clause by clause; the heuristic was discarded because it does not survive an audit. Each new format cost less than the last:

PPTXthe whole engine

DOCXone order less

XLSXone more

PDFstabilizes

PDF is the first substrate that is not Office, yet it cost like the third format: the engine became format-agnostic, and the four formats run on one architecture, each with its own declared guarantee.

It is not plug and play for someone arriving from outside: the speed comes from the team that knows the engines.

Data protection is design

You verify it by auditing the schema

• The platform tables hold no document content; content lives in your organization’s own schema, sensitive and erasable.
• Tenant isolation is a column, not a promise.
• Certification today: none. Controls are designed to serve as evidence when it is sought.

Open channels: API and MCP

Everything the agent can do exists in the open API

The agent channel is a standard OAuth resource server (401 without a credential, discovery published), and by contract MCP ⊆ OpenAPI. Your team can build a third-party agent, a dashboard or a workflow on the same substrate.

How we validate, and how we decide

Tests that refuse, audit with method, decisions superseded sentence by sentence

Tests: the design-system suite runs on every build. Guards: a build that breaks a rule does not ship. Load: on 2026-07-20, on a production replica, 50 concurrent reads in 0.77 s, a heavy job peaking at 4.71 GiB of a 5 GiB ceiling, and waves of five and ten jobs with zero failures; under overload, work queues.

We are not SOC2 or ISO certified. We have documented internal audit, with a declared method, and its defects published next to what passed. The written decisions are designed to serve as control evidence when certification is sought.

Every architecture decision is a dated document with the rejected alternative and the reason: 61 on 2026-09-01. A new decision names the sentence of an old one that stops holding.

Receipt

Plug and play4 ADRs and the recipe · the four-point curve · the table partition, re-derivable

Queue control5 ADRs · the 2026-07-20 load test, and the production capacity measured below

Architecture · lineage · tenancywith the provider boundary declared as a named hole

Decision versioningdated decisions, surgical supersession

Declared practice

Schema versioningdeclared direction

Artifact versioningdeclared direction

Agent-to-agent communicationdeclared direction, with failure modes measured

Capacity measured in production

What one production server processed in a load test, and what is not measured yet

Measured on 2026-10-27 and 2026-10-28 at release b245844a4, for one tenant, on one server with 2 vCPU and 7.6 GiB of memory as the operating system reports it. At that release, uploads were capped at 40 MiB per file. Each client’s SazAI Corpus will be installed on that client’s own server, so its numbers will depend on that server.

What was sent, in files. 83 files were sent: 82 were accepted and 1 was refused at upload, a text file under a .pdf name. The 82 accepted files hold 150.1 MiB; the largest is 26.4 MiB.

What happened, in jobs. One file can run several jobs: reading, preview, OCR, comparison. The 82 accepted files ran 151 jobs. 149 were completed at the last status read. Among the 143 jobs with a final read, 0 failed; 8 jobs have no final read, 2 of them still running when the first part of the test stopped. Those 2 are counted as not finished, not dropped. During the watched windows no worker ran out of memory or restarted; the last 40 seconds of the run were not watched.

Processing time per step, in seconds. From the start of a step to its end, waiting in line excluded. p50 is the median and longest is the longest run; n is the number of runs. A p95 is given only where n is 20 or more: reading png 0.4, OCR images 406.3.

Previews the server ran on its own took 2.4 s or less, and statistics 3.6 s or less, in every run timed per run. OCR is the slow step. For 11 presentations in the first part of the run, time was recorded per activity and not per run, so they are not in this table.

Waiting in line, in seconds. Before reading started, by format, p50 and longest: docx 176.2 and 200.8 (n 12), jpeg 350.8 and 373.7 (n 5), pdf 233.0 and 276.4 (n 13), png 296.0 and 608.5 (n 25, p95 587.9), pptx 0.1 and 0.5 (n 2), xlsx 214.2 and 235.5 (n 12). These waits were measured under this run’s own load, with files sent one after another and the server’s own OCR jobs in the same run, so they are not the wait of a single upload on an idle server, and they are not processing time.

Memory. Largest memory the worker used while running a job in this run: about 2.8 GiB (147 of 151 jobs measured).

Not measured yet. 17 jpeg images of the plan, 6 of them from 0.1 to 10 MiB, not sent yet; a batch of 300 files; the batches after it; large spreadsheets; more than one tenant at a time; files above 40 MiB; any other server.

Method: the run was made by the QA agent with its load harness; the numbers come from its capacity sheet, built offline from the recorded files (sha256 71bb0c58cb187f14f61bcc272ef7dc2ac0dc836e0dc92941328ab7892e21f376). The section is updated after the 300-file batch and the jpeg batch. Last update: 2026-10-28.

Roadmap: what we are building

Nothing below has shipped, no item should weigh on your decision today, and nobody on our team should present one in the present tense. When a piece ships, it leaves this list and appears on its capability page, with the date. What has shipped is in the product walk; its limits are in trust.

• Redline and negotiation intelligence. The comparison engine runs today over document versions; the legal layer, knowing an altered clause is not just a different paragraph, does not exist.
• Specialized agents over your vault. A tutor or an evaluator with its own scope. The corpus, lineage and source citation exist; per-agent specialization does not.
• A governed substrate for a fleet of agents. The vault is already portable and readable from outside; fleet governance is not built.
• The identity provider inside your zone. Federated sign-in passes through a cloud identity provider today; running it inside an installation of your own is direction, not delivered.

What exists, but without public proof

• Vault export. No published demonstration anyone can reproduce without us yet; until then, it is a due-diligence conversation.
• The record as formal audit evidence. It serves as control evidence; whether it meets a requirement in your sector is answered case by case.
• Scale above what we measured. Hundreds of thousands or millions of documents have not been exercised: a sizing project before a purchase.

What does not exist yet

• Visual verification. The system counts elements; it does not look at the final page.
• Deletion that reaches backup copies. Deletion is complete in live systems and does not reach backups within the retention window; the path is defined, not built. Scope in privacy and sovereignty.

Where the boundary passes

The provider. Lineage stops where text leaves for the language model and resumes when it returns; the other side is governed by the provider’s retention terms, and in your own installation the provider is your choice. The copyleft exclusion. No AGPL library enters the engine, written in the dependency file; it is a comment, not a gate. The agents. This system is built by agents with declared scope and a review chain; their communication is practice, not receipt. How our engineering claims are anchored, and where they are weak, is in trust.