Questions before you sign up

Nothing. There is no billing in MyTailLog at all— no plans, no tiers, no trial clock, no credit card, no payment code anywhere in the app. The source is public, so that isn't a promise you have to take on trust.

The one line item that costs real money is the AI. Reading a logbook page is a vision-model call, and those are billed to whoever's API key is used. By default that's the key of whoever runs the instance, so shared use is capped two ways: a per-person daily call limit and an overall daily-dollar ceiling. If the day's shared budget is spent, extraction pauses until tomorrow — everything else (timeline, status, forecast, reminders, export) keeps working.

If you have a backlog of hundreds of pages and don't want to wait out the cap, add your own Anthropic or OpenAI API key in Profile. Then the calls bill to your provider account at its list prices and your limit is much higher. See is my API key safe.

AI cost is also kept down by routing printed OCR, PDFs, and text-only questions to the provider's cheapest capable model. Handwritten pages use the stronger vision model because transcription accuracy matters more than the small per-page saving.

We're not going to pretend there's a price list coming, because there isn't one. If that ever changes, the MIT license and the full ZIP export below mean you are not trapped by the change.

Aircraft records — tail numbers, serial numbers, owner names, home base — are treated as sensitive personal data. Every row belongs to the users who own or are shared on its aircraft, and that's enforced by Postgres row-level security, not by application code: access funnels through a single has_aircraft_access() / can_edit_aircraft() choke point that every table is scoped to. An RLS-isolation regression suite runs in CI on every pull request.

Who can actually read your aircraft:

• You, the owner.
• People you invite, as viewers (read-only) or editors (can contribute). You can remove them at any time.
• Apps you consent to over our OAuth 2.1 API — read-only, limited to the aircraft you picked on the consent screen, and never your log entries or scans. Revoke any of them under Profile → Connected apps.

Scanned pages and documents live in a private Google Cloud Storage bucket and are served only through access-checked app routes — never from a public CDN URL. Third-party secrets are encrypted at rest; see below.

And the honest part: whoever operates the hosted instance at mytaillog.com has database access, the same as with any hosted service. Two elevated, RLS-bypassing paths exist by design — the nightly reminder job (behind a shared-secret gate) and the AI-usage ledger write (so the cost guard can't be forged by a browser) — and nothing else. If you don't want to extend that trust to anyone, run your own copy; that's exactly why the license is MIT.

The full defensive posture, and how to report a hole in it, is in SECURITY.md.

MyTailLog trains nothing.There is no training pipeline, no fine-tuning, no dataset job, and no code path that pools users' records for any purpose. The repository is public — that claim is checkable rather than promised.

What does happen: to read a page, its image is sent to the configured AI provider API, and to answer a question, the relevant entry text is sent the same way. That is the only place your records go. What the selected provider does with API traffic is governed by their terms, and we'd rather you read those directly than take our paraphrase of someone else's policy.

If you'd rather that relationship be yours and not ours, add your own Anthropic or OpenAI API key — then the calls are made under your account, subject to your agreement with them.

No. Not partly, not eventually. Your physical logbooks remain the system of record under 14 CFR 91.417. MyTailLog is an index of them and a decision-support layer on top — it is not a maintenance record, not an airworthiness determination, and not a sign-off.

This is a design decision, not a missing feature. Electronic signatures are explicitly out of scopeprecisely so the product stays on the index side of the line and out of AC 120-78A territory. Keep the books; keep them safe; use this to find things in them and to see what's coming due.

We don't publish an accuracy percentage, and we're not going to. A single number spanning crisp typed 2019 entries and a smudged 1963 fountain-pen scrawl would be marketing, not information — your books are not the average of everyone's books.

What we give you instead is the ability to see, per field, where it was unsure:

• A confidence score on every field — date, hours, work performed, parts, AD/SB references, signature — shown as a percentage on the field itself, with anything below threshold highlighted.
• A cropped snippet of the scan beside each field, showing exactly where that value was read from, so you can confirm it without hunting the page.
• The full page image next to the entries, always.
• Bulk confirm only for the clean ones— “Confirm N clean” accepts only entries with a high overall score, no flagged field, and no page-spanning fragment. Anything doubtful is left for you.

Where it struggles, so you know before you hit it: heavy cursive handwriting, faded or bled ink, stamps overlapping text, and scanned spreads where two physical pages sit side by side in one image (those get flagged so you can review both halves).

If you want a human's guarantee on every single entry rather than a model's flagged uncertainty, that's a real and reasonable preference — see how it compares.

You fix it, and nothing downstream is stuck. Every extracted field is editable in the review screen with the original scan beside it; editing an entry marks it confirmed. You can also re-extracta whole page if it was read badly — that replaces that page's entries rather than duplicating them — and there's a duplicate finder for when re-captures and re-extractions pile up.

Everything derived — the status grid, the maintenance forecast, the AD list, the equipment list, the gap audit — is computed from your entries, so correcting an entry corrects the views that read it. Extraction can also ripple: reading a maintenance page will propose equipment installs/removals and advance maintenance last-done dates. Help marks every one of those ripple effects.

None of it is authoritative. Nothing here is a substitute for reading the entry in the book before you act on it — that's why the page image never leaves the screen.

Yes. Export your maintenance history as CSVand import it directly — you don't have to print it to PDF and run it through the page extractor.

There is no importer per vendor, because the columns are mapped, not the rows. One AI pass reads your header row plus a few sample rows and proposes what each column means — “Tach Out” → Tach, “A&P” → Signature, “Invoice #” → don't import. You confirm or correct that once, and then every row is converted in plain code, so the same file always imports the same way and nothing is invented per row.

Dates are never guessed. 03/04/2026is 3 April or 4 March depending on who exported it. The whole date column is scanned, and the first date with a day past the 12th settles the reading for the file; you're asked only when every row genuinely reads both ways, and then you're shown what the first few dates become each way.

You see a count of what will be created before anything is written, and imported entries land unconfirmed— a foreign spreadsheet doesn't get to drive a reminder or an annual-due date until you've reviewed it.

Limits, stated plainly: CSV only (save your XLSX as CSV first), maintenance log entries only as the target, 5 MB / 5,000 rows per file. Importing into an aircraft that already has entries can create duplicates — there's a screen for finding those.

Yes — immediately, yourself, with no request form and no waiting on a job queue:

• CSV per data set — log entries, AD/SB compliance, equipment, maintenance items.
• A printable records bundle — Print → Save as PDF gives you the full history, forecast, and compliance state as a document.
• A complete .zip backup — a manifest, every aircraft-scoped row verbatim as JSON, and the original scanned images and documents. It re-imports into any MyTailLog instance, including one you host yourself, and the import is non-destructive (it creates a new aircraft).

You don't have to remember to do it, either — MyTailLog can push that same ZIP to cloud storage you ownon a schedule. It's also the clean way to hand an aircraft's full history to a buyer.

What we don't have yet: pilot-logbook interchange formats (ForeFlight / MyFlightbook CSV). Maintenance records export fully; those two flight-logging formats aren't written today.

Yes. Connect Dropbox and/or Google Drive in Profile, pick monthly or quarterly, and the same re-importable .zip described above is pushed there on that schedule — one archive per aircraft, named <TAIL>/<date>-<TAIL>.zip. It's off until you connect something.

Connect bothif you want to: they run independently, on separate schedules, each reporting its own status. That gives you copies in two different companies' clouds, which is a materially better position than trusting any one of us — including us.

MyTailLog cannot read the rest of your storage, and that's enforced by the permission we ask for rather than by a promise. Dropbox uses an App folder, so we only ever see our own folder. Google uses drive.file, which grants access only to files the app itself created. Neither can list, read, or touch anything else you keep there. We also don't request your email address from either provider.

Nothing in your account is ever deleted or overwritten.Each run writes a new dated file and leaves every previous one alone, so retention is yours to manage. Automatically pruning someone else's cloud storage isn't a risk worth taking for the disk space it would save.

Disconnecting destroys the tokens.Revoking a destination in Profile erases the stored access and refresh tokens outright — not a flag on a row — so nothing decryptable is left behind. The archives already in your cloud are yours and stay put. While connected, the tokens are encrypted (AES-256-GCM) in a database schema that isn't reachable over the API at all, and are never sent to the browser.

If a backup fails you get told. Profile shows the last run, its status and its size; after two consecutive failures you get an email. A backup that quietly stopped working months ago is worse than no backup, because you believed you had one. Very large aircraft (currently over 400 MB of scans) are reported as skipped rather than failing silently — take a manual ZIP for those.

This is a copy of the index, not a substitute for the paper. See does this replace my paper logbooks.

Worth asking, and here's the straight answer: MyTailLog is maintained by one person, there is no company, no revenue, and no SLA. Nothing about this is a promise of perpetual uptime, and SECURITY.md says the same about response times.

What that risk is bounded by:

• MIT license, public repository. The whole application, schema, and RLS policies are yours to run. Nobody can withdraw that.
• The ZIP round trip. Records and original scans, re-importable. Take one today and you already hold a complete copy.
• No proprietary format. The archive is a manifest plus plain JSON rows plus your image files — readable with or without this app.

A shutdown would cost you a migration, not your records. That is deliberately a much smaller failure than the one that brings most people to a page like this.

Yes. MIT-licensed, and the deployment path is documented rather than theoretical. You need a Supabase project (Postgres + Auth), an Anthropic or OpenAI API key, and somewhere to run a Next.js server — the README walks through Firebase App Hosting on Cloud Run, which is what mytaillog.com runs on. A Google Cloud Storage bucket holds the scans; Resend plus a scheduled daily POST enable the reminder emails, and both are optional.

The friction you should know about up front: SQL migrations are applied by hand, in order, through the Supabase SQL editor — the repo isn't CLI-linked. And the security policy explicitly puts self-hosted deployments out of its scope: your environment, your keys, your Supabase project to secure.

First: it's optional. Everything works on the shared key within the daily caps; you only add your own to lift them and bill your own account.

If you do add one:

• It's stored AES-256-GCM encrypted at rest, alongside our other third-party credentials.
• The ciphertext lives in a Postgres schema that is not exposed over the REST API and is reachable only through SECURITY DEFINERfunctions granted to the server role — it isn't in browser reach even in encrypted form.
• It is decrypted server-side only and never sent back to the browser. After you save it, only the last four characters are ever displayed.
• You can remove it at any time from Profile.

Why encryption on top of RLS: row-level security already stops other users from reading the row. The encryption is aimed at a different failure — a leaked database backup or read replica, where RLS isn't in the picture. What it does not defend against is someone who has both the running server and its encryption key; no at-rest scheme does.

It must be a console API key (starting sk-ant-) with pay-as-you-go credit. A Claude.ai Pro or Max subscription is a different product and has no API access — it won't work here.

Each aircraft gets five logbooks: airframe, engine, prop, avionics, and Other— the last for A&P paperwork rather than running maintenance. Scan a weight & balance sheet into Other and it becomes a new W&B revision; scan an AD compliance report and it becomes the ground truth for your AD state. Permanent records (airworthiness certificate, registration, radio station authorization, POH/AFM, STCs, 337s, 8130-3s, manuals) go in the Records Vault.

The product is sized for a piston GA ownerand the people they share the plane with. The recurring items seeded for you are the Part 91 set — annual (91.409), transponder (91.413), pitot-static/altimeter (91.411), ELT (91.207), VOR check (91.171), 100-hour — plus advisory items (oil change, engine TBO, prop overhaul) that are marked non-regulatory so they're never mistaken for legal requirements. Intervals are defaults you can change.

Nothing stops you enrolling anything else, but be clear-eyed about what isn't modeled: no turbine or Part 135/121 inspection programs, no progressive inspection programs, and no multi-fleet MRO management. Enrollment auto-fills make, model, and serial from the FAA registry by tail number, so non-US registrations mean typing those in yourself.

Pages come in as PDF, JPEG, or PNG (multi-page PDFs are split into one page each), or straight from your phone's own camera app.

Each person signs in as themselves — but you don't have to set anything up for them first. Invite an email address as a viewer (read-only) or an editor (can contribute), and access appears the moment that person signs in with that address. There is no seat cost, because there is no cost.

Two roles, not five. Sharing, ownership transfer, and deletion are owner-only. Squawks are the deliberate exception: anyone with access can reportan in-flight discrepancy, and editors resolve them — a renter or a partner shouldn't need edit rights to tell you the nav light is out.

There is no self-serve account deletion yet. You can delete any aircraft yourself (type-to-confirm, which removes its records and scans); to have the account itself removed, email mytaillog@iamit.org.