Wiki·rules·rules/rules-reference.md

Rules Reference

A compact catalog of the operational rules the ERP enforces. Each section is stand-alone; the LLM can pull any one of them when answering a question. For the long-form MEL rules see MEL Deferral Rules.

Contents

Discrepancy Types and Categories

Every row in DP_DISCP_DISCREPANCY_DTL carries a DISCP_TYPE and DISCP_CATEGORY.

Types (most common, from real data):

  • MIREP — Maintenance Report. A defect raised by maintenance (crew write-up or inspection finding). Default for most line snags.
  • MLGEN — Maintenance-log general. Used for non-fault entries that still need tracking.
  • DPGEN — Discrepancy general.
  • CMGEN — Component maintenance general (shop side).

Categories — operator-specific. In this dataset: QC26, ATTRI2, FF77, EY84, IT25, etc. Each category maps to an ATA chapter / severity class.

Applicability (DISCP_APPLICABILITY):

  • AIRC — against the aircraft (default)
  • COMP — against a specific component (DISCP_COMPONENT_ID populated)
  • ENGN — against an engine

Record status (DISCP_RECORD_STATUS): UNRES → RESOL → CLOSED, with DEFERRED as a parallel state reached from UNRES.

See also: Discrepancy Lifecycle.

Sign-Off Requirements

A task is legally "done" only when signed off by someone authorised for that work at that work centre.

Required:

  • Employee code (TLGTSO_EMP_NO on FLOG_TLGTSO_TSK_SNOFF)
  • Skill code (TLGTSO_SKILL_CODE) — must be in the employee's skill matrix
  • Timestamp (TLGTSO_SIGN_OFF_DATE)
  • Work centre — cross-referenced via BAS_WC_WCUSR_WC_USER_MAP

Multi-skill tasks need additional sign-offs — captured as rows in flog_adlsoff_tsk_dtl (AdditionalSignOff). Classic case: mechanic does the work + inspector signs it off.

Sub-task sign-offs (FLOG_TLGSTSO_SUBTSK_SNOFF) must all be present before the parent task's sign-off is valid.

Certifying Staff (CRS sign) — only a specific list of employees can sign a CertificateOfMaintenance. Enforced by BAS_WC_WCCERA_WC_CERT_APPL for the work centre.

Work Unit Completion Rules

A work unit (task) transitions through states enforced by the ERP:

PLANNED → IN-PROGRESS → PENDING-SIGNOFF → COMPLETED → CLOSED
                               │
                               └─(sign-off fails)→ REWORK

Completion gates:

  1. All sub-tasks must be COMPLETED
  2. All required sign-offs present
  3. All parameter updates captured (if the task requires readings, e.g., torque, pressure)
  4. All consumed parts reconciled (parts issued = parts used + parts returned)

A task cannot COMPLETED → CLOSED until an AMEPackage-level check passes that these conditions hold.

Certificate of Maintenance

The CRS / COM — the legal release document. Issued via FLOG_TLGCOM_TECH_COM_DTL at the end of an AMEPackage.

Prerequisites:

  • Every task in the package has a valid sign-off
  • Every discrepancy raised is either CLOSED or deferred under a valid DeferralRecord
  • All mandatory parameter updates are recorded
  • The issuing certifier has the right authority for the work done

The certificate carries:

  • TLgCOM_Com_NO — the certificate number
  • TLgCOM_TechLog_No — the parent AME package
  • Issuing certifier's employee code + skill
  • Date/time of issue
  • Station where issued

Skill authority is checked against FLOG_TLGSKL_COM_SKILL_DTL — each certificate number has an authorised skill list.

Without a valid COM, the aircraft can't legally release.

Component Removal Reasons

CM_RMVRSN_REMOVAL_REASONS defines 18 reason codes. Grouped:

  • SCHEDULED: SCHED — component hit its time/cycle limit. No defect.
  • UNSCHEDULED: UNSCHED, FAILURE, LEAK, NOISE, VIB — in-service failure or degradation.
  • BER: BER — beyond economic repair. Written off post-inspection at shop.
  • MFR: MFR-DEF — manufacturer defect. Warranty path.
  • CONVENIENCE: CONV, MOD — removed for modification, upgrade, reconfiguration.
  • NFF: NFF — No Fault Found at shop inspection. Reinstall.

The removal reason is captured on the originating Discrepancy and carried forward to the generated ShopWorkOrder via swo_swoassoc_main_core_dtl.

Shop WO Routing and Disposition

A ShopWorkOrder's life is a sequence of routing events in swo_swortng_routing_dtl. Each event:

  • swortng_from_wc → swortng_to_wc — the work centre hop
  • swortng_Disposition — what's being done (inspect / repair / scrap / quarantine)
  • swortng_genrtd_swo — the parent SWO
  • swortng_rep_shopno / swortng_rep_shopfrom — if outsourced to external repair agency

Common dispositions:

  • REPAIR — standard repair path
  • INSPECT — routed to inspection only
  • NFF — tested, returns as-is
  • BER — beyond economic repair, goes to scrap/quarantine
  • EXTERNAL — outsourced to an external repair vendor

Routing status (swortng_routing_status): PENDING → IN-TRANSIT → RECEIVED → CLOSED.

Physical location at any time is swortng_current_Loc.

Customer Warranty and Charging

For third-party MROs, each ShopWorkOrder has flags:

  • swoh_cust_no — which customer owns the component
  • swoh_cust_warr_req_flag — is the customer requesting warranty consideration
  • swoh_cust_warr_res_flag — did the shop grant warranty

If warr_res = Y, the work is non-billable (or offset against a warranty pool). Charges in swo_swocrg_charge_details net to zero for the customer.

If warr_res = N, standard billing applies: labour + parts + overhead rolls up into swo_swocst_cost_summary and out to invoice via swo_swocrg_charge_details.

Historical charge revisions (after customer dispute etc.) land in swo_swocrgh_charge_details_his.

Priority Classifications

BAS_CM_PRI_PRIORITY_NUMBER defines 18 priority codes. In practice three levels dominate:

  • AOG (Aircraft on Ground) — highest priority. Aircraft cannot fly until resolved. 24/7 shop response, expedited sourcing, cost-no-object.
  • URGENT — needs resolution within the next 24–72 hours to avoid AOG.
  • ROUTINE — standard scheduling.

Priority is set on ShopWorkOrder and cascades down to routing. An AOG SWO jumps the queue at every routing hop.

Visit Package Planning Rules

Base visits (C-check, D-check) are planned 6–12 months ahead. Rules:

  1. Effectivity: tasks added to a visit plan must be applicable to the aircraft's model per bas_tsk_tskme_mdl_effect.
  2. Due-by dates: each scheduled task has a due-by (calendar / FH / FC). The visit must capture all tasks due within the visit window + typical look-ahead.
  3. Engineering Orders: all active, applicable ADs/SBs must be rolled into the visit (or have an explicit deferral).
  4. Life-Limited Parts: SWO_Visit_LLP_Info rows must cover every LLP approaching its limit within the next visit cycle.
  5. Baseline lock: once baselined, changes require an amendment in swo_wsa_amend_hdr with a documented reason.
  6. Resource commitment: the visit's primary work centre + facility must have capacity booked.

Three-Way Match on Shop WOs

The shop equivalent of PR/PO/GRN. For every part consumed in an SWO task, three records must reconcile:

  1. Routing — swo_swortng_routing_dtl says the part was routed in and to which work centre
  2. Part consumption — swo_swoprt_part_details says the task consumed it (quantity, status)
  3. Sign-off — swo_swostk_sub_task_details sign-off confirms the consumption

Reconciliation query:

routing.qty + initial_stock  =  parts.used_qty + parts.ret_qty + parts.pend_qty

Any mismatch is flagged as a potential audit issue — parts unaccounted for, or phantom consumption. The cost roll-up into swo_swocst_cost_summary assumes reconciliation passes.

Defect Deferral Limits

(See MEL Deferral Rules for the full MEL mechanics.)

Summary:

  • Calendar: opened_date + limit (Cat A: 0 days / B: 3 / C: 10 / D: 120)
  • Flight hours: opened_FH + limit, tracked via flog_tlgpm_param_upd_dtl
  • Flight cycles: opened_FC + limit, same tracking

Effective expiry is the earliest of the three. At expiry the deferral auto-closes and the discrepancy reverts to UNRESOLVED.

Usage counters advance at AMEPackage closeout.

Task Effectivity Model

Which tasks apply to which aircraft? Governed by bas_tsk_tskme_mdl_effect:

  • Model effectivity — task applies to all of model X
  • Serial effectivity — task applies only to serial ranges within a model
  • Configuration effectivity — task applies only when configuration ID matches

During visit / AME planning, the system filters the task catalog to only those rows whose effectivity is satisfied by the aircraft's model + serial + config. Prevents e.g. loading an A320-specific inspection onto a B767.

OU Scoping

Organization Unit (OU) is the horizontal partition of the ERP. Every transactional row has one or more OU columns:

  • _OUINSTANCE — the OU the row belongs to
  • _SLFSRC_OUINSTANCE — the OU the row was sourced from
  • _CRT_OUINSTANCE — the OU that created the row

Why it matters:

  • A big MRO serving multiple airline customers may set up one OU per customer
  • Data in OU=2 is logically isolated from OU=3 unless explicitly shared
  • Every query should filter by OU when running in multi-tenant mode

In this dataset the predominant OU is 2. Some rows reference 2.0 (float representation) — the ERP treats these as equivalent but queries should handle both.

Data Quality and Case Sensitivity

Real operational data has quirks. Noted in this dataset:

  • Case sensitivity in aircraft regs. We see VT-666 and Vt-666 / vt-666 as separate rows in transaction tables. Logically the same aircraft, physically separate keys in the DB. Handling: normalise to a canonical casing when aggregating — uppercase is standard in aviation. See the seed expansion in db/seed_case_map.json for how we handle this.
  • Orphan aircraft regs — 36 reg values in transactions that have no matching row in AC_ACI_AIRCRAFT_INFO. Usually test records or de-registered aircraft. Handling: safe to ignore unless explicitly asked.
  • Wildcard doc numbers — some rows carry DISCP_DOC_NO = '%' or similar wildcard-ish values. These are template / placeholder records from test systems; should be filtered out when showing real operational data.
  • Float OU instances. 2.0 and 2 are used interchangeably across tables. Cast to text consistently when joining.
  • Blank category values — ~4,300 discrepancies have empty DISCP_CATEGORY. Acceptable — categorisation is a later-curation step and is retrofitted by the ops team.

The Brain handles these quirks quietly — the Rules pages here document them so the LLM can explain/cite when a user asks "why is this aircraft missing?"

See also