Platform
Local-first by construction. The product runs entirely on the engineer's machine, and its services are reachable only from the machine itself — nothing is exposed to your network beyond what you configure. Specs, programs, boards and STDF stay local; the only network egress is the prompts the engineer chooses to send to their own LLM provider, on their own keys — and the payload is inspectable before it goes.
ATE·IQ is a desktop product that happens to be built from web technology, not a cloud product with a desktop wrapper. One install serves both the standalone IDE window and the Excel task pane, from the same local server.
The desktop shell sits in the system tray and registers the Office add-in. Closing the main window hides to the tray rather than shutting the product down, so the Excel task pane keeps working. The task pane and the IDE are the same install and the same database — a workbook ingested from Excel is immediately part of the project the IDE sees.
Long-running work — test-program generation, code-map indexing, document and board ingest — runs in the background without blocking the app. The scheduling underneath is deliberately conservative: a failure is retried, and work that still fails is surfaced with its error rather than dropped silently; work interrupted by a crash is recovered on restart, not lost. The in-app status bar watches the platform's health continuously, so a stalled pipeline is a visible fault, not a mystery.
ATE·IQ ships no model and holds no keys of its own. The customer configures a provider, supplies their own credentials, and every AI feature routes through that choice — which means the customer's existing egress policy and data agreement with their provider apply unchanged.
| Provider | Configuration |
|---|---|
| Anthropic | Direct API with the customer's key. |
| OpenAI-compatible | Any endpoint speaking the OpenAI API — hosted, or a self-hosted gateway inside the customer's network, via a configurable base URL. |
| Azure OpenAI | Endpoint, deployment and API version — for organisations whose model access is already contracted through Azure. |
The provider is switchable at runtime from Settings — no reinstall. And what goes to the provider is not a mystery: the Context Curator shows the exact assembled payload — every artefact, every score — before a query is sent. AI is also optional per feature: the validators, analyzers, DIB checker, STDF tools and traceability reconciles are deterministic and run with no provider configured at all.
| Control | Implementation |
|---|---|
| Network exposure | Local-only by design — services are reachable only from the machine itself, and nothing is exposed to your network beyond what you configure. There is no cloud component and no telemetry. |
| Credentials at rest | LLM API keys and Git personal-access tokens are encrypted at rest — never stored in plain text. |
| Excel bridge | The live-workbook bridge requires a shared secret on every request, generated locally on first run — a request without it is refused. |
| Workbook file reads | Workbook access is constrained to the user profile and OneDrive roots and to .xlsm/.xlam extensions — it cannot be used to read arbitrary files. |
| API authentication | Every page and every API surface authenticates the caller in its own right, and the product's internal calls are authenticated as well — there is no unauthenticated back door between components. |
Every screenshot in this guide was produced on a single Windows workstation: the demonstration spec, the 34-test program, the five-sheet board, the routed copper and the eight STDF lots all live in the local database, and the analyzers, validators, DRC and traceability reconciles that judged them ran without a network connection. The only traffic that left the machine during the build was the generation and chat prompts sent to the configured provider — the same payloads the curator preview displays.