Tester Walkthrough — FTDT (Flight Time / Duty Time)
Updated: 2026-10-19 16:41 ET · Covers the Blazor Hybrid FTDT dashboard specifically
(the beta three-tab /ftdt/dashboard experience) — not the legacy native FTDT screens. On the
Page Readiness screen set the Area dropdown to FTDT. Screenshots were captured on a
393×852 device (iPhone 15 Pro class), the width the Figma frames are drawn at.
TLDR: 11 checks across the FTDT tracker — seeding known data with
the Test Scenarios page, reading the cumulative limitation bars, the beta rest-rules engine
(§117.25 / §700.40–700.43, §700.60(7), §700.63(3)) and its violation reporting, creating a duty period and watching
limits and violations compute live, the two-step conclude, archived logs and the delete/restore round-trip, the full
op-type range plus the FAR 117 Guide link, the Add Rest Opportunity / Add Note forms, and putting your own data
back when you're done. Six readings you build by hand (5d–5i) show the §117.19(a)(3) flag on an extension that
takes the 60-in-168 limit over, the Canadian §700.40 "home base assumed: no legs" rest floor, §700.41 night
and late duty read on the actual end, the §700.43 rest after positioning logged either as minutes on the duty or as
its own POSITIONING duty period, and the longer rest after an extended flight duty period (§700.60(7) for an
augmented crew, §700.63(3) with the unforeseen-operational-circumstances reason), and the one "overlapping duties"
line, with a link to the earlier duty, when a duty reports before the previous one ends. Two checks (5b and 5c, the
trans-theater and acclimation rest rules) need airport data that only a signed-in session caches and are marked skip
when signed out. Work through it signed in; FTDT data lives on your device and seeded data never syncs, so only the
duty periods you create in Checks 5d–5i and 7 reach your account.
Before you start
No login needed — FTDT records live on your device (they sync to your account in the background when
you are signed in).
Your own duty periods are safe. The Test Scenarios seeder hides your real records rather than
deleting them, and Restore My Data brings them back — Check 9 is the cleanup step; don't skip it.
Signing out does the same cleanup first, so your records come back even if you sign out before Check 9;
your Regulations and Rest Rules Engine settings return to their defaults. Signing in from the login screen
does the same cleanup, so seeds loaded signed out or under another member never count in your totals; a
scenario loaded signed out, or on a build that recorded no member, leaves both settings at their defaults
after that sign-in rather than at what you had before. The two settings belong to the phone, not to your
account: they are not synced, and only a Test Scenarios session end or a sign-out resets them.
Signing out always does this cleanup, so only a sign-in with no sign-out before it, as the member who
loaded the scenarios, keeps your seeds: closing and reopening the app (it signs you back in on its own).
Settings → Diagnostics → Refresh Auth Token signs you out and back in, so it ends the session too. Seeded
records never reach the server either: they carry a seed: marker that every sync path skips.
Stay signed in for this walkthrough. Seeded scenario data never reaches the server, so it
cannot touch your account, and signed in is how a member actually uses the app — it is also what the
§117.25(c)/(d) rules need (Checks 5b and 5c).
The one exception is Check 7. A duty period you create yourself is a real record, not seeded,
and it does sync to your ALPA account. Deleting it afterwards leaves a deleted-marked copy on the
server. Delete it at Check 9 and it stays a footnote rather than a surprise in your history.
The rest-rules engine and the Test Scenarios page are beta tester functionality — they exist in
this new version only (the current production FTDT has neither).
Checks
1 · The FTDT dashboard
Steps: On the Page Readiness screen set the Area dropdown to FTDT and tap the
FTDT Dashboard row.
There may be no FTDT tab in the bottom navigation. The bottom bar is a
configured shortcut list, not a fixed one — on the build this guide was captured against it reads
HOME / JUMPSEAT / KCM / PDR / DAL MEC, with no FTDT entry. The Page Readiness route above always
works; use the tab only if your build happens to show one.
The dashboard opens on Cumulative Limitations, not on your duty periods. That is
intended — the first question is whether you are within limits. Your individual duty periods are one tab
across, under Duty Periods. With no data the cumulative bars read zero rather than showing nothing,
so a screen of zeros is correct, not a failure to load.
What you should see: Three tabs — Cumulative Limitations, Duty Periods,
Archived Logs — with the cumulative tab open: Flight Hours and Flight Duty Period Hours limit bars and
the blue ADD DUTY PERIOD » button pinned at the bottom. The tester setup rows (next check) show
only in Diagnostic Mode.
Something's wrong if: A tab is missing, or the screen is blank instead of showing
the limit groups (they show zeros when you have no data — blank is different from zero).
2 · The tester setup rows
Steps: Turn on Diagnostic Mode (Settings → tap the version number five times). Turn
Settings → FTDT Rest Rules Engine on (it is off by default). Open the dashboard's Cumulative
tab.
No FTDT Rest Rules Engine row in Settings? The engine is switched off for this
environment: the FTDTRestRulesEngine app setting is off or missing. The app reads it at launch
and on each return to the foreground, so a change can take a moment to arrive. The setting is configured
only on gatewayapi (production), so a build pointed at QA (Settings → Environment = Development) never
shows the row.
What you should see: Above the limit bars: Regulations (Part 117 FAR ↔ Part 700 CARs),
Test data source (Mock ↔ Live — FTDT scenarios only) and How do I read this?, then
Home base override and a "Rest and Duty Rules — FAR 117" (or "— CARs 700" in CARs mode) card. Switching
Regulations flips the rule set.
Something's wrong if: Regulations, Test data source or How do I read this? show
with Diagnostic Mode off; Home base override or the Rest Rules card show with the engine off; or turning
the engine on/off changes or deletes any duty-period data — the toggle only changes what's
calculated and shown, never the records.
3 · Seed known data with Test Scenarios
Steps: On the Page Readiness screen, set the Area dropdown to FTDT (it opens on
the first area, so the FTDT rows are not shown until you pick it — scrolling will not find them). Then
tap Test Scenarios (Beta), tap US — Rest Rules: Violations, and wait for its badge.
One card per prepared state — US and CA sets
Tapped — the badge flips to ✓ Ready
What you should see: The tapped card shows ✓ Ready. The scenario sets the right toggles
for itself and fills the tracker with synthetic duty periods that produce the state its name says
(near-limit bars, rest violations, an empty state, …).
Something's wrong if: The badge never turns Ready, or the dashboard afterwards
doesn't match the scenario's name (e.g. "Rest Rules: Violations" seeded but no violations show with the
engine on).
4 · Cumulative bars — and they must agree with the current app
Steps: Back on the dashboard's Cumulative tab, read the four limit bars against the seeded
scenario.
What you should see: Four bars. With US — Rest Rules: Violations seeded, the two
Flight Hours bars are fixed: 10:00 of 100-in-672 (10.00%, 90:00 remaining) and
10:00 of 1,000-in-365-days (1.00%, 990:00 remaining).
The two Flight Duty Period Hours bars move with the clock — don't check them against a
fixed number. The seeded duty periods sit near the edge of the 168-hour window, so as real time
passes the older ones age out of it and the totals fall. Two readings taken 40 minutes apart during
validation gave 18:12 and 17:29 for the 60-in-168 bar. Check the arithmetic instead: used +
remaining must equal the limit, and the percentage must match used ÷ limit.
Whatever the figures are, they are the same numbers the current production FTDT screen computes from
the same records — the two versions share one data store, so if you open the classic FTDT screen the
totals must match exactly.
Something's wrong if: A bar's hours, percentage, and remaining figures don't
agree with each other (but see the 59:59 rounding note under Known gaps first), or the new dashboard and
the classic FTDT screen disagree about the same data.
5 · Rest-rules violations (beta)
Steps: With the engine on and the violations scenario seeded, look at the "Rest and Duty Rules — FAR 117"
card. Tap its header to expand.
What you should see: A ⚠ count in the card header, and expanding it lists each violating
duty period with the specific rule and reason. This scenario seeds one §117.25(e) violation
("Rest period 8.50h is less than the 10h minimum required before reserve or flight duty period.") and
one §117.25(c) ("New-theater acclimation: largest continuous rest in past 168h is 31.00h;
36h required."), matching the rules named on the scenario card itself. With a clean
scenario ("Rest Rules: OK") the card shows ✓ No violations instead.
Then act on one without leaving the tab. Each violating period is the same card you see on
the Duty Periods tab, so tap MANAGE FLIGHTS & DETAILS on it and you get the same four
actions — EDIT DUTY PERIOD, ADD FLIGHT SEGMENT, ADD REST OPPORTUNITY,
ADD NOTE. Editing from here opens the period the violation is about, so check the date on the
Edit screen matches the one you tapped.
The violation and the period it belongs to, with the same management row the list has
One difference from the Duty Periods tab, on purpose: there is no swipe-to-delete
here. These rows explain a violation; deleting a duty record from a panel you opened to read would be too
easy to do by accident. Delete lives on the Duty Periods tab, and on the Edit screen.
Something's wrong if: The count disagrees with the listed violations, a
violation text names hours that don't match the duty periods on the Duty Periods tab, or
EDIT DUTY PERIOD here opens a different period than the one the violation named.
5b · Trans-theater rest (§117.25(d)) — signed in only, and the scenario card stays Blocked
Signed out, skip this check: an absent §117.25(d) violation is not a bug to report. The
rule is built and wired, and it reads each airport's longitude and time zone from the airport list the Flight
Finder caches on the device. That list is fetched only while you are signed in, so signed out the cache is empty
and the rule stays quiet by design. On the simulator walk of 2026-10-13 (signed out, Home base override DFW, a
DFW → LHR duty followed by LHR → DFW the next day) the rest-rules card showed nothing for it, and the
Test Scenarios card US — Acclimation / Trans-Theater reads Blocked and does not load.
What it does: flag the extra rest required after a duty period that follows travel across more than
60° of longitude — the trans-theater case. The rest-rules card lists it alongside the other §117.25 citations
you saw in Check 5.
What it needs: the airport cache filled (sign in and open the Flight Finder once; the gateway airports
API returns each airport's timeZoneId and coordinates, read through FlightSearchAirportLookup),
and a home base — your profile's, or an airport code typed into the Cumulative tab's Home base
override. Leave the override blank to use your real one. An airport the cache does not know keeps the rule
quiet for that duty.
Steps, signed in: open the Flight Finder once, type your base (or DFW) into Home base override,
add an Unaugmented duty with a flight DFW → LHR, conclude it, then an Unaugmented duty the next day with LHR → DFW.
What you should see is not yet confirmed on this build — the walk could not sign in. If the card shows a
§117.25(d) line, note its text and the two duty periods in your report; if it shows nothing with the cache
filled and a home base set, report that too. Either answer is useful.
For whoever picks this up: the dormancy is the null-tolerant contract on
IAirportLookup — an airport without longitude or time zone keeps §117.25(c)/(d) quiet. The
scenario card's Blocked badge is a flag on the scenario itself (FTDTTestDataService), not a
reading of the cache; it needs lifting once a signed-in run has confirmed the rule fires.
5c · Acclimation rest (§117.25(c)) — blocked, not ready for testing
Skip this check, for the same reason as 5b. The rule is built and wired but
cannot produce a result yet, so an absent §117.25(c) violation is not a bug to report.
What it will do, once unblocked: upgrade your weekly rest requirement when you are in a new
theater and not yet acclimated. The ordinary §117.25(b) block of 30 continuous hours becomes
36 — and completing that 36-hour rest is itself what makes you acclimated again.
What will trigger it: a duty period with Acclimated switched off on its Edit
screen. That toggle is the "am I in a new theater" input, and it is the one part of this check you can
already exercise — the switch works today, it simply has nothing to feed.
Why it can't run today: the same gate as 5b. Working out whether you are in a new theater
means comparing where you are against your home base, which needs airport longitude from the
backend airports API, plus a home base on your profile and being signed in. Miss any one of
those and the rule stays quiet by design.
Why both checks are blocked together: §117.25(c) and (d) are hydrated by the
same code path — one airport lookup, one home-base resolution, feeding both rules. Whatever unblocks 5b
unblocks this at the same moment, so expect to test them as a pair rather than one after the other.
5d · §117.19(a)(3) — an extension that takes the 60-in-168 limit over
Steps: Regulations Part 117 FAR, engine on. Build 46:00 of duty in the last seven days: five
duty periods on consecutive days (Unaugmented, 08:00 report, one flight segment 09:00–17:00, CONCLUDE
with End 17:00 — 9:00 each, since the bar counts report to last Block In; make one of them Block In and End
18:00). The Cumulative tab's 60 hours in 168 hours bar
now reads 46:00. Then add today's: Unaugmented, 07:00 report, 1 segment (the form shows Max Duty Period 14:00,
Ends 21:00). ADD FLIGHT SEGMENT 14:00–22:00 — it blocks in 1:00 past the end, and the card turns red.
Open EDIT DUTY PERIOD: under Exceeded FDP — Reason tap Unforeseen operational
circumstances, then CONCLUDE, End 22:00, CONFIRM CONCLUDE.
What you should see: Before the reason is recorded the Edit page lists §117.13 ("FDP ran 1:00
past its maximum. Allowed only as an extension for unforeseen operational circumstances (§117.19); record the
reason on the duty period."). The moment you tap the reason it is replaced by §117.19(a)(3):
"Extension takes 60 h in 168 h to 61:00. Allowed only if extended after takeoff (§117.19(a)(3), (b)(3))." After
CONFIRM CONCLUDE the Cumulative tab's rest-rules card shows ⚠ 1 with the same line, and the
60 hours in 168 hours bar reads 61:00 — the same h:mm the message names, because both count
the same flight duty period hours for the same records, each from its report to its last Block In.
Then vary it (move an earlier period's flight Block In and its End Time together; the card
recalculates on every save):
Shorten one earlier period by an hour so the total is exactly 60:00: the flag goes, the card reads
✓ No violations, the bar reads 60:00.
Lengthen one by two hours so the week was already over before the extension (bar 63:00): still no
§117.19(a)(3) — the overage is the week's, not the extension's. The bar being past 100% is the only signal.
Tap the reason off again and SAVE: §117.13 comes back, and the (a)(3) line goes; an extension with no
reason recorded is not a §117.19 extension.
Move the last Block In and the End to 23:30 (2:30 over): §117.19 ("FDP extended 2:30 past its
maximum…") replaces (a)(3) — only extensions of 2:00 or less are read as before-takeoff ones.
An Unaugmented Reserve that runs past its limit shows §117.21(c)(3) ("Reserve duty period ran
1:00 past its limit… §117.19 extends the FDP, not this limit.") whatever reason you record, never (a)(3).
DELETE one of the earlier periods: the flag goes with it; Archived Logs → RESTORE brings both
back.
Split duty past 14 hours. When a leg of a split duty blocks in more than 14 hours after
the report, the FDP and the rest pass the §117.15(f) 14 hours, so the rest counts as FDP and the limit is Table B,
before and after CONCLUDE alike (AB#3358): a 20:00 report with the rest 22:00–05:00 and a leg blocking in at 11:30
reads Max Duty Period 12:00 and "§117.13 FDP ran 3:30 past" on the Edit page, the same 3:30 on the card. Interim
reading pending the SME (register N-7).
Something's wrong if: the h:mm in the (a)(3) message differs from the 60 h / 168 h bar
while the extended period is your latest record; the flag shows at exactly 60:00, or without the reason
recorded, or on a reserve; or the flag survives when the week was already over without the extension.
5e · Canadian §700.40 — rest after a duty with no flights (CARs)
Steps: Regulations Part 700 CARs, engine on, type YUL into Home base override.
Add an Unaugmented (CA) duty period, 08:00 report, no flight segments, CONCLUDE with End 20:00 — a
ground duty or a reserve day with nothing flown. Then ADD DUTY PERIOD → Unaugmented for the next day with
a 07:00 report (11 hours later) and read the form before you CREATE.
What you should see: On the Add form, on the Edit page after CREATE and on the rest-rules card:
§700.40 "Insufficient rest: 11:00 provided, 12:00 required (home base assumed: no legs)". A duty with no
legs is taken as ending at your home base, so the 12-hour home-base floor applies, and the message says that is an
assumption. Edit the report to 08:00 (12 hours): ✓ No violations. Report 06:00 (10 hours): "10:00 provided,
12:00 required (home base assumed: no legs)". Now give the first duty a flight segment YUL → YYZ: at 06:00 the
violation goes (10 hours is enough away from home), and at 05:30 it reads "09:30 provided, 10:00 required (away
from home base)". Make that flight YYZ → YUL instead: "12:00 required (home base)" — no "assumed". Clear the
override: with no home base nothing places you at home, so the 10-hour floor applies and 10 hours passes.
The home-base options (§700.40(1)(a), AB#3354): with the first duty's flight back as YYZ → YUL and the
07:00 report (11 hours), EDIT DUTY PERIOD on the first duty: under Rest Rules, beside the positioning
field, type 45 into Travel time to and from the rest location and SAVE. The next duty now reads
"11:00 provided, 11:00 + 00:45 travel required (home base)"; move its report to 07:45 (11:45) and it passes (07:44
reads "11:44 provided"). Move the report back to 07:00, type 90 into the travel field and SAVE: 12 hours
always satisfies the rule, so the 07:00 report (11 hours) reads "11:00 provided, 12:00 required (home base, 12 h option: 01:30 travel recorded)" and an 08:00 report passes,
never asking for 12:30. Clear
the minutes and switch Operator provided suitable accommodation on: the 07:00 report passes (10 hours is
enough), and a 05:59 report reads "09:59 provided, 10:00 required (home base, accommodation provided)". With both
recorded the 10-hour option applies. Type 721, or 0, into the travel field: it outlines red with
"Enter whole minutes from 1 to 720, or leave blank." and SAVE refuses until it is corrected (no travel is a blank
field). Make the first duty's flight YUL → YYZ (ending away) and neither input changes the 10-hour floor. When the
duty is brought home by positioning logged as its own duty period, the options can be recorded on either record:
those on the positioning record are read, and those on the flight's record when the positioning record has none.
One record's options are read together, never mixed: travel on the positioning record and accommodation on the
flight's record reads the travel time alone. A toggle switched on and back off counts as never set.
The Rest Rules inputs on a Canadian duty period: travel time (45 here) and the accommodation toggle
Something's wrong if: a duty with no flights reads "(away from home base)" while the
override holds your base; "(home base assumed: no legs)" appears on a duty that has flights; a 12-hour gap after
the legless duty is flagged; or a 10-hour gap after it is not. For the options: 90 minutes of travel asks for more than 12:00; 45 minutes of travel still asks for
12:00; accommodation still asks for 12:00 or 11:00; an entry of 721 saves; or a duty ending away reads "(home base,
accommodation provided)".
5f · Canadian §700.41 — night and late duty read on the actual end (CARs)
Steps: Regulations Part 700 CARs, engine on. Add an Unaugmented (CA) duty period, 15:00
report, CONCLUDE with End 20:00. Add another for the next day with a 05:00 report (an early duty). Read the
rest-rules card. Then EDIT DUTY PERIOD on the first one and move its End Time to 02:30 the next day; read
the card again; try 01:59 and 23:30 the same way.
What you should see: Ending 20:00, the early duty shows only the ordinary §700.40 (9 hours is
short) — no §700.41. Ending 02:30 (night duty: began after 13:00 and ran past 01:59) the early duty gains
§700.41(1)(a) "Local night's rest required between late/night duty and the following early duty; rest
2026-10-02 02:30 -04:00 to 2026-10-02 05:00 -04:00", on the clock you entered. Ending 01:59 (late duty) gives the same citation;
ending 23:30 gives none. The rule reads the end you concluded with, not the Max Duty Period end.
The other direction, on an open duty: after an early duty (05:00–12:00) add a 14:00 report and leave
it open. The card shows §700.41(1)(b) "Local night's rest required between early duty and the following
late/night duty…" straight away: an open duty is classified on its estimated end, report plus Max Duty Period
(02:30 here). CONCLUDE it at 20:00 and the line goes; edit its End to 02:30 and the line is back. An
Unaugmented Reserve left on availability only (not Assigned) with a 00:30 RAP start raises no §700.41 — it
has no flight duty period to classify.
The screenshot above is from before AB#3359 and shows the window in UTC ("06:30:00Z –
09:00:00Z"); the app now prints it on the duty's clock, as the line above says. Report a UTC time as a defect.
Something's wrong if: a duty ending 20:00 is read as night or late duty; the open duty is
classified from anything but report + Max Duty Period; concluding it at 20:00 leaves the (1)(b) line in place;
or the availability-only reserve raises §700.41.
5g · Canadian §700.43 — rest after positioning, logged three ways (CARs)
Steps, positioning as minutes on the duty: Regulations Part 700 CARs, engine on, Home base
override blank (you are away). Add an Unaugmented (CA) duty period, 13:00 report (the form shows Max Duty
Period 12:30, Ends 01:30). ADD FLIGHT SEGMENT YYZ → YVR 13:30–00:30. EDIT DUTY PERIOD: type 180
into Immediate Positioning After FDP (§700.43), CONCLUDE, End 01:00 the next day, CONFIRM
CONCLUDE. Then ADD DUTY PERIOD → Unaugmented for that next day with a 17:00 report — 13 hours after the
positioning ended at 04:00 — and read the form before you CREATE.
What you should see: On the Add form, on the Edit page after CREATE and on the rest-rules card:
§700.43(1)(a) "Insufficient rest after positioning: 13:00 provided, 15:00 required (hours of work 15:00, FDP +
positioning 02:30 over the 12:30 maximum; rest 2026-10-06 04:00 -04:00 to 2026-10-06 17:00 -04:00)". The hours of
work run from the 13:00 report to the end of the positioning, and the rest owed equals them when they are three
hours or less over the maximum. Then vary it (Edit the first duty; the card recalculates on every save):
240 minutes: §700.43(1)(b) "12:00 provided, 19:30 required (hours of work 16:00, FDP + positioning
03:30 over the 12:30 maximum…)" — more than three hours over, so the excess is added.
30 minutes: the line goes (12:30 of work is within the maximum). Move the second report to 10:00 and it
reads §700.43(2) "08:30 provided, 10:00 required (700.40(1)(b) rest after 00:30 of positioning…)" — the
§700.40 floor, one line for the one gap. Before the AB#3353 review fix a §700.40 "09:00 provided, 10:00
required (away from home base)" line showed above it, measured from the duty's own end; if it still does, report
it.
Back to 180 minutes, second report 19:00: ✓ No violations (exactly 15:00); 18:59: "14:59 provided,
15:00 required".
Clear the field: no §700.43 line at all.
Split Duty on, the flight split into 13:30–16:30 and 21:30–00:30 with a rest opportunity 17:00–21:00
(Max Duty Period rises to 14:07): the break is left out of the hours of work (11:00), so at a 10:00 report the card
reads §700.43(2) "06:00 provided, 10:00 required (700.40(1)(b) rest after 03:00 of positioning…)".
REMOVE REST OPPORTUNITY and it is §700.43(1)(a) with hours of work 15:00 again.
Steps, positioning as its own duty period: type YUL into Home base override. Add an
Unaugmented (CA) duty period, 06:00 report, flight YUL → YYZ 06:30–13:30, CONCLUDE End 14:00. ADD
DUTY PERIOD → Unaugmented with a 15:00 report the same day and CREATE (the form lists §700.40 "01:00 provided,
10:00 required" and §700.41(1)(b) — they go once the leg below is saved). ADD FLIGHT SEGMENT: under DUTY
TYPE tap POSITIONING, YYZ → YVR 15:00–20:00, SAVE; CONCLUDE it with End 20:00. Add an
Unaugmented 06:00 report the next day.
The Canadian Add Flight Segment page offers FLIGHT and POSITIONING; the title changes to Add Positioning
What you should see: nothing for the one-hour gap between the flight duty and the positioning — it is not a
rest period, it is positioning right after the FDP. On the next duty: §700.43(1)(a) "Insufficient rest after
positioning: 10:00 provided, 14:00 required (hours of work 14:00, FDP + positioning 02:00 over the 12:00 maximum;
rest 2026-10-08 20:00 -04:00 to 2026-10-09 06:00 -04:00)" — the hours of work run from the 06:00 report of the
flight duty to the end of the positioning, the same reading the minutes field gives. Then vary it:
Tap the positioning leg on the duty's card: POSITIONING is selected and cannot be changed. Moving its
Block In past the duty's release is refused ("The segment cannot end after the duty period's release…") — change
the End on the Edit page first; with the leg and the End at 21:00 the line reads "09:00 provided, 15:00 required
(hours of work 15:00, FDP + positioning 03:00 over the 12:00 maximum…)".
Add a FLIGHT to the positioning duty (End 23:30, flight 21:30–23:00): it is a flight duty period again,
and two §700.40 lines ("01:00 provided" for the gap before it, "06:30 provided" for the gap after it) replace
the §700.43 one. Delete the flight and the §700.43 line is back.
Positioning that reports 10 hours or more after the flight duty's release — the §700.40 rest — stands
alone: it gets its own §700.40 and §700.41 reading, and the next duty reads §700.40 "08:00 provided, 10:00
required" after it. At 9:59 it is joined: §700.43(1)(b) "08:00 provided, 34:00 required (hours of work 23:00,
FDP + positioning 11:00 over the 12:00 maximum…)". Positioning two days later is the same: its own §700.40.
Steps, positioning as a leg of the same duty: repeat the first set of steps without the minutes: on the
13:00 duty, after the YYZ → YVR flight 13:30–00:30, ADD FLIGHT SEGMENT, tap POSITIONING, YVR → YYZ
01:00–04:00 (date: the next day), SAVE, and CONCLUDE with End 04:00. The leg runs past the 01:30 Max Duty
Period end, so CONCLUDE first asks "The FDP limit has been exceeded. Please select a reason.": under Exceeded FDP —
Reason Required tap Positioning, then CONCLUDE and CONFIRM CONCLUDE (the minutes way, ending
01:00, never asks; the reason chosen does not change the line below). Add the next duty with a 17:00 report (13 hours
after the positioning).
The positioning as a leg of the same duty: the card marks it Positioning under the flight
What you should see: the same §700.43(1)(a) "13:00 provided, 15:00 required (hours of work 15:00,
FDP + positioning 02:30 over the 12:30 maximum…)" as the minutes gave: a positioning leg after the duty's last
flight is positioning immediately after the FDP (AB#3365; before, this third way got no §700.43 line at all). If you
also type minutes into Immediate Positioning After FDP on that duty, the legs are the record of the travel and
the minutes are left out (the app log says so); the line does not change. Conclude the duty half an hour after the
positioning blocks in (End 04:30) and the rest is counted from the release: "12:30 provided, 15:30 required (hours of
work 15:30…)"; End 04:31 (03:01 over) moves it to §700.43(1)(b) "12:29 provided, 18:32 required". A
positioning leg still open (no Block In) leaves the duty under §700.40 as before, with no §700.43 line. The final
simulator walk could not create one on the device: the Flight Segment page refuses a cleared Block In ("Enter a valid
date and time.", AB#3373), so skip this case unless you have such a record.
Something's wrong if: the three ways of logging the same positioning give different hours
of work or a different required rest; the §700.40 "01:00 provided" line stays on the positioning duty after its
POSITIONING leg is saved; the maximum named in the message is not the flight duty's Max Duty Period; a
positioning-only duty with a flight added still reads §700.43; or the §700.43 line survives a cleared minutes
field.
5h · Canadian rest after an extended flight duty period — §700.60(7) augmented, §700.63(3) with the reason (CARs)
Steps, augmented crew: Regulations Part 700 CARs, engine on, Home base override blank. ADD
DUTY PERIOD → Augmented (Class 1, +1 as the form opens), 08:00 report (Max Duty Period 15:00). ADD FLIGHT
SEGMENT YYZ → YVR 08:30–22:30, then CONCLUDE with End 23:00 — a 15-hour duty whose flight ran past the
unaugmented (700.28) maximum though within the augmented one. Add an Unaugmented 11:00 report the next day,
12 hours later.
What you should see:§700.60(7) "Insufficient rest after an extended flight duty period: 12:00
provided, 15:00 required (the duty period just completed 15:00; 14:00 in suitable accommodation away from home base;
rest 2026-10-05 23:00 -04:00 to 2026-10-06 11:00 -04:00) [interim reading: an augmented crew's FDP past the 700.28
maximum counts as extended]". The rest is the longer of the duty just completed and 14 hours away. The bracketed
note is deliberate: the reading awaits the SME. Then vary it:
YUL in Home base override and the flight landing YUL: "16:00 required (… 16:00 at home base …)".
Flight 08:30–20:00, End 20:30: ✓ No violations — within the 700.28 maximum, nothing was extended.
Flight to 23:30 with End 00:00 (16 hours, an hour over the augmented maximum): the Edit page refuses CONCLUDE
until a reason is chosen ("The FDP limit has been exceeded. Please select a reason."). Choose Duty: the card
shows one line, §700.40 "11:00 provided, 16:00 required (away from home base)" — the §700.40(2) rest and the
§700.60(7) rest tie at 16:00 and the general rule names it. Add a POSITIONING leg 23:45–00:45 with End
01:00: one line again, §700.60(7) "10:00 provided, 17:00 required (the duty period just completed 17:00 …)",
the larger of the two.
Steps, unforeseen operational circumstances: Home base override blank. Unaugmented (CA), 13:00
report (Max 12:30, Ends 01:30), flight YYZ → YVR 13:30–02:15 — 0:45 over, the card turns red. EDIT DUTY
PERIOD: under Exceeded FDP — Reason Required tap UOC, CONCLUDE, End 02:15, CONFIRM
CONCLUDE. Add an Unaugmented 12:45 report, 10:30 later.
What you should see:§700.63(3) "Insufficient rest after a flight duty period extended for an
unforeseen operational circumstance: 10:30 provided, 10:45 required (700.40(1)(b) 10:00 extended by the 00:45
extension of the flight duty period; rest 2026-10-06 02:15 -04:00 to 2026-10-06 12:45 -04:00) [interim reading: the
extension is the FDP flown past its maximum with unforeseen operational circumstances recorded]". Then vary it:
Reason Duty instead of UOC: nothing at 12:45, and plain §700.40 "09:45 provided, 10:00 required"
at a 12:00 report — no §700.63(3) without the reason.
Flight and End 02:45 (1:15 over) with UOC: one line, §700.40 "10:00 provided, 13:45 required" — the
§700.40(2) rest (the duty length) is larger than 10:00 plus the 1:15 extension, so it is the one named.
Split Duty on with the reason: the §700.63(3) line goes and nothing replaces it (a split duty's
circumstance is not read as a §700.63 extension; the app log records it as FTDT_REST_CHECK_UNCHECKED). Off again
and the line is back.
Two things not to report. The Edit page's Minimum Rest 13:15 hint under the UOC
reason is the legacy figure (the duty length), not the engine's 10:45 — logged as Issue 3364. The homecoming case,
where the base rest would name 700.42(2) after a 5-hour zone difference, needs the airport cache: signed out it
cannot be read, as in Check 5b.
Something's wrong if: a §700.60(7) line appears under an Unaugmented duty, or a §700.63(3)
line without the UOC reason; two lines name the same gap after an extended duty (§700.40 beside §700.60(7) or
§700.63(3), or either of those beside a §700.43 line when positioning minutes were entered — since the AB#3353 review
the §700.43(2) floor carries the extended rest and the standalone line does not print) — one line names the larger;
a §700.60(7) requirement is below 14:00 away or 16:00 at home; the
"[interim reading: …]" note is missing; or the §700.63(3) base names 700.40(1)(a) 12:00 for a duty that ended
away.
5i · Overlapping duties — one line, and a link to the earlier duty (US and CARs)
Steps: Regulations Part 117 FAR, engine on. Add an Unaugmented duty period, 21:00 report,
CONCLUDE with End 08:30 the next day. Then ADD DUTY PERIOD → Unaugmented for that next day with an
06:00 report — two and a half hours before the first one ends — and CREATE, then CONCLUDE it with End
14:10. Nothing stops the save: an overlap is usually a typing slip on one of the two records, and the app lets you
keep both while you find which. Left open, the later duty shows only the §117.25(e) line (⚠ 1): §117.25(a) places
a duty once it has an End.
What you should see: the rest-rules card shows ⚠ 2 and "2 VIOLATIONS DETECTED" over one
line, §117.25(e), §117.25(a) via §117.25(e) · overlapping duties: "This duty reports Oct 14 06:00, before
your previous duty ends at Oct 14 08:30. Fix the time that is wrong on either duty." (your dates, not these).
The badge still counts every rule broken; the two are shown as one line because one overlap causes both. Below
it a dashed card, Overlaps with previous duty, gives the earlier duty's Report and, in red, its Release, and
the later duty's report time under it is red too. The later duty's EDIT DUTY PERIOD page shows the same
single line.
Fix it from the card.EDIT PREVIOUS DUTY → opens the earlier duty's Edit Duty Period page
(21:00 report, End 08:30). Correct the End that is wrong and SAVE; or, if the later duty's report is the wrong
one, correct it on that duty's Edit page instead. If the two records are the same duty entered twice, delete one
on the Duty Periods tab (swipe the card left, as in Check 9).
EDIT PREVIOUS DUTY lands on the earlier record, not the one the violation is listed under
Then vary it:
Move the earlier duty's End to 05:00: the overlap line, the dashed card and the red report go. The one-hour
gap is still short, so the card stays at ⚠ 2, now as two lines in their own words: §117.25(e)
"Rest period 1.00h is less than the 10h minimum required before reserve or flight duty period." and
§117.25(a) via §117.25(e) "FDP Oct 14 06:00–14:10 overlaps the rest required by §117.25(e), Oct 14
05:00–15:00 (UTC-05:00)."
Put the later duty on -04:00 (TIME ZONE on its Edit page), still 06:00: the two clocks differ, so each
time carries its offset: "This duty reports Oct 14 06:00 (UTC-04:00), before your previous duty ends at Oct 14
08:30 (UTC-05:00). …".
Regulations Part 700 CARs with the same two duties (CA Unaugmented): the same layout, cited as
§700.40, §700.41(1)(a) · overlapping duties.
Turn Settings → FTDT Rest Rules Engine off: no card, no dashed card, no red report, and the records
are unchanged.
The same overlap under CARs 700
Before AB#3417 an overlap read as a short rest: "Rest period 0.00h is less than the 10h
minimum…" (US) or "Insufficient rest: 00:00 provided…" (CA), one line per rule, and nothing pointed at the earlier
duty. Report either text on an overlap as a defect.
Something's wrong if: one overlap shows as more than one line; the badge or the
"N VIOLATIONS DETECTED" count drops to the number of lines; the dashed card or a red report time shows for a
violation that is not an overlap, or with the engine off; EDIT PREVIOUS DUTY opens the later duty; a time
in the message is not the one on that duty's own clock; or the overlapping duty cannot be saved.
6 · Duty Periods tab and per-period management
Steps: Open the Duty Periods tab. Tap MANAGE FLIGHTS & DETAILS on any card.
What you should see: One card per duty period (start, Max Duty Period, Ends, Duty hours), and
the manage row expands to four actions: EDIT DUTY PERIOD, ADD FLIGHT SEGMENT,
ADD REST OPPORTUNITY, ADD NOTE — each opens its own form
(flight segment form: Equipment, Flight Number,
Depart, Arrival, Date, Time Zone).
A card with a coloured outline is flagged, not broken. Cards are white with a
plain divider. Two states outline the card instead: amber means the duty period is still
open — no end time recorded, or a flight segment inside it is still open — and red means
it has exceeded its limit. Both are deliberate signals about the record, not rendering faults.
The duty period you create in Check 7 will be amber until you conclude it, and turns white once you do.
To see them without creating anything, seed US — Card States from the Test Scenarios page:
it lays one of each next to the other. Red wins where a period is both open and exceeded — an open
period never concludes, so it can exceed while still open, and the danger signal must not be hidden
behind the open one.
Seeded by US — Card States — open (amber) above exceeded (red); an ordinary
concluded period has no outline, as in the screenshot above
Something's wrong if: A card's action opens the wrong duty period (check the
dates), or an add form saves onto a different period than the one you managed. Also report a card whose
outline contradicts what it says — amber while the Duty row shows concluded hours rather than
Open, or no outline at all on a period you have not concluded.
7 · Create a duty period — limits and violations compute live
Steps: Tap ADD DUTY PERIOD → choose Unaugmented → leave the prefilled date/time
and tap CREATE DUTY PERIOD.
Operation types (matches the current app 1:1)
Create form — date/time/zone, segments, §117.25(e) sleep hours
What you should see: The create form computes Max Duty Period and Ends live,
before you submit, and carries an Acclimated toggle. Creating lands you on the Edit page
with both figures already computed and Ends equal to start + Max Duty Period. With the engine on,
rest violations against your neighbouring duty periods are flagged immediately — whether any appear
depends on how far your new period sits from the seeded ones, so no new violation is not by itself a
failure. The rest-rules inputs — Sleep Opportunity Hours §117.25(e) and the Insufficient Rest
§117.25(f) toggle — are on this page too.
Change one thing to confirm: clear the Date and tap CREATE DUTY PERIOD. The form stays open with "Enter a valid date and time." under Start Time, Max Duty Period and Ends show "—", and no duty period is created. Pick the date again and CREATE works.
Something's wrong if: Create with every field valid silently does nothing, Create with a field in error makes a duty period, the computed Ends time
doesn't equal start + Max Duty Period, or violations appear/disappear without any input changing.
8 · Conclude is a two-step action
Steps: On the Edit page, tap CONCLUDE once, then read the buttons before tapping again.
What you should see: The first tap arms the action — the button changes to
CONFIRM CONCLUDE — and only the second tap actually concludes the period and returns you to the
Duty Periods list. (This is deliberate: concluding writes the end of the duty period.)
Something's wrong if: A single tap concludes immediately, or CANCEL doesn't
disarm it.
Verified end to end (2026-08-04). The first tap arms, CANCEL disarms back
to CONCLUDE without leaving the page, and the second CONFIRM CONCLUDE tap concludes the
period and lands on the Duty Periods tab. The earlier 2026-07-17 "inconclusive" flag on the second tap
was a limitation of the scripted-tap tooling, not an app issue.
9 · Archived Logs, and the delete/restore round-trip — then put your data back
Steps: Open the Archived Logs tab and confirm older records render the same card layout.
Then, on the Duty Periods tab, open MANAGE FLIGHTS & DETAILS → EDIT DUTY PERIOD on
any period and tap DELETE. Finally, to finish: go back to Test Scenarios and tap
Restore My Data.
What you should see: Archived periods listed read-only-style with the same card anatomy; and
after Restore My Data the seeded synthetic records are gone and your own duty periods (if you had
any) are back — the card tells you how many were being held. Regulations and
Settings → FTDT Rest Rules Engine are back to what you had before your first scenario; one you
changed yourself after the last scenario is left as you set it. The Restore My Data card shows
✓ Ready with Go to Dashboard →; the next time you open Test Scenarios it reads
Nothing to restore and can't be tapped.
Something's wrong if: Restore leaves seeded scenario data behind, your own
records don't come back, or the dashboard stays on the scenario's Regulations (an empty CARs dashboard
after a CA scenario, for example; but see the note under Known gaps if you updated from 6.0.0 mid-scenario).
The DELETE button (on any Edit Duty Period page) is a two-step action,
like Conclude (Check 8): the first tap arms it and the button changes to CONFIRM DELETE;
only the second tap deletes. And it isn't a hard delete either: the period moves straight to
Archived Logs, and re-opening its
MANAGE FLIGHTS & DETAILS panel there shows a RESTORE action that puts it back on the
Duty Periods tab exactly as it was (confirmed live: totals on the Cumulative tab dropped after
delete and returned to their prior values after restore). Swiping a card left on the Duty Periods tab
and tapping the red trash strip deletes it in place too, in one tap with no CONFIRM step, and both that
delete and RESTORE update the Cumulative Limitations tab without leaving the dashboard:
once the change has finished saving, switch back to it and the totals reflect the change. On a slow or
failing network that waits for the server's answer to the write.
After DELETE — the period lands in Archived Logs, not gone
Its manage panel there offers RESTORE
Something's wrong if: DELETE removes a period without it appearing in Archived
Logs (a real, unrecoverable data loss — report immediately), or RESTORE doesn't return it to Duty Periods
with its original data intact, or the Cumulative tab keeps the totals from before a swipe DELETE or a RESTORE
until you leave the dashboard and come back.
Worth a design conversation: DELETE now confirms before acting, which closes
most of the earlier concern. What remains is that it still reads as permanent (red text, the word
"delete") while it actually archives reversibly — a tester who deletes something has no on-screen cue
that Archived Logs holds it and offers RESTORE.
10 · Add Rest Opportunity and Add Note
Steps: On the Duty Periods tab, open MANAGE FLIGHTS & DETAILS on any card, then tap
ADD REST OPPORTUNITY. Go back and tap ADD NOTE.
Date / Start / End / Time Zone, with Max Duty Period and Rest Duration shown for context
Single free-text note field
What you should see:Add Rest Opportunity takes Date, Start, End, and Time Zone, and
shows Max Duty Period and Rest Duration above the save button. On a US split duty the form opens on
22:00 on the duty date to 05:00 the next day; Edit Rest Opportunity opens on the saved window. Max Duty
Period changes as you change the times, before you save, and after SAVE the card's Rest Duration and the
edit page's Rest Window show the window you entered.
Add Note is a single "Enter notes here…" textarea saved with ADD NOTE.
Something's wrong if: Either form saves onto a different duty period than the
one you opened it from, the rest opportunity doesn't factor into the rest-rules violation check
(Check 5) afterwards, or reopening EDIT REST OPPORTUNITY after SAVE shows a different window from the
one you saved.
11 · Full op-type range and the FAR 117 Guide
Steps: With Regulations set to Part 117 FAR on the Cumulative tab, tap
ADD DUTY PERIOD. Note the full list of operation types, then tap FAR 117 Guide at the
bottom.
What you should see: Five US operation types — Unaugmented, Augmented, Split Duty,
Unaugmented Reserve, Augmented Reserve — Check 7 above only walks Unaugmented; the others are real,
separate create paths worth spot-checking too. Below the list: a FAR 117 Guide row and a
"Send app feedback to FTDTAPP@alpa.org" button. Switching Regulations to Part 700 CARS
changes this to CA Operation Selection with four types (no Split Duty) and drops the FAR 117 Guide
row (it's US-specific) while keeping the feedback button.
What you should see (a reserve type, US or CA): the Reserve Availability Period section has
RAP Start Date and RAP Start Time side by side. Date Oct 4, Start Time 03:00, Assigned on,
RAP Start Time 20:00: RAP Start Date becomes Oct 3 with no message. Pick Oct 4 in RAP Start Date: "The RAP start
cannot be after the report (Oct 4 03:00)." shows in red and CREATE DUTY PERIOD does not create it.
With Assigned off, a RAP Start Time later than the Start Time stays on the duty date with no message.
What you should see (FAR 117 Guide): Tapping it opens ALPA's actual "Guide to Part 117
Flight-Time Limitations and Rest Requirements" PDF in an in-app web view (member-gated — it auto-signs
you in). The My ALPA login form may flash on screen for a few seconds first, with your member number
already filled in, while the auto-sign-in completes — that is expected, not a login wall.
Known issue — getting back out (reported 2026-08-04, don't re-report): there is
no ✕ on screen when the PDF opens. Its action button is laid out almost entirely off-screen past
the top-left corner; only a small corner of it is tappable. Tapping that corner reveals a
‹ and an ✕ at the bottom right — and of those, only ‹ actually leaves the PDF.
✕ just hides the two buttons again. Use ‹ to return to Select Operation Type.
Something's wrong if: A non-Unaugmented op type's create form is missing fields
Unaugmented has, the FAR 117 Guide link 404s or shows a login wall instead of auto-signing in, or the
feedback button does nothing when tapped (it should open your device's mail composer addressed to
FTDTAPP@alpa.org).
What this checks, overall
The full FTDT loop on the new dashboard — seeding known states, cumulative-limit math (which must agree
exactly with the current production FTDT screen, since both read the same records), the beta rest-rules
engine's violation reporting under §117.25 and §§700.40–700.43, 700.60(7) and 700.63(3) (the Canadian rest after
positioning and after an extended flight duty period, Checks 5g and 5h), the overlapping-duties line and its link to the earlier duty
(Check 5i), per-period management including the less-common add-rest/add-note
forms, the full op-type range and the FAR 117 Guide reference link, live limit computation on create, the
deliberate two-step conclude, archived logs with the delete/restore round-trip, and restoring the tester's
own data afterwards.
Known gaps / differences from the current app (don't re-report these)
The 60-in-168 duty bar sums to 59:59. Its used and remaining figures are each rounded to the
minute independently, so they can land a minute short of the limit (18:12 + 41:47 seen during
validation). The other three bars sum exactly. Reported 2026-08-04 — don't re-report, but do report any
bar that is out by more than a minute.
Restore after updating from 6.0.0 mid-scenario. If you had a Test Scenario loaded when you
updated from 6.0.0, Restore My Data may leave Regulations on that scenario's value (6.0.0
never recorded yours). Set it back once with the Regulations pill on the dashboard (Diagnostic
Mode); later restores put it back on their own.
The three dashboard tabs don't all fit — and that is the design. The strip scrolls sideways and
snaps to whichever tab you select, so all three are reachable; the label is just clipped until you tap it.
Figma draws it the same way, and harder: the dashboard frame lays the tab row out at 458 points inside a
345-point container, and the archived-logs frame shows that row scrolled left to bring the third tab into
view. On device the row needs 423 in a 393 viewport, so it is clipped less than the design intends.
The bottom navigation is cut off on Select Operation Type. That page renders taller than the
screen, pushing the bar's labels half below the bottom edge. Cosmetic — the buttons still work.
Workflows don't map one-to-one. The current app is a single list page with a Calculate-style
form; the new design is a three-tab dashboard where Create lands on an Edit page with live-computed
limits. Compare results (totals, violations, end times) between the two, not screen-by-screen
layouts.
§117.25(c) and (d) fire only with airport data on the device. Both read longitude and time zone
from the airport list the Flight Finder caches while you are signed in, and both need a home base (profile or
the Home base override) — see Checks 5b and 5c. Signed out they never fire: built, wired, quiet on purpose; not
gaps to report. They share one hydration path, so they start working together rather than separately.
Rest rules exist only here. The production FTDT has no §117.25/§700.40–700.43/§700.60(7)/§700.63(3) rest
work at all — there is nothing to compare the rest-rules card against except the regulation text and the seeded
scenarios.
Canadian readings marked "[interim reading: …]" are project decisions awaiting the SME (§700.43 hours of
work and the 700.28 maximum for an augmented crew, §700.60(7) "extended", §700.63(3) "extension"). Report a number
that disagrees with the message's own terms; do not report the reading itself.
The Edit page's Minimum Rest hint under the UOC reason is the legacy figure (the duty length), not the
engine's §700.63(3) rest — Issue 3364; read the rest-rules card. With positioning minutes entered on a duty, a short
gap lists both a §700.40 line (from the duty's end) and the §700.43 line (from the end of the positioning); the
§700.43 line is the rest owed.
Limit-bar colors. Bars now render the blue-to-red gradient as a bar approaches its limit.
The exact stops are still pending design polish, so compare the behaviour (redder as it fills), not the
precise shade.
Engineers: sync data-integrity for the rest-rules fields has its own test plan —
the rest-rules test plan (internal wiki: wiki/FTDT/FTDT-REST-RULES-TEST-PLAN.md) (manual full re-pull:
Settings → FTDT Manual Sync in the current app).
