{
 "slug": "aviation-correction-chain",
 "topic_id": "TOPIC-136",
 "cluster": "Aviation, MRO & Aerospace Airworthiness Identity",
 "tier": "Tier A",
 "title": "The FAA expanded its falsification rule in 2026. What that means for digital maintenance records.",
 "summary": "In a paper logbook a correction is a line-out with initials — visibly a correction. In a database a correction is an UPDATE. Whether it was honest depends on an audit trail the operator controls.",
 "lede": "Here is a question with an uncomfortable answer. If you corrected a maintenance record last month, could you prove to a stranger that it was a correction and not a cover-up? In a paper logbook, yes — the original entry is still there, struck through, initialled and dated. In your maintenance information system, probably not.",
 "date": "2025-12-22",
 "category": "Vertical",
 "author_id": "priya-venkatraman",
 "tags": [
  "43.12",
  "falsification",
  "maintenance records",
  "tamper evidence",
  "MRO",
  "aviation compliance"
 ],
 "image": "https://cdn.twc.sh/images/igcache/Aviation%20Correction%20Chain/1200_630/blog.jpg",
 "schema": "Article",
 "key_takeaways": [
  "Paper made corrections visible by accident. Databases store current state, and the history lives in an audit table that an administrator can modify.",
  "A correction chain links the original entry, the correction and the reason — each individually signed — so the difference between fixing and hiding is visible without database access.",
  "The FAA's February 2026 final rule consolidated and expanded falsification provisions, which raises the value of being able to demonstrate the difference."
 ],
 "body": [
  {
   "type": "h2",
   "text": "Think about how paper worked"
  },
  {
   "type": "diagram",
   "kind": "compare",
   "alt": "The same correction, two media",
   "caption": "Paper makes the correction part of the record. A database makes it invisible unless something outside preserves it.",
   "nodes": [],
   "left": {
    "title": "Paper logbook",
    "items": [
     "Line-out, initials, date",
     "Original still legible",
     "Correction is visibly a correction",
     "Tamper leaves marks"
    ]
   },
   "right": {
    "title": "Maintenance database",
    "items": [
     "UPDATE statement",
     "Prior value in an audit table",
     "Correction indistinguishable from entry",
     "Audit table is operator-controlled"
    ]
   }
  },
  {
   "type": "p",
   "html": "Imagine a mechanic in 1994 realises she wrote the wrong total time in service. She draws a single line through the figure, writes the correct one beside it, initials and dates the change. The original is still legible. Anyone reading the logbook in 2031 sees exactly what happened."
  },
  {
   "type": "p",
   "html": "That is tamper evidence, and nobody designed it. It fell out of the physical properties of ink and paper. You cannot un-write a line, so the only available correction is an additive one."
  },
  {
   "type": "p",
   "html": "Now imagine the same correction in a maintenance information system. She opens the record, changes the value, saves. The record shows the correct figure. The original is in an audit table, if the system keeps one, and that table is a database object like any other."
  },
  {
   "type": "h2",
   "text": "Why this matters more after February 2026"
  },
  {
   "type": "p",
   "html": "The FAA issued a final rule in February 2026 consolidating and expanding its falsification scheme, covering applications, records and other documents. §43.12 already made a fraudulent or intentionally false maintenance entry a basis for certificate action. The 2026 rulemaking tightened and broadened the framework around it."
  },
  {
   "type": "p",
   "html": "So the consequence of a record being characterised as falsified went up, while the ability to demonstrate that a change was an honest correction stayed exactly where it was."
  },
  {
   "type": "h2",
   "text": "The three things a database cannot show you"
  },
  {
   "type": "table",
   "head": [
    "What you need to show",
    "What the system gives you",
    "The gap"
   ],
   "rows": [
    [
     "The original entry",
     "A row in an audit table",
     "Written and modifiable by the same system"
    ],
    [
     "That the change was made by a person, deliberately",
     "A user id and timestamp",
     "Session-attributed; no proof of presence"
    ],
    [
     "Why the change was made",
     "A free-text comment, if the field exists",
     "Unstructured, unbound, and editable"
    ]
   ]
  },
  {
   "type": "p",
   "html": "Vendors describe audit tables as tamper-evident. That is true against casual editing through the application. It is not true against anyone with database privileges, which includes your own administrators and anyone who obtains their credentials."
  },
  {
   "type": "h2",
   "text": "The correction chain"
  },
  {
   "type": "p",
   "html": "The fix borrows directly from what paper did accidentally: make corrections additive and make each link individually signed."
  },
  {
   "type": "ol",
   "items": [
    "<strong style=\"font-weight:600\">Original receipt.</strong> When the entry is first made, it is signed. That produces a hash of the original content that exists independently of your database.",
    "<strong style=\"font-weight:600\">Correction receipt.</strong> The correction references the original receipt by hash, states the new content, and is signed by the person making it.",
    "<strong style=\"font-weight:600\">Reason statement.</strong> The reason is part of the signed object, not a comment field, so it becomes immutable at the moment of signing."
   ]
  },
  {
   "type": "p",
   "html": "An inspector reading the chain sees the original, the correction, who made each, when, and why — without access to your system and without trusting your administrators. That is the paper property, restored."
  },
  {
   "type": "h2",
   "text": "A worked example"
  },
  {
   "type": "code",
   "text": "receipt_1  entry       hash a3f9...  \"Total time in service: 14,203.2 hrs\"\n                                    signed by [tech A], cert [number]\n\nreceipt_2  correction  references a3f9...\n                       \"Total time in service: 14,230.2 hrs\"\n                       reason: \"transposition error identified during\n                                closeout review of work package [id]\"\n                       signed by [tech A], cert [number]"
  },
  {
   "type": "p",
   "html": "Note that the corrector signs, and the reason is inside the signature. Neither can be adjusted later without producing a third receipt, which would itself be visible."
  },
  {
   "type": "h2",
   "text": "What this does not claim"
  },
  {
   "type": "p",
   "html": "It does not prevent someone entering a false value in the first place and signing it. Cryptography cannot tell you whether a number is true; it can only tell you who asserted it and whether the assertion changed afterwards."
  },
  {
   "type": "p",
   "html": "What it removes is the ambiguity that currently surrounds every correction. Today, an operator with a legitimate correction and an operator concealing an error produce indistinguishable database states. That ambiguity does not help the honest operator, and after February 2026 it costs them more than it used to."
  },
  {
   "type": "h2",
   "text": "Where to start"
  },
  {
   "type": "ol",
   "items": [
    "Count corrections. Pull the last twelve months of record modifications from your maintenance system and count how many touched an entry after the aircraft returned to service.",
    "Sample five and try to reconstruct the original value, the person and the reason from the record alone.",
    "If reconstruction requires a database query or a vendor support ticket, your correction history is not self-describing.",
    "Apply the chain to return-to-service entries first. They are the smallest set with the largest consequence."
   ]
  },
  {
   "type": "h2",
   "text": "What an honest correction chain contains"
  },
  {
   "type": "table",
   "caption": "Five elements, and which systems usually keep",
   "head": [
    "Element",
    "Usually kept?"
   ],
   "rows": [
    [
     "Prior value",
     "Often, in an audit table"
    ],
    [
     "New value",
     "Yes"
    ],
    [
     "Who made the change",
     "An account"
    ],
    [
     "Why",
     "Rarely — free text if at all"
    ],
    [
     "<strong style=\"font-weight:600\">A signature over both states</strong>",
     "<strong style=\"font-weight:600\">No</strong>"
    ]
   ]
  },
  {
   "type": "p",
   "html": "The last row is what converts an audit table into evidence. Without it, the record of a correction is written by the same system that made the correction, which is the weakest thing an investigator can be handed."
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Our audit trail is immutable.”</strong> Within the system. The question an investigator asks is who could write to it, and the honest answer includes administrators and integrations."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Corrections are rare and reviewed.”</strong> Then signing them is cheap. Rarity is an argument for binding them, not against."
  }
 ],
 "faq": [
  {
   "q": "Is our audit table not already tamper-evident?",
   "a": "It is evident against application-level editing. It is not evident against anyone with database access, and the audit table is written by the same system that wrote the record."
  },
  {
   "q": "Do we have to sign every entry to have a correction chain?",
   "a": "You need the original signed to reference it by hash. If only corrections are signed, the chain has no anchor. Starting with return-to-service entries gives you a meaningful anchor set without instrumenting everything."
  },
  {
   "q": "What if the person who made the original entry has left?",
   "a": "The correction is signed by whoever makes it, and the chain records that the corrector differs from the original signer. That is information an inspector wants, not a problem."
  },
  {
   "q": "Does this satisfy the FAA?",
   "a": "No artefact satisfies a regulator by itself. It gives you the ability to demonstrate the difference between correction and falsification, which is the factual question underneath the rule."
  },
  {
   "q": "Why is a database correction harder to audit than paper?",
   "a": "On paper a correction is visibly a correction. In a database it is an UPDATE, and the evidence of what changed sits in a table the operator controls."
  },
  {
   "q": "What should a correction record contain?",
   "a": "Prior value, new value, who, why as structured data, and a signature covering both states."
  },
  {
   "q": "How long must it survive?",
   "a": "For the life of the aircraft, which typically exceeds the life of the maintenance system that holds it."
  }
 ],
 "sources": [
  {
   "t": "Federal Aviation Administration regulations and policies",
   "u": "https://www.faa.gov/regulations_policies"
  },
  {
   "t": "14 CFR §43.12 — maintenance records: falsification, reproduction or alteration."
  },
  {
   "t": "Federal Rule of Evidence 902 — Evidence That Is Self-Authenticating",
   "u": "https://www.law.cornell.edu/rules/fre/rule_902"
  },
  {
   "t": "FAA — Advisory Circulars",
   "u": "https://www.faa.gov/regulations_policies/advisory_circulars"
  }
 ],
 "related": [
  {
   "slug": "rts-signature-uniqueness-test",
   "title": "Unique to one individual",
   "category": "Vertical"
  },
  {
   "slug": "signatory-authority-attestation",
   "title": "Third-country repair stations",
   "category": "Vertical"
  },
  {
   "slug": "oos-invalidation-receipt",
   "title": "Invalidating an out-of-specification result",
   "category": "Developer"
  }
 ],
 "wordcount": 1084,
 "url": "/blog/aviation-correction-chain.html",
 "reading_time": "5 min read",
 "image_title": "Aviation Correction Chain",
 "seo_title": "FAA falsification rule and digital maintenance records",
 "meta_description": "In a paper logbook a correction is a line-out with initials. In a database a correction is an UPDATE, and honesty rests on an audit trail.",
 "hub": {
  "slug": "topics/airworthiness-identity",
  "title": "Aviation and airworthiness identity"
 },
 "answer": "A correction stops being visible. In a paper logbook a correction is a line-out with initials — obviously a correction. In a database it is an UPDATE, and whether it was honest depends entirely on an audit trail the operator controls. The FAA's expanded falsification provisions raise the stakes on that difference.",
 "answer_q": "What changes when a maintenance logbook becomes a database?",
 "glossary": [
  {
   "term": "Falsification",
   "def": "Making or causing a false entry in a required record. The FAA's provisions were consolidated and expanded in a 2026 final rule."
  },
  {
   "term": "Correction chain",
   "def": "The linked history of a record's values, with who changed each and why."
  },
  {
   "term": "Required record",
   "def": "A record a regulation obliges an operator to keep, which brings falsification provisions into play."
  }
 ],
 "checklist": {
  "title": "Making corrections evidential",
  "id": "corrections",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Sign the prior and new state together.",
    "text": "One statement containing both, with a reason."
   },
   {
    "name": "Require a reason, as structured data.",
    "text": "Not free text that nobody reads."
   },
   {
    "name": "Bind to the specific record and aircraft.",
    "text": "So a correction cannot be reattributed later."
   },
   {
    "name": "Retain for the life of the aircraft.",
    "text": "Which is longer than the life of most systems."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav binds an airworthiness or operational signature to the exact record it certifies, on a credential under one individual's sole control, and produces a receipt an auditor or a regulator can verify years later without access to the operator's systems.",
  "href": "../docs.html",
  "label": "See signature binding"
 }
}