Deterrence Has Three Clocks

In the first nine months of 2026, Ukraine’s defense industry grew to more than 1,600 companies, Norway committed NOK 1.2 billion to uncrewed maritime systems built with Ukrainian producers, and 36 navies brought 300 uncrewed systems to a single NATO exercise off Portugal.¹³ A product in this sector moves from a reported problem to a fielded fix in months, and sometimes in weeks. The European procurement, certification and insurance reviews that must approve such a product run for months and often years. The operator who receives an alert from one of these systems has minutes to decide what to do with it.

These are three distinct clocks. The release clock is set by the feedback loop between operators and developers that produces fixes. The assurance clock is set by the institutions that must approve, certify, insure or finance a product before it is adopted. The incident clock is set by the time available between an AI output and a human decision. Most of the debate about AI in defense concerns the first clock, and who can build and field faster. I think the more consequential question is what happens between the clocks. As releases outpace reviews, the evidence that buyers and certifiers hold describes products that no longer exist. As alerts arrive faster than either of the other clocks can catch up, operators are asked to trust outputs that no one has tested in the version producing them. Closing those gaps is now part of the deterrent, and it can be measured.

This essay describes each clock and the evidence available on its tempo, maps the interaction between the clocks as a set of feedback loops, proposes adaptation velocity as a measure that captures the lap rather than the fleet, and sets out four gates that Syntony applies between an AI output and the decision it informs. It closes with the limits of the argument and the work needed to turn a framing into a measurement.

The release clock

Ukraine’s defense sector now counts more than 1,600 companies, and its industry council reports that firms make progress on a product within a few months.¹ Investment in Ukrainian defense technology rose from about $1.1 million in 2023 to $105.2 million in 2025, with the largest share going to unmanned and autonomous systems.² That capacity is moving west through joint production, and through European subsidiaries and start-ups built on Ukrainian engineering. Norway’s June 2026 package funds uncrewed maritime systems from Norwegian and Ukrainian industry together, and REPMUS 2026 put 300 uncrewed systems from 36 navies through trials in Portuguese waters.³

Technology changed the terms, but the organizational arrangements are what make this clock fast. Operators report a problem, developers work on it, and useful changes reach units while the problem is still relevant. Copying the equipment alone will not reproduce that process. Joint production can carry part of it to partners, provided the partners inherit the feedback loop along with the production line.

The assurance clock

Every one of those products ends up in front of a European buyer, a certifier, an insurer or an investor, and each of them asks a question that combat use does not answer. Combat use demonstrates that a system can work. It does not document how the system behaves when its inputs are spoofed, when the link drops, or after the next software update. Fixes ship every few weeks and reviews take months, so the evidence in a buyer’s file is usually several versions old by the time anyone reads it.

Regulation adds a second question. The EU AI Act excludes systems used exclusively for military, defense or national security purposes.⁴ Much of the new detection and surveillance software is also sold to ports, energy operators and cable owners, and that version may fall inside the Act. Companies selling into both markets need to know which rules apply to which version, and who owns compliance for each customer.

The tempting response is to slow releases down to suit the paperwork. That gives up the one advantage worth keeping. The better response is to re-test on defined triggers, so that the evidence ages at the same rate as the product. Safeguards that remain static while the product changes are not safeguards for the product in service. That holds for a loitering munition’s target classifier and a counter-drone radar as much as for a maritime drone.

The incident clock

The third clock is the one that concerns me most, because it is where AI and people meet under time pressure. In September 2026, an analyst’s AI chatbot misread a ship’s cargo and nearly led U.S. forces to board a Chinese vessel.⁵ The Joint Expeditionary Force’s Nordic Warden uses AI to score the risk posed by vessels across 22 areas of interest in Northern European waters.⁶ Tools of this kind help analysts decide where to look. They also give a corrupted or spoofed input a new route to authority, and an alert cannot establish that anyone meant harm.

The inputs themselves are under attack. In January 2026, fourteen Baltic and North Sea coastal states warned mariners about satellite navigation interference.⁷ The same jamming and spoofing affects drones and precision munitions, and it degrades the sensors that feed AI classifiers on land. Attribution takes time and is sometimes wrong. When the Sweden to Latvia cable broke in January 2025, Swedish prosecutors eventually concluded that it was an accident.⁸ A risk score that had flagged the ship as hostile would have reached the wrong answer sooner.

A fast incident clock draws on the same scarce resource in every domain: the analysts who establish what happened, the engineers who repair what broke, and the attention of the people who can authorize action. An institution worn down by small incidents and false alarms may be badly placed for a large one. Repairs and continuity measures should not wait for attribution, and an AI alert should not be allowed to decide on its own that attribution is settled.

How the clocks interact

The three clocks are not independent. Following Donella Meadows and the system dynamics tradition, Figure 2 draws the relationships between them as a causal loop diagram, using the same conventions as my October entry on near-term harms.⁹ Each arrow is a hypothesized causal link. A plus sign means two variables move in the same direction, a minus sign means they move in opposite directions, and a pair of bars marks a delay.

Two loops reinforce themselves. In the patch pressure loop (R1), a faster release rate puts more untested versions into service, untested versions produce more incidents and false alarms, incidents create pressure to patch, and pressure raises the release rate. In the alert load loop (R2), incidents and false alarms raise analyst load, higher load reduces the verification each alert receives, and thinner verification lets more errors through to become incidents. The one loop that pushes back is triggered re-testing (B1): a release triggers a re-test, and the re-test removes versions from the untested stock. It kicks in after a delay equal to the review time. If the review takes months, the brake engages long after the version it tested has been replaced.

The structure points to where to intervene. Slowing the release rate weakens R1 and gives up the advantage. Adding analysts to R2 helps until the next increase in alerts. Shortening the delay on B1, so that re-tests complete within the release interval, is the intervention that touches both reinforcing loops at once. That is the case for testing on defined triggers rather than on a calendar.

Measure the lap, not the fleet

If the gaps between the clocks are the problem, the measure to watch is how fast the loop closes. Adaptation velocity belongs alongside readiness, stockpiles, force posture and spending. I define it as the time required to recognize an operational problem, develop a tested response and put it into use. The endpoint matters. An update that units cannot adopt has not restored capability.

Two refinements make the measure usable. The time needed to authorize a change is a different quantity from the time needed to make one. The first is a decision-rights problem and can often be shortened; the second is bounded by production and training. And a drone component and a warship cannot share one acquisition clock. One number for both hides which is slow.

Deterrence depends on whether an opponent believes that capacity will persist. Repeated adaptation under pressure provides that evidence. A rapid prototype alone provides much less. Standing authority for bounded experimentation, access to operational data and reliable funding for adoption make the process less dependent on individual champions.

Four gates between an AI output and a decision

This is the part Syntony works on. Every red-team finding we deliver goes to an owner, a control, a decision and a re-test, so that the evidence reaches someone with the authority to act and is then checked again. For AI in defense decisions, four gates between an AI output and the decision it informs may be worth adopting as a starting position. Each is a test that can be run before deployment and repeated every time a model or an integration changes.

Contestability. An operator must be able to challenge the alert and pause the decision it informs. That authority has to be settled before a crisis, with the reviewer named and the pause procedure rehearsed.

Provenance. AI-derived intelligence should be labeled as such, checked against its sources before it informs a use of force, and kept for review. The September 2026 case would have been caught at this gate.

Degraded mode. The fallback must still work when the data link or GNSS drops, and the test should be run under interference rather than assumed from the specification.

Concentration. No single compromised provider, model or cloud service should be able to take down several services at once. Where it can, the dependency should be documented and a second path provisioned.

The answers should be scored by what happens to the service: how often failures recur, how long recovery takes, and whether the system stays usable when degraded. Those numbers are harder to collect than a count of completed assessments, and they are the ones that show whether the clocks are coming back into step.

Limitations and next steps

This essay should be read for what it does and does not do. The three clocks are a framing, not a measurement. Where each clock sits for a given force or product would require that force’s own data: release logs, procurement timelines and incident records. Table 1 and Figure 1 are indicative, drawn from the public cases cited rather than from a dataset. The loops in Figure 2 are signed but unweighted, and they have not been reviewed by independent experts or tested against incident data.

Adaptation velocity also needs a working definition of when a fix counts as in use, and that definition will differ between a software patch and a hull. We are building those definitions with the organizations we test for, together with an explicit adjacency matrix for the loops in Figure 2 carrying an estimated strength, a confidence level and sources for every link. We will share what holds up.

Conclusion

The same analysts, engineers and decision-makers are being asked to absorb a growing number of systems, each updating more often and each producing alerts, in every domain at once. Speed is valuable when it sustains effectiveness, and dangerous when it outruns understanding of the consequences. The release clock should not be slowed to suit the other two. The assurance clock can be made to run on triggers rather than calendars, and the incident clock can be given gates that an operator controls. Testing on every change, and making sure each finding lands with someone who can act on it, is how the three stay in step.