This is a forceful critique of a programme that clearly warrants scrutiny. But it is more confident about causation than the available evidence justifies.
The argument reduces the problem to a choice between training failure and design failure, with track tension as the implied mechanism. That is an oversimplification. The issues publicly associated with Ajax, including vibration, noise, integration, and delayed usability, point to a system-level failure rather than a single-point defect. In complex platforms, these effects emerge from the interaction of design, operating conditions, maintenance, and institutional use. Isolating one variable and treating it as decisive risks misidentifying symptoms as causes.
The same applies to the treatment of official statements. ‘Safe within specification’ and ‘not the soldiers’ fault’ are presented as inconsistent. They are not necessarily so. A system can meet technical specifications while proving unsafe or impractical under realistic conditions. The gap between designed performance and usable performance is well established in complex systems and does not require either confusion or bad faith to explain it.
More broadly, the piece treats ambiguity as something that must be resolved into either incompetence or deception. That framing is too narrow. Defence systems are only partially legible by design. Readiness is distributed across personnel, logistics, maintenance, training, and industrial capacity, much of which cannot be exposed without distortion or risk. Under those conditions, explanations are often incomplete and indirect. That is a structural constraint, not in itself evidence of evasion.
There is also a more fundamental issue. The analysis remains at the level of the programme, when the pattern is systemic. Ajax is not unusual because it failed. It is typical of how capability struggles to translate from technical form into operational effect within existing institutional structures. Focusing on whether tracks were correctly tensioned does not address that problem.
The more relevant question is why failures of this kind persist across programmes with different technologies and contractors. That points towards procurement architecture, risk distribution, and the capacity of institutions to absorb new capability, rather than a single technical fault or a single misleading statement.
For a broader treatment of these constraints, particularly institutional absorption and the limits of publicly legible readiness, I have written about it here:
I write as an ex armoured soldier, mechanical engineer and armoured reconnaissance expert.
The only sources of vibration in an AFV are thr engine, the gearbox or the tracks. If it doesn't vibrate when it's static then its the tracks. End of.
Whil3 I concur that the MOD's problema and the failure of Ajax have multiple causes, chasing then down before acting robustly to actually defend the realm.
The history of UK armed forces decline soans multiple enquires into systems and structures. Thisnone tim the senior people have been caught bang to rights. They shoukd be sacked and that would, perhaps, encourager les autres
I too am former member of the Armed Forces and having worked on trials for both AS90 and Warrior.
The focus on tracks as the primary source of vibration is understandable, but it is too narrow. In armoured vehicles, vibration is rarely attributable to a single component. It emerges from how components interact under dynamic conditions. Tracks, suspension, drivetrain, and hull structure form a coupled system. Change one element and you change how energy propagates through the whole vehicle.
That is why issues of this kind can pass trials and then emerge more clearly in use. The question is not simply whether individual components meet specification, but whether the system behaves as expected once fully integrated and operated at scale. Controlled environments do not always expose those interactions.
Seen in that light, this is not just a technical problem. It is a systemic one.
Ajax fits a wider pattern in UK defence procurement, where programmes struggle at the point where requirements, design, testing, and operational use converge. The difficulty is not identifying a single fault, but managing integration risk and ensuring that what is tested translates into what is actually usable.
Focusing on whether tracks were correctly tensioned risks missing the more important issue. Similar problems recur across different programmes and over long periods. That suggests the constraint lies less in any one engineering decision and more in how procurement itself is structured, how requirements evolve, and how risk is handled.
Until that is addressed, changing components will not resolve the underlying problem.
I'm glad that I dealt with aircraft. A new aircraft that continually crashed on take off would be considered unfit for purpose and the manufacturer sued.
Ajax seems to fall directly into that category and as "Views.." writes, there are many involved in this catastrophy of a programme that should be sacked.
Ajax isn’t just a vehicle that ‘doesn’t work’, it’s a heavily modified version of the ASCOD. Once you start adding weight, changing turrets, and layering UK-specific requirements onto it, you are no longer dealing with a proven design. You are effectively building a new system.
That’s where the problem lies.
This isn’t the first time the UK has taken an existing platform and then pushed it beyond its original design envelope. The risk is not that the base vehicle is foreign, it’s that the modification and integration are not treated with the same rigour as a clean-sheet design.
The aircraft comparison is useful in one respect. In aviation, integration risk is treated very explicitly and certification standards are unforgiving. In land systems, the same level of systemic discipline is not always applied, particularly when programmes evolve over time.
So yes, accountability matters. But this looks less like a single failure and more like a recurring procurement pattern.
Thanks. Maybe I'm taking a simplistic approach, but a piece of military equipment that damages its users, is not fit for purpose. I suppose it depends on how the contract has been written and I've seen some truly bad ones.
I am and automotive engineer but have never dealt with track laying vehicles - but can imagine sound from high load variations transmitted into a hefty hull is going to create quite a racket.
The continuity angle.
Could it be the overall Ajax team did not know the base vehicle well enough, since many other suppliers turned it into something else? In modern speak this is integration, or, more basically, doing one's engineering job.
Then the professional purchasers. Either they don't have capability or access to capability to understand what is being bought or how to monitor / adapt a business contract. Running any contract with a third party is usually emotional, and clear definition of the task is all that's between success and failure.
Ajax was developed from an earlier European model by General Dynamics based in Oakdale/Newbridge in South Wales. This is the same General Dynamics that was responsible for the Army's Bowman radios. Draw your own conclusions.
This is a forceful critique of a programme that clearly warrants scrutiny. But it is more confident about causation than the available evidence justifies.
The argument reduces the problem to a choice between training failure and design failure, with track tension as the implied mechanism. That is an oversimplification. The issues publicly associated with Ajax, including vibration, noise, integration, and delayed usability, point to a system-level failure rather than a single-point defect. In complex platforms, these effects emerge from the interaction of design, operating conditions, maintenance, and institutional use. Isolating one variable and treating it as decisive risks misidentifying symptoms as causes.
The same applies to the treatment of official statements. ‘Safe within specification’ and ‘not the soldiers’ fault’ are presented as inconsistent. They are not necessarily so. A system can meet technical specifications while proving unsafe or impractical under realistic conditions. The gap between designed performance and usable performance is well established in complex systems and does not require either confusion or bad faith to explain it.
More broadly, the piece treats ambiguity as something that must be resolved into either incompetence or deception. That framing is too narrow. Defence systems are only partially legible by design. Readiness is distributed across personnel, logistics, maintenance, training, and industrial capacity, much of which cannot be exposed without distortion or risk. Under those conditions, explanations are often incomplete and indirect. That is a structural constraint, not in itself evidence of evasion.
There is also a more fundamental issue. The analysis remains at the level of the programme, when the pattern is systemic. Ajax is not unusual because it failed. It is typical of how capability struggles to translate from technical form into operational effect within existing institutional structures. Focusing on whether tracks were correctly tensioned does not address that problem.
The more relevant question is why failures of this kind persist across programmes with different technologies and contractors. That points towards procurement architecture, risk distribution, and the capacity of institutions to absorb new capability, rather than a single technical fault or a single misleading statement.
For a broader treatment of these constraints, particularly institutional absorption and the limits of publicly legible readiness, I have written about it here:
https://observatoryanalysis.substack.com/p/capabilitys-problem-is-not-technologyit
https://observatoryanalysis.substack.com/p/why-readiness-is-discussed-more-than
I write as an ex armoured soldier, mechanical engineer and armoured reconnaissance expert.
The only sources of vibration in an AFV are thr engine, the gearbox or the tracks. If it doesn't vibrate when it's static then its the tracks. End of.
Whil3 I concur that the MOD's problema and the failure of Ajax have multiple causes, chasing then down before acting robustly to actually defend the realm.
The history of UK armed forces decline soans multiple enquires into systems and structures. Thisnone tim the senior people have been caught bang to rights. They shoukd be sacked and that would, perhaps, encourager les autres
I too am former member of the Armed Forces and having worked on trials for both AS90 and Warrior.
The focus on tracks as the primary source of vibration is understandable, but it is too narrow. In armoured vehicles, vibration is rarely attributable to a single component. It emerges from how components interact under dynamic conditions. Tracks, suspension, drivetrain, and hull structure form a coupled system. Change one element and you change how energy propagates through the whole vehicle.
That is why issues of this kind can pass trials and then emerge more clearly in use. The question is not simply whether individual components meet specification, but whether the system behaves as expected once fully integrated and operated at scale. Controlled environments do not always expose those interactions.
Seen in that light, this is not just a technical problem. It is a systemic one.
Ajax fits a wider pattern in UK defence procurement, where programmes struggle at the point where requirements, design, testing, and operational use converge. The difficulty is not identifying a single fault, but managing integration risk and ensuring that what is tested translates into what is actually usable.
Focusing on whether tracks were correctly tensioned risks missing the more important issue. Similar problems recur across different programmes and over long periods. That suggests the constraint lies less in any one engineering decision and more in how procurement itself is structured, how requirements evolve, and how risk is handled.
Until that is addressed, changing components will not resolve the underlying problem.
I'm glad that I dealt with aircraft. A new aircraft that continually crashed on take off would be considered unfit for purpose and the manufacturer sued.
Ajax seems to fall directly into that category and as "Views.." writes, there are many involved in this catastrophy of a programme that should be sacked.
Ajax isn’t just a vehicle that ‘doesn’t work’, it’s a heavily modified version of the ASCOD. Once you start adding weight, changing turrets, and layering UK-specific requirements onto it, you are no longer dealing with a proven design. You are effectively building a new system.
That’s where the problem lies.
This isn’t the first time the UK has taken an existing platform and then pushed it beyond its original design envelope. The risk is not that the base vehicle is foreign, it’s that the modification and integration are not treated with the same rigour as a clean-sheet design.
The aircraft comparison is useful in one respect. In aviation, integration risk is treated very explicitly and certification standards are unforgiving. In land systems, the same level of systemic discipline is not always applied, particularly when programmes evolve over time.
So yes, accountability matters. But this looks less like a single failure and more like a recurring procurement pattern.
Thanks. Maybe I'm taking a simplistic approach, but a piece of military equipment that damages its users, is not fit for purpose. I suppose it depends on how the contract has been written and I've seen some truly bad ones.
I think you are right.
What a remarkable situation.
I am and automotive engineer but have never dealt with track laying vehicles - but can imagine sound from high load variations transmitted into a hefty hull is going to create quite a racket.
The continuity angle.
Could it be the overall Ajax team did not know the base vehicle well enough, since many other suppliers turned it into something else? In modern speak this is integration, or, more basically, doing one's engineering job.
Then the professional purchasers. Either they don't have capability or access to capability to understand what is being bought or how to monitor / adapt a business contract. Running any contract with a third party is usually emotional, and clear definition of the task is all that's between success and failure.
Ajax was developed from an earlier European model by General Dynamics based in Oakdale/Newbridge in South Wales. This is the same General Dynamics that was responsible for the Army's Bowman radios. Draw your own conclusions.