COMPLIANCE

What the model carries, and what it does not.

Compliance in a maintenance system is not declared, it is checked. This page states, for each specification, whether it leaves a trace in the data model — and what that trace does not cover.

The six ASD S-Series specifications

Three of them leave a trace in the data model and in the code. The other three do not, and are listed as such.

  • S1000DIn the model

    Technical publications

    Data module vocabulary structures the OEM catalogue import and technical receipt. XML interchange and the common source database are not covered.

  • S2000MIn the model

    Material management

    The illustrated parts catalogue and employment points follow ATA Spec 2000 numbering and sequence numbers. Interchange messages are implemented: catalogue, spare parts list, codification, order and shipment, with acknowledgements both ways and outgoing messages validated against the operator's schema.

  • S4000PIn the model

    Maintenance programme

    Task lifecycle and tracking follow the specification's semantics, covered by integration tests. The reliability analysis that precedes it is still to be built.

  • S3000LPlanned

    Logistic support analysis

    The vocabulary sits in the reference data, but the analysis itself has no tooling.

  • S5000FPlanned

    In-service data feedback

    The data builds up in work orders and removals. Exporting it in the standard format is still to be written.

  • S6000TPlanned

    Training needs analysis

    Outside the current scope.

Regulatory frame

The platform is built for approved organisations. That frame shapes the data model, not just the wording.

  • EASA Part-145 and Part-M for civil maintenance and continuing airworthiness management.
  • FRA 145 and FRA M for their French state equivalents.
  • ASD STE100 for the semantics of an item's condition.
  • eIDAS for release-to-service signature — entity and sealing still to come.

What is not covered

Two functions belong to the roadmap, not to the product. They are listed here rather than left out: finding them out during a demo would cost more than announcing them.

  • TelemetryPlanned

    Sensors and predictive maintenance

    Raising a work order from a sensor signature requires an ingestion chain and a time-series store. Neither exists today.

  • ReplicationPlanned

    Resynchronisation between instances

    The groundwork is in place — hybrid logical clock, per-instance unique identifiers — but the replication service is not written. An isolated instance runs; it does not yet catch up on its own.

NEXT STEPS

Let's see how it holds against your reference data.

A 90-minute demo over video: product walkthrough, technical Q&A, review of your constraints. Tell us your context and we will tailor the session to it.

Or write to us directlycontact@envergure.cloud

Contact form

Required fields