seib-1

seib-1 is a 27-billion-parameter language model with image input, purpose-trained on verified industrial engineering work. It is the model behind seib Cowork, the desktop coworker that plans engineering tasks, reads specifications and plant data, and proposes changes for a person to approve. seib-1 is the first model in the seib Industrial Foundation Model (IFM) programme; the wider IFM described elsewhere on this site remains in training.

The model is sized to run on hardware a plant already owns. At 4-bit precision it fits a single 32 GB workstation GPU with room for about ten concurrent agent sessions, which is what makes an on-premises deployment with no route to the internet practical rather than theoretical. In the cloud, seib-1 is hosted in the EU.

This first version of the report describes the model, how it is served and the evaluation method. It states no benchmark results: the evaluation suite has so far run against a mock model, and results on seib-1 will be added to this report, with their failure cases, when they exist.

What this report is not. It does not claim certification against IEC 61508 or IEC 62443, does not name a training strategy, and does not compare seib-1 with other models. Figures marked as estimates come from arithmetic on published hardware numbers, not from measurements.

seib-1 is a decoder-only transformer with a hybrid attention stack. Of its 64 layers, three in every four use gated linear attention, which keeps a fixed-size state instead of a growing cache; every fourth layer is full attention. Full-attention layers use 4 key-value heads of 256 dimensions.

The choice matters for agent work more than for chat. An engineering task re-sends the whole conversation at every step — the tool protocol, the plan, the files read so far — so a typical step carries 10,000 to 30,000 tokens. In a conventional dense model of this size, the key-value cache for that context runs to several gigabytes per task. In seib-1 it is 64 KB per token at FP16 and 32 KB at FP8, so a 32k-token task holds 1–2 GB, plus about 0.15 GB of linear-attention state. That is the difference between a handful of engineers per GPU and a team.

A vision encoder of about 0.4 billion parameters reads images. Engineering material is full of them: scanned specifications, drawings, screenshots of an HMI or an engineering tool. The agent sends pages and images to the model directly rather than through a separate captioning step.

The model also carries a multi-token prediction head. Serving stacks can use it for speculative decoding, which typically raises writing speed by 1.3–1.8× on a lightly loaded GPU and helps little on a full one.

seib-1 is purpose-trained on verified industrial engineering work: engineering that was actually built and actually ran, with the artefacts that prove it. The distinction is deliberate. Manuals and support tickets describe engineering; project files, control exports, test protocols and their outcomes are engineering. The training programme targets four kinds of material:

Engineering documents

Requirements, functional specifications, control narratives, test protocols and review records.

Automation artefacts

Control projects and their exports — Rockwell L5X, Siemens TIA Portal, PLCopen XML — together with tag lists, naming conventions and I/O lists.

Plant and system models

OPC UA NodeSets, IEC 61850 SCL, AutomationML and the structure of real cells and lines.

Tool use

Complete agent tasks: the plan, every file read and query, the proposed change, and whether a person allowed it.

Verification is part of the training signal rather than a filter applied afterwards. Where an output can be checked mechanically — it compiles, it parses, it matches the project’s own tags, the test sheet covers every I/O point — the check decides whether the example counts. A draft that does not clear a real toolchain is not a good answer that needs checking; it is a wrong answer.

Standards publishers such as IEC, ISO and ISA restrict machine-learning use of their documents. Organisations deploying seib-1 are asked to load into knowledge bases only content they are licensed to use.

seib-1 never touches a file or a system itself. It proposes the next action as a structured tool call; the seib Cowork desktop checks the call against organisation policy and folder limits, shows it to the engineer, runs it only if allowed, and records it. The model sees the result and plans the next step.

1. 1ProposeThe model emits one or more tool calls in a text protocol, alongside a short explanation.
2. 2CheckThe desktop validates each call against policy: allowed tools, the task's folder, approved hosts, read-only connectors.
3. 3AskEdits, commands and every write to another system are shown exactly, as a diff or a statement. The engineer allows, edits or refuses.
4. 4Run and recordOnly allowed calls run. Each gets an undo copy and a hash-chained audit entry.

The tool protocol is text rather than a provider-specific function-calling format, so the same model serves identically from seib’s EU endpoint, from vLLM on a customer’s GPU, or from llama.cpp on a workstation. Sub-agents run up to three at once under the same rules. Clarifying questions are a tool too: when a task is ambiguous, the model asks with two to five ready-made choices instead of guessing.

The tool set covers reading PDF, Word, Excel, DWG/DXF and images; summarising engineering exports; searching inside documents with page citations; writing Excel, Word and company templates; and connectors for databases, OPC UA, MQTT and Sparkplug B, historians, SAP, Jira, ServiceNow, mail and knowledge bases.

General-purpose code benchmarks do not cover industrial engineering, and the ones that come closest reward output that reads well. seib-1 is evaluated on four axes, each scored against a real toolchain or a real project rather than against a reference answer’s wording.

Compile-and-run correctness

Does the artefact build in the toolchain it targets, and behave as specified in simulation? Pass or fail.

Project-grounded accuracy

Does the answer use the project's own tags, routines and conventions, or invent plausible ones?

Task completion

Given a real task on a reference project — an I/O list, a specification review, a FAT protocol — is the delivered work complete and correct, and how many approvals did it take?

Refusal and escalation

How reliably does the model decline work it should not do, above all anything touching safety-related program units?

The harness replays complete agent tasks on fixture projects through the same desktop application engineers use, so tool-call formatting, approvals and undo are part of what is measured. It currently runs against a mock model; runs on seib-1 at each serving precision are next.

seib-1 runs in two places. In the cloud, it is hosted in the EU and reached over TLS; project files stay on the engineer’s workstation and only what a step needs is sent. On premises, it runs under vLLM on a GPU in the customer’s own server, next to an embedding model and the knowledge store, with no route to the internet.

The default on-premises card is a single 32 GB workstation-class GPU for a standard rack server. At 4-bit weights and an FP8 cache it holds about ten concurrent sessions at 32k tokens each. Because a running task occupies the GPU only about half the time — the rest is tools, reading files and waiting for approvals — and about one engineer in three has a task running at the busiest hour, that serves a team of roughly 45.

Prompt reading is the hidden limit. Every step re-sends the conversation, so prefix caching — reading only the one to three thousand new tokens of each step — is what keeps time to first token within a few seconds. With it, a 32 GB card reads a cold 20,000-token prompt in about four seconds at 4-bit.

The embedding model that powers knowledge search is small enough to run on the server’s CPU, leaving the GPU to seib-1. Knowledge bases hold about 16 KB per passage, so 100,000 passages take about 1.6 GB.

seib-1’s safety does not rest on the model behaving well. It rests on the model having no way to act except through a desktop that checks, asks and records.

Proposes, never deploys

The model has no direct access to files, systems or machines. Every action is a proposal the desktop may refuse.

A person approves every change

Edits, commands and every write to another system are shown exactly. Writes to other systems have no “always allow”.

Safety-related program units

seib is designed so that writing to safety-related program units is blocked in every deployment mode.

Documents are content, not instructions

A command that matches text from a document the model just read is flagged and always asks.

Least privilege

Each person connects with their own account; credentials stay in the operating system's keychain and never reach the model.

A record of every step

A hash-chained audit trail per task, exportable as CSV or JSON Lines, that reports whether it is intact.

Results are pending

No benchmark has yet been run on seib-1 itself; this report will say so until one has.

Quantisation costs most at the edges

At 3-bit, tool calls are the first thing to degrade: malformed calls and ignored instructions. 4-bit is the floor for daily work.

Long tasks are expensive

Capacity falls in proportion to context. The same card that serves about 85 people at 16k serves about 12 at 128k.

Prefix caching for hybrid models is young

Serving frameworks cache hybrid linear-attention models less reliably than plain attention models. Check the hit rate under load.

Plausible is not correct

Like any language model, seib-1 can produce output that reads well and is wrong. The toolchain gates, the approvals and the undo exist because of this.

Cite as: seib (2026). seib-1 technical report, version 0.1. https://seib.ai/research/seib-1