# Workpackage model review against local AMOS documentation

Reviewed 2026-10-05. Sources: `amoshelp/backend/Planning/Workpackages/View Edit Workpackage.pdf.txt` (aircraft Workpackage, pages 20–24) and `amoshelp/backend/Component Maintenance/Component Workpackage.pdf.txt` (component Workpackage, pages 13–17). This review concerns header data and its validation; AMOS screens also include linked tasks, resources, approvals, documents, and workflow actions stored outside the header.

## Implemented in this review

| AMOS requirement | Coflyr implementation |
| --- | --- |
| Known aircraft selection, while allowing an unknown registration | Nullable `AircraftTailId` lookup alongside the existing `AircraftRegistration` text. |
| Component required condition selected from the condition table | Nullable `RequiredConditionId` linked to `RotableCondition`. |
| Target start/end and estimated start/end dates distinct from planned dates | Four optional date fields on `WorkpackageMaster`. |
| Explicit paperwork delivery tracking | `PaperworkTracked` boolean separate from `PaperworkPending` and `PaperworkReceivedDate`. |
| Rotable quantity fixed to one | Component workpackage mutation validation rejects `IsRotable` with `Quantity != 1`. |
| Start/end date ordering | Component validation checks planned, target, and estimated ranges when both ends are present. |
| Explicit Unknown A/C choice and default aircraft classification | `UnknownAircraft` is stored; aircraft headers validate the choice and default classification to Unspecified. |
| Aircraft registration/type follow selected aircraft | Header validation resolves `AircraftTailId` and fills registration and type from the selected aircraft. |
| Station, maintenance provider, project, and quotation selection | Optional IDs link to the Coflyr station, Business Partner, financial project, and commercial quotation catalogs; existing reference text remains for imports. |
| Multiple component authorities | `WorkpackageAuthorities` joins a package to multiple regulatory authority partners. The authorities endpoint replaces the selected set and updates the legacy primary authority. |
| Additional aircraft header details | Added customer workpackage number, aircraft subtype/model, operator lookup, inbound/outbound flight and gate fields, drop-off location, reserved facility, and dock office reference. |
| Maintenance program revision shown on the package | Added a maintenance program lookup and revision number/date fields; validation requires a program when revision information is supplied. |

## Existing coverage

- Component header already has part selection or unknown part number, serial/batch number, quantity, main/current shop, responsible staff, owner, failure confirmation, return type, planned start/end, priority, and shop arrival.
- Aircraft header already has workpackage number, description, registration and type text, operator, classification, planned start/end, provider text, project number text, and production handover state.
- Component creation already requires number, description, main shop, planned dates, part information, and serial/batch information. Those requirements match the key mandatory fields described in the component guide.

## Remaining gaps requiring domain decisions

| AMOS behavior | Current model limitation | Decision needed |
| --- | --- | --- |
| AMOS station is an Address with station properties (View/Edit p.21) | Coflyr's selected `StationId` points to `AirportCodeMaster` with `STATION` property | Introduce an address-backed station catalog if AMOS address ownership and station contact details are needed. |
| AMOS classification names (View/Edit p.22) | New/changed aircraft values are validated, but legacy imported values are kept on unchanged updates | Normalize old classification values after reviewing existing data. |
| Component status and priority can be configured in AMOS tables (Component pp.15–16) | Coflyr uses fixed enums | Decide whether tenant-configurable catalogs are required. |
| Updating an MP revision is conditional on no assigned taskcards and a licence (View/Edit p.23) | Revision fields and lookup exist, but the update operation does not yet enforce AMOS licence and taskcard constraints | Add a dedicated revision update command integrated with work templates and permissions. |
| Event and requirement collection status (View/Edit p.23) | Header does not calculate the AMOS collection indicators from linked events and requirements | Implement derived status in the planning/service layer rather than duplicate independently editable header flags. |

Earlier field-removal decisions remain in force pending the user's answer about whether AMOS documentation should override them. A literal copy of every AMOS screen field onto the header would duplicate linked entities and reverse those decisions.