---

The promise is the same everywhere: software at lower cost, at higher speed - and, done right, at a quality that can be proven rather than promised. What differs by domain is the barrier to getting there; the cost of never getting there does not differ at all.

The change every one of them is facing

Defense and other restricted environments cannot send source code to a hosted model at all. Regulated domains can, in principle, but a new development method takes years to work through processes that were written for the old one. Elsewhere the barrier is simply that nobody has agreed yet what evidence an AI-assisted change has to carry.

The constraints differ. The exposure does not: an organization that waits until the question is settled will be competing on cost, speed and quality against ones that did not wait.

We build for the awkward middle - the period in which the method is clearly coming and the conditions to use it safely are not yet in place.

That has one consequence worth stating plainly. Because the acceptance decision is made outside the generator, the generator does not have to be the best one available. A weaker model that iterates against a deterministic gate, versioned test oracles and evidence measured on the real target is a different proposition from a strong model trusted to assess its own output. It makes locally hosted models a workable option where a hosted frontier model is not permitted - and that is exactly the situation in the domains with the strictest constraints.

Deployment modes and the data boundary are agreed per engagement.

The same observation methods can support regulated assurance, integration debugging, performance analysis and field-oriented investigations. The evidence claim changes with the use case; a diagnostic result is not presented as certification evidence merely because the underlying trace mechanism is the same.

What it is built for

Avionics. The barrier is process: certification workflows take years to absorb a new development method. The evidence layer is ready earlier - evidence from a modified executable needs a representativeness argument within the certification context, and passive observation from the trace port avoids application-side coverage counters and reduces that particular difference, for today’s code and unchanged for generated code. → avionics

Defense and space. The constraint here is not the standard, it is access: code that cannot leave the environment, and a toolchain whose origin has to be declarable. CEDARtools.Forge is built to run where the code already is - including with locally hosted models, where a hosted frontier model is not permitted - and Accemic develops in Germany. How far that reaches shows at the far end of the chain: CEDARtools.TraceEncoder is our own RTL, developed in Germany and published under an open license, so even the trace source in your silicon is RTL whose origin is declarable: every distributed file developed by Accemic in Germany, with the provenance records to show it.

Automotive. The same class of barrier at automotive pace: the assurance argument for an AI-assisted change under ISO 26262 is still being worked out. The measurement does not have to wait - structural coverage not only at unit level but at integration and system level, on the ECU rather than on a host simulation. → automotive

Rail. EN 50128 / EN 50716 ask for the same structural evidence, and rail adds time: systems specified now will still be in service when the method change is long complete. Evidence measured on the shipped binary keeps its meaning across that change - whoever, or whatever, wrote the code.

Industrial automation. The least regulated domain here, so the barrier is agreement: no shared expectation yet of what evidence an AI-assisted change has to carry. Evidence about the shipped binary is a starting point that needs no standard to be useful - and it pays for itself today, in long-running processes where the interesting fault appears after days.

Medical devices. IEC 62304 scales verification with the software safety class, and it also requires the project to identify and control SOUP - software developed outside the current device lifecycle, often without the development records the standard expects, and frequently delivered with no source and no build to instrument. That is the code most likely to be excluded from a coverage figure and most likely to be running when a device is in a patient’s room. Passive observation from the trace port sees it execute like any other code, because it does not need the build. Code from an AI assistant raises the same question in a new form - trusting code your team did not write - and the answer does not change: evidence about what actually runs.

The part this list gets wrong

Read straight down, that list says: this is a tool for regulated industries. It is not, and we would rather say so on the page than let the list imply it.

Safety domains are where these methods were developed, because regulation forced someone to pay for them. The methods themselves are not safety-specific - they are expensive-specific. Wherever a failure in the field costs more than the testing would have, evidence about the shipped binary is worth having, whether or not an auditor asks for it.

The regulated domains are the proving ground. They are not the boundary.

Where that shows in practice - real-target evidence when no auditor is asking