Configuration proposals

This page answers a different question than the catalogue and the aircraft sheet: given what I want to carry, which authorised configuration is fastest to reach from where the aircraft stands right now? It targets the preparer / technical office — not the flight line, which has no need to arbitrate between several possible configurations.

Screen	Answers
Operational configurations	Which station → reference combinations are authorised?
Aircraft sheet, Configuration tab	What does THIS aircraft carry, right now?
This page	Of all authorised configurations, which needs the least effort for this aircraft?

Expressing a need: one aircraft, zero to N wanted references

The need does not describe a mission — there is no “mission” object yet in Envergure. It is limited to two things:

an aircraft, mandatory — the proposal always compares against the REAL state of that aircraft;
wanted references, optional — “I want to see this tank and this pod carried”.

With no reference checked, the screen shows the whole field of authorised configurations applicable to that aircraft (family, variant, version, serial-number range, modification level). Checking references filters that field: a configuration is only retained if all the requested references appear in it — checking two references means “I want to carry this AND that”, not “this OR that”. A reference can also be covered by a declared interchangeable equivalent (see the Operational configurations page for the interchangeability rule): requesting an older reference also finds the configurations that require the reference which replaced it.

The movement: the only number that matters

Movement: A hang-up OR an unhook — a single physical gesture on a station. Replacing a store on the same station therefore costs two movements: one unhook, then one hang-up.

This count, and this count alone, ranks the proposals. Not how close the code looks, not the catalogue’s order: the number of gestures needed to go from the aircraft’s current state to the proposed configuration. Between two equally authorised configurations, the one that needs two gestures always beats the one that needs six — even if the second one looks “closer” on paper.

A store already hanging that satisfies a requirement through interchangeability costs no movement. This is the rule most easily missed on a quick read: if the aircraft already carries reference B, and an approved interchangeability document says B replaces the required reference A, then that requirement is already satisfied — showing it as a movement to do would suggest unhooking a perfectly serviceable store to hang its own approved equivalent back up, which makes no sense.

Realisable does not mean authorised — it means there is stock

A configuration can be perfectly authorised and still not realisable today, if stock does not follow. For every requirement the aircraft does not already satisfy, an available instance is needed:

serialised (batched or quantity-tracked articles cannot be hung, cf. R2);
in new or serviceable condition;
technical reception validated;
neither hung nor installed anywhere else;
admitted on the target station (the compatibilities declared on the station).

Technical reception: The check by which the airworthiness technician validates the identification and counters of an instance before its first use. While pending, the instance exists in stock but can be neither installed nor hung.

This is the trap most easily overlooked: POST/stock-items/:stockItemId/carry — hanging a store already requires this validation. A proposal that ignored it would suggest hang-ups the system would then refuse at execution time — a misleading proposal is worse than no proposal at all.

A single instance obviously can only cover one requirement: if only one available instance of a reference exists and two different stations each ask for one, only one of the two can be satisfied by current stock.

Why a non-realisable configuration stays visible

A non-realisable configuration is never hidden. It sorts after the realisable ones, with the precise list of what is missing (station and reference). Hiding it would deprive the preparer of useful information: “this is the best configuration for this need, only a pod is missing — is it worth sourcing, or better to fall back to the next one?” That is a human call the screen should inform, not make on its behalf.

Alerts

Checking this page on demand is not enough: nobody thinks to open it unless something points them to it. The system therefore surfaces three situations on its own, with no screen to open — in the “Priority actions” panel of the dashboard, next to the airworthiness compliance alerts that already lived there:

non-compliant aircraft — what it carries matches no authorised configuration that applies to it;
a hung store past its potential — as soon as a store’s counters run (hanging it makes them run, see above), the existing due-state tracking already knows how to see an overdue potential. The alert simply surfaces it, and only for an instance currently hung: an overdue potential sitting in stores, never mounted or unhooked since, remains ordinary maintenance due-state business — not this one;
compliance reached under a condition — the same interchangeability rule described above: when the only path to compliance goes through a substitution carrying a condition text, the alert shows that text as-is. It is never evaluated by the application — a human must judge it, before the flight.

Why THESE three, and not “anything that looks off”: an aircraft with no applicable configuration at all does not alert — there is nothing to compare it against, and flashing an entire fleet that is not yet catalogued would make the panel useless rather than useful. A plain compliance, with no condition invoked, has nothing to report either: that is the normal state, not an exception worth a banner.

Why a superseded revision, still carried, does not alert

Supersession (R5): A revision replaces the previous one. What flew under the old revision remains true: past checks are never rewritten.

Only active configurations enter the alert calculation — a superseded revision is never loaded, so it is never compared against anything. It can therefore never, structurally, be the cause of an alert: not a positive one (it never makes an aircraft falsely “compliant”), nor a negative one (it never tips an aircraft into “non-compliant”). Publishing a new revision of a configuration therefore does not trigger a wave of alerts across a whole fleet that is still legitimately flying under the old one — the same principle as the aircraft sheet’s compliance check, simply extended to the dashboard:

GET/operational-configurations/alerts recomputes on every read, against the catalogue currently in force, never against its history.