EASA Standby and Reserve Rules: Call-Out Test Matrix

Executive Summary

European Union Aviation Safety Agency (EASA) standby and reserve rules require different roster states. In Part-ORO, organisation requirements for air operations, flight time limitations (FTL) are addressed by Subpart FTL. Under ORO.FTL.225, standby start and end times must be defined and notified in advance. Airport standby counts fully as duty for the specified cumulative-duty and rest provisions. Reserve, by contrast, involves assignments notified at least 10 hours in advance. A scheduling database therefore needs more than a final duty code to explain a changed assignment. (Source: www.easa.europa.eu) (Source: eur-lex.europa.eu)

For crew-scheduling leads, operations-control managers and information technology (IT) teams, the practical acceptance question is whether an authorized reviewer can reconstruct what was rostered, what was communicated, when contact occurred and when the crew member reported. EASA's frequently asked questions (FAQs) explain that a call during rostered other standby can lead to reporting after its planned end, with the response interval continuing the standby. Duties should in principle start within the operator's defined response time; calls belong within rostered availability. The FAQ also distinguishes changing other standby into airport standby from assigning home standby after reserve ends. These are agency explanations, subject to the controlling provisions and the operator's approved scheme. (Source: www.easa.europa.eu)

The report's proposed test matrix evaluates event provenance, meaning the origin, timing and revision history of the evidence behind a result. The World Wide Web Consortium's PROV Ontology (PROV-O) provides a vocabulary for provenance, while CloudEvents provides a common event description. Neither is prescribed here as an aviation requirement. The useful design principle is to retain the original notification and its later corrections, rather than make the current roster the only surviving record. Microsoft's event-sourcing guidance describes that preservation pattern. ^{[1] [2] [3]}

Public product descriptions establish useful starting points, not acceptance of these scenarios under a particular scheme. FlightStratix advertises an ORO.FTL engine, Leon documents publication acknowledgements and programmatic report access, and AIMS describes crew notification lists. A vendor demonstration should connect those functions to a replayable case and inspectable export. The decision is then concrete: use existing configuration when the evidence survives, add an integration when it is accessible elsewhere, or investigate a larger capability gap when historical evidence cannot be recovered. This report proposes that decision process; it provides no live crew-assignment verdict. ^{[4] [5] [6]}

Introduction and Background

A roster can display a plausible final assignment while leaving an important review question unanswered: what did the crew member know at the relevant time? A revised end time, a call near that end, or a later airport report creates several events for review. The operator needs a way to distinguish their meanings before applying its scheme. Pharos Production's current engineering guide already recognizes notified standby inputs and storing results against roster versions, so the useful next step is a transition-specific acceptance exercise. ^[7]

The jurisdiction is European Union air operations. ORO.FTL.100 describes commercial air transport (CAT) operations with aeroplanes; the applicable certification-specification scope also needs checking for the particular operation. This report addresses the scheduled and charter CAT aeroplane context, without extending its examples to emergency medical service, air taxi, single-pilot or other excluded operations. An air operator certificate (AOC) alone does not settle the applicable specification. (Source: www.easa.europa.eu)

The baseline compilation inspected for publication on 15 October 2026 is EASA's Revision 24, March 2026. Later entries were checked in the Air Operations index, including a Part-ORO amendment concerning flight simulation training devices. The compilation date should therefore be recorded as a research baseline, not represented as proof that all subsequent legislation is irrelevant. An operator's implementation review must identify its applicable amendments and effective dates. (Source: www.easa.europa.eu)

The analysis distinguishes legal requirements, certification specifications (CS), acceptable means of compliance (AMC), guidance material (GM), agency FAQs and proposed software acceptance criteria. EASA explicitly says its FAQ answers are not legally binding. The operator's approved flight time specification scheme and operations manual remain central to the review. (Source: www.easa.europa.eu)

The integration perspective is relevant because LANDING.AERO describes building applications around an operator's specific needs. That is an adjacent implementation route, not a crew-scheduling product or a source of regulatory approval. The article evaluates the evidence that an existing system or integration would need to expose.

Key Changes: Roster Transitions, Not Assumed New Law

A revised standby end is a notification event

“Changes” in this report means changes to an assignment's state. It does not imply that the scenario interpretations were newly enacted in the publication year. EASA's revised-end FAQ explains that standby may cease following notification during standby and that minimum rest should follow notification of the revised end. (Source: www.easa.europa.eu)

The proposed acceptance test should preserve original end, revised end, notification event and effective cessation separately. The reviewer should be able to see whether these coincide or differ, and why. A revision link is preferable to an unexplained overwrite: PROV-O explicitly represents a revised entity's relationship to its original. This is a design recommendation for reconstructability, not a required database technology. ^{[1] [3]}

A near-end call does not make planned end the actual cessation

For testing, give call placement, communication outcome and reporting their own fields. Record the flight duty period (FDP) separately from the reporting event. A single “updated at” value cannot explain which event it represents. The Open Worldwide Application Security Project (OWASP) logging guidance distinguishes event time from logging time, a useful engineering distinction when a mobile record reaches the server later. ^{[8] [9]}

Other standby becoming airport standby changes classification

A proposed record should retain the earlier other-standby interval and the airport reporting event, with the classification applying to each segment. A later correction should explain its relationship to the earlier interpretation. Microsoft's event-sourcing description uses compensating events to preserve originals. ^{[3] [1]}

Reserve ending is different from rewriting active reserve

Reserve's definition uses elapsed advance notification, rather than a loose “next-day” label. The original implementing text specifies at least 10 hours for notification of the assigned duty. (Source: eur-lex.europa.eu)

Test reserve end and any subsequent standby start as distinct events. Preserve the notification of that subsequent standby and any assignment. The absence of a flight should not become permission to relabel reserve retrospectively as recovery rest. EASA addresses that particular retrospective classification separately. (Source: www.easa.europa.eu)

Event Vocabulary and the Evidence Model

The proposed model has two layers: an event history and a current roster view derived from it. Microsoft describes reconstructing current state by replaying events. The proposed demonstration should reconstruct the original case and each corrected version. ^{[3] [1]}

Table 1 separates the proposed evidence fields. These are procurement and integration requirements for the test package, not a claim that EASA mandates these exact field names. OWASP's “when, where, who and what” provides a useful general logging framework. ^[8]

The table deliberately separates operational meaning from storage chronology. OWASP recommends interaction identifiers for related events. In this test package, a correlation reference should join a roster publication, notification attempt, acknowledged change and resulting assignment without pretending that those are the same event. An export should preserve both the individual records and their relationship. ^[8]

Origin and responsibility should travel with corrections. PROV-O attribution links an entity to an agent. The proposed export can use simpler terminology, such as source system, editor and reviewer, provided the meaning is documented. A shared account or automated import should be identifiable as such rather than silently appearing to be a crew acknowledgement. ^{[1] [8]}

The following timelines are hypothetical examples. Their purpose is to test what the product preserves. They do not certify an assignment or replace scheme-specific calculations. An event timeline is useful precisely because a final-state view may conceal the sequence; replay is the relevant capability to demonstrate. ^[3]

Hypothetical Example: revised standby end

Published window -> standby begins -> revised-end notification -> effective cessation -> rest record -> later correction, if any

Hypothetical Example: near-end call

Published window -> call within availability -> original planned end -> actual report -> assigned duty -> review

Hypothetical Example: other standby to airport duty

For this hypothetical conversion, assume less than six hours of other standby.

Other standby -> assignment notification -> airport report (subsequent FDP counting origin in this conversion) -> airport duty segment -> later flight assignment -> review

EASA’s conversion FAQ counts the maximum FDP from reporting for airport standby in this case. Ordinary airport standby under CS FTL.1.225(a)(2)(i) uses the start of the assigned FDP as its FDP counting origin. ( EASA conversion FAQ) ( CS FTL.1.225)

Hypothetical Example: reserve to later standby

Rostered reserve -> reserve end -> separately notified standby -> contact or release -> review

Transition Test Matrix and Event Timelines

Table 2 turns those paths into demonstrations. Its “expected evidence” column specifies the proposed test contract. The legal references identify what the reviewer must consult, not a universal pass/fail ruling generated by the article.

A useful outcome is not necessarily a green legality indicator. For an ambiguous communication record, evidence incomplete is a meaningful software result. The proposed workflow should identify what is missing and who can resolve it. OWASP's distinction between event and logging time supports this treatment of a delayed import; the eventual arrival of a record should not rewrite what the system knew earlier. ^[8]

The event timeline should also distinguish a corrected fact from a changed interpretation. PROV-O's revision relationship provides a general way to link versions, while attribution identifies the responsible agent. A reviewer should be able to determine whether airport reporting was corrected, a scheme parameter changed, or someone applied a different classification to unchanged facts. ^[1]

Implementation Considerations and Process Changes

Preserve history without prescribing a platform replacement

ORO.FTL.245 requires specified individual records and reports to be maintained for 24 months. That requirement should not be represented as an explicit mandate for every proposed event field in this report. The operator should map mandatory records and its additional review evidence to a documented retention policy. (Source: www.easa.europa.eu)

An integration may suffice when existing roster, notification or crew-application events need a combined view. Microsoft says traditional data management suffices for most systems. Begin with an evidence inventory and replay demonstration before selecting an architecture. ^[3]

Use a proposed export contract with defined relationships. CloudEvents supplies a common event envelope, but the operator still needs the crew-specific payload and semantics. PROV-O offers provenance concepts without obliging an implementation to use its full ontology. The interface should explain its fields in terms that scheduling and IT staff can both review. ^{[2] [1]}

Acceptance requirements are:

• Identity: stable source-system and event references, plus the affected assignment. ^[9]
• Chronology: occurrence, receipt, publication and correction meanings documented separately. ^[8]
• Classification: interval type and location retained before and after a change. ^[1]
• Notification: communication outcome preserved without equating dispatch, delivery and acknowledgement.
• Configuration: scheme and calculation configuration identified in the result. ^[7]
• Correction: an explicit replacement or correction relationship, with attribution. ^[1]
• Export: machine-readable history that an operator can inspect outside the user interface. ^[1]
• Review: named ownership for missing evidence and disputed classifications. ^[1]

For identity, the official CloudEvents specification requires a unique combination of source and identifier and permits consumers to recognize repeated combinations as duplicates. A roster integration should document its equivalent convention. Reprocessing the same source event should not create a second operational call or a second crew acknowledgement. ^[9]

Test transport behavior as well as calculation behavior

Delivery guarantees depend on the actual interface. Amazon Simple Queue Service (SQS) standard queues, for example, document possible duplicate delivery and occasional out-of-order arrival. That does not establish how any named roster product works. It does justify asking an integration supplier to demonstrate its own duplicate and ordering behavior explicitly. ^[10]

The replay exercise should include the following proposed tests:

• Duplicate import: replay an identical event and inspect the resulting history. ^[9]
• Late arrival: receive the reporting event before an older notification record. ^[10]
• Correction: amend a source time while preserving the previously recorded value. ^[3]
• Partial outage: reconnect a crew device and distinguish event time from receipt time. ^[8]
• Re-export: compare successive exports for stable identifiers and documented changes. ^[9]
• Configuration change: evaluate the same evidence under identified configuration versions. ^[3]
• Access control: demonstrate who can correct evidence and who can approve its interpretation. ^[1]
• Recovery: rebuild the review view from the retained source evidence. ^[3]

These are synthetic acceptance inputs, not claims about observed vendor failures. Microsoft's guidance recommends event version identifiers. In this context, the test should verify how an older exported event is interpreted after a schema change, and whether the archived case remains understandable without a current production interface. ^[3]

Timestamp Interpretation and Export Tests

Request for Comments (RFC) 3339 permits numeric offsets, and its discussion of string ordering assumes consistent representations, including fractional-second precision. Sort normalized instants rather than assuming arbitrary timestamp strings produce a reliable chronology. Preserve the supplied value alongside the normalized value when it is important to the review. ^[11]

Database type selection needs explicit testing. PostgreSQL documents that a timestamp without time zone can ignore a supplied zone indication, while full zone names can carry daylight-saving rules. A migration test should therefore cover local-clock transitions, missing offsets and import conventions. It should demonstrate the chosen product's actual behavior, not assume that all database types interpret the same input identically. ^[12]

Occurrence time should mean the event's claimed real-world time. CloudEvents defines a time attribute for occurrence, but makes it optional and permits a consistent substitute when occurrence time is unknown. Consequently, accepting a generic event envelope is insufficient: the operator should specify what each exported time actually means. ^{[9] [8]}

UTC and local context also need separate treatment. RFC 3339 defines numeric offsets relative to Coordinated Universal Time (UTC). PostgreSQL's timestamp-with-time-zone storage does not retain the originally supplied zone. Preserve the original local representation and applicable zone separately when they are needed to explain a roster boundary; do not assume a UTC column can recover them. ^{[11] [12]}

The proposed round-trip test should start with an exported record, pass it through the intended integration, and compare the reconstructed operational instant and retained local context. Include a missing offset, a repeated local-clock value and a later correction. Mark ambiguous inputs for review rather than inventing a zone. Test stable ordering independently of how the user interface formats the timestamps. The documented offset and storage semantics explain why both checks matter. ^{[11] [12]}

Vendor Demonstration and API Acceptance

Public feature descriptions are starting evidence. Pharos's updated guide discusses storing verdicts against roster versions. FlightStratix advertises checks when assignments are entered. Those statements support a concrete demonstration request, but do not establish how every historical transition is stored or exposed under the operator's configuration. ^{[7] [4]}

Leon documents automatic publication notifications, acknowledgement tracking and report data through its GraphQL application programming interface (API). AIMS describes notification lists and an option to mark crew as notified. The acceptance exercise should ask what those statuses mean, who or what sets them, and which associated times appear in the export. ^{[5] [6]}

A proposed vendor demonstration script is:

• Load the case: identify the hypothetical crew, applicable operation and scheme configuration.
• Publish the window: export the original assignment and publication evidence.
• Create the transition: revise the end, place the call, or change the subsequent assignment.
• Inspect communication: show message attempts, outcomes and acknowledgements actually retained.
• Record reporting: enter instructed and actual reporting independently.
• Inspect the result: identify input intervals and configuration behind the displayed outcome.
• Correct one fact: show the previous value and the reason for correction.
• Export history: produce records that reconstruct both the original and corrected case.
• Replay independently: rebuild the review view using the exported package.
• Assign exceptions: show the operational and technical owner of unresolved evidence.

A distinction between aggregate reporting and event evidence is important. Leon's Roster Robustness documentation says changes made within five minutes of the preceding update do not trigger that report's change count. That is a documented counting behavior, not proof that underlying audit records are missing. Ask for the underlying evidence rather than treating a report counter as a complete history. ^[13]

Likewise, an API claim does not establish a complete event schema. Leon's documented programmatic report access should prompt a field-level inspection. Ask the supplier to identify which endpoint, permission, date filter and historical-version mechanism actually returns the evidence needed by the matrix. A screen capture is useful context, but a repeatable export is the proposed acceptance artifact. ^[5]

The decision can be recorded as existing capability, configuration work, integration work or unresolved evidence requirement. These are proposed project categories, not a market ranking. Record the evidence supporting the selected project category and the operational reviewer responsible for accepting it. ^[3]

Data Analysis and Evidence

The quantitative core is deliberately limited to sourced rule parameters and reproducible evidence tests. It does not estimate fatigue from a roster counter. Table 3 summarizes selected CS provisions that the authorized reviewer may need when interpreting the scenario package. All entries come from the inspected CS text; their applicability and interaction still require the approved scheme.

The table separates clock boundaries from evidence requirements. It does not make the referenced airport combined-duration rule universal across every FDP arrangement, or turn standby plus FDP into observed wakefulness. The CS source is used here as a concise parameter inventory rather than a ready-to-dispatch calculator.

Hypothetical Example: elapsed interval. Suppose the notified standby start is 08:00, a revised-end notification is recorded at 11:30, and the effective end is also 11:30. The elapsed interval is 3 hours 30 minutes, by direct subtraction. That arithmetic is illustrative, not a legal verdict. The evidence test is whether the export preserves the original end, both notification and effective-end meanings, and any later correction. OWASP's event-versus-log distinction explains why the server's receipt time should not silently replace the operational event time. ^[8]

A quantitative acceptance report should publish denominators rather than unsupported performance claims. Proposed measures include:

• Reconstructable cases: cases whose required evidence is available, divided by cases executed.
• Missing fields: absent required evidence items, grouped by scenario and source system. ^[8]
• Replay agreement: cases reproducing the approved expected interpretation, divided by cases reviewed. ^[3]
• Duplicate stability: repeated imports that leave the interpreted event count unchanged. ^[9]
• Correction traceability: corrected cases retaining the original fact and responsible editor. ^{[3] [1]}

These are proposed project measurements. No vendor benchmark or acceptance percentage is asserted. Microsoft's replay pattern and CloudEvents' duplicate-identification convention explain what the tests exercise, but the operator must approve the expected interpretations and acceptance criteria. ^{[3] [9]}

Original aviation research also distinguishes duty data from sleep observations. A controlled-rest study used actiwatches and sleep logs; a separate roster survey collected reported duty, standby and rest information. Those are different evidence types. Neither justifies inventing an individual crew member's sleep from an unassigned period on the roster. ^{[14] [15]}

Implications and Future Directions

The useful procurement question is which evidence is recoverable, not merely whether a supplier advertises an FTL engine. FlightStratix's documented engine and AIMS's notification features describe relevant functions, while Pharos explicitly discusses version-linked results. A fair evaluation should acknowledge those published capabilities and then test the operator's actual scenarios without assuming undocumented support or absence. ^{[4] [6] [7]}

A small integration may be appropriate when an existing product holds the events but the review workflow cannot join them. LANDING.AERO's stated scope includes integrating disparate data sources; that represents a custom implementation category, not a substitute for a crew-roster product or competent-authority approval. Any project should begin with the source inventory, export sample and approved review responsibilities.

Future interface improvements should emphasize explicit meanings rather than additional generic timestamps. CloudEvents standardizes a common description; PROV-O supports interchange of provenance. Those concepts can help operators specify portable evidence without claiming that adoption of either standard makes a system compliant. Suppliers can demonstrate the result through a historical case rather than architecture slides. ^{[2] [1]}

Operator ownership should include both technical interpretation and crew experience. Original qualitative aviation research identifies value in pilots' experience within fatigue risk management. For this project, that supports including operational users when reviewing whether a notification history is intelligible, while keeping regulatory interpretation and scheme ownership with the authorized functions. It does not establish an effectiveness benchmark for the proposed integration. ^[16]

The practical next deliverable is an agreed evidence package and a signed acceptance record. PROV-O's attribution concept is useful here: the package should identify who supplied a source fact, who corrected it and who accepted an interpretation. Future corrections should supplement that record rather than make the earlier review disappear. ^{[1] [3]}

Frequently Asked Questions (FAQs)

Is reserve simply home standby with a different label?

No. Reserve's definition provides advance notification of an assigned duty of at least 10 hours. The distinction matters even if both periods occur away from the airport. The export should identify the classification actually rostered and the notification evidence, rather than infer the category from location alone. (Source: eur-lex.europa.eu)

Does a visible notification status prove every relevant timestamp exists?

No such conclusion follows from a feature label. AIMS documents a notified status option, and Leon documents acknowledgement tracking. The proposed acceptance test asks for the underlying meaning, author and timestamps. It should record what the product demonstrates instead of assuming an API exposes every detail visible in the interface. ^{[6] [5]}

What should a timed transition and its correction export show?

Hypothetical revised-end acceptance test: all times below are UTC on the same day. Publish a standby window of 08:00–14:00. Initially record revised-end notification and effective cessation at 11:30, received by the system at 11:32. At 12:00, add a correction stating that both notification and cessation occurred at 11:25. These are synthetic test inputs, not an operational or legal verdict.

The proposed export should contain:

Require the correction to retain the previous values, reason, source reference and responsible editor. Replay the before-correction and after-correction views separately; keep the planned window identifiable in both. ^[3]

Conclusion

A useful standby and reserve evaluation begins with the question the reviewer must answer, then works backwards to the evidence. The matrix focuses on revised ends, late calls, changes to airport duty and reserve transitions because they expose the difference between a final roster and a reconstructable history. The proposed deliverable is an explainable case package, not an additional generic counter.

Keep meanings separate: planned, notified, actual and corrected times; communication outcomes; interval classifications; source facts; and reviewer interpretation. General provenance and logging guidance support those separations, while the operator defines the concrete payload and acceptance process. Neither a common event format nor a database pattern replaces the approved scheme. ^{[1] [8]}

Require a demonstration: create the scenario, inspect the result, export the evidence, correct a fact and replay the case. Judge published vendor functions against what is actually demonstrated in the configured environment. Where the necessary history exists, configuration or integration may be enough. Where evidence is unavailable, record the unresolved requirement and its owner before accepting the workflow. ^[3]

The operator remains responsible for the operational interpretation. Scheduling, operations control, safety and IT should leave the acceptance exercise with a shared record of the evidence preserved, the assumptions applied and the exceptions requiring authorized review. That makes the software decision concrete while keeping regulatory and operational authority in the appropriate hands.