Why SSIM files fail quietly — and why validation matters

An SSIM file can be wrong in ways that never raise an error. A transfer cut short, a field shifted by one character, a date that doesn’t exist, a code share counted as a flight the airline operates — each one still produces a schedule that looks complete. Nothing crashes. The numbers are simply wrong, and they travel: into a planning model, a revenue forecast, a slot request, a report to the board.

That is why validation has to come before anything else reads the file.

The errors that don’t announce themselves

Most schedule errors are not malformed lines. They are well-formed lines that say the wrong thing.

• A file that stopped early. Every line that arrived is a valid record, so a truncated file reads without complaint. The only sign is what’s missing — and you can’t see what isn’t there.
• A field one place off. SSIM is fixed-width. A value that slips by a single character becomes a different value in the next field: a time becomes part of a station code, a station becomes part of an aircraft type.
• Dates and days that disagree. A period that never contains one of its own operating days, or an overnight arrival dated before its departure, produces flights that never happen — or happen twice.
• The same flight counted twice. Code shares, wet leases and shared designations look like ordinary flights. Count them as operated and capacity is inflated, sometimes by a third or more on a busy route.
• Codes that aren’t codes. A service type, a meal note or a data element that isn’t in the standard is easy to miss and easy to misread.

What it costs

A schedule is rarely the end product. It feeds network planning, revenue management, slot coordination, crew and aircraft planning, distribution and analytics. An error that slips through at the start is multiplied by every system that trusts it — and found, if at all, much later and much further away, when someone notices a market that doesn’t add up.

The cheapest place to catch an error is the moment the file arrives.

What good validation looks like

Good validation is more than “does the file parse”. It reads the file the way the standard defines it — every record, every field — and then asks whether the parts agree with each other. And it reports in a way people can act on:

• Where — the exact record and field, so it can be fixed at the source rather than worked around.
• Why — which rule it breaks, in plain words.
• How serious — an error that makes a flight wrong is not the same as a quirk the industry tolerates. Real files carry harmless deviations; flagging them all as failures buries the ones that matter.

That last point is where most home-grown checks fall down. Too strict, and every real feed fails. Too lenient, and the errors that change the numbers get through.

Where SSIM Toolkit fits

SSIM Toolkit validates a schedule as it reads it. Every finding names its rule, points at the record and field it concerns, and says how serious it is — with real-world quirks told apart from real errors. Your file stays on your machine throughout.

Try it on a file you know. SSIM Toolkit comes with a 30-day free trial.

FAQ

Is a file that opens without errors a valid file? No. Most serious schedule errors are well-formed records that say the wrong thing. Reading a file and validating it are different jobs.

Should every deviation from the standard be treated as an error? No. Real feeds carry deviations that are harmless and widely tolerated. Useful validation separates those from the ones that change what the schedule means.

When should a schedule be validated? As soon as it arrives, before anything downstream reads it.