In early August we published an article here that describes an architecture principle but names no product: Why the AI must never write. The reason for the restraint was simple: the device it was about still had its acceptance ahead of it, and you do not talk about a product with a pending acceptance as if it were finished. Today, both are done. The device is called IDSCOUT Encode, it is the first product of our AI layer IDSCOUT, and it is available now.
One layer, six experts
Before we get to the station, a word on what is actually launching today. IDSCOUT is not a single device — it is the new AI layer above the IDCRAFT portfolio. The observation behind it comes from our day-to-day work as a distributor: what Auto-ID projects get stuck on is rarely the hardware — it is the expert knowledge at a handful of bottlenecks. Setting up encoding jobs, validating incoming goods, integrating readers into your own software, picking the right transponder out of hundreds, meeting standards and approvals: all specialist work, and specialists are scarce.
IDSCOUT staffs these bottlenecks with locally running AI domain experts — one scout per field, all built on the same architecture: evidenced answers instead of claims, local operation instead of cloud, and an AI that by construction cannot break anything. Six experts are named: Encode (encoding, available today), Integrate (developer assistant for the readers we distribute, in progress), Verify (checking instead of writing, in planning), plus Stage, Select and Comply. Encode is the first, and at the same time the proof that the architecture holds. The rest of this article shows what that proof looks like.
What the station does
IDSCOUT Encode is an encoding station for NFC labels, built for label converters whose staff come from print production. The operator describes the encoding job the way it reads on the job ticket. The station recognises the job pattern, pre-fills a form and shows the status of every value: green is literally evidenced from the job text, carrying the original quote as proof of origin; orange is a model suggestion; red is missing. Encoding only starts after label 1 has been physically read back and confirmed in plain text; this first-piece check is enforced. The batch then runs with a full read-back of every label and ends with a UID-bound CSV report including a spec checksum and the software and recipe version.
The rule behind it is the same as in the teaser article: the AI never writes. The language model — local on the device, open weights, Apache 2.0 licence, model-agnostic and replaceable — understands and evidences; whatever goes onto the chip is built exclusively by deterministic, tested software. A faulty suggestion dies at validation, at the guardrails or at the first piece. It never reaches the label.
The acceptance series — and the run that failed
Since July 2026 we have measured the language layer in ten pre-registered acceptance runs. Pre-registered means: test scope and thresholds are fixed before the run starts and are not adjusted afterwards. The total: more than 2,200 checked job fields, every measurement repeated three times, more than 6,600 individual measurements. In none of these runs has a faulty AI value ever reached a label.
The series includes one run we report just as openly: run number nine missed the pre-fixed determinism criterion, and was not released. No nudging of the threshold, no "almost passed": cause found, structurally fixed, new run scheduled. That run passed in full. To us, this one withheld release is the best evidence that the acceptance is real: a gate that never fires is not a gate.
The result of the released acceptance run:
100 % slot accuracy — 298 of 298 job fields, every measurement repeated three times · 14 of 14 deliberately planted safety traps caught and stopped · 0 phantom values, 0 build errors, 0 determinism deviations. Pre-registered acceptance run of the language layer, recipe catalogue v8, as of 16 August 2026.
What the station encodes at launch
Recipe catalogue v8 covers the payloads that actually appear on encoding job tickets: link or text, fixed or with a running number; an individual link per label from a CSV file; the digital business card as vCard 3.0; Wi-Fi access as a WPS/WSC credential (WPA2 or open); Smart Poster with link and display title; URI presets for phone, e-mail and geo position; raw block and raw page for special cases; plus customer-specific house formats such as GateSense.
Supported chips are NTAG213 with 144 bytes of usable capacity, plus ICODE SLI (108 bytes), SLIX (108 bytes) and SLIX2 (312 bytes). In a live test under real-world conditions, 4 of 4 encoded chip payloads were byte-identical to the specification, each verified three times.
Local stays local
Nothing about the sovereignty architecture from the teaser has changed — it has simply become buyable: the station runs entirely on the device, air-gap capable, with no cloud account and no telemetry; it is operated in a browser over the local network. The operator interface visibly shows the transparency notice under Article 50(1) of the EU AI Act; based on our own assessment, no high-risk use case under Annex III applies. The AI Act assessment is available as a one-pager (DE/EN) for prospects. The station is developed and assembled by IDCRAFT in Germany.
See it with your own job ticket
The interactive demo runs at idscout.de. For pilot and demo appointments there is exactly one preparation step: bring a real job ticket — that is precisely where the station shows what it can do. We will send the data sheet and the AI Act one-pager on request: sales@idcraft.com.
