The Testing-Readiness Brief

What an evaluation in Ukraine actually produces is a document with a date on it — a record of how a named build behaved against a specific threat, on a specific week. That date is the whole reason readiness matters. The threat picture your question was written against does not wait for your paperwork, so the point of preparing is not neatness; it is being able to start while the answer you are buying is still the answer you need.

Makers who stall on the way to a Ukrainian evaluation almost never stall on the hardware. They stall because a licence was started late, because the configuration kept moving, or because nobody wrote down what the test was supposed to prove. The fifteen checks below are the preconditions — the things that have to be true before a range, a unit and a window can be booked around you.

Two of them set the calendar and the rest do not. Start both licences first, then work the remainder while they run.

Moving a defense article into Ukraine for a temporary evaluation is two separate permissions, granted by two different states, and neither one is a formality you can compress. Your own government has to allow the hardware to leave, on the understanding that it is a loan and it comes back. Ukraine has to allow it in, through a party inside the country who takes on the import.

Both of these can be started before you have a range date, a unit, or even a finalised test plan. That is the single highest-value thing on this page: the two items with the longest and least controllable lead times are also the two you can start earliest.

Fifteen checks across five blocks. Nothing you tick is transmitted — the scoring runs entirely in your browser, which is the same rule the rest of our tools follow, and the right rule for anything that describes an unfielded system.

A frozen configuration is the precondition behind every other precondition. Evaluations run over weeks; engineering teams iterate over days. If the build changes mid-evaluation, the record splits into before and after, and neither half is long enough to prove anything.

• Name the build. A revision you can cite in a report six months later, when a procurement officer asks whether the unit they are buying is the unit that was tested.
• Bring spares. Systems are lost during real evaluations — that is what distinguishes them from a demonstration. A single prototype you cannot afford to lose will produce a cautious test and a weak document.
• Solve serviceability. Either someone travels with the hardware, or the failure modes are written down well enough that a local operator can keep it running without you.

Determine jurisdiction before anything else, because it decides which agency, which form and which timeline you are on. Two details catch people out. The first is that US-origin content travels — a European manufacturer with an American subsystem inside the product is on the US regime regardless of where the company sits. The second is that a temporary export is a loan: the paperwork assumes a return leg, and a plan that quietly ends with the hardware staying in Ukraine is a different filing entirely.

The import conclusion is filed from inside Ukraine, which makes your host a structural requirement rather than a nicety — they are the applicant, the counterparty and the party who physically holds the hardware. Get the three documents to agree with each other before any of them is filed.

Discrepancies here are the most avoidable delay in the entire sequence, and they are almost always clerical: a spare that was added after the licence was filed, a serial that changed when a unit was swapped, a quantity that was rounded.

An evaluation is only as good as the question it was built to answer. “See how it performs” cannot fail, and a test that cannot fail cannot support a claim either. Write the question as something that could come back negative, then design the profile against the threat as it stands rather than as it stood when the product was specified.

An evaluation puts your system in front of people whose job is not confidentiality — an operating unit, a range crew, an integrator. The NDA has to reach all of them, and it has to be in place before scoping rather than before shipping, because scoping is when the technical detail first moves.

• Write the IP boundary down. What an operator may see, what may be photographed, what may leave the country. An unwritten boundary is enforced by whoever is standing there at the time.
• Know what you are buying. The deliverable is a documented white paper you can hand to a procurement officer — not a verbal impression and not a video. Establish who owns it before it exists.

1. 1Determine jurisdiction and start your own temporary-export licence. It is the longest pole and it can begin today.
2. 2Name your host in Ukraine and start the temporary-import conclusion in parallel — it needs an applicant on the ground.
3. 3Freeze the configuration and decide the shipping quantity, so both filings describe the same thing.
4. 4Write the falsifiable question and the mission profile, then put the NDA and IP boundary around them.
5. 5Only then book a window. A range and a unit are the constraints you cannot reschedule cheaply.

Makers who lose a season rarely lose it to a refusal. They lose it to order — booking the parts of the evaluation they control before starting the parts they do not, then waiting on a licence with a range already reserved.

Once the preconditions are closed, the mechanics of the evaluation itself are covered in how to test your defense system in Ukraine, and the choice between an independent evaluation and the state platform in independent T&E vs Brave1.