The release.
What crosses to a machine, and what never does. A machine never receives a session. It receives a release: a sealed package a named person signed for, built for the controls that machine already has, and refusable on inspection.
A machine never receives a session.
A session is a recording of one person working. It stays on our side of every boundary drawn on this page, and it stays there permanently.
What reaches a machine is a release. A release is a package built for one family of machine, carrying one named way of working, made to work with the controls that machine already has. It adds no controls, changes no controls, and sits in no part of a safety case. It is built away from the machine, signed before it travels, and it can be looked at and turned back before it is accepted.
A release is signed for by a named person. Not by a system, not by a schedule, not by an account. If no named person signed, nothing goes. That single requirement is what makes the rest of this page possible: every change to what a machine does has a date, a signature and a record behind it, and any of the three can be produced years later.
- 01Built away from the machineNothing of ours is connected to a machine's controls while a session is recorded, and nothing is assembled on a machine in the field. A release is made on our side of the boundary and then it travels.
- 02Signed for by a named personA release carries the name the licence runs under and the signature of the person who released it. Neither can be changed afterwards without the change being visible.
- 03Sealed when it is madeA party at the far end can check that the package in front of them is the package that was signed for, without being handed anything that went into it.
- 04Refusable on inspectionNothing arrives that cannot be inspected and turned back. A refusal needs no reason from us and costs the refusing party nothing.
- 05Fixed once releasedWhat a machine does under a release does not change between releases. A change is a new release, made the same way, signed the same way, authorized the same way.
The contents stay behind. A fingerprint of them travels.
Naming what does not cross is not modesty. It is the specification.
A release carries no recording and no part of one. It carries nothing identifying the person beyond the name the licence runs under — no particulars, nothing about where they work or who they work for, and nothing that could be read as an assessment of them. That last point is a rule and not a preference: a record is never supplied to assess the person, to an insurer or to anyone else. A recording of somebody working is personal information because that person is identifiable in it, and it is handled on that footing from the seat onward.
What a release does carry, in place of contents, is a digest: a short fingerprint taken from what went into it. A digest lets a party at the far end check, today or in several years, that the package in front of them is the package that was signed for. It carries none of the contents and cannot be turned back into them. This is how a licensee's own records, a maker's records and ours can be set beside each other and made to agree without anybody handing over a person's work. How a package is checked years later
Three things, and nothing else
A sealed package, built for the controls that machine already has.
The name the licence runs under, so the hour can be attributed and counted.
A digest of what went into it, so the package can be checked against what was signed for.
What stays on our side
The session, sealed where it was made.
Any part of a recording, in any form.
Anything identifying the person beyond the name the licence runs under.
The contents the digest was taken from.
The boundary at the machine.
The dashed rule below is the product. What crosses it is short and stated; what does not cross it is longer, and stated just as plainly.
Fig. 1 — The boundary at the machine. The sealed object carries a mark; the dashed rule is what information does not cross.
A released package is fixed. It does not learn in the field.
Between one release and the next, what a machine does under a licensed way of working does not drift. This is a design decision, and the reason for it is worth setting out in full.
A release does not adapt to the site, tune itself on the week's work, or carry anything forward from the last job. A change arrives the way the first release did: built away from the machine, signed for by a named person, inspected, and authorized at the machine before anything runs. Every change is therefore a discrete act with a date and a signature attached to it.
Directive (EU) 2024/2853 applies from 9 December 2026, and under Article 2(1) it applies to products placed on the market after that date. A physical machine is unambiguously a product.
Article 7(2)(c) requires a court to take into account "the effect on the product of any ability to continue to learn or acquire new features after it is placed on the market or put into service." Recital 32 puts the same point in terms: "a manufacturer that designs a product with the ability to develop unexpected behaviour should remain liable for behaviour that causes harm."
Article 4(18), read with Recital 40, goes further. A substantial modification can arise "due to the continuous learning of an AI system". Where it does, the modified product is newly placed on the market at the moment the modification is made; Article 8(2) makes the party that made it a manufacturer in its own right; and Article 17(1)(b) restarts the ten-year clock from that moment.
The distinction is exact, and a maker's counsel will hold it to the letter. Continuous learning can constitute a substantial modification, where the two-part test in Article 4(18) is met. It is untested. No judgment anywhere has addressed whether routine incremental refinement crosses the threshold, and there is no authority today that would tell a maker where its own product sits.
A machine whose behaviour is fixed between deliberate, signed releases does not have to answer the question. There is no continuous learning to characterize, no moment to identify, and no argument to be had about which side of an untested threshold a week of site work fell on. Each change is a dated act by a named person, recorded, and checkable long afterwards. It is the clean answer to Article 4(18), and a maker's counsel sees it immediately.
This sets out our own design decision and the reason it was taken. It is not advice about anybody else's obligations, and nothing here tells a licensee what the law requires of them.
The package proposes. A person authorizes. Safety has veto.
A release authorizes nothing by arriving. A person on the crew selects a named way of working before the work starts and clears the machine to run it. That act is what starts the meter: clearance and invoice come off one signed row, so neither can be adjusted without the other. How the count works
There is no default and there is no last-used. A machine does not carry yesterday's choice forward into today's work. A machine running on a choice nobody made this morning would be running on nobody's authority, and afterwards nobody could say whose hour it was or who should be paid for it. Requiring the choice each time costs a few seconds and is what makes the hour attributable at all.
Safety has veto, and the veto is the machine's. Nothing we supply overrides an interlock, sits ahead of a machine's own limits, or forms part of a safety case. We are not a designer, manufacturer, integrator or supplier of any machine or any driver, and no part of any safety case rests on anything we supply. What we stand behind is a short list: the money owed, the count, and the deletion. Never the machine, never the job, never the output.
A release is also not permanent. When the person it came from ends their consent, no new job starts under that name from the day the withdrawal arrives. A job already underway finishes, because stopping a machine mid-pass is its own hazard, and that is the one delay in it. Neither we nor a licensee can extend it, and a withdrawal is never a breach by us and never a failure of supply. What happens to a running machine
Building a machine that has to account for what it runs?
Tell us what your controls already accept, and what they never should.