Platform

Architecture & Security

Local-first by construction. Every service binds 127.0.0.1 — nothing is reachable from the LAN. Specs, programs, boards and STDF stay on the engineer's machine; 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.

01

Everything on the host

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.

ENGINEER'S MACHINE — ALL SERVICES BIND 127.0.0.1 ELECTRON tray · add-in registration APP Next.js · 127.0.0.1:3000 POSTGRESQL projects · boards · STDF · job queue WORKER generate · code-map · ingest EXCEL task pane · live bridge spawns enqueue claim loopback HTTPS + shared secret LLM PROVIDER customer's choice prompts the only egress — on the customer's keys no LAN exposure — code, specs, boards and STDF never leave the host except as prompts the engineer chooses to send
Fig. 1 — The whole platform on one machine. The Electron shell spawns the app and the worker; Excel talks to the same local server; one labelled arrow crosses the boundary.

The Electron shell owns the desktop experience: it spawns the app and the worker, sits in the system tray, and registers the Office add-in. Closing the main window hides to the tray rather than killing the server, 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.

02

Two processes, one queue

The runtime is two processes: the app, and a background worker. Long-running work — test-program generation, code-map indexing, document and board ingest — runs as jobs the app enqueues into a database-backed queue and the worker claims. There are no resident microservices to babysit; capabilities that once ran as separate servers now run in-process.

PENDING deduplicated on enqueue RUNNING claimed atomically COMPLETE result stored worker claims success failure → retried within a budget · worker crash → lease expires, job reclaimed a job that exhausts its retries fails visibly with its error — never dropped silently
Fig. 2 — Job lifecycle. Claims are atomic, retries are budgeted, and a crashed worker's jobs are reclaimed on restart rather than lost.

The queue is deliberately conservative: duplicate requests collapse on a dedupe key, a claim is a single atomic database operation, failures retry within a budget, and a job orphaned by a crash is reclaimed when its lease expires. The worker exposes a health endpoint the in-app status bar polls, so a stalled pipeline is a visible fault, not a mystery.

03

Bring your own LLM

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.

ProviderConfiguration
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.

04

Security posture

ControlImplementation
Network exposure Every service binds 127.0.0.1 explicitly — the app and the worker are unreachable from the LAN. There is no cloud component and no telemetry.
Credentials at rest LLM API keys and Git personal-access tokens are encrypted with AES-256-GCM before they touch the database.
Excel bridge The live-workbook bridge requires a shared secret on every request. The secret is auto-generated on first run and stored in the user's profile; the add-in reads it from disk, the task pane fetches it over an authenticated session.
Workbook file reads Server-side workbook access is constrained to the user profile and OneDrive roots and to .xlsm/.xlam extensions — the endpoint cannot be used to read arbitrary files.
API authentication Pages sit behind session middleware; every API route additionally authenticates itself. Internal cross-process calls carry a shared internal key.
05

On the TMP126 demo

Every screenshot in this guide was produced on a single Windows workstation. The TMP126 spec, the 34-test program, the five-sheet board, the routed copper and the eight STDF lots all live in the local database; 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.

Honest boundary Today's stack is Next.js with PostgreSQL in a local Docker container — a developer-grade install. The delivery direction is a packaged single Windows executable with an embedded SQLite store, removing the Docker and Node prerequisites. That is the direction of travel, not a dated commitment.