To get an evidence package through a regulator, OEM or technical service, review it against the reviewer’s own checklist before they do. For an FDA 510(k), every checklist item must be either present or backed by a written rationale for leaving it out. Every finding you raise should be closed with proof that the fix worked, not with a deadline. Have someone outside the team that wrote the package run the review, because UL 4600 requires conformance checks by someone other than the developer, and SR 11-7 ties effective challenge to separation from development. In GxP inspection readiness, a common mistake is treating preparation as a short-term project shortly before the audit.

That is why we treat approval-grade evidence as an engineering output in its own right. It is not a policy document or a marketing artefact: it is something a non-engineer (an auditor, a compliance owner, a model-risk committee) can read, defend and sign against.

How do we run an independent readiness review against the reviewer’s actual checklist?

Run the review on the reviewer’s criteria, not your own. The FDA, for example, decides whether to accept a 510(k) submission using objective criteria from a published acceptance checklist. TI Automotive expects suppliers to reference the AIAG PPAP manual and submit using its own checklist. The steps, in order:

1. Get the checklist the reviewer will actually use. For PPAP that means the customer’s checklist and any OEM-specific format it passes down. For a medical device file it means the acceptance checklist for that submission type.
2. Give every line a status: present, not applicable with a reason, or missing. The FDA does not treat an item as present unless the submission includes either the information or a reason for leaving it out. A blank is not a statement: a blank prior-submissions section is not read as “there were none”. In one supplier’s PPAP rules, a single blank field on the Part Submission Warrant gets the whole submission rejected automatically.
3. Check completeness and adequacy as two separate passes. The FDA’s acceptance review only checks whether the required elements are there. Whether they are good enough is judged later, in substantive review. A readiness review should do both, and should label which findings are about completeness and which are about adequacy.
4. Trace records from end to end instead of sampling them one at a time. Internal auditors should work the way an inspector does: ask for evidence rather than assurances, and follow records all the way through. Tracing two or three batches from raw material release to the final record finds procedural gaps that document checks miss.
5. Use a reviewer who is independent of the authors. Under SR 11-7, effective challenge depends on incentives, competence and influence, and the incentive is stronger when the challenger is further removed from development. UL 4600 requires conformance checks to be done by someone other than the developer of the item being checked.
6. Close findings with proof that the fix worked. Inspectors often pick five closed CAPAs and follow the audit trail to confirm that each fix actually solved the problem.
7. Write down whatever is still open. Under UL 4600, anything that is not documented and provided to the assessor cannot count towards conformance, even if a verbal explanation sounds reasonable.

The step that matters most is the independent reviewer. A review run by the team that built the package mostly confirms what that team already believes, and it is least likely to catch an assumption the authors never questioned.

Closing gaps before PPAP, a GxP inspection or a homologation review

Pre-submission remediation looks different in each regime, so the three cases are answered separately. In each, an open gap belongs in the regime’s formal disclosure route and a closed gap needs evidence behind it.

Can a subcontractor be included in PPAP while their process capability is still being built?

Yes, but only under interim approval. In Tenneco’s 2025 supplier guidelines, a PPAP with open deviations or out-of-specification dimensions that need engineering review can only receive interim approval. Interim approval permits shipment for a limited time or quantity. If the reason is a supplier PPAP issue, the supplier must put containment in place so that only acceptable material ships, and must agree an action plan with the customer. TI Automotive’s guideline adds that interim approvals are valid for defined timescales, batches or quantities. The customer states what full approval will require, and the interim is managed through a deviation process. A request for interim approval should be clearly marked as such on the Part Submission Warrant, with the deficiencies listed, a clear action plan and a resubmission date.

Sign-off is split. The supplier authorises the Part Submission Warrant as the summary of everything in the package. The customer’s representative then signs to accept it, and that signature means only that the package was accepted. The supplier remains responsible for whether its content is accurate. Inside your own organisation, we would keep the person who accepts the interim risk separate from the person who later confirms full qualification. If one person holds both decisions, an interim that was meant to be temporary can quietly become permanent.

The timeline depends on the size of the capability gap. What you can do is set a measurable exit criterion. One supplier assessment template checks process capability on every special characteristic against a 1.67 Cpk target and a 1.33 minimum. Characteristics below the minimum need a corrective action plan and extra controls until they reach it. We would tie the remediation milestone to that number rather than to “process matured”. When the corrective action is in place, the supplier re-submits PPAP. A good resubmission states why it is being resubmitted, what the earlier gaps were, what corrective action was taken and what the updated results show.

Can we run a mock inspection against MHRA data integrity guidance before an FDA visit?

Yes: mock inspections remain one of the most effective ways to find weaknesses before regulators do. A mock inspection is a structured internal walkthrough that simulates a regulatory visit, including document requests and staff interviews, so that gaps show up while there is still time to fix them. Run it under conditions as close to the real thing as you can: document retrieval exercises, facility walkthroughs, interviews, deviation and CAPA reviews, data integrity assessment and traceability checks. A sensible starting point is an internal GxP audit against the MHRA’s latest guidance, focused on the areas cited most often: CAPA, change control and data integrity.

Data integrity deserves particular attention. According to one MHRA inspection preparation guide, between 2016 and 2023, data integrity lapses made up nearly 40% of all critical and major GMP deficiencies the MHRA reported. Typical problems were incomplete audit trails, shared credentials and undocumented reprocessing. The same themes come up on the FDA side, where incomplete or altered records, weak access controls and untraceable laboratory data appear in GMP findings year after year. We would treat the overlap as making an MHRA-based rehearsal a good proxy. It does not cover FDA-specific expectations, so we would add those to the scope rather than assume they are covered.

As for what CAPA evidence needs to be on file: inspectors now ask to be shown that a CAPA was effective, not just that a CAPA procedure exists. A common weakness is a CAPA closed without any evidence that it worked. WHO’s data integrity guideline also expects corrective action for data integrity weaknesses to be applied across every relevant system, not only where the problem was found. Under PIC/S guidance, self-inspection is where you check periodically that data integrity controls are working as intended.

We would have someone outside the organisation test the self-assessment. In a consultant-run mock inspection, the consultant plays the investigator: requesting documents, touring the site and interviewing your subject experts as an inspector would. We would not rely on self-certification alone, and would back it with rigorous CAPA closure evidence.

Who can review a homologation dossier before the technical service sees it?

Use an independent functional-safety assessor and run the review as a formal assessment rather than a read-through. An independent functional safety assessment provides evidence that someone other than the project made a judgement on whether functional safety was achieved. Under ISO 26262, a confirmation review checks a work product’s correctness, completeness, consistency, adequacy and contents against the standard’s requirements. ABB’s IEC 61508 assessment practice reports one of three results: acceptance, qualified acceptance with remedial action due within a set period, or rejection. We would welcome a qualified acceptance before submission, because it gives you a list of what to fix.

This page gives no figures for a homologation consultant’s fees or turnaround. Some gaps are checkable, though. In FDA acceptance review, descriptive information must be consistent across the submission. The FDA suggests listing earlier feedback and stating where in the new submission it has been addressed. Inconsistent descriptions, unanswered feedback and unexplained omissions are cheap to find in advance, so a pre-review should find them first. An independent review does not remove the risk of a technical service raising something unexpected.

Checking the whole dossier for consistency, not a sample

An automated check over a structured dossier’s links, re-run on each revision, catches inconsistencies for the change types it can check. Pair that check with a separate internal QA sign-off that decides whether a vendor’s package can go into the audit file.

TechnoLynx builds this kind of checker as an engineering engagement for automotive and manufacturing teams. We agree with your team what counts as a cross-reference, a completeness criterion and a safety-relevance weighting. We then build the graph analysis over the full safety case, including incremental re-runs for revised chapters, and validate it against dossiers seeded with known broken references and gaps.

Is there a tool that can scan the whole dossier for broken cross-references?

Yes, provided the dossier is structured enough for a tool to follow its links. In model-based assurance cases, research tooling can validate the whole case from a single point. It follows each claim’s cited artefacts, runs the validation rules attached to them and flags the elements that fail. Checkable safety cases go further: deleting a requirement raises a broken-link warning, adding a hazard flags the missing argument, and changing a trace relationship tests whether the argument structure still holds. Where references are informal, as in unstructured text, these checks are often done by hand. If a dossier is a set of word-processor files with manual references, we would first extract the links into a graph.

We would rank discrepancies by safety relevance only as far as the criticality metadata allows. When an ASIL attribute changes, checks can test whether the ASIL decomposition is still correct and tell the engineer what kind of recovery is needed. If ASIL or criticality is missing or unlinked in the graph, the ranking falls back to guesswork.

Targeted checks flag only the elements a change actually affects. FASTEN.Safe, for instance, raises warnings only for specific kinds of change that affect specific claims. Evaluation can run at regular intervals so that changes to models and artefacts do not silently invalidate the assurance case. That matters because evidence goes stale whenever the system specification changes. The limit: automated consistency checks only work for certain types of change, depending on how far the claims and work products can be formalised. If revisions are not tracked precisely, incremental re-runs cannot be trusted and a full re-scan is the safer choice.

What should our internal QA checklist for accepting a vendor’s IEC 62304 deliverables contain?

We would take the clause-level items from the standard itself. Your QA team should build that list from its own copy of IEC 62304 and keep it under document control, rather than relying on a second-hand summary. Neighbouring guidance sets related acceptance expectations:

• Design and test evidence from the vendor. SR 11-7 says banks should require model vendors to provide developmental evidence on design and intended use, testing results, and a clear statement of limitations.
• No sole reliance on the vendor’s qualification package. PIC/S guidance says companies should not rely only on vendor qualification packages, and should add their own tests of data integrity under intended use.
• Original data behind summary reports. Summary reports often leave out critical supporting data and metadata, so reviewers should not rely on them alone. Summaries should come with a signed declaration of authenticity and accuracy.
• On-site checking where the risk justifies it. PIC/S considers a desk-top assessment generally not enough to establish a supplier’s data integrity compliance, and expects an on-site audit when risk makes it important.
• Version control. Under IEC 61508 documentation rules, documentation should carry revision indexes, and it should be possible to identify the latest version.

The person who signs that a vendor package is audit-ready should be one named reviewer, with authority recorded in your quality system. The reason is downstream: a supplier’s work products become part of the manufacturer’s safety argument. We treat the QA sign-off as an organisational gate, not proof of technical correctness. It should take the automated consistency report as one of its inputs.

Mapping scenario coverage to ISO 34502 before the technical service does

Map the dossier’s scenario coverage and traceability item by item to a recognised scenario-based framework, then run a consistency check across every cross-site record against that mapping. ISO 34502 provides a scenario-based safety evaluation framework for automated driving systems, applied during product development. It sets out what a critical scenario, a hazardous scenario and a risk factor are. It conforms to SOTIF (ISO 21448), treats functional safety and SOTIF as complementary, and adds a process for identifying risk factors and critical scenarios. ISO 34502 describes a safety evaluation process, not a package format. Using it to lay out the evidence is a choice that makes the package easier for a reviewer to read.

The mapping has three layers. We would trace each risk factor to the critical scenarios that contain it, and each scenario to its test evidence. ASAM’s OpenTestSpecification requirements call for traceability from requirements through functional, abstract, logical and concrete scenario levels to the test specification, and back again. Test cases should link to requirements, with traceability information carried through to test reports. Testing artefacts should be tagged against the ODD description, and KPIs should be defined to measure the ODD coverage achieved. For ODD definition itself, coverage research points to ISO 34503, with the matching tags in ISO 34504. If the reviewer also cites another taxonomy, such as PAS 1883, we would run the same mapping against it.

Coverage metrics expose the gaps. Researchers proposing coverage metrics for type-approval scenario databases separate two questions: whether the collected scenarios cover all relevant parts of the ODD, and whether they cover what is actually in the driving data. Both metrics can show missing data or scenarios that the safety assessment should consider. The same authors note that 100% coverage is not always practical or necessary, and that suitable thresholds are still future work. We would plan to argue your thresholds rather than cite them.

Will the technical service accept your cross-site format? We would make the format consistent across sites. ASAM requires test specifications to be exchangeable between organisations in standardised formats, and asks for test procedures and results to share the same structure to support review. Specifications should state requirement baselines and the exact versions of the system under test, test cases and reports. Assessment relies on the assessor’s judgement and competence. Our guide to turning SOTIF scenario testing into audit-ready evidence covers how the scenario test evidence itself is built.

Disclosing a coverage gap so it reads as managed risk

Disclose each uncovered or low-confidence span formally, in writing, with its own risk rationale, an owner and a remediation date. UL 4600 disregards any part of a safety case that is not documented and provided to the assessor. SR 11-7 says that when validation cannot be done before use, that fact should be documented and reported, and the uncertainty offset with compensating controls. Where banks cannot use key validation tools such as back-testing, senior management should be fully informed of the model’s limitations.

What the disclosure contains depends on the kind of gap:

Kind of gap	What the disclosure contains
Item inapplicable to this product	A documented argument that it is fundamentally inapplicable. UL 4600 allows deviation from REQUIRED elements only on that basis.
Best practice deliberately not followed	An explicit note with a technical rationale. UL 4600 accepts omissions of HIGHLY RECOMMENDED elements when they are noted with an acceptable rationale.
Evidence found insufficient in an assessment (qualified acceptance or rejection)	A corrective action plan with a completion date. ABB’s assessment practice requires the project’s lead engineer to provide one, with an agreed date.
Open deviation at a supplier approval	Containment plus an agreed action plan, under interim approval.

Each deviation should trace to the specific element it covers. UL 4600 allows one justification to cover several elements only if the traceability to each one is documented. To find low-confidence spans before the reviewer does, we would look for defeaters. Defeaters are factors that weaken or invalidate a safety claim. Evidence validity defeaters attack the factual basis of an assurance case. Overlooked implicit assumptions in assurance cases are one route to false confidence.

Review regimes have formal routes for evidence that is not yet complete. ISO 26262 assessment reports may recommend conditional acceptance with the corrective actions required. Assessments can result in qualified acceptance. PPAP has interim approval. A remediation plan with no credible timeline or named owner is likely to read as a compliance failure, whatever route you use.

Borrowing SR 11-7 when your industry has no model-governance standard

A non-bank such as a utility can use SR 11-7 as a governance template, presented as a voluntary, recognised framework and not as an obligation. Its core elements (independent validation, ongoing monitoring, documentation, inventory) do not depend on banking. TechnoLynx’s AI Governance and Trust work builds governance evidence packs aligned to named published rubrics, a model-risk inventory and approval workflow, and lineage for production decisions. We build it as engineering, not as policy advice or certification.

The parts that carry over are clear in the text. SR 11-7 defines model validation as checking that models perform as expected against their design objectives and business uses. An effective validation framework has three core elements: conceptual soundness, ongoing monitoring and outcomes analysis. Ongoing monitoring confirms that the model is implemented and performing as intended, and checks whether changed conditions call for adjustment or replacement. The framework expects detailed documentation, including an inventory of models in use, validation results, and model issues with their resolution. Documentation should be detailed enough that someone unfamiliar with a model can understand how it works, what its limitations are and what it assumes.

If your rate-case body names no model-governance standard, we would cite SR 11-7 to give the commission an external yardstick. That is stronger than an internal policy nobody outside has seen. Change the terminology to fit (“rate-case commission” in place of “supervisor”) and explain the mapping element by element, because a commission may push back on a banking framework that is applied without justification. With voluntary adoption, we would keep the rigour up internally. SR 11-7’s own expectation that internal audit verifies policy compliance and validation records is a good model for that. Our piece on building an audit-ready model documentation and approval package covers the documentation side in more depth.

Who can independently check our evidence package before it is submitted?

TechnoLynx builds the engineering behind a package that has to pass review: automated consistency and completeness checks over the dossier graph, traceability from requirements and scenarios to evidence, and governance evidence that a non-engineer can sign against. On whether to build in-house or bring in a specialist: we would build in-house if you already have structured artefacts and someone independent of the authors to run the checks. Bring in a specialist if the dossier has to be turned into something a machine can check, or if no internal reviewer is far enough removed from the work. When choosing a partner, ask how they validate a checker before trusting it (seeded defects, known dossiers) and whether they will tell you what it cannot catch. Governance evidence sits under AI Governance and Trust.

This work does not suit everyone. TechnoLynx is not a technical service, notified body or certification body, and it does not sign off homologation, PPAP or GxP compliance. For a formal pre-submission assessment, we would go to an accredited functional-safety assessor. For supplier qualification, we would use your supplier-quality function. For a GxP mock inspection, we would use auditors who have inspected under that regime. If your packages are small and your quality function can staff an independent internal review, doing it in-house is a reasonable choice.

Readiness that holds between submissions

The harder discipline is keeping the package ready after it has passed. Changes to the item after confirmation measures are complete mean those measures must be repeated or supplemented. UL 4600 expects conformance to be re-evaluated on an ongoing basis. Guidance on GxP inspection readiness describes the same thing as a continuous state: audit trails reviewed as routine work and CAPAs closed on evidence, not a sprint before each inspection. If you are deciding where to start, we would start at the checks that re-run automatically on change.

FAQ

What does audit ready mean?

One GxP readiness guide defines inspection readiness as being able to withstand a regulatory inspection at any time, without warning and without a scramble to pull records together. Quality systems, documentation and people meet the regulator’s standard as part of daily operation.

What are the principles of data integrity?

GxP guidance expects records to be ALCOA+: attributable, legible, contemporaneous, original and accurate, plus complete, consistent, enduring and available.

What does safety assessment mean?

Under ISO 26262, a functional safety assessment judges whether the item has achieved functional safety. A functional safety audit is different: it examines whether the required processes have been implemented. Assessment relies heavily on the assessor’s judgement and competence.