SOI readiness
SOI review artifact readiness checklist
For Certification teams, Engineering teams and avionics suppliers, preparing for a stage-of-involvement review creates a need to prove sOI review artifact readiness checklist from documents rather than summary wording. The checklist follows accepted plans and transition criteria and requirements and design trace data back to source pages, then tests verification results and coverage evidence and accomplishment summary and problem report status against the claimed status. Unsupported configuration, timing, release, or task evidence is logged. The output gives the team prioritized findings, evidence references, and closure actions.
When this review is needed
- A status report is available, but the team has not confirmed the source evidence behind it.
- preparing for a stage-of-involvement review depends on closing questions about accepted plans and transition criteria.
- The file has records from multiple systems, holders, or maintenance events.
- The buyer wants blockers separated from administrative cleanup before escalation.
The problem
The hard work is not finding documents, it is proving that each document supports the exact status being claimed. Certification liaison, Software lead and Hardware lead often see tidy reports where the weak point is a missing link between accepted plans and transition criteria and verification results and coverage evidence.
What gets reviewed
- Build a working index from accepted plans and transition criteria and the documents that support it.
- The review notes that trace requirements and design trace data through the source file rather than relying on a summary reference.
- Test verification results and coverage evidence for consistency with dates, revisions, status, and installed configuration.
- Flag gaps in accomplishment summary and problem report status that affect acceptance, transfer, or submission.
- Separate blocker findings from items suitable for post-event cleanup.
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Send a representative, redacted record set and we will scope the review.
What gets validated
- Accept a claim only when the referenced page supports the exact part, task, or approval.
- Reject the item when trace data contains dangling links.
- Compare tracking exports with logbooks before treating due status as proven.
- Hold the line open if configuration evidence does not match the installed or returned item.
Evidence normally required
- accepted plans and transition criteria
- requirements and design trace data
- verification results and coverage evidence
- accomplishment summary and problem report status
Common discrepancies
- SOI entered with a plan not accepted by the authority.
- The review notes that trace data contains dangling links.
- Open problem reports lack disposition.
What is at stake
If the package is accepted without correction, the problem can return during import, redelivery, onboarding, or the next audit. That creates duplicated review effort and avoidable dispute over who owns the gap.
How the work runs
Frame Soi Readiness
Confirm the exact event, affected file set, buyer role, and decision standard before any accepted plans and transition criteria is treated as sufficient.
The review notes that trace Certification Teams
Walk the named evidence from index entry to source artifact and mark where the trail supports, conflicts with, or fails to answer the page-specific question.
Sort Artifact Artifacts
Group exceptions by closure route: document retrieval, data correction, engineering disposition, authority response, or contractual decision.
Package Must Place
Deliver the exception list, evidence map, and owner sequence in a form that can move directly into remediation, submittal cleanup, or transaction negotiation.
What the buyer receives
- Pass, fail, and reservation register for sOI readiness
- Document index marking each supporting record used
- Priority gap list with owner, item, and closure evidence
- Buyer summary separating blockers from cleanup items
Who uses the output
- Certification liaison uses the evidence map to defend accepted lines.
- Software lead uses the gap list to assign document retrieval work.
- Hardware lead uses the blocker list during handover, acceptance, or submission meetings.
How the work fits into the transaction or program
This checklist is what an applicant verifies before an FAA or EASA stage-of-involvement audit, and it names the hardest readiness items across SOI-1 through SOI-4: at SOI-1, approved plans (PSAC/PHAC and the discipline plans) and a defined transition criteria; at SOI-2, requirements and design data with bi-directional traceability populated; at SOI-3, verification results with structural-coverage and independence evidence; at SOI-4, the accomplishment summary and open problem-report disposition; the. The evidence set centers on the plans, the trace data, the verification records, and the summary. The likely weak points are entering an SOI with a plan the authority has not accepted, and offering trace data with dangling requirement links, both of which turn the audit into findings and a re-review. Handoff: certification liaison, preparing for a stage-of-involvement review, SOI review artifact readiness checklist.
Jurisdiction-specific considerations
FAA and EASA references are used as record expectations for the evidence set. The review does not assume automatic acceptance by another authority, operator, or contract party.
Regulatory limits
The work is an evidence review, not a regulatory approval or return-to-service action. Any compliance finding, airworthiness decision, or formal acceptance remains with the appropriate authority, designee, operator, or approved organization.
What this review does not cover
- Corrective maintenance, repair design, or embodied work
- Legal interpretation of contract acceptance language
- Authority liaison unless separately scoped
Specific to this review
- Readiness changes by SOI stage, so the checklist names the evidence expected at each review point.
- The review notes that trace quality is checked before the meeting because dangling links can dominate the review.
- Open problem reports are sorted by authority impact and closure path.
- The scope uses the Soi Readiness Checklist Certification question as the control point, so the review stays tied to preparing for a stage-of-involvement review and the buyer decision behind it.
- The evidence starts with accepted plans and transition criteria and follows Teams Review Artifact Artifacts references until every exception has a source location and a reason code.
- The finding logic separates missing paperwork, conflicting status, stale revision data, and unsupported disposition because each class closes through a different owner.
- The timing matters for Certification liaison: the output is useful only if the unresolved items are visible before acceptance, submittal, handback, or negotiation pressure fixes the sequence.
- The boundary control keeps Evidence Must Place Stage questions in the records or certification lane and sends technical acceptance issues to the authorized people who own them.
- The handoff value comes from Pass, fail, and reservation register for sOI readiness; it gives the next reviewer a precise map instead of another broad request for a better file.
- The source discipline is stricter on this page than on a general audit because the claim being tested is Verify readiness for an FAA or EASA stage-of-involvement review before each SOI..
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
What makes this checklists review different from a general file audit?
The scope is tied to soi readiness checklist certification and to the decision named in the request. A general audit can list weak records; this pass ranks the gaps by whether they block preparing for a stage-of-involvement review or can be closed later without changing the decision.
What evidence has to be available before this work starts?
The starting point is accepted plans and transition criteria, the current status source, and any index or matrix that tells reviewers where the supporting artifact should live. Missing inputs are logged as findings rather than filled with assumptions.
Who decides whether an open item is acceptable?
The review explains what the evidence supports and gives certification liaison a closure path. Acceptance remains with the buyer, operator, authority, delegated engineer, or authorized person responsible for the underlying airworthiness or certification decision.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Adapt the checklist to your asset, event, and jurisdiction.