Multi-Layered Restoration Architecture
If one page survives, everything comes back

1. If One Page Out of a Hundred Survives

TokiQR's bulk mode splits long audio recordings into multiple QR codes. A 30-minute recording can produce a hundred A4 sheets. They are printed, bound, and stored. But a hundred years from now, there is no guarantee that the entire bundle remains intact. Water damage, fire, moving, deterioration. Losing ninety pages is entirely plausible.

Previously, restoring data from the remaining pages required scanning each one individually with a camera. But if ninety pages are lost, scanning ten will not produce a complete restoration. What if only a single page survives?

The answer is: one page is enough. Because each page carries not only the main QR code but also embedded pathways to restore the entire PDF.

2. Five Restoration Pathways

Each A4 page contains, in addition to the main QR code (180mm square), two small QR codes (18mm square). A blue "play QR" in the bottom-left and a gray "recovery QR" in the bottom-right. Combined with PDF hyperlinks, the newsletter play button, and conventional manual scanning, five independent restoration pathways exist.

Pathways A through D each retrieve the entire PDF from a single page or newsletter link and play back the full recording at once. Only pathway E is the traditional "scan one page at a time" method, but it functions as a last resort in offline environments since it requires no network access.

The Sixth Path: Document Scanners

A smartphone camera scans one page at a time, but a document scanner converts an entire stack of paper into a PDF at once. Feed a hundred pages through the automatic document feeder and a single PDF file is produced in minutes. Import that PDF into TokiQR and the same decode process as pathway E runs—except all hundred pages are processed in a single batch instead of one by one.

Document scanners capture at high resolution with stable lighting, far less susceptible to the blur and uneven illumination that affect smartphone cameras. QR codes on deteriorated paper that a phone camera struggles to read can often be recognized by a flatbed or sheet-feed scanner. When digitizing large volumes of printed pages, a document scanner is the more practical choice over a smartphone.

3. Design Decisions: Play QR vs. Recovery QR

The bottom-left play QR (blue) encodes a URL of the form play.html?zip=<url>. When scanned with a smartphone, TokiQR's playback page opens, automatically fetches the ZIP, reads the manifest, and navigates directly to the playback screen. The user's only action is to scan.

The bottom-right recovery QR (gray) encodes a direct link to the PDF file. A GitHub Pages or NDL (National Diet Library) URL. Scanning opens the PDF itself. It does not play instantly, but the PDF can be saved locally. Even in a future environment where the play QR no longer functions, manual import remains possible as long as the PDF can be obtained.

Blue is the pathway for "listen now." Gray is the pathway for "preserve for the future." The color tells you the role at a glance.

Why They Don't Interfere with the Main QR

When a PDF is imported into TokiQR, all QR codes on every page are scanned. The play QR and recovery QR are detected as well. However, TokiQR's decoder has a URL filter. It extracts only URLs containing play.html or m=, and ignores everything else. The recovery QR (.../output/TQ-00001.pdf) is automatically excluded by this filter. The play QR (play.html?zip=...) passes the filter but contains no data chunks, so it is not treated as a playback target.

Adding two small QR codes to each page causes zero interference with main QR decoding. This was not achieved by writing additional filter rules—the existing filter was correctly designed from the start.

4. The Asymmetry of Paper and Digital

Paper deteriorates. Sunlight, humidity, insects, fire. But paper does not depend on any particular service. It requires no power. A page that survives a fire can still be read a thousand years later.

Digital data does not deteriorate. Bit sequences remain unchanged through unlimited copies. But digital data depends on the continued existence of the service that hosts it. When the service shuts down, the bits vanish with it.

The answer to this asymmetry is multi-layered restoration pathways. QR codes on paper exist in the physical world. PDFs on GitHub Pages exist in the digital world. NDL deposit exists as legally mandated preservation. If any one layer is lost, data can be reached through another.

5. Zero External Dependencies

The technologies used across all five restoration pathways: QR codes (ISO/IEC 18004). PDF (ISO 32000). HTML (WHATWG Living Standard). GitHub Pages (static file hosting). jsPDF (client-side PDF generation). qrcode.js (client-side QR generation).

All are international standards or open-source implementations. None depend on a specific cloud service's API, a specific app store's review process, or a specific authentication provider's availability. Even if GitHub Pages goes down, moving the PDF files to another host restores all pathways. As long as URLs remain unchanged—or even if they change, scanning the recovery QR on paper leads to the NDL copy.

A combination of standard technologies is the most robust architecture. Every proprietary service you add is another point of failure.

6. Redundancy Meets Minimalism

Five restoration pathways might seem excessive at first glance. But the amount of code added to achieve this redundancy is remarkably small.

• Play QR + Recovery QR: Approximately 40 lines added to createPdf() in pdf-export.js. Simply calls the existing QR generation library (QRCode.toDataURL) and jsPDF's addImage/link/textWithLink
• Auto-decode: Approximately 30 lines added to archive.html. Simply calls the existing parsePdf() and TokiDB.saveArchive(). No changes to parsePdf were needed because it already worked with both File and Blob objects
• Play button: 4 lines of CSS + 2 helper functions + a few rendering changes in the newsletter template

Under a hundred lines total. The redundancy arises not from design complexity but from the number of connection points. Because existing modules were properly separated, new pathways could be opened with minimal code.

The Accidental Compatibility of parsePdf

parsePdf(file) was originally designed to process File objects from <input type="file">. Internally, it calls file.arrayBuffer() to obtain binary data. Blob objects also have an .arrayBuffer() method. This means passing a Blob obtained via fetch works without any modification to parsePdf.

This was not intentional design. JavaScript's type hierarchy—where File inherits from Blob—happened to guarantee API compatibility. An accident, but one that was possible only because the design adhered faithfully to standard Web APIs. Had a custom wrapper or adapter been interposed, this compatibility would have broken.

Following standards is leaving options for your future self.

7. Structural Completeness

This essay has a self-referential structure.

• The essay discusses embedding recovery QR codes in PDFs
• This essay itself will be included in a newsletter PDF
• That PDF will contain the very recovery QR codes discussed in this essay
• That PDF will be deposited with the National Diet Library of Japan

Argument, implementation, and preservation form a trinity on the same artifact. If you are reading this on paper, look at the bottom-right corner—the gray recovery QR should be printed there. Scan the blue play QR at the bottom-left, and the entire recording plays back instantly.

Academic papers argue "this should be done," but the papers themselves carry no restoration pathway. Technical blog posts write "this is how we built it," but there is no guarantee the post itself will be archived. This essay is different: the mechanism it describes is implemented in the very artifact that contains the essay.

For the fundamental principles of backup strategy, see "3-2-1 Backup Rule." For the bidirectionality of print and digital, see "The Self-Print Economy." For the full picture of storage design, see "Storage Strategy."