Who it's for · Head of unit

Miguel signs it. He needs a reason, not a slide.

“I sign the roster. If the regulator asks me which of the eight elements this satisfies, I need an answer that is not a vendor slide.”

Miguel runs a mid-sized area control centre.^* ATS.OR.320 puts the rostering system's fatigue management under his name, not the rostering office's. When an inspector or a union representative asks which element of the regulation a specific duty pattern satisfies, the question lands on his desk, not on whoever built the roster.

What he actually needs to decide is narrower than picking a vendor. Are the eight elements ATS.OR.320 requires him to specify actually specified, in numbers, for this unit? Can he show that specification without translating it out of a sales deck? And once a roster is published, can it be checked against that specification again, on demand, rather than just trusted because a planner clicked solve once?

The regulation, mapped

Eight elements. Eight settings.

ATS.OR.320(a) names eight things a rostering system must specify. Below is where each one lives in SkyRoster's configuration, not in a brochure.

ATS.OR.320, verbatim

“An air traffic control service provider shall develop, implement and monitor a rostering system in order to manage the risks of occupational fatigue of air traffic controllers through a safe alternation of duty and rest periods. Within the rostering system, the air traffic control service provider shall specify the following elements: (1) maximum consecutive working days with duty; (2) maximum hours per duty period; (3) maximum time providing air traffic control service without breaks; (4) the ratio of duty periods to breaks when providing air traffic control service; (5) minimum rest periods; (6) maximum consecutive duty periods encroaching the night time, if applicable, depending upon the operating hours of the air traffic control unit concerned; (7) minimum rest period after a duty period encroaching the night time; (8) minimum number of rest periods within a roster cycle.”

“An air traffic control services provider shall consult those air traffic controllers who will be subject to the rostering system, or, as applicable, their representatives, during its development and its application, to identify and mitigate risks concerning fatigue which could be due to the rostering system itself.”

Commission Implementing Regulation (EU) 2017/373, Annex IV (Part-ATS.OR), ATS.OR.320(a) and (b)

Element	How SkyRoster configures it
(1) Maximum consecutive working days with duty	A per-unit rule caps how many consecutive days someone can be rostered before a rest day is forced. Set it hard or soft, and set the number, per unit.configured
(2) Maximum hours per duty period	A per-shift-type hour cap, checked on every duty the solver places or a planner hand-assigns. configured
(3) Maximum time providing ATC service without breaks (4) Ratio of duty periods to breaks	These two sit one level down from the monthly roster, on the shift type itself, as a configured break window and duration. Every shift type your unit defines carries its own break rule, not one company-wide number. configured
(5) Minimum rest periods	The rest-time rule checked between any two consecutive shifts a person is assigned, unit by unit. configured
(6) Maximum consecutive duty periods encroaching night time	A dedicated rule for consecutive nights, separate from the general consecutive-duty cap, so a unit can set a tighter limit on nights specifically.configured
(7) Minimum rest period after a duty period encroaching night time	Each shift type carries its own configured minimum rest afterward. Set a longer recovery period on your night shift types than your day ones, and the two numbers are enforced separately. configured
(8) Minimum number of rest periods within a roster cycle	A minimum-consecutive-off-days rule, applied across whatever cycle length your unit rosters against. configured
(b) Consult the controllers subject to the rostering system	Not a software setting. This is a process your unit runs. SkyRoster gives you the screen to record the numbers that consultation produces, not a way around having it. See how units document it.

Five of the eight elements above are configurable rules inside SkyRoster's solver catalogue, which holds close to ninety of them in total: enabled or not, hard or soft, and a numeric threshold, per unit. The other three, the two about breaks within a duty period and the minimum rest specifically after a night duty, are configured one level down, on the shift type itself, because a break window or a shift-specific rest requirement is a property of the shift you're scheduling, not a property of the monthly roster around it. Either way, the number is yours to set. Nothing here ships as a fixed default disguised as a regulation.

Before he signs

A catalogue he can check himself, not take on faith

Three facts, not one document, are what the safety case behind this actually rests on.

Fact one · compiled on every build

The rule catalogue

Every constraint the solver can enforce, its display name, and whether it's a fixed data-integrity guard or an admin-tunable rule, regenerated straight from the product's own constraint code on every release. What Miguel reads matches what the solver actually runs, not what a slide said eighteen months ago. verified

Fact two is the consultation: the numbers in the table above were reached by talking to the controllers subject to them, which ATS.OR.320(b) requires and which stays a conversation you have, not a feature you buy. See consulting controllers.

Fact three is that the published roster can still be checked, not just trusted. Check Solution re-scores a roster, published or hand-edited, against every active rule in seconds and shows exactly which duty broke which rule, if any did. It isn't a re-solve; it's the same compliance check a planner ran before publishing, available again whenever anyone asks.

Which changes actually need his name on them

Not every roster edit should need a head of unit's sign-off, and not every one should skip it either. Publishing carries three strategies: Override for an in-place correction, Minor for a routine change, and Major for a real re-design. A unit can be configured so that a Major publish requires the head of unit's explicit approval, while Minor and Override publishes are delegated to any authorised planner. configuredYou decide where the line between routine and needs-my-name sits for your unit.

Honestly

What SkyRoster does not do for him

It does not choose the eight numbers. The thresholds are a safety-policy decision for your unit and its safety management process. SkyRoster enforces whatever you configure; it has no independent opinion on what's actually safe for your operation.

It does not run the consultation ATS.OR.320(b) requires. That conversation with your controllers or their representatives is yours to have. The product gives you a place to encode the outcome once you have it, not a way to skip it.

It does not certify compliance. What you get, every time you publish, is a check against the rules you've configured. Whether that configuration itself satisfies a regulator's reading of ATS.OR.320 is a judgment for your safety office and your regulator, not a badge the software issues.

Solving is not deterministic. Two solves of the same demand against the same rules can place duties differently while landing on an equally compliant, comparable score. A published roster satisfies your rules; it is not the one true answer to them.

* Miguel is a fictional persona, not a specific customer or contact. He stands in for the head-of-unit conversation that comes up on most deals.

Bring your unit's numbers, not ours.

A working session puts your actual consecutive-day, rest and night limits into a test configuration, live, so you leave with the eight elements mapped to your unit, not a demo one.

Book a working session Send a question instead

Who else will ask, and what they will want