Can my logbook change without me doing anything?

The short answer is "yes."  Should you be concerned?  Well, obviously the only person who can answer that is you, but I think the answer is "no" and this post will go into excruciating detail about the ways in which your logbook can change without your action, and you will at least understand my perspective for why you shouldn't be concerned.

There are three ways your logbook can change without you doing anything.  A MyFlightbook admin can make a change; this is actually the only way that you logbook can be directly affected without any interaction on your part.  The second way is that an instructor can sign flights, revoke a signature, issue an endorsement, or add flights.  The other is that your logbook can be indirectly changed through a change to crowd-sourced data upon which it relies.

Allow me to address each of these scenarios. 

Site Admin Changes

Site admins can do anything to your logbook because they can emulate your account.  (There are other admins with lesser privileges too, who do not have this ability).  Why such great power?  Customer support, primarily: I can't track down an issue if I can't see what you see.  

This is, of course completely standard industry practice: when you call Amazon or Expedia or your bank, they can get into your account to some degree or another for precisely these reasons; they wouldn't be able to fix the quantity on your purchase, fix your reservation, or explain a credit card charge if they didn't have these tools.  These are trusted employees, and (particularly where money is involved!) the tools have audit trails so they can't do anything nefarious without getting caught.  And the system works.

I am one of two site admins, and I do pretty much all of the admin work.  I would estimate that more than 95% of the time that I emulate an account, I make no changes at all - I'm trying to track down a bug report, or explain why something is happening, or I need to see some data "in context" to inform a development decision and so forth.

But there are a (very) few scenarios where I will make a change to your logbook.

The most common reason - by far - is fixing aircraft.  I have a very specific way to do anonymous aircraft and sims/training devices to avoid conflicts with registered aircraft, but people will often create aircraft with tail numbers like "BE23" for an anonymous Beech 23 (which could conflict with a Chinese aircraft, which begin with "B") or "FTD" for a sim ("F" is the prefix for French aircraft).  No big deal, it's just a naming thing, and with the press of a button I can map your flights in the misnamed aircraft to the correctly named one and thus keep the set of aircraft clean.

Another area is images.  Data admins (data admins are a distinct set of admins, with more limited capabilities than site admins; all site admins are data admins, but not all data admins are site admins - think of them as Wikipedia editors) have the ability to review images for flights and/or aircraft, and remove any deemed inappropriate.  E.g., if it's porn, if there's a copyright complaint, etc.  Been months (maybe years?) since I last deleted such an image, but I will do it periodically.

There is only one other - rare - scenario where I will modify a flight of yours, that I can think of: signed Flights can sometimes be marked as having a valid signature when they are no longer in sync with what was signed, or vice-versa.  I periodically review these flights and set the state correctly.

That's really it for what ever might happen directly to your logbook without your participation.

Instructor changes

You can have an instructor sign a flight ad-hoc, but this requires that you be face-to-face with the instructor, so I don't think that counts as "without you doing anything".

 

But if you set up a student/instructor relationship with an instructor, you may grant them certain permission to make changes that they can exercise unless/until you revoke those permissions.

Specifically, an instructor can:

• Issue new endorsements.  No specific permission is required - if they're your instructor, they can do this.  They cannot delete or edit endorsements.
• Sign flights that you have requested that they sign.
• If you've granted the instructor permission to view your logbook, they can also sign any unsigned flight they encounter (or re-sign any flight that they had originally signed but which has been modified), even if you did not request that signature.
  
• If you've granted the instructor permission to add flights to your logbook, then they can, umm, add flights to your logbook.  They can also revoke signatures from flights that they have signed (e.g., if they mistakenly signed the wrong flight).
  

Crowd-sourcing Changes

Perhaps of more interest is the indirect stuff.  When you log a flight in N12345, your flight entry doesn't know anything about N12345 - it's just a reference to an aircraft somewhere else in the database.  And that aircraft, in turn, references a model definition that is in yet another location in the database.  So attributes like "it's a Boeing 737" or "it has a glass cockpit" are not stored in your flight.  See here for considerably more detail about how this all works, but the important thing is that the data about aircraft and models comes from the MyFlightbook user community - and can be edited by the MyFlightbook community as well.

The key point is that if the model of an aircraft that you fly changes, or if the definition of a model used by one of your aircraft changes, then your totals and/or your currency could potentially change.  Yikes!

Or is "yikes" an overreaction?

If you (or someone else) changes an aircraft or a model and you (or they) are the only person with any logbook references to that aircraft/model, then by definition there is no problem: the change made affects the person making the change and nobody else, thus all is good.

On the other hand, if the change is to an aircraft or model that is used by pilots other than the one making the change, then obviously that could be an issue.

In this scenario, an email goes out both to any data admins on the site as well as to any pilot potentially affected by the change.  The purpose of this is twofold: (a) the data admins will review the change.  That's non-negotiable.  But - often more importantly - (b) the affected pilots can see if there's any problem with the change, and they will contact the data admins if there is.  The affected pilots, kinda by definition, actually fly these aircraft and as a result know them better than any admin could.

The vast, vast, vast majority of these changes fall into one of two categories.  The details are described here, but the gist is that most edits are either:

• A "minor" change that actually improves the accuracy of the data.  E.g., specifying that a "C-172" is actually a "C-172 P".  Either way, it's still a C-172, and your totals/currency/etc. don't change.
  
• A more significant change, which ends up resulting in the aircraft being cloned.  Two common examples here are a tail number re-assignment (N12345 was a C-172 but is now a B-737) or an aircraft that is on wheels part of the year and floats on part of the year being edited to indicate the opposite undercarriage.  In this case, your logbook still doesn't change: the clone is detected automatically, and your logbook preserves a reference to the original, not the clone.  (You still get an email, in case the clone is either more accurate for you, or in case you want both versions.)

There are the occasional edits that are in error, or otherwise require reverting.  These are very rare (a few a month, perhaps) and typically corrected within hours of occurring. That's really the primary risk here.  But it is always (a) reviewed by a data admin, so it is (b) fixed promptly.

And the benefits of the two non-erroneous edit examples above vastly outweigh the downside of the rare and short-lived erroneous data.  (And, of course, rare-and-short-lived-erroneous-data happens all the time with curated data, not just crowd-sourced).

As I write this, MyFlightbook has 6-figures of users (wow!) and 8-figures of flights in the database, and has been around for 15 years.  And the examples of this leading to problems of inaccurate computations for things like totals/currency has been...basically nil.

There's one other set of data in MyFlightbook that allows for crowd-sourcing: airports.

Airports in MyFlightbook are a bit of an odd-duck: they're in the database, but they're not "connected" to your logbook in any meaningful way.  You can add airports to your flight that aren't in the airport database and it is no problem.  I keep old airport codes around as long as I can - after all, if you flew to KOLD years ago and it's now KNEW, then KOLD should continue to work.

At a high level, I use airports for 3 purposes:

• Mapping your flight
• Showing where you've been
• In ratings progress, determining if you've met cross-country distance requirements

So if you have a flight that references XYZ and XYZ isn't in the database or refers to something other than what you thought it referred to ("LCL" being a great example - people use that for local flights, but it's an airport in Cuba), then the worst downsides are that your map looks wrong, there's in error computing where you've been, or MyFlightbook thinks you have or haven't met a rating requirement. But none of those are "material" - your logbook still accurately has the record of the flights you've taken and where you visited, as you recorded it.

Most of my airport data (currently over 58,000 airports, heliports, and seaports) comes from various (free) data sources, including the FAA.  Airports entered into the system are considered "native", and cannot be overwritten or deleted by anybody - not even an admin.  Well, OK, I suppose as site developer, I can go directly into the database and delete something...but I just don't do that because direct database access is juggling with very sharp running chainsaws; the point is, there's no tool to do this.

MyFlightbook users can add their own airports (currently over 2,500!).  This is a great addition to the system, with all of the aforementioned benefits of crowdsourcing.  These airports CAN be deleted by either the user who created them, or by a data admin (if they review and decide it's inappropriate for one reason or another), but not by other users.

There are a few changes that can occur in the airport database:

• By far, the most common is that a new airport is added.  Note that if KOLD becomes KNEW, then I don't change the KOLD entry in the airport database, I add KNEW alongside it so that either code works for the airport.  I'll probably designate KNEW as "preferred", but KOLD will continue to work.
• If a user enters an airport that looks like its in the same location as an existing airport, and it appears to be an "official" code for the airport (typically ICAO, IATA, or FAA), then I'll "absorb" it into the system, making it native.  Then it can't be deleted.
• If a code assigned to one airport is assigned by an official organization (ICAO, IATA, FAA) to a new airport, then I'll overwrite the existing name/location for the code with the new name/location.  This is the scenario where KOLD used to be in California but is now an airport in Florida.  
• I have a tool that looks for user-created airports that are duplicates of existing airports (e.g., with existing FAA or ICAO or IATA codes).  The idea is to try to find where someone made up a code for an airport but that didn't need to do so.  In this tool, I usually simply coalesce the airports and mark the official one as "preferred", but I can also decide to delete the (presumably) made-up airport code, especially if I'm worried about a potential conflict.  If I do this, then the "Route" field of the creating-user's flights containing that code is updated to reflect the remaining airport.  I've only rarely deleted airports in this manner, and because this maps to a more current code, it should map correctly and compute distances correctly. [Update Jan 26: I'm removing the piece of this code that updates the route for user flights].
  

With the exception of the last scenario, no flights for any users are changed.  The only change that you would notice is in the third scenario: if you have a flight with KOLD in the route, then it will map using the new location rather than the previous location.  Of course, that's what it would do in ForeFlight, Garmin, or any other mapping app, as you'd expect.  

I think it's more accurate to say that changes in the airport database don't change your logbook, but they can change the map or analysis of your logbook.

And that's about it.  Personally, I think the tradeoffs - the benefits of lots of eyes keeping the data accurate and up to date - vastly outweigh the rare and ephemeral errors.

Hopefully this explains what can - and cannot - be affected by MyFlightbook's crowd-sourcing.