Software regulation is becoming an execution question, not a paperwork question
For most of its history, regulation has lived in documents. A rule is written, a firm writes a policy that says how it will follow the rule, staff are trained on the policy, and an auditor later reads samples to confirm that behaviour matched the text. The system assumes that the important actions are taken by people, at a pace at which a person can stop and check.
Software has quietly broken that assumption. A payment system, a trading engine or an automated compliance filter takes thousands of decisions before anyone reviews the first one. The policy document is still on the shelf. The behaviour it is supposed to govern has moved into code paths that were written by other people, at another time, with other assumptions. When something goes wrong, the investigation reconstructs intent from logs, because nothing recorded intent when the action was taken.
Recent debates about regulating software after a harm tend to reach for more paperwork: more disclosures, more certifications, more attestations that a process exists. Those measures describe the system. They do not constrain it. The harder and more useful question is whether a rule can be carried out by the system at the moment it acts, and whether the act leaves behind evidence that the rule was applied.
Three things have to be true for that to work. The rule has to attach to a legal subject rather than to a device or an account, so that responsibility for the action is a fact and not an inference. The subject has to hold a mandate whose limits are machine-readable, so that the system can tell an action inside the mandate from one outside it. And the check has to produce its evidence at execution, so that an auditor reads the record of a decision instead of trying to rebuild one from surrounding data.
Notice that none of this requires new legislation. The rules already exist. Who may move regulated money, who may sign for a company, what must be reported and when are settled questions in every serious jurisdiction. What is missing is the machinery to apply them where the action now happens, which is inside software, and to bind that application to an entity that can be held to account.
That is what lawful automation means, and it is a standard rather than a product. LTIN argues for it because organisational identity that can be verified is the first of the three requirements, and because identity-bound policy, enforced at a layer above settlement with evidence produced at execution, is the design we are specifying for the layers above it. That design is at an early stage. Nothing in it runs in production, and we attach no date to it.
The direction, though, is not in doubt. Paper controls are losing contact with the speed of the systems they are meant to govern. The next generation of compliance will be judged not on what it documents but on what it can show was checked, by whom, under which authority, at the moment the software acted.
What we do not claim: no automated policy enforcement runs in any LTIN system today, and no regulator has endorsed the approach described here.
