Software logs can significantly reduce the time and ambiguity involved in answering audit questions about First Article Inspection Report (FAIR) changes, but only if logging is designed, configured, and governed with that purpose in mind.
What auditors typically want to know about FAIR changes
When an auditor challenges a FAIR change, they are usually probing for:
- Who changed the FAIR or related characteristics.
- What was changed (fields, values, attachments, ballooning, signatures).
- When the change occurred relative to production, approvals, and revision releases.
- Why the change was made (NCR, drawing revision, supplier change, internal error correction).
- How the change was controlled (review, approval, validation, and linkage to QMS records).
Well-implemented software logs can provide objective evidence for each of these questions.
How software logs support FAIR change traceability
In an AS9102 / FAI context, useful logs generally include:
- Authentication and identity logs: Show who was logged in under which account when changes were made. These support user attribution and separation of duties.
- Application or audit logs: Record specific actions on FAIR objects, such as creation, modification, re-submission, status changes, or record locking/unlocking.
- Configuration and master data logs: Track updates to inspection plans, characteristic libraries, drawing revisions, and routing/operation structures that feed FAIRs.
- Integration logs: Show data movement between PLM, ERP, MES, QMS, and FAI software (for example, when a drawing revision pushed from PLM resulted in a FAIR update).
When combined, these logs can answer:
- Which FAIR revision was in effect when a specific lot or serial number was produced.
- Whether a FAIR change aligned with a drawing or specification change.
- Whether a change was made before, during, or after key approvals or shipments.
- Whether changes were made inside approved workflows, or manually outside the intended process.
Examples of using logs to resolve FAIR audit questions
Typical audit scenarios where logs are useful include:
- “This characteristic was added later. How do you know the part was inspected to the current revision?”
Version and application logs can show when the characteristic was added, who added it, and which work orders or serials were associated with each FAIR revision. If your MES or traveler is integrated, you may be able to show that units produced after a certain date used the updated inspection plan.
- “Why was the FAIR resubmitted?”
Change events tied to NCR or CAPA references can show that resubmission was linked to a documented nonconformance, drawing change, or customer request, with time stamps and approver identities.
- “Who modified these results and under whose authority?”
Application logs can attribute each data change (for example, measured value edits, disposition changes) to a named account, along with the workflow step or role used to perform the edit and any associated electronic signatures.
- “Was this change done through a validated process or a backdoor?”
System administration and configuration logs can show whether a change was executed through standard UI workflows or through database-level actions or administrative overrides. The latter will typically raise questions and may need additional mitigation and documentation.
Dependencies and limitations
The usefulness of software logs for FAIR-related audits is not automatic. It depends heavily on:
- Logging design and configuration: Many systems offer configurable logging levels. If FAIR-related events are not explicitly logged (for example, field-level changes to characteristics or balloon numbers), you may not have the detail you expect.
- Identity management and access control: Shared accounts, generic logins (for example, “INSPECTOR1”), or poor role design reduce the evidentiary value of logs because you cannot reliably connect actions to individuals or qualified roles.
- Time synchronization: Systems involved in FAI, MES, PLM, and ERP should have synchronized clocks. Without this, constructing a reliable timeline across systems is difficult and may be challenged by auditors.
- Data retention policies: Logs must be retained at least as long as FAIR and production records are required. If logs are purged or rolled over aggressively to save storage, older FAIR changes may be impossible to reconstruct.
- Validation status: In regulated environments, the way logging is configured and used can be in scope for system validation. If you rely on logs as part of your control evidence, the configuration and change control around logging itself often needs to be documented and validated.
- Integration quality: If FAIR data lives in one system while drawing revisions and work orders live in others, incomplete or unreliable integrations can create gaps. Logs may show that an integration call succeeded, but not that the payload matched the engineering intent.
Brownfield and coexistence considerations
In most plants, FAIRs are created and managed across multiple systems: PLM for drawings, ERP for part and revision data, MES or travelers for operations, QMS for NCR/CAPA, and dedicated FAI software or shared quality tools. Full replacement of these systems is rarely practical due to validation effort, downtime risk, and complex integrations.
As a result, audit questions about FAIR changes often require correlating logs from several sources:
- PLM / CAD / PDM: When and how a drawing revision was released.
- FAI / quality system: When the FAIR was created, modified, or resubmitted, by whom, and which revision it references.
- MES or digital traveler: Which FAIR revision or inspection plan was associated with each order, lot, or serial.
- ERP: Shipment dates, customer IDs, and batch/lot associations.
Because these systems often come from different vendors and eras, you cannot assume a unified audit trail. In practice, resolving FAIR-related audit questions often involves:
- Defining which system is the record of truth for each element (drawing, FAIR, traveler, NCR, approval).
- Ensuring each system’s logs are accessible, time-synchronized, and retained.
- Documenting cross-references (for example, FAIR ID stored on the work order, NCR number stored on the FAIR record).
- Training staff to retrieve and interpret logs consistently during audits.
Practical steps to make logs audit-useful for FAIR changes
To increase the value of logs for FAIR questions:
- Map required evidence to events: Start from typical AS9102 and AS9100 audit questions and translate them into specific system events and fields that must be logged (for example, “FAIR approval,” “drawing revision link updated,” “measurement value edited,” “characteristic added/removed”).
- Enable and test detailed logging in the FAI tool: Verify that creating, editing, and reissuing FAIRs generates clear, searchable audit events. Confirm that characteristic-level and attachment changes are captured where needed.
- Align FAIR logs with QMS records: Where changes are driven by NCRs, ECNs, or CAPAs, require that these references be captured as fields or links in the FAIR record so you can bridge from FAIR logs to QMS logs.
- Harden identity and access management: Eliminate shared generic accounts used for FAIR activities. Ensure inspectors, engineers, and approvers use unique, authenticated identities with appropriate roles.
- Define log retention and access procedures: Set retention durations consistent with customer and regulatory requirements for FAIR and production records. Define who can access logs, how queries are documented, and how extracts are preserved for audit packages.
- Include logging in change control: Treat changes to logging configuration (for example, disabling detailed logs for performance) as controlled changes, evaluated for their impact on auditability and compliance.
Using logs during an actual audit
In an audit setting, logs are most effective when you can present them in a structured, traceable way rather than as raw dumps. A typical approach is to:
- Clarify the auditor’s question (for example, which part, lot, and time period).
- Identify the relevant FAIR revision and its associated work orders or serials.
- Extract a chronological view of FAIR-related events from the FAI software logs.
- Overlay key PLM, MES, ERP, and QMS events (drawing release, NCR, CAPA, shipment) using time stamps and IDs.
- Summarize the timeline in plain language, with log extracts or screenshots as supporting evidence.
This approach respects the reality of multi-system environments while still using logs to provide a defendable, time-stamped narrative for FAIR changes.
Key takeaway
Software logs do not automatically guarantee clean outcomes in FAIR audits, but when they are intentionally designed, validated, and governed around AS9102 workflows, they can provide concrete answers to who changed what, when, why, and under which controls. The main work is not enabling logging, but making sure it aligns with your FAIR process, spans all relevant systems, and is maintained under robust change control.
