MES designed for AS9100 Rev D aerospace manufacturers

Configuration Management & Engineering Change Orders

AS9100 §8.1.2 and §8.3.6 require configuration management and controlled design change. Qontiv's ECO workflow manages revision-controlled items, BOMs, and routes. Approved revisions are immutable — the interceptor prevents any further edits. Every ECO has a tamper-evident SHA-256 signature hash covering the change title, description, reason, and revision transitions. Multi-role sign-off is configurable per tenant.

• • AS9100 Rev D §8.1.2 — configuration management
• • AS9100 Rev D §8.3.6 — design and development changes

PFMEA — AIAG-VDA Action Priority

Process FMEA with AIAG-VDA 2019 Action Priority scoring (High/Medium/Low — no RPN). AS9100 §6.1.2 requires risk analysis; PFMEA is the standard vehicle. Cross-functional team requirement (3+ disciplines) is enforced before approval. Control plans derived from Critical and Significant PFMEA rows.

• • AS9100 Rev D §6.1.2 — risk and opportunity analysis
• • AS9100 Rev D §8.5.1.1 — manufacturing process design

Lot Genealogy & Traceability

AS9100 §8.5.2 requires identification and traceability throughout the product realization process. Qontiv captures genealogy at the point of work. Forward and backward queries identify the complete affected population for containment — in seconds, not hours.

• • AS9100 Rev D §8.5.2 — identification and traceability
• • AS9100 Rev D §8.7 — control of nonconforming outputs

CAPA with Root-Cause Analysis

AS9100 Rev D §10.2 requires documented corrective actions with root-cause analysis. Qontiv's CAPA module enforces named methodology (5-Why, Fishbone, Fault Tree) and effectiveness verification before closure — the same evidence auditors ask for.

• • AS9100 Rev D §10.2 — nonconformity and corrective action

Supplier Quality — AS9100 §8.4

Approved Supplier List with state-machine governance and SCAR workflow using AIAG 8D methodology. AS9100 §8.4 requires evaluation and re-evaluation of external providers. Supplier qualification status gates material release in incoming inspection.

• • AS9100 Rev D §8.4 — control of externally provided products

What an approved revision will and will not let you change

"Immutable" is a word most systems use loosely. Here it is a specific, enumerable set. Once an item, BOM, or route revision is Approved, the write path permits exactly three things: the audit metadata that records who touched it and when; a transition to Obsolete, and no other status; and the effectivity end date, and only while the supersession worker holds the guard that authorizes it. Everything else is rejected — the revision string, the revision sequence, the part code, the effective-from date, the approving change order, and every entity-specific identity field. An Obsolete revision permits nothing but audit metadata. Deleting an approved or obsolete revision is refused unconditionally. Child records lock with their parent: BOM lines and route operations cannot be added, edited, or removed once the revision above them is approved.

The detail worth pressing us on in a demo: every blocked attempt writes its own evidence through a separate database connection before the rejection propagates. The transaction rollback that refuses the change therefore cannot erase the record that it was attempted. An auditor asking "has anyone tried to edit a frozen revision" gets an answer instead of silence.

Revisions are ordered internally by a monotonic sequence, never by the revision string — ASCII sorting puts "Z" after "AA", which is wrong for every real part-numbering scheme. The label your customer sees is separately configurable per tenant as alphabetic, numeric, alphanumeric, or a custom pattern, so your scheme is honored on the drawing while ordering stays correct underneath. There are exactly three revision states — draft, approved, obsolete — and any revision's state as of a given instant is directly queryable. Supersession is closed automatically by a worker within a minute of a newer revision becoming effective; it is not instantaneous, and we would rather say so than imply a guarantee the clock does not give.

• • AS9100 Rev D §8.1.2 — configuration management, enforced at the write path
• • AS9100 Rev D §8.5.6 — control of changes to production
• • 21 CFR Part 11 §11.10(e) — a blocked mutation is itself an audit-trail event

ECO approval — unanimity, not a quorum

Submitting a change order creates one approval slot per required role, unique per order and role, from the role set your tenant configures. Promotion requires every configured role to have approved: there is no quorum, no N-of-M, and no majority. A single rejection from any role flips the whole order to rejected immediately, and signing a slot twice is refused. Each approval carries a SHA-256 digest over the signer, the timestamp, the order code, and a hash of the order's content, so an approval cannot be quietly re-pointed at different content after the fact.

One cross-module gate is worth naming because it is the kind of thing that fails an audit when a system does not have it: a change order whose linked risk file is not itself approved cannot be approved. On promotion, in a single transaction, the order goes approved and each linked revision moves from draft to approved with its effective-from date and the approving order recorded — each transition checked against the revision state machine, not written directly.

• • AS9100 Rev D §8.3.6 — design and development changes
• • AS9100 Rev D §6.1.2 — risk and opportunity analysis, applied here as a gate on change approval

Audit binder and read-only inspector mode

For a date range you nominate, Qontiv assembles an audit binder as an archive containing the audit-log rows and the electronic-signature records for that window, a machine-readable summary, and a manifest carrying a SHA-256 for each file. It is streamed to storage as it is built and retained for seven days, so a binder is a deliberate, dated artifact rather than an indefinite copy of your records sitting somewhere.

The part auditors notice is inspector mode. You issue a time-boxed, read-only session as a link. Its duration is clamped at issue to a maximum of seven days, and the expiry is written once at creation and cannot be extended afterwards — not by an administrator, not by re-issuing against the same session. Every request re-checks the clock, so the session expires on the clock rather than on a sweep, and the token is stored only as a SHA-256 hash and carried in an HttpOnly, Secure, strictly same-site cookie. Requests to the entry point are rate-limited.

An inspector holds a dedicated thirteenth role that sits outside the twelve operational roles and outside every composite role group, so it cannot be swept into a permission set by accident. It grants read access to exactly two things: the audit log and its row count. No mutation in the product carries the role, and that is enforced by an architecture test that fails the build if one ever does — not by a code-review convention. Personally identifying values in audit entries — email addresses, phone numbers, street addresses — are redacted at query time for inspector sessions, while the acting user and the timestamp are always preserved, because those are the two fields the audit is actually about. Every page the inspector opens writes an immutable activity record attributed to the session, the named inspector, and their organization.

• • AS9100 Rev D §7.5.3 — control of documented information, including access
• • 21 CFR Part 11 §11.10(e) / §11.10(d) — audit trail, and limiting system access to authorized individuals

SSO certificate handling — stated precisely

On the Qontiv side of a SAML federation, each identity provider gets its own self-signed RSA-2048 service-provider certificate generated inside the product, valid for five years. The PEM is disclosed to your administrator once at generation, stored encrypted at rest, and regenerable from the admin console when your security policy calls for it.

On your side, Qontiv discovers your identity provider's signing certificate from its metadata URL and caches it. When a signature check fails against the cached copy, the cache entry is dropped and the certificate is re-fetched on the next attempt — so a certificate you rotate is picked up without a restart and without a configuration change on our side. To be exact about what that is not: there is no overlap window, no dual-certificate acceptance, and no certificate-expiry monitoring or alerting. A login in flight at the moment of a rotation fails and the next one succeeds. If your IdP rotation procedure needs a maintenance window, plan for one.

• • AS9100 Rev D §7.5.3 — controlled access to documented information
• • SAML 2.0 + OIDC — with SCIM provisioning, on the Enterprise tier