Industrial Autonomous Assurance

A robot cell is sold with a Declaration of Conformity, a risk assessment and a sign-off. Then somebody updates the safety controller firmware, reshapes a scanner zone, or patches a PLC project — and every one of those documents quietly stops describing the machine that is actually on the floor. Nothing in the plant says so. The paperwork still looks correct, which is worse than it looking wrong.

Two regulations turned that from a quality problem into a legal one:

Reg. (EU) 2024/2847 — Cyber Resilience Act, Art. 14	Applies since 11 Sep 2026. An actively exploited vulnerability means 24 hours to file an early warning that indicates, where applicable, the Member States where you know the product has been made available (Art. 14(2)(a)). Art. 69(3) extends the duty to products placed on the market before 11 Dec 2027.
Reg. (EU) 2023/1230 — Machinery Regulation, Annex III 1.1.9	Applies 20 Jan 2027. The machine must identify the software installed on it that is necessary for it to operate safely, and collect evidence of a legitimate or illegitimate intervention in, or modification of, that software or its configuration.

Annex III 1.1.9 is a design requirement on the machine; Art. 14 is a reporting process; the Machinery Regulation obligation falls on the manufacturer's design of the machine. Software of ours satisfies neither for you. What a hash-chained record of what is on each machine, which checks were run against it, and when can do is let a manufacturer evidence its own process, and show a reviewer which records stopped describing the machine.

That record is what this builds.

---

Start here: see a real report in a second, then run it on your own plant

pip install cryptography                       # the one third-party package the offline kit imports
export PYTHONPATH=src                          # run from this checkout; nothing else is installed
python -m assurance report demo --out demo/    # a worked fleet; nothing to edit; open demo/report.html

That runs the real collection, normalisation and engines on synthetic exports and writes a self-contained demo/report.html (no scripts, no network). It is a demonstration on made-up machines, not evidence about yours.

For your own plant, the kit is a skeleton you fill in. kit run refuses to produce evidence while template values remain, because that report goes to an auditor, an insurer or a customer:

python -m assurance kit init plant/            # a kit skeleton: edit kit.json and plans/cell.json (placeholders)
python -m assurance kit check plant/kit.json   # names every placeholder still there, and what it would open. Reads only
python -m assurance kit run  plant/kit.json --out plant/out

Once the placeholders are replaced and your vendor exports are in place, you get plant/out/report.html, plant/out/evidence.db and plant/out/attestation-request.json. Your ledger, your disk. For the kit: no account, no API key, no upload, nothing to procure. (That is true of the kit and of the other offline commands. It is not true of the hosted service below, which needs an account and a key.)

pip install -e . from the checkout is the same minimal install: the project's base dependencies are cryptography and nothing else, because that is all the offline kit imports outside the standard library (pip install -e '.[assurance-attest]' is identical, a label kept so existing commands work). The hosted API, the MCP gateways and the NeuralBridge integration platform are extras, listed under Install.

The run arms a guard over the process's socket layer, refuses every outbound connection — including name resolution, because resolving a name has already told a DNS server something — records any attempt with the line of code that made it, and seals that record into your own ledger. "It does not phone home" stops being a promise in a datasheet and becomes a hash in a file you hold.

check is the command to hand your IT department. It lists every file a run would open and touches nothing.

See deploy/assurance/KIT.md.

What it does, and where each claim is enforced

Every row below maps to code that runs, offline, on your own files. The hosted counter-signature (POST /v1/ledger/attest) is a separate thing: it answers 503 no_attestation_key_configured until the service has a signing key, and none is configured on any deployment today. Nothing is listed here that the software does not do; what it does not do is listed in each command's output.

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗