Ownership and handoffs

Why ownership exists

Ownership shows which position is currently responsible for a strip. It also prevents an ordinary handoff from being started by a controller who does not own the strip.

Flight Strips maintains three parts of the controller route:

• Owner: the position responsible now.
• Next controllers: the ordered positions expected to receive the strip later.
• Previous controllers: positions that have already handled the strip.

You do not edit these lists. Flight Strips updates them when a strip is assumed, a handoff is completed, ownership is freed or the route is recalculated.

Read the SI box

The SI box shows the strip from your position’s perspective:

• White: you own the strip.
• Purple: your position is in the expected route and has not owned the strip yet.
• Orange: your position has already owned the strip.
• Grey: your position is neither the owner nor part of the expected route.

A split colour means a coordination is waiting for action:

• White and orange: your position started a normal transfer, or another controller has requested the strip with REQ. Click the SI box to recall your normal transfer or to accept the tag request.
• Purple and white: the strip is being offered to your position. Click the SI box to assume it.

The demo shows the same strip from the sending and receiving positions. Click the sending SI box to start or recall the handoff, and the receiving SI box to complete it.

Your station perspective

SAS1234

A320
OY-KAU

B19

TSAT CTOT

22R

Other station perspective

SAS1234

A320
OY-KAU

B19

TSAT CTOT

22R

Make a normal handoff

When you own the strip, use either of these paths:

1. Click the white SI box to offer the strip to the next expected controller. This is available when another position exists in the strip’s next-controller route.
2. Select the strip, choose TRF, and select a connected controller when you need a different target.

The transfer does not change ownership immediately. Flight Strips creates a pending coordination and shows the split SI colours. The receiving controller must click their SI box to assume the strip. Flight Strips then changes the owner, advances the controller route and clears the pending coordination for everyone.

[Pictcture of a strip been transfered from AD->TW]

If you started the wrong transfer, click your split SI box or use RECALL in the strip menu. Only the position that started the coordination can recall it.

Assume an unowned strip

If nobody owns the strip and your position is in its next-controller route, your SI box is purple and clickable. Click it to assume the strip directly. No transfer request is created first.

This is manual because Flight Strips knows the expected route, but it does not know whether you are ready to accept responsibility.

Request a strip with REQ

Use REQ when another controller owns a strip that you need:

1. Click REQ. The green button means request mode is armed.
2. Click the strip’s callsign.
3. Wait for the owner to accept the request by clicking their split SI box.

Flight Strips only sends the request when the strip has an owner, you are not that owner and no other coordination is active. Accepting the request transfers ownership to the requester and recalculates the remaining route.

Use FORCE ASSUME only to recover

FORCE ASSUME immediately replaces the current owner, removes any pending coordination and recalculates the strip’s route. It bypasses the normal handoff sequence, so use it only when the displayed ownership no longer matches operational responsibility.

The action is available for a strip owned by another position, except from the clearance-delivery role. If an active validation makes the callsign open Validation Status, use FORCE ASSUME from that window instead of the strip menu.

What happens automatically

After your action, Flight Strips synchronizes the result to all clients and maintains the owner route. Some operational transitions also complete coordination automatically. For example, a pending arrival handoff is accepted when the aircraft is detected on the runway after landing, and an owned airborne departure can be offered to the configured airborne controller when an eligible controller is connected.

These automatic paths use the same ownership and pending-coordination states as a manual handoff. Do not create a second transfer when one is already shown.