Canadian Flight Duty Record Keeping Requirements: 704/705

Executive Summary

Canadian flight duty record keeping requirements start with Canadian Aviation Regulations (CARs) section 700.20, rather than with a roster format. The operator must monitor each flight crew member’s flight time, flight duty periods (FDPs), hours of work and rest, and describe that system in its company operations manual. Records cover flight time; the start, end and duration of FDP, duty and rest; time free from duty; and specified pilot-in-command (PIC) notifications. Retention is 24 months after the day records are made. ^[1] Transport Canada’s guidance includes the operator’s activity across subparts. ^[2]

For scheduling and information technology (IT) teams, the central question is whether the retained evidence can reconstruct a crew member’s actual activity after schedules change. A report assembled from current roster rows alone should be tested against actual duty submissions, positioning, rest evidence and exceptional notifications. Public documentation illustrates different evidence channels: Leon describes a roster-and-duty export, while FL3XX documents actual duty entry and external-system integration. These features identify inspection points, rather than establishing any particular installation’s regulatory completeness. ^{[3] [4] [5]}

A defensible data contract should distinguish the event’s effective time from its arrival in the integration layer, retain the original source reference, and preserve corrections. OpenTelemetry distinguishes source event time from observation time; the World Wide Web Consortium’s provenance model treats a revision as a new entity. ^{[6] [7]} Preserve a Coordinated Universal Time (UTC) instant, the original offset and a named time zone separately: PostgreSQL’s time-zone-aware timestamp does not retain the originally supplied zone, and the Internet Assigned Numbers Authority (IANA) documents changing offset and daylight-saving rules. ^{[8] [9]}

Applicability still needs an operator-specific check. Inspect the scope of any fatigue risk management system (FRMS) exemption. Division V information has a separate five-year retention requirement. ^[10] This report provides a requirement map, a synthetic event ledger and acceptance tests for CARs 704/705 scheduling teams. Its proposed identifiers, revision history and export controls are engineering recommendations. They do not replace the governing regulation, the operator’s applicable exemption instruments or its procedures.

Introduction and Background

A planned roster describes an intention. A flight log describes aircraft activity. A timekeeping application may record payroll-oriented attendance. The useful integration question is how those representations become a coherent crew record. It should be possible to identify the source of an interval, establish whether it was planned or actual, and explain a later correction without relying on someone’s memory.

This analysis is anchored to October 16, 2026. The re-opened recordkeeping and scheduling pages displayed regulations current to September 30, 2026, last amended June 17, 2026. This is the available consolidation date, rather than a claim that an October consolidation was verified. ^[11]

Transport Canada’s Advisory Circular (AC) 700-047, Issue 05, effective June 28, 2024, covers Subparts 703/704/705; it is guidance. ^[2] The report uses that guidance to interpret the record boundary, and the consolidated CARs for operative obligations.

The intended reader is the scheduling lead, operations manager or data owner deciding whether existing systems collectively preserve sufficient evidence. This is not a duty eligibility calculator. No United States or European flight-time rules are imported. A software purchase or integration project should begin with the operator’s applicable Canadian provisions and documented procedures, then test the actual configuration and available exports.

The analysis separates required records, context needed to interpret them, and recommended provenance controls. That distinction matters because a sensible database field is not automatically a statutory field. An integration can preserve excellent technical logs while still omitting a crew member’s duty activity; an operations record can contain the necessary intervals while being difficult to reconstruct after changes. Both conditions deserve explicit acceptance criteria.

Key Changes

Expand the record boundary beyond the visible roster

“Changes” here means changes to the system design and procurement checklist, not newly enacted amendments. Under CAR 700.19, Division III excludes Subpart 702 operations and medical evacuation flights. ^[12] Operators must therefore establish the operation and rule context before reusing a generic Canadian rule mapping.

AC 700-047 sections 4.4 and 4.31 distinguish same-operator cross-subpart activity from another operator’s times, which the operator need not monitor or record. ^[2] A missing segment from the same operator’s other scheduling system is consequently a different issue from an external-employer declaration. The integration should preserve that distinction instead of labelling both “outside hours.”

A practical onboarding review should identify:

• Certificate scope: which operating subparts and flight categories the configuration serves.
• Crew identity: how records from separate systems map to the same person.
• Activity origin: which operator and source application supplied the activity.
• Rule context: which approved mapping and procedure version were used.
• Unresolved inputs: who investigates absent or contradictory information.

These are proposed governance fields and responsibilities. They make the rule mapping reviewable without suggesting that the regulation specifies this database schema.

Preserve categories that superficially look alike

Positioning must not disappear because a flight-count rule excludes it. CAR 700.28 excludes positioning from the flight count in its specified tables; the AC explains that positioning remains duty. ^{[13] [2]} A bridge should preserve a positioning activity type and its relationship to surrounding duty, rather than converting every travel segment into an operating flight.

Reserve and standby also require distinct source labels. CAR 700.29 specifies different treatment of reserve availability and standby in hours of work. ^[14] The procurement consequence is straightforward: request the original activity classification and intervals, not only an upstream total whose composition cannot be inspected. Any regulatory weighting belongs in a reviewed rules layer.

Rest needs contextual evidence as well. CAR 700.40 addresses home-base status, travel and accommodation; CAR 700.41 addresses specified sequences of early, late and night duties; CAR 700.42 addresses time-zone differences. ^{[15] [16] [17]} Preserve those inputs where the applicable procedure needs them. A blank calendar cell should not automatically become verified rest.

Treat exemptions as scoped records

For an FRMS operation, inspect the actual exemption and covered flights. CAR 700.200’s initial exemption does not list CAR 700.20 among the provisions from which it grants relief. ^[18] Keep the scope instrument linked to the applicable configuration, rather than enabling a global “FRMS” switch.

A system should distinguish a normal retained duty record, a rule evaluation, and FRMS supporting information. They may describe the same activity but have different purposes, owners and disposal rules. Designing that distinction before migration is preferable to trying to infer it from archived filenames.

Minimum Record and Provenance Map

A useful record map connects each requirement to a producer and an accountable owner. It should be reviewed against actual exports, because a screen label does not establish what the underlying interface contains. Leon, for example, documents duty details from crew planning modules in its report; the availability of that report still leaves its coverage and historical behaviour to be tested. ^[3]

Table 1 maps the legal record classes and related context to proposed system ownership. The owner column is a recommended allocation, not a delegation of the operator’s obligation.

The table highlights why one “duty total” is insufficient as an interface contract. It cannot identify the boundaries of overlapping record classes or explain which source changed. Proposed ownership should therefore follow the evidence lifecycle: who supplies the original, who resolves discrepancies, and who can retrieve it after the operational source is replaced.

For each exported object, request a stable crew identifier, source system, source record identifier, activity type, planned/actual status, interval boundaries, duration, location context, and revision relationship. These are proposed integration fields. CloudEvents provides a relevant design precedent by pairing source and event identity to distinguish events and recognize duplicates. ^[20]

Duration should retain its provenance. If imported, identify the source and meaning; if recomputed, identify the reviewed transformation and preserve the source boundaries. Request for Comments (RFC) 3339 represents instants, not interval semantics, so timestamp formatting alone cannot define what an exported duty period means. ^[21] The data dictionary must explain whether a boundary marks reporting, aircraft activity, release or another event.

The PIC notice needs a retrievable object, not just a checked box. CAR 700.63 requires notification of changes under that section at the end of the FDP. ^[22] A recommended envelope includes the original message or form, submitting identity, receipt time, related crew and duty identifiers, and the later classification decision. Preserve uncertainty when the message arrives before the corrected duty record.

Time Representation and Correction History

Store instants and preserve their interpretation

Use Coordinated Universal Time (UTC) as a shared instant representation, while retaining the original local representation and zone context. RFC 3339 describes an unambiguous representation of an instant. ^[21] That does not make UTC alone sufficient evidence for every regulatory time-of-day question.

A proposed schema should distinguish event location, home base and the acclimatization reference used in the operator’s reviewed interpretation. The method for determining that reference needs operator review. Merely taking the airport’s present local time would erase the distinction that the regulation makes.

IANA time-zone identifiers supply location-based context; IANA maintains historical local-time information and updates offset and daylight-saving rules. ^[9] Retaining the timezone database version used in a calculation is a recommended reproducibility control. Preserve the captured offset too, so a later software update does not silently alter how an old source value is displayed.

Database types require explicit acceptance tests. PostgreSQL documents that a time-zone-aware timestamp does not retain the originally stated zone, and that output is converted using the session time zone. ^[8] It also warns that a timestamp without time zone can ignore a supplied zone indication. ^[8] Those behaviours support keeping the source zone and source text as separate fields, with validation at ingestion.

For a daylight-saving transition, test whether the interface can distinguish repeated local times. Python’s zoneinfo documentation describes ambiguous transition times and the fold mechanism for distinguishing their offsets. ^[23] The test should reject an unresolved local timestamp or route it for clarification, rather than quietly choose an occurrence. The AC separately notes that the regulation does not specifically address the daylight-to-standard-time switch. ^[2] That interpretive issue belongs with the operator’s reviewed procedure.

Separate occurrence, receipt and correction

A late message should change the reconstructed activity without rewriting the history of what the monitoring system knew earlier. OpenTelemetry’s distinction between event and observation timestamps is a useful engineering precedent. ^[6] Where an event time is unknown, preserve that uncertainty explicitly instead of substituting ingestion time and calling it actual. ^[6]

Recommended correction metadata includes:

• Original value: retain the submitted boundaries and their source.
• Effective time: state when the corrected operational fact applies.
• Received time: state when the bridge obtained the message.
• Correction time: state when the accepted revision was recorded.
• Responsible actor: identify the person or process making the change.
• Reason and predecessor: explain the correction and link the replaced version.

The World Wide Web Consortium’s PROV model distinguishes revisions and supports attribution to agents. ^[7] This supports a reconstruction model; it does not establish an aviation requirement to implement that particular standard.

Database history can help, but inspect its semantics. Microsoft documents temporal tables that retain previous versions on changes; their system period uses the transaction’s beginning time. ^[24] That time is not automatically the duty’s effective time or the crew submission’s original time. An export must expose the necessary history explicitly; Microsoft also documents hidden period columns that require explicit selection. ^[24]

Implementation Considerations and Process Changes

Reconcile sources before declaring completeness

Define the authoritative producer for each event, then handle disagreements through an owned workflow. A payroll release time, an aircraft arrival and a crew-entered actual may describe different boundaries. The AC distinguishes FDP ending at engines off from duty ending when the crew member is released. ^[2] A reconciliation rule should preserve both where relevant.

FL3XX documents crew entry of actual duty time into roster entries. ^[4] An operator using such a channel should test how submitted actuals interact with scheduling edits: whether the source marks a revision, whether the bridge receives it, and whether an earlier export can still be reconstructed. The documented ability to enter a value does not answer those history questions.

Acceptance should include the following cases:

• Missing cross-subpart hours: omit a same-operator segment and verify a coverage exception reaches its owner.
• Late actual: deliver the crew submission after the initial export and inspect both current and earlier views.
• Repeated delivery: replay a source event and verify that it does not create duplicate duty.
• Conflicting sources: supply incompatible release times and require an attributable resolution.
• Positioning: carry the travel event through without relabelling it as operating flight.
• Unconfirmed rest: preserve the distinction between absent evidence and accepted classification.
• Exceptional notice: deliver a PIC message separately, then verify its link to the corrected duty.
• Time-zone change: confirm that current-location and acclimatization context remain distinct.
• Ambiguous local time: require offset or disambiguation rather than an arbitrary instant.
• Historical export: retrieve a superseded interval with its correction reason and source.

These are proposed acceptance cases, not a regulatory calculation suite. Duplicate handling has a published precedent in CloudEvents’ matching source-and-id model. ^[20] Test the operator’s chosen behaviour with synthetic records before relying on live monitoring.

Preserve retrievability through migrations

Retention is meaningful only if records can be retrieved and interpreted. Maintain a schema dictionary, enumerated activity meanings, source identifiers and revision links with the export. Microsoft’s documented history support illustrates why the export must include history rather than merely the current operational view. ^[24] A migration should prove that the target can interpret the exported objects without the retired application’s interface.

Security controls should support attribution and retrieval. The Canadian Centre for Cyber Security recommends asking providers what log data subscribers can access and protecting stored log data cryptographically. ^[25] Separate who can correct operational records from who can administer the evidence repository, and record those actions. These are recommended controls for the implementation.

Crew records also contain personal information. The Office of the Privacy Commissioner explains that the Personal Information Protection and Electronic Documents Act (PIPEDA) covers employee information in federally regulated organizations, including its aviation examples. ^[26] Its retention guidance recommends knowing what information is kept, why and for how long. ^[27] Confirm the operator’s applicable privacy framework and access rules rather than copying duty records indiscriminately into every connected system.

A disposal policy should distinguish mandatory operational evidence from convenience copies. The Privacy Commissioner’s guidance recognizes legislative retention requirements. ^[27] Map each retained object to its purpose and retention trigger, and test retrieval before deleting a source copy. Privacy minimization and required aviation retention belong in the same records design.

Packaged Crew Systems and Integration Choices

A crew application, an integration bridge and an evidence repository solve different problems. Procurement should establish which component owns scheduling decisions, which transports events and which preserves the record. A custom bridge should not inadvertently become an unreviewed substitute for the operator’s approved monitoring process.

LANDING.AERO’s perspective in this discussion is integration around existing operational workflows. It is adjacent to the packaged crew-system category considered below. The purchasing decision remains whether the operator needs a crew product, a connection between systems, or both.

Table 2 compares documented evidence channels, rather than ranking vendors or asserting Canadian regulatory suitability.

The table demonstrates multiple input channels, not interchangeable implementations. Public documentation establishes the described features; it does not establish full export rights, retention coverage, access after termination or the operator’s configured rule set. Every candidate should therefore demonstrate the same evidence scenarios using the operator’s field map.

Contract and demonstration questions should include:

• Export scope: current records, historical versions, attachments and deleted-item markers.
• Identifier stability: behaviour during crew merges, roster changes and system migration.
• Interface semantics: event occurrence, ingestion, effective date and correction timestamps.
• Delivery recovery: retries, duplicate suppression, missed-event detection and reconciliation.
• Retention coverage: operational records, notices, revisions, backups and relevant FRMS information.
• Exit access: extraction format, permitted use, charges and access after termination.
• Operational ownership: who approves mappings, resolves exceptions and changes procedures.
• Acceptance evidence: reproducible test output and the retained source-to-record trace.

A documented application programming interface (API) is a starting point. FL3XX describes external-system synchronization, but the buyer still needs the actual schema and contract. ^[5] Likewise, a documented roster export does not answer whether attachments or earlier versions travel with it. ^[3]

Choose a packaged crew system when the missing capability is scheduling workflow. Consider a bridge when the sources exist but their evidence is fragmented. Consider a dedicated repository when operational applications cannot provide the required long-term reconstruction. These are decision criteria; no public benchmark or vendor certification was used to assign a score.

Data Analysis and Evidence

The most useful quantitative evidence here is the regulation’s structure and time horizons, not an estimate of software market size. The data contract should retain interval boundaries, source values and the reviewed result of any transformation. Timestamp formatting alone does not define an interval’s meaning. ^[21] A total without boundaries cannot explain which underlying segment changed.

Record age and event age are different dimensions. AC 700-047 section 4.6 measures the ordinary retention period from record creation. ^[2] A delayed submission or correction therefore needs its own recorded creation context. The operator should review how revisions are classified for retention; the system should not assume that keeping the latest row for a period measured only from flight date satisfies the requirement.

The monitoring evidence must also support recurring review. CAR 700.21 requires a monthly determination of whether a flight crew member’s maximum FDP with respect to a flight was exceeded on more than 10% of occasions during 90 consecutive days. If more than 10% of the member’s maximum FDPs were exceeded as a result of an unforeseen operational circumstance, the operator must change the schedule or flight crew member pairing for the flight no later than 28 days after the determination. If the operator sets schedules seasonally, those changes may be delayed until the beginning of the same season in the following year. ^[11] Those are regulatory review requirements, not a calculator supplied here. Retaining the flight identity, planned schedule, actual outcome and relevant notification is a proposed means of making that review reproducible.

Five-year Division V retention under CAR 700.258 is a separate information class. ^[10] A repository that applies one blanket expiry to every aviation object risks losing that distinction. Conversely, a longer retention setting does not prove that all required information was ever ingested.

Table 3 provides a synthetic event ledger (Hypothetical Example). All identifiers and timestamps below are invented to illustrate storage semantics only; they do not determine crew eligibility. The pattern draws on separate occurrence/observation times and linked revisions. ^{[6] [7]}

The ledger permits a reviewer to ask what was planned, what was known after the first submission, and what changed subsequently. Its time format follows the instant representation described in RFC 3339. ^[21] A database transaction timestamp alone would not provide those meanings, as Microsoft’s temporal-table semantics illustrate. ^[24] The acceptance criterion is successful reconstruction, not a particular database product.

Implications and Future Directions

An evidence-oriented integration changes the purchase conversation. Instead of accepting “supports duty tracking” as a complete answer, an operator can request a replay of missing activity, late submissions and corrections. Schedaero’s documented duty tracking and CAE’s documented roster access are examples of capabilities to inspect within that demonstration. ^{[29] [28]} Their presence does not establish the contents of an archive or the contractual right to retrieve it.

Rule mapping and data mapping should have separate owners who review changes together. A new export field may alter a classification; a new operational procedure may change which timestamps need preserving. IANA’s changing timezone data and Python’s dependence on available zone data illustrate that even the interpretation of local timestamps has maintained software dependencies. ^{[9] [23]} Preserve version context where it affects reproducibility.

A sensible deployment sequence is:

• Inventory: identify record classes, source owners and retention triggers.
• Map: document each source field and its operational meaning.
• Prototype: export a representative synthetic sequence, including corrections.
• Reconcile: compare source objects, imported objects and reconstructed views.
• Challenge: run missing-data, ambiguity, replay and recovery cases.
• Approve: record the operator’s mapping and procedural decisions.
• Monitor: assign exceptions and periodically test historical retrieval.

Automation can support reconciliation, but authoritative corrections need attributable decisions. PROV’s distinction between entities, activities and agents provides one vocabulary for those relationships. ^[7] Automated extraction should retain the original notice or source object and flag uncertain classification rather than converting an inference into an unexplained fact.

Finally, export portability should be tested operationally. Hidden database history, event timestamps with unclear meanings, and source-specific activity codes can all complicate reconstruction. Microsoft documents explicit selection of hidden temporal columns, while CloudEvents defines occurrence-time semantics that an interface contract must interpret consistently. ^{[24] [20]} A successful exit test should leave an intelligible record set, not merely downloadable files.

Conclusion

A reliable Canadian flight-duty record system should connect flight, duty, rest and notification evidence to a shared record map. Scheduling and IT teams should use that map to expose gaps between sources, agree ownership, and test historical retrieval against the operator’s applicable procedures.

The practical acceptance question is whether a reviewer can reconstruct the sequence after a late actual, correction or schedule change. A portable record should preserve source identity, the meaning of each boundary, time interpretation and the relationship between versions. The provenance model’s treatment of revisions supplies a useful engineering precedent. ^[7] No particular database schema, API or vendor feature independently establishes regulatory completeness.

Procurement should require evidence of complete exports and explicit agreement on access, history and exit arrangements. Leon’s documented export and FL3XX’s documented API illustrate different channels that require inspection. ^{[3] [5]} Test those channels against the same acceptance cases, then retain the demonstration results with the approved mapping.

The resulting system should make missing evidence visible, corrections explainable and retained records retrievable. That is the appropriate foundation for duty/rest monitoring. Eligibility decisions and exceptional operations remain subject to the applicable Canadian rules, exemption scope and operator procedures.