The compute module in your robot has a published end date

Every robot deployment carries a date the operator negotiated and a date somebody else set. The negotiated one is in the file: a 36-month lease, a five-year service agreement, a depreciation schedule that assumes the asset earns until year seven. The other one is a line on a vendor web page, it was fixed before the tender opened, and nobody in the procurement chain is contractually obliged to bring it to your attention.

The second date belongs to the computer inside the machine. Service robots and inspection robots overwhelmingly run their perception and autonomy workloads on an embedded module rather than a general-purpose PC, and NVIDIA's Jetson line is one of the recurring families in that role — the payload documented further down is one published example rather than a claim about market share. NVIDIA publishes, for each module, the date through which it will be available. That page is the closest thing this market has to a component end-of-life register, and it is free to read.

None of this is a compliance obligation. No regulation requires an operator to track it, and no conformity assessment turns on it. It is an asset-life question, which is why it belongs beside the lease term rather than in the safety file.

NVIDIA maintains a Jetson Product Lifecycle page listing each module against an availability date. Read on 9 September 2026, the page carries no publication or revision date of its own, which is itself worth noting: it is a live table, and the dates on it have moved before.

The commercial modules, as listed:

• Jetson Nano — available through January 2027.
• Jetson AGX Xavier 32 GB, Xavier NX 16 GB, Xavier NX 8 GB, TX2 NX — July 2027.
• Jetson AGX Orin 64 GB and 32 GB, Orin NX 16 GB and 8 GB, Orin Nano 8 GB and 4 GB — January 2032.
• Jetson T5000 — August 2035; Jetson T4000 — January 2036.

The industrial variants run on their own line: AGX Orin Industrial through July 2033, AGX Xavier Industrial and TX2i through July 2027. Three modules are already listed as end of life — TX2 4 GB and 8 GB and AGX Xavier 64 GB in January 2025, TX1 back in January 2021.

Two of those dates deserve a second look from anyone signing this quarter. The Jetson Nano stops being available in January 2027, roughly four months from now. The entire Xavier family stops in July 2027, roughly ten. A robot bought in autumn 2026 on a five-year plan expects to be working in 2031. Only the Orin and Thor lines have an availability date past that.

The list is only useful if you can map it onto an actual machine, and that is the step most tender processes skip. It is not always possible — many manufacturers do not disclose their compute — but where the manufacturer publishes developer documentation, it usually is.

Boston Dynamics is the clearest case in this segment. Its developer documentation, at the version labelled Spot 5.1.9, states of the inspection compute payload: “The CORE I/O has an NVIDIA Xavier NX, which has an NVIDIA Volta architecture GPU with 384 NVIDIA CUDA® cores.” That single sentence, cross-referenced against the lifecycle page, dates the payload. Xavier NX is a July 2027 module.

This is not a defect in the product and it is not a warning about Boston Dynamics. It is the opposite: the information is published, at a named documentation version, by a manufacturer that maintains a public developer manual. The operator's exposure is not created by the disclosure. It is created by nobody reading it.

The practical asymmetry to plan around is that documentation depth varies enormously across the manufacturer base. Some publish a versioned developer manual; others publish a product brochure and nothing else. Which of the two you are dealing with is knowable before signature, and it is a reasonable thing to ask for in a tender.

A module being purchasable is the weakest of the guarantees on offer, and it is the one that lasts longest. What stops sooner is the software line.

NVIDIA's JetPack SDK is versioned separately from the hardware. JetPack 6 supports the Jetson Orin modules and developer kits, and does not run on earlier Jetsons. JetPack 5 is the line that carries Xavier alongside Orin, and it runs Ubuntu 20.04.

Follow that one step further, because it is where the exposure actually sits. Ubuntu 20.04 LTS was released in April 2020. Its standard security maintenance ended in May 2025. Coverage continues to May 2030, but under Expanded Security Maintenance, which is a paid Ubuntu Pro subscription rather than the default. A Xavier module is served by the JetPack 5 line, and that line's base operating system left standard maintenance sixteen months ago, on a module that remains available for another ten. Which JetPack or L4T version a given payload actually ships is a separate question, and one worth asking directly: Boston Dynamics' documentation names the module but does not state the JetPack version.

The general shape holds beyond this specific example, and it is the part worth carrying into the next tender:

• Purchasable is the longest window and the least useful.
• Receiving new SDK feature releases stops earlier, and stops for the whole module generation at once.
• Receiving security maintenance on the base OS without a paid subscription stops earlier still, and is the one that shows up in a security review.

A machine can be all three, or purchasable and none of the rest, and the contract language rarely distinguishes them.

There is a third schedule, and it is the one that most often surprises an integrator rather than an operator. Where a robot's software stack builds on ROS 2 — as a great deal of mobile and inspection robotics does, and as several manufacturers state in their own connector documentation — the distribution has a published support window of its own.

REP 2000, the Robotics Enhancement Proposal that records releases and target platforms, gives:

• Humble Hawksbill — released May 2022, supported to May 2027, Tier 1 on Ubuntu 22.04 (amd64 and arm64).
• Iron Irwini — May 2023 to November 2024. Already past.
• Jazzy Jalisco — May 2024 to May 2029, Tier 1 on Ubuntu 24.04.
• Kilted Kaiju — May 2025 to November 2026, Tier 1 on Ubuntu 24.04.

Kilted's support ends in about two months. REP 2000 also notes a change in its own status: it applies to ROS 2 releases up to Kilted Kaiju, and from Lyrical Luth onward the same information moves into each release's documentation. An operator does not need to track REP numbering, but anyone maintaining a bookmark to the support table should know it is being retired.

The three clocks interlock and they do not align. ROS 2 Jazzy needs Ubuntu 24.04. JetPack 5, which is what a Xavier module runs, is on Ubuntu 20.04. That gap is not something a service contract closes.

None of this argues against buying. It argues for four lines in the file that are usually absent, all of them answerable before signature and none of them requiring a technical audit.

1. Name the compute module. Manufacturer and part, in the specification, not in an email. Where the manufacturer publishes a developer manual, cite the documentation version you read it in.
2. Record the published availability date beside the contract term. If the term ends after the availability date, that is not a blocker; it is a fact that should have been priced.
3. Separate the three windows in writing. Availability of the module, feature support on the SDK line, and security maintenance on the base OS are three different commitments. Ask which of them the manufacturer is undertaking to you, and for how long.
4. Ask what a module transition costs. Moving a payload from one Jetson generation to the next is a software port, not a swap. The question is who performs it, who pays for it, and whether the answer changes if the manufacturer has moved on by then.

One caution on tooling. A fleet view that shows a firmware or software version per robot makes this legible, and werob's own console does exactly that — but that console is a public demo environment running sample data, not a record of a deployed fleet. Treat any such view as a place the answer can be recorded, not as evidence that it already has been.

The related decision at the far end of the term is covered separately in what happens to a robot fleet at end of life, and the case where the manufacturer itself disappears in what an operator actually loses when a robot supplier goes under.

Precision about what a published date means matters as much as the date itself, and three limits are worth stating plainly.

An availability date is not a switch-off. A module past its availability date does not stop working, and a fleet running on Xavier in 2028 is not thereby broken. What ends is the ability to buy the part — which matters for spares, for expanding a fleet with matching units, and for a manufacturer's willingness to keep building the same product.

Availability is not support. The dates on the lifecycle page say when a module can be bought. They say nothing about how long the manufacturer of your robot will keep issuing software for it. That second commitment comes only from the robot manufacturer, and it is a contract term rather than a published fact.

These are the vendor's dates, and vendors move them. The Orin family's availability was extended once already. An extension is good news for an installed base and it is not something to plan on; a date that can move forward can be read the other way round as well.

What the dates do give an operator is the thing that was missing: a number to put next to the contract term, from a named source, that can be checked by anyone at any time and does not depend on what a salesperson said in the room.