Standards Should Be Executable

A standard written for a human to read is a poor fit for a development process that changes by the hour. The shift from documents to data is already happening in places. Here is why it matters, what it requires, and where it is genuinely hard.

Executive summary

A standard is usually published as a PDF: prose, written to be read and interpreted by a qualified human. Modern hardware, and the firmware that ships with it, changes continuously. A document that has to be read by a person to answer a single question does not fit a process that asks that question many times a day.

The interface between the standard and the engineering process is, today, a human reading a PDF. That interface does not scale, and the cost shows up as repeated interpretation, inconsistent results across teams, and no machine link between a clause and the evidence that satisfies it.

This article argues that the content of a standard, its definitions, parameters, limits, and the conditions under which they apply, can and in places already is being represented as structured data that software can check against deterministically, with results traceable to the clause. It is precise about what "executable" does and does not mean: it does not replace engineering judgement or a certification body, and it does not resolve genuine ambiguity by itself. It mechanises the mechanical part and leaves judgement where it belongs. The article gives concrete existing examples, sketches the architecture, and is honest about the hard parts, including ambiguity, copyright, and the authority of the machine-readable representation.

The mismatch at the interface

Consider how a standard is actually consumed. It is written as prose, published as a document, and read by an engineer who interprets it and applies it to a specific product. That has been the model for a long time, and for slow-moving products it was adequate.

Hardware development is no longer slow-moving in this respect. A connected product's behaviour depends on its components, its layout, and its firmware, and any of those can change repeatedly through development and across a product's life. Each change can raise the same question: what does this mean for the applicable standards.

So the question is not asked once. It is asked again and again. And every time it is asked, the model requires a human to read or re-read prose and apply judgement, because the standard exists only as something to be read.

This is the mismatch. The development process is iterative and fast; the interface to the rules is a static document and a human reader. The slow side of that interface becomes the constraint, in exactly the way the companion article on Certification Velocity describes. The document is not wrong. It is simply the wrong shape for a process that needs to consult it continuously.

What "executable" does and does not mean

The word "executable" invites a misreading, so let us be exact, because the misreading is the thing this whole field has to guard against.

Executable does not mean a program replaces the engineer's judgement. It does not mean software certifies a product. It does not mean a certification body is removed from the process. And it does not mean that genuine ambiguity in a standard is resolved automatically, because some ambiguity is real, and some is deliberate.

Executable does mean that the content of a standard, its definitions, its parameters, its limits, and the conditions under which each applies, is represented as structured data that software can check a configuration against. The checking is deterministic and reproducible, and its result is traceable to the specific clause and the specific evidence.

The dividing line is between interpretation and checking. Interpreting an ambiguous clause is a human act and stays a human act. Checking whether a measured value sits within a stated limit, for a configuration that falls within a stated applicability condition, is mechanical, and it does not have to be done by a person reading a PDF.

The argument of this article is narrow and, hopefully, uncontroversial when stated carefully: the mechanical part should be mechanised, and the parts of a standard that are mechanical are larger than the all-prose format makes them look.

The cost of prose-only standards

A standard that exists only as prose imposes costs that are easy to overlook because they are spread across everyone who uses it.

Interpretation is re-done by every consumer. Each team that reads the standard performs the same interpretation independently. The effort does not compound across the industry; it is paid again by each reader.

Ambiguity is resolved inconsistently. Where a clause admits more than one reading, different teams resolve it differently, with no shared record of how. Two compliant-looking products may rest on incompatible interpretations of the same words.

There is no machine link from clause to evidence. The connection between a requirement and the test result or document that satisfies it lives in someone's filing system, not in a form a tool can follow. Tracing it is manual.

Updates cannot propagate. When a standard is revised, nothing automatically flags the artefacts and decisions that depended on the previous version. The propagation is done by hand, if it is done at all.

Cross-references are manual. Standards reference other standards. Following a chain of references to understand a single requirement is a reading task, repeated by every consumer.

None of these is a failure of the people involved. They are properties of the format. A document optimised for human reading is, almost by definition, not optimised for machine processing, and the costs above are what that trade-off looks like at scale.

It is already happening

This is not a thought experiment. There are real, deployed examples of rules and standards represented as data that tools can process, and they are worth knowing as concrete proof that the idea works.

NIST OSCAL. The Open Security Controls Assessment Language, published by the US National Institute of Standards and Technology, represents security control catalogues and assessment information in machine-readable formats such as XML, JSON and YAML. It allows control catalogues, including the controls in NIST SP 800-53, to be processed, mapped and assessed by software rather than transcribed by hand. The project pages are at pages.nist.gov/OSCAL. OSCAL is a clear demonstration that a control framework written for humans can be given a faithful machine-readable form that tools act on.

Machine-readable standards at the international bodies. ISO and IEC have programmes working towards machine-readable, or "SMART", standards, intended to make standards content processable by software rather than only readable as documents. The framing and progress should be checked against the bodies' own pages at iso.org and iec.ch, since this is an evolving area.

Validation languages for structured data. The World Wide Web Consortium publishes the Shapes Constraint Language, SHACL, a standard for validating graph data against a set of constraints. SHACL is, in effect, a way to express rules that data must satisfy and to check them deterministically, which is the same shape as checking a configuration against the conditions in a standard. The older, rule-based validation standard Schematron (ISO/IEC 19757-3) does a related job for structured documents.

The lesson from these examples is that representing rules as data, and checking against them deterministically, is established practice in adjacent domains. The open work is extending it faithfully to the engineering standards that govern regulated hardware, not inventing a new idea from scratch.

The architecture of executable standards

If you assemble the pieces, the architecture has three layers. None of them is speculative on its own; the work is in connecting them for a given domain.

Layer one: the standard's content as structured data. The clauses, definitions, parameters, limits, and applicability conditions of a standard, represented as data. A limit becomes a value with units and a condition under which it applies, not just a sentence. An applicability condition, for example a band, a device class, a topology, or a measurement method, becomes a field that software can match against, not a clause to be read and remembered.

Layer two: the engineering artefacts and evidence, linked to the clauses. The product's configuration, and the evidence about it such as test results, linked explicitly to the clauses they bear on. This is the traceability layer, and a knowledge graph is a natural way to hold it, because the relationships between configurations, clauses and evidence are exactly the kind of structure a graph represents well.

Layer three: deterministic verification. Given a configuration and the applicable structured rules, a checking step produces a result that is traceable to the clause and the evidence, and that is reproducible. This is where SHACL-style validation, or any deterministic rule engine, does its work. The output is not an opinion; it is a checkable statement about a specific configuration against specific rules.

The connective tissue across all three is provenance: a record of which rule, which evidence, which configuration, and which result. With that record, the question "why does this product satisfy this requirement" has a machine-navigable answer, rather than an answer that depends on finding the right person.

Continuous certification and engineering provenance

Once standards are data and evidence is linked, a useful consequence follows. A change can be checked continuously, in the way code is checked in continuous integration.

When an engineer changes the configuration, the deterministic verification step can re-run against the applicable structured rules and report what the change does, immediately, with the result tied to the clause and the evidence. This is what "continuous certification" should mean: not that a machine issues certificates, but that the impact of change on compliance is checked continuously rather than discovered at the end.

The accompanying idea is engineering provenance. Every result carries its trail: the configuration it applied to, the rules it was checked against, the evidence it rested on, and the version of the standard in force. That trail is auditable. A reviewer, or a certification body, can follow it rather than reconstruct it.

It bears repeating, because the field's credibility depends on it: this does not certify the product, and it does not remove the human or the body. It makes their job faster and more auditable by handing them a checked, traceable record instead of a pile of documents and a request to trust someone's memory. The judgement that matters stays human. The bookkeeping that surrounds it stops being manual.

The hard parts

It would be dishonest to present this as easy. There are real obstacles, and they are worth stating plainly, because pretending they do not exist is how this idea gets oversold.

Ambiguity is real and sometimes deliberate. Not every clause reduces cleanly to a machine-checkable condition. Some standards use open wording on purpose, to leave room for engineering judgement or future technology. A faithful machine-readable representation has to mark these as requiring human interpretation, not force them into a false precision. The goal is to mechanise what is mechanical, not to pretend that everything is.

Standards are copyrighted and access-controlled. Many standards are published by bodies that fund themselves through sales and license access carefully. Building open machine-readable versions runs into legitimate rights questions. The bodies' own machine-readable standards programmes are, in part, a response to this: the authoritative structured version may need to come from, or be sanctioned by, the body that owns the standard.

The authority of the representation matters. If a standard is turned into data, someone has to be responsible for the data faithfully representing the document, and for keeping it correct across revisions. A machine-readable representation that drifts from the authoritative text is worse than no representation, because it looks precise while being wrong. Versioning, and a clear chain of authority from the document to the data, are not optional details. They are the core of whether the thing can be trusted.

Cross-standard consistency. Standards reference and depend on each other, and the structured representations have to capture those relationships correctly, including across revisions of the referenced standards. This is tractable but not trivial.

These are reasons the transition is gradual and careful, not reasons it will not happen. The examples above show the mechanics already work. The hard parts are about faithfulness, rights and authority, which are governance problems as much as technical ones.

How Crado approaches this

Crado builds structured representations of certification clauses and a deterministic verification step that checks a configuration against the applicable rules, with every result traceable to the specific clause and the specific evidence it rests on.

AI is used only to read and structure documents such as standards and test reports. The decision comes from deterministic verification, not from generation, which is what makes a result reproducible and auditable rather than a matter of trust.

Crado does not certify products, does not guarantee compliance, and does not replace engineers, accredited laboratories or certification bodies. It treats the standard's mechanical content as data to be checked, and leaves interpretation and final judgement with the people and bodies responsible for them.

Conclusion

The question is not whether standards become executable. In adjacent domains they already are, and the international bodies are working towards it for their own catalogues. The real questions are how faithfully the structured representation reflects the authoritative document, who is responsible for that faithfulness, and how fast the transition can be made without overclaiming.

The document does not disappear. The prose standard, and the human judgement it calls for, remain. What changes is that the document stops being the only interface to the rules. Alongside it sits a structured, checkable representation that a fast, iterative development process can actually consult, continuously, with a trail that a reviewer can follow. That is a better fit for how modern hardware is built, and it is already, in places, how this works.

1. NIST OSCAL — NIST
2. NIST SP 800-53 (Rev. 5) — NIST
3. W3C SHACL — W3C
4. Schematron, ISO/IEC 19757-3 — ISO
5. ISO — ISO
6. IEC — IEC