Operational configuration

The word “configuration” covers three different questions in this trade. Operational configuration answers the last one, and it is the only one this page is about.

Configuration	Answers	Where to see it
Definition	What standard is the aircraft built to?	Applicable configuration, amendments
Physical	What equipment is installed, where, since when?	Decomposition
Operational	What does the aircraft carry, for a sortie?	This page

The first two answer “is this aircraft compliant and maintained”. The third answers “is this aircraft fit for this mission”. It isn’t the same timescale: one moves at inspection time, the other between two sorties within the same day.

What the aircraft carries

A fuel tank, a designation pod, a munitions rack, a decoy: all of these are stores — serialised instances hung on a station (a hardpoint, a pylon, a rack) for a sortie. A station can itself carry a rack which carries loads: the station hierarchy follows the employment-point hierarchy.

Station: A physical carriage point, modelled as an employment point of “stores” nature. A station is declared in the aircraft’s applicable configuration, exactly like an airworthiness employment point — but with an Emport badge that sets it apart.

Store: A serialised instance hung on a station: fuel tank, pod, load, decoy. A store remains an ordinary catalogue article — no separate referential exists for stores (see below).

No stores referential is created. A store is an article like any other: a reference, serialised instances, stock. The compatibilities declared on the station say what it may carry — exactly as for a technical employment point. That single declaration serves twice: it filters the picker when building an approved configuration, and it guards the physical hook-up described below.

The isolated movement: one gesture, one trace

Hanging a fuel tank between two sorties is not a maintenance act: no scheduled inspection, no component replaced, no Part-145 signature expected. But it is work, and it gets traced — time spent, consumables used, who fitted what.

You have nothing to open for that. The gesture stays the same — a station, an instance, confirm — and the gesture itself makes its trace: the hook-up is recorded in the aircraft’s movement journal for the day, created on the first gesture and shared by every one that follows.

Why one journal per day rather than one work package per gesture: a squadron does dozens a day. One package per fuel tank hung would drown the real maintenance jobs in the list. The day is the unit a squadron already thinks in.

Two exceptions to that rule, in this order:

A reconfiguration job is open on the aircraft — the movement goes there, not into the journal. It closes the operation that was waiting for it; and if it was not on the programme, it is recorded there anyway. That is the gap between planned and done, and it is the first thing a debrief looks at.
You are changing the whole configuration — that gets prepared, see “Changing configuration” below.

None of this is imposed on you at the moment of the gesture. Envergure decides where to record; you hang the store.

Hang a store

Pick the station
From the aircraft sheet, open the operational configuration. Each station shows its state: empty, or already carrying a store.
Pick the instance
The picker proposes ONLY the instances whose reference is admitted on that station — see “The hard refusal” below.
Confirm
The hook-up is recorded via POST/stock-items/:stockItemId/carry — which requires NO work package to be open beforehand: it is what files the movement where it belongs.

Unhooking reuses the same mechanism as removing a maintenance component (POST/installations/:installationId/uninstall): closing a carriage line needs no more preparation than opening one did, and is filed the same way.

Direct consequence on how the aircraft reads. Neither act ever shows up in the airworthiness history, nor in the technical decomposition. Mixing a computer replacement with hanging a fuel tank would make both unreadable — the two are told apart at the data level, not only on screen.

The package carrying the trace says so itself: its kind is Stores movements, never preventive nor corrective. Tracing work and declaring it maintenance are two different things, and the second would be false here.

Changing configuration: through a work order

Moving from one configuration to another is not an isolated movement — it is a sequence of removals and fits that must be traced: time spent, parts consumed, and the airworthiness duty of knowing who fitted what, and when.

From the Configuration proposals screen, one button generates the matching work package and work order. Nothing is recomputed by hand: Envergure takes the movements it had just displayed and materialises them into operations — one per instance, removals before fits, because an occupied station must be freed before it can be filled again.

Three choices are worth knowing, because they explain what you will see:

The order never names a serial number. An operation says “fit a fuel tank on P2”, and records the instance actually fitted at the moment of the gesture. Until Envergure can reserve an instance in stock, writing a serial number into an order would be a promise it cannot keep. Side benefit: interchangeability can play at the moment of the gesture, not only when the order was written.
One open reconfiguration per aircraft. Two orders would each describe a starting state the other invalidates. The refusal names the one already open.
An order the stock cannot yet cover is still generated. Preparing the job before the part arrives is normal use; the screen says so, and it is the fits that will block on the day.

The gesture itself does not change. Hanging and unhooking go through the same dialogs, with the same checks — and when a movement matches an operation the open job was waiting for, it is the movement that closes the operation, never the other way round. There is therefore only one write path: two paths each carrying their own guards would eventually diverge.

The plan as a hook-up interface

The underside plan does more than show the aircraft from below: on the aircraft sheet, for any station already positioned, it becomes a graphical shortcut to exactly the same gesture as the station cards above.

Empty station, drawn on the plan — a click opens the same hang dialog as the « + Hang » button on its card, already targeted on that station.
Store drawn at its position — a click opens the same unhook dialog as the « Unhook » button on its card, already targeted on that precise carriage record.
Full station (as many stores as slots) — the plan no longer offers hanging for it, exactly as its card no longer shows the button.

The drawing is a shortcut to the gesture, never a different path. The hard refusal outside compatibility (below), the picker filtered to only admitted references, the requirement for a serialised, received instance: none of it is relaxed because the click starts from an image rather than a card button — both paths open the same dialog, with the same controls.

A station with no declared compatibility stays visible on the plan, but is never clickable there. It appears greyed out, visually distinct from stations that can receive: the drawing must never invite a click only to answer with a refusal. The explanation stays written under the plan, not only visible on hover over a point.

Accessibility. Every target on the plan is a real HTML button, reachable by keyboard like any other control in the application, with a name that states the station AND its state — for example « Accrocher un emport sur la station P5 » (Hang a store on station P5) or « Décrocher RPL-711:F4957 de la station P2 » (Unhook RPL-711:F4957 from station P2). The application is French-only today, so the accessible name itself reads in French — a drawing that only responded to the mouse would be a step back from the cards it doubles regardless of language.

An unpositioned station never appears on the plan at all (see station pointing): its card remains its only representation.

The hard refusal, outside compatibility

On a maintenance install, a component whose reference isn’t listed in the compatibilities triggers an acknowledgeable warning: the operator can override it knowingly, and the warning stays on record.

Hanging a store does not work that way. A reference outside compatibility is refused, with no acknowledgement path. The reason: the same compatibility declaration underpins the approved operational configurations. Bypassing it at hook-up time would empty of meaning the downstream compliance check that relies on it — an aircraft cannot be “compliant under condition” for a combination forced past the very declaration meant to guarantee it.

The reflex: a station with no compatibility can carry nothing

A station with no declared compatibility can literally hang nothing. This isn’t a picker limitation — it is the direct consequence of the hard refusal above: with no admitted reference, there is nothing to offer.

When a station looks unusable, the first reflex is therefore to check its compatibilities, not to look for a bug. The screen states this explicitly rather than showing a silent empty list, and links to the applicable-configuration editor where the station’s compatibilities are declared.

The counter effect: stores’ potentials start running

This is the collateral gain, invisible on screen but real: because hanging and unhooking reuse the same reading mechanism as fitting and removing a piece of equipment, stores’ counters start running. A fuel tank, a pod, a rack are serialised rotables like any other — they have potentials, scheduled inspections, their own airworthiness. It’s simply that, as long as nothing tracked their hook-up, their counters stayed at zero regardless of their actual flight history.

Every hang and every unhook can therefore carry a counter reading (flight hours, cycles, a specific measurement) — exactly like a maintenance install or removal. It is through that reading that a store’s potential advances.