Glossary

as-maintained configuration

The as-maintained configuration is the documented state of a product or asset after maintenance, repair, or service changes.

Aerospace MRO Execution and Traceability Maintenance Lineage

As-maintained configuration refers to the documented configuration of a product, system, or asset after maintenance, repair, overhaul, or service activity has been performed. It reflects the actual approved parts, software, settings, revisions, and other controlled attributes that are in place once the work is complete.

In manufacturing and sustainment environments, this term is used in configuration management, service records, MRO workflows, and traceability processes. It helps show what condition an item was left in after intervention, not just how it was originally designed or first built. For example, an aircraft component may have an as-built configuration at release and a different as-maintained configuration after field replacement of a serialized subassembly or installation of a software update.

As-maintained configuration is commonly confused with related terms:

As-designed: the intended engineering definition.
As-built: what was actually manufactured or assembled at production release.
As-operated or current state: how the asset is presently running in service, which may or may not fully match the last recorded maintenance state.

The term usually implies controlled recording of post-service changes so that maintenance lineage, impact assessment, and downstream inspection or support activity can be based on the correct configuration.

For aerospace maintenance content, access control should be role-based, need-to-know, and tightly integrated with identity management, export control, and configuration management. Expect multiple layers: RBAC/ABAC, segregation of duties, workflow-based approvals, read-only vs authoring separation, strong authentication, and detailed audit trails across MES, MRO, PLM, and document systems. Exact controls depend on your mix of ITAR/export-controlled data, system integrations, and process maturity.

What are common integration pitfalls in aerospace MRO environments?

Common integration pitfalls in aerospace MRO include weak configuration control between ERP, MRO, and engineering systems; broken traceability across tail/serial, part, and task history; over-customized legacy tools; underestimated data cleansing and mapping; ITAR/export control gaps; and rollout plans that ignore hangar realities and validation burdens. These risks are magnified in brownfield, multi-vendor stacks.

How does risk management differ between design and MRO under AS9100?

Under AS9100, risk management in design is proactive, model- and requirement-driven, and tightly coupled to configuration control and design change. In MRO, it is more condition-driven, field-data-based, and focused on continuing airworthiness, maintenance errors, and repair deviations. Both must be documented, traceable, and integrated with the QMS, but the triggers, data sources, and control levers differ substantially, especially in brownfield environments with legacy systems.

What is the relationship between ISO 9001 and MRO quality requirements?

ISO 9001 defines a generic quality management framework, while MRO quality requirements are industry- and customer-specific layers built on top of that framework. ISO 9001 alone does not satisfy aviation or defense MRO requirements; it must be complemented by sector standards, customer contracts, and regulatory rules, all implemented through validated, auditable processes and systems.

Related Glossary