Register design
Discrepancy-register structure checklist
This checklist sets up a discrepancy register so each finding carries what closure needs, namely a clear statement, the source document, a severity, the responsible party, and the evidence that will close it. Use it before logging findings on a transaction or audit so the register holds up later. You finish with a register field schema, a severity and ownership scheme, and a worked example finding.
When this review is needed
- Findings are about to be logged on an audit or transaction and the register has no agreed structure.
- An existing register has stalled because items lack an owner or a closure definition.
- Multiple parties are working the same findings and need a shared field set.
- A register built ad hoc has grown unsearchable and needs a defined schema before it grows further.
The problem
A register that started as a quick spreadsheet ages badly. Each item gets logged with the issue and the proposed fix jammed into one cell, severity is applied by whoever typed it, items sit open with no named owner, and closed lines carry a resolved flag with no record of what closed them. Months later nobody can defend it, and the same finding gets re-litigated because the evidence was never captured.
What gets reviewed
- A clear finding statement separating the issue from the proposed fix
- The source document and the record area each finding sits in
- A severity scheme tied to transaction or airworthiness exposure
- The responsible party and the closure evidence required
- Status fields that show where each item is in its lifecycle
- A unique identifier per finding that survives sorting and merging
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
- Every finding names the specific source document it came from
- Severity is assigned on a defined scale, not left to free text
- Each finding has one accountable owner, not a shared placeholder
- Closure is defined as the evidence required, not a generic resolved flag
- Each finding keeps a stable identifier so it can be tracked across versions
Evidence normally required
- The findings or raw notes to be logged
- The transaction or audit context that sets severity
- The parties available to own and close items
- Any existing register the new structure has to absorb
- The record areas the findings span across the engagement
Common discrepancies
- Findings that mix the issue and the proposed fix into one unsearchable line
- A severity field used inconsistently so triage cannot trust it
- Items with no named owner that sit open by default
- A closed status with no record of the evidence that closed it
- Duplicate entries for one finding because there was no stable identifier
What is at stake
An undefendable register loses arguments. On a transaction a buyer reopens items the register cannot prove were closed; on an audit a closed flag with no evidence is treated as open. A defined schema set before findings are logged keeps the register usable for the life of the engagement.
How the work runs
Define the fields
Set the columns a finding needs, with the issue separated from the proposed fix and a stable identifier per item.
Set severity and ownership
Define a severity scale tied to exposure and require one accountable owner per finding.
Define closure
Make closure mean the evidence captured, not a generic resolved flag, so closed items stay defendable.
Work an example
Apply the schema to one real finding end to end so the team logs the rest consistently.
What the buyer receives
- A register field schema with definitions for each column
- A severity and ownership scheme tied to exposure
- A worked example finding showing the schema applied end to end
Who uses the output
- Records teams logging and closing findings
- Transaction management tracking exposure to close
- Quality and compliance defending the register under audit
How the work fits into the transaction or program
The checklist designs the register that every other records review feeds. Findings from the readiness check, the source-to-status reconciliation, and a lease-return audit all land in a register built to this schema.
Regulatory limits
The checklist defines how findings are recorded and tracked. It does not make an airworthiness determination, decide whether a finding is acceptable, or substitute for the technical judgment behind each entry.
What this review does not cover
- Resolving the underlying findings themselves
- Selecting or implementing a software tool to host the register
- Any airworthiness determination on a logged finding
Specific to this review
- A register is only as useful as its closure definition; a resolved flag with no evidence reference cannot be relied on later.
- Separating the finding from the proposed fix keeps the register searchable and stops a debated fix from hiding the underlying issue.
- A stable per-finding identifier is what prevents duplicates and lets the same item be tracked as the register is sorted and merged.
Sources
U.S. Government (eCFR). Maintenance recordkeeping content and approval-for-return-to-service requirements, including 43.9, 43.11, and Appendix B.
Federal Aviation Administration. FAA guidance on making and keeping maintenance records and acceptable recordkeeping practices.
European Union / EASA. Continuing airworthiness, maintenance records, CAMO responsibilities, and the airworthiness review process in the EASA system.
Frequently asked questions
What is the single most common reason a register stalls?
Closure with no evidence. A resolved flag that does not reference the document or confirmation that closed the item cannot be defended later, so closure is defined as the evidence required from the start.
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.