How grounding squawks work

A squawk is a reported defect, the aviation word for “something is wrong with this asset”. Syndik8 takes every squawk seriously enough to record it, but only some squawks stop the asset being used. Three severities, a short lifecycle, and a deferral mechanism make the difference; the reasons for each are worth knowing before you need them.

Why three severities and not two

A plain “can I fly it or not” boolean throws away too much information. Real operating experience has three kinds of finding:

Grounding: something that must be fixed before the asset is used again. Low oil pressure, a cracked exhaust, a tyre worn to the canvas.
Caution: something the next user needs to know about but can work around. A broken chart-holder clip or a worn cabin furnishing, following the appropriate assessment. A category label does not establish whether equipment is required or a defect affects safety.
Info: a historical record the syndicate wants on the asset. A small tear in the upholstery, a radio frequency programmed unusually.

Collapsing the middle and lower categories into “not a problem” is a false economy. A caution squawk carries forward to the next pilot’s pre-flight check; an info squawk builds the asset’s long-term record. Only grounding blocks availability; caution and info do nothing to the booking calendar. See Squawk severities for the exact behaviour of each.

Why grounding is binary at the asset level

For booking purposes, Syndik8 needs one answer: does a recorded restriction apply? It computes a single indicator per asset, visible on the asset detail and enforced by the booking dialog. An open grounding squawk restricts bookings; resolving it or recording a lawful deferral removes that restriction if no other cause remains. This calculation does not determine actual airworthiness. See Airworthiness rules for everything that feeds that calculation.

The nuance lives inside the boolean. A recorded restriction has a specific squawk or maintenance item behind it; the syndicate sees that reason in plain text on the airworthiness card. The binary is cheap; the explanation behind it is rich.

The squawk lifecycle

A squawk moves through a short set of states. Pending exists only when the syndicate requires admin confirmation of reports; it lets an admin weigh severity before the grounding effect kicks in. A pending squawk is either confirmed, which makes it open, or dismissed if it turns out not to be a real defect. An open squawk is active, and it leaves active status by being resolved (the defect is fixed) or deferred (a recorded decision to defer the defect until a stated date). Dismissal is therefore a triage decision taken before confirmation, not a way to close an open squawk. See Squawk statuses for the transitions and who can make them.

Nobody can reopen a resolved or dismissed squawk. If the same defect returns, the correct action is a fresh squawk, referencing the original if useful. Keeping the history immutable protects the audit trail.

Deferral is a controlled tool, not a workaround

The most common question about this model is: “what stops an admin from just deferring every grounding squawk so the asset keeps flying?” The app records a reason and a date, but those controls do not establish that a deferral is lawful. An admin must first obtain the decision of a person authorised under the rules for that aircraft and operation; an app role provides no aviation qualification.

Deferral requires a reason. Use the existing field to record the authorised person’s decision and the relevant basis/reference. It is stored on the squawk.
Deferral requires an expiry date. This booking restriction is lifted until that date, not indefinitely.
The date ticks. Once the deferral date is in the past, the asset re-grounds automatically. Nobody has to remember; the airworthiness rules include a check for deferred squawks past their date.
The deferral is on the record. It appears on the squawk, and the reason and date are visible to every member, not only admins.

For aircraft subject to UK Part-ML, CAA ML.A.403 distinguishes defects that must be rectified before flight from those that an appropriately authorised person may defer. The permitted decision-maker and conditions depend on the defect and operation. Parts on order or a workshop booking alone do not authorise flight. Syndik8 records the decision; it does not approve it.

Why resolution is separate from dismissal

Resolving a squawk says the defect has been fixed. Dismissing a squawk says the defect wasn’t real (a mis-report, a duplicate, a misunderstanding). These are different statements and the syndicate’s record should show which one happened. Dismissal requires a written reason, for the same audit-trail reason deferral does. See Squawk statuses for the exact rules on who can do each.