Orbis Technical Brief

General-purpose AI chatbots fail on automotive engineering tasks because they cannot ingest multi-gigabyte measurement binaries, hallucinate non-existent calibration labels, lack a terminal to execute validation scripts, and require uploading sensitive data to external clouds.

Orbis is constructed specifically for automotive constraints: large files are queried via sparse tools rather than dumped into context windows, and all processing operates locally.

Production A2L files routinely contain millions of lines of text. Orbis never streams complete A2L files into the model context. Instead, tools like a2l_search locate labels via targeted regex, and a2l_lookup retrieves record layouts, units, and currently flashed values.

Drop intake tooling inspects incoming calibration folders, classifying measurements, patch packages, and specifications while flagging unclassified or archived files.

Orbis does not act unsupervised. Every code modification, hex patch, and shell execution is staged as a visual diff with four approval options: allow once, allow for session, always allow, or deny.

A native pseudo-terminal (PTY) runs real compiler toolchains, conversion scripts, and pytest suites, feeding live terminal streams directly into the reasoning transcript.

Orbis is in early access. It is not an autonomous calibration agent and does not make unsupervised parameter modifications without engineer approval.

Orbis does not replace domain engineers; it serves as an augmented engineering workbench to accelerate routine analysis, scripting, and verification workflows.