Offwing: FAA 8130 certificates on AT Proto

Introduction

Offwing is a proof-of-concept demonstration of how the AT Protocol can be used to solve interesting problems beyond social media apps.

The Offwing feed, listing release certificates as repair stations issue and accept them, each with its part and serial number

For background, I work in machine learning and data for a major US airline, leading multiple technical initiatives around aircraft maintenance and AI. This project is a kind of “worlds collide” concept, where I’ve taken two fairly niche topics and combined them into one interesting idea. In fact, I’m not sure how many people would be very familiar with either topic, let alone both. So, I’ll start by briefly explaining each part individually before discussing the application.

Parts tracking in aviation

To start: when an aircraft receives maintenance, the result often involves replacing certain parts. If any of those parts are serviceable, meaning they can be repaired and put back into service on another aircraft, they can be sent out for repair. Aviation regulatory authorities, like the FAA and EASA, require these parts to be tracked, both onwing and offwing, if they are ever to be installed on an aircraft again. The device for tracking these parts during the course of repair varies by regulatory authority.

For the FAA, this is accomplished through the 8130-3 certificate. When any part is not installed on an aircraft, it must have an associated 8130 document to accompany it. This is a literal paper document, traveling with the part. This is especially important when the part is sent out for repair to a third party vendor. The part is delivered in a crate, and the paper 8130 document is included in the package. Admittedly, this seems a bit out of date, but be assured that modern solutions have been in development for the last 15 years based on solid XML.

A blank FAA Form 8130-3 Authorized Release Certificate, its fields laid out as numbered blocks

This paper-based process creates numerous challenges for the aviation industry. Managing the paper records, from receiving and inspection, to scanning and verification, is error prone and not standardized. When an operator buys or sells a serviceable part on the second hand market (i.e., used), the part must be accompanied by its full “back to birth” tracing, meaning all of its past 8130 documents. This guarantees a proper accounting of the entire history of the part’s utilization, where it has been and who has possessed it. This is important as parts have life and cycle limits, go through required modifications, and must be inspected for authenticity.

Much more consequentially, flaws in this system have been exploited for fraudulent activity, by falsifying 8130 documents and fabricating part history. There was a very significant case of this related to engine parts in recent years, which led to major carriers grounding aircraft all over the world. AOG Technics was recently prosecuted over this.

In the industry, everyone recognizes this is a flawed system in need of modernization. The challenge is that it requires the entire industry - regulators, operators, suppliers, manufacturers, and maintenance vendors - to adopt a common alternative to maintain transferability. There is one interesting vendor-led solution being piloted by some carriers, but it introduces a new problem by becoming a centralized holder of sensitive information.

AT Protocol

Enter the really interesting AT Protocol, and we now have a way to approach this problem in a very different way. I’ll leave it to many other better sources to explain the technical details of the AT Protocol, but I will describe it briefly in regard to Offwing.

For Offwing, the AT Protocol provides a way to both publish key information publicly, while respecting proprietary information, and distribute ownership across multiple parties. In this contrived app, there is a general hosted PDS instance (similar to what Bluesky offers), but it is perfectly valid for any party to host their own PDS instance. The managed PDS is at f8130.cldixon.dev. Orgs are at subdomains, e.g., northwind-turbine.f8130.cldixon.dev.

The managed PDS, holding 29 organization repositories, publishes releases to a firehose that feeds both the offwing AppView and the watchdog AppView; offwing also reads the PDS directly to verify organizations.

verify the organizations

Managed PDS: f8130.cldixon.dev
29 org repos

firehose
releases are published

offwing: Main AppView
at offwing.cldixon.dev

watchdog: AppView focused on fraud detection

How Offwing works

Now, we can turn to Offwing. The core concept of Offwing is providing a combined public and private method for releasing and verifying a published 8130 document. When a repair station prepares to return a repaired part to its owner, it completes an 8130-3 document. Today, this document would be printed and included in the part’s package. With Offwing, in addition to the returned paper document, the vendor submits the document through the app’s interface.

Once uploaded, data from the official fields are computed into a single cryptographic hash using a merkle tree. This hash, along with the fair public information from the form, such as part manufacturer and serial number, timestamp, and a few others, is published to the AT Protocol network under the repair station’s repo. See core/src/commitment.ts for cryptography details.

Interactive demo

Below is an interactive demo of Offwing’s core cryptographic process for 8130 documents. All fields in the form are computed into a single hash, which is then published to the network. You can edit any fields in the pre-filled form and modify the hash. Any changes would result in the computed hash not matching the original, published one, and would be flagged as a discrepancy.

Authorized Release CertificateFAA Form 8130-3 · Airworthiness Approval Tag
1Approving authority
3Form tracking number
4Organization
4Address
5Work order
6Item
7Description
8Part number
9Quantity
10Serial number
11Status / work
12Remarks
13/14Certifying block
13a/14aApproval basis
13c/14cApproval / certificate no.
13d/14dName
13e/14eDate
Published hash
8f6775e334ee5ec501ea919704f385b9a15fd0d97875b542223f6146bb7d5759

Matches the record published by Northwind Turbine.

Interactive demo of 8130 hashing concept.

The next stage of Offwing’s workflow occurs when the owner of the part receives the returned package from the repair station. Once received, the recipient collects the printed 8130 document, and verifies it through Offwing. The user enters the form’s fields (one could imagine this being done via scanning, computer vision, etc.), and Offwing then recomputes the hash and checks against the published records from the identified repair station. If the match fails, the recipient is alerted to either review the returned form or reach out to the repair station directly to reconcile the discrepancy. Optionally, the Offwing system provides a way for the recipients to publicly attest to the verification result on the network, which plays a role in detecting fraud and ensuring integrity over time. More on that below.

Based on how the hash generation works, verification will only result in a binary outcome: success or failure. The verification process doesn’t reveal which specific fields did not match, as this could lead to sensitive, proprietary information being exposed by malicious actors later. And, just as importantly, none of the sensitive, proprietary information in the 8130 form is included in the AT Proto record. See later note on AT Proto Spaces.

The Offwing app provides simulated examples for anyone to try these workflows themselves. AI is used in the background to generate synthetic data such as part numbers, operators, repair stations, and 8130 forms. The live feed on the homepage provides a real-time view of synthetic activity on the network if you watch for a few moments.

Impact on 8130 mechanism

The downstream implications of this system would be significant. Not only would it provide better assurance to part owners and much faster feedback loops for identifying problematic repairers, it would provide a profound view for regulators and authorities to track history, lineage, and general patterns for parts, repair stations, and operators.

Additionally, this system would support the “back to birth” tracing requirement of 8130 documents for serviceable parts. With each 8130 form having a published record including the part’s serial number, one could crawl any individual part’s record history in the network to reconstruct its repair history. In Offwing, you can click on a part number to see this very thing.

A note on AT Proto Spaces

A key aspect I had to design around in this application was how to handle information that should be private, while enabling the core public information which makes the system work. For instance, the sensitive, proprietary information included in the 8130 form, such as the customer organization, the repair remarks (detailing what was found wrong with the part), the final status (e.g., repaired, overhauled, replaced, tested), can’t be made public to the network. Additionally, the two entities represented in the app today are repair stations and operators, but another important entity missing is the regulatory organization, such as the FAA or EASA.

These are challenges to model in Offwing due to all data on the AT Proto network being public by default. However, in the time while I worked on this, the AT Proto Spaces alpha release occurred, which introduces private data into the network. I can imagine an Offwing V2 which utilizes this feature to capture the full 8130 form’s fields, including the repair remarks, etc. Additionally, the full 8130 record access could be granted by the repair station to the part’s owner and operator, providing a more thorough method for receiving and verifying the returned part and document.

With the ability to share access to private records, when a part is later sold on the secondary market, the seller could grant access to or transfer the full, private 8130 records to the purchaser. This could reduce what today takes months to process into a near real-time transaction.

Finally, in a system with both private and public data, the regulatory authorities could request and be granted access to records by the owners. Today, regulatory authorities have this right for all operators under their jurisdiction. Making it an access grant would be better for all parties involved.

Conclusion

This was my first time building an app on AT Proto. I see the potential for this technology to be a new primitive for the future of the web, much like HTTP, TLS, and others. Decomposing data storage and the web application into separate concerns is very powerful, much like what has been happening to the database in recent years.

Generally, making things more modular opens new opportunities for innovation and collaboration across technical stacks. I think the recent introduction of private data will unlock substantially more use cases, especially if the protocol is to go beyond its current emphasis on social apps.

I also think Offwing is novel in how it applies AT Proto toward a more industrial and commercial application. I suspect there is much more here than we currently see.

The code for Offwing is available on GitHub.