AI
FamilySearch needs to know that the recent AI‑driven changes are replacing accurate, well‑researched information with false, automated data. This is not “helpful.” It is damaging the integrity of the Family Tree. I am seeing correct information overwritten with AI‑generated nonsense, and it is unacceptable.
Family history requires accuracy, sources, and human verification — not algorithmic guesses. These automated changes are harming the quality of the site and undoing years of careful work by contributors. FamilySearch is going downhill because of this, and long‑time users are noticing.
Please stop AI‑generated alterations to existing data. They are wrong, misleading, and destructive to the purpose of the site.
Answers
-
Could you please supply an example of what you are talking about, and explain how you were able to conclude that AI is the source of the problem?
6 -
There are definitely problems affecting data integrity within the FS tree and record collections, but I think the term "AI" is sometimes used when the cause of the problem is elsewhere.
6 -
The four types of AI usage of which I am aware in a FS context are:
1.Full text image transcription, which feeds both Full Text Search and Computer Aided Indexing.
2.Some other aspects of Computer Aided Indexing (the end results of which are, as I understand it, always reviewed by humans via Get Involved before being published).
3.AI-assisted user searching of FS data stores (read-only).
4.Some BYU Record Linking Lab projects which end up updating the Family Tree via the FamilySearch APIs and/or via lists of generated BYU-specific hints implemented manually by volunteers (with no involvement from FS engineers in either case).
Does anyone know of anything else?
2 -
"Chat with AI about your Ancestors" Labs project.
It often suggests records that are not at all relevant - wrong century, wrong country, and worse.
3 -
I agree 100% with this what you said. I brought this discussion up a few months ago about the AI stuff. Plus you get a number of inexperienced people researching and they tend to just slap whatever down that they think is right without looking at documents and now this AI stuff will just make matters worse, especially for the inexperienced crowd.
0 -
@Gary Kincaid Could you please provide examples of "replacing accurate, well‑researched information with false, automated data" with A.I. in the context of FamilySearch and the data in your family tree?
Many community members have recently expressed concern that A.I. is making changes to their ancestors in the FamilySearch Family Tree.
FamilySearch does not use A.I. to automatically change your tree. Every edit—merges, sources, relationships, and conclusions—is made by a human contributor. What we often see is that suggested hints or possible duplicates are accepted too quickly, without reviewing the underlying evidence. This can create the impression that the system is “doing things on its own,” when in reality another user has clicked through a suggestion without verifying it.
Algorithms do assist with suggestions—such as record hints, standardized place names, or possible duplicates—but these are only recommendations. Nothing is added, merged, or changed unless a user approves it.
As a community, we can reduce unintended errors by slowing down and checking each source, each hint, and each merge carefully. Thoughtful verification protects the accuracy of the shared tree and honors the people we are documenting.
Improving the accuracy of the shared FamilySearch Tree is a community effort. Most problems come from rushed merges or hints accepted without verification. We can reduce these issues by teaching careful evidence review, modeling good practices, communicating kindly with contributors, and building norms around thoughtful editing. When we slow down and verify each source, the shared tree becomes stronger for everyone.
If you are seeing something different happening, we would definitely want to know the specifics about the problem so we can investigate it fully.
0 -
Re 'Nothing is added, merged, or changed unless a user approves it': this is true of all Family Tree automation that follows FS' published API usage standards, e.g. the 3rd party products in the Solutions Gallery, but is not true of BYU RLL's automation projects.
4 -
For completeness, I guess FS' engineers may use AI tools such as Claude to help them in coding and managing their software.
2 -
@MandyShaw1 Thank you for your response and additional info on BYU RLL.
You are correct; this principle does not apply to automation created by the BYU Record Linking Lab (RLL). BYU RLL is an academic research lab at Brigham Young University that develops experimental, large‑scale record‑linkage and automation projects. Their work operates under separate research agreements with FamilySearch and does not use the public API. As a result, some RLL projects may add, modify, or merge data in the Family Tree without requiring user confirmation.
Understanding this distinction helps community members make informed decisions about which tools they use and how those tools interact with the Family Tree.
What is BYU RLL?
The BYU Record Linking Lab (RLL) operates very differently from tools that use the standard FamilySearch API.
API‑based tools — including all certified third‑party products — must obtain explicit user approval before adding, changing, or merging anything in the Family Tree.RLL projects do not use the public API and function under separate research agreements. Because of this, some RLL automation may create or modify Family Tree data without user confirmation, which is not permitted for standard API tools
0 -
@sc woz thanks for clarifying this - that is very concerning, given the many high-volume problems Community members have encountered with BYU RLL's 'experimental' work (see the Data Quality report I submitted, as linked to above - any news on that, incidentally?)
4 -
@sc woz said:
"… Understanding this distinction helps community members make informed decisions about which tools they use and how those tools interact with the Family Tree. …"
Yes and no. Ordinary community members don't have any choice (informed decisions) about which tools they use, in that they have no access to the BYU RLL tools (thank goodness). Rather the distinction is a warning to ordinary community members that any BYU RLL stuff may be sub-standard according to their own experiences because of the lack of those explicit user approvals.
4 -
@sc woz are you able to identify the FT modification standards that /do/ apply to BYU RLL, please? (This is not really about the published APIs, it is about controlling the use of /anything/ other than the main FS user interface to update live Family Tree data.)
1 -
I’m not an expert in this area, but from what I understand, the BYU Record Linking Lab (RLL) operates independently at Brigham Young University. They collaborate with FamilySearch on certain projects, but they are not directly under FamilySearch or part of its organizational structure. Hopefully this helps answer your questions, and if not, I can reach out to someone higher up who may be better qualified to provide more detail.
The BYU Record Linking Lab (RLL) is an independent research laboratory within Brigham Young University. When RLL interacts with the FamilySearch Family Tree through the FamilySearch API, all modification activity is governed by the publicly available FamilySearch Developer Documentation. (This documentation appears to have most of the answers you may be looking for.) These rules apply only to RLL projects that read, write, update, merge, or otherwise modify Family Tree data through authorized API endpoints.
FamilySearch API ( An API is simply a structured way for one computer program to talk to another. Think of it as a set of rules and doors that let software safely request or send information.) rules apply to BYU RLL only when a project uses the FamilySearch API.
- Write‑enabled API projects (create, update, merge, attach sources) must follow all FamilySearch rules: allowed operations, automation limits, rate limits, privacy protections, change attribution, source formatting, merge/relationship rules, and API logging.
- Read‑only API projects must follow access‑related rules only: allowed reads, rate limits, privacy, identity protection, Terms of Use, and authentication.
They do not trigger modification rules. - FamilySearch dataset projects follow privacy and Terms of Use.
Modification rules apply only if dataset‑generated edits are later submitted to the Family Tree.
0 -
Got that, the API usage standards I was talking about are indeed the ones at https://developers.familysearch.org/main/docs/contributing-to-the-familysearch-family-tree(as discussed in the document you kindly submitted as a Data Quality incident on my behalf).
What I am asking is, where are the rules that do apply to BYU RLL when they update the Family Tree, given that they are making large volumes of changes to an extremely large and complex database, owned and managed by FamilySearch, to which everyone else's update access is (understandably) carefully controlled?
4 -
Is there a list of users associated with the BYU RLL and any other such automated projects? I've run across A LOT of changes made by one user in particular (username R29036) that has so much volume and so many very blatant inaccuracies and inconsistencies (along with making many small fragments with 1 child and 2 parents), that it makes me feel like it may be an automated user. I think it would be good to know which users are doing automated work, so that we can maybe treat those with a little more "suspicion" and review those changes a little more closely. Maybe having some specific visual identifier next to all usernames doing automated work would be a relatively easy way to do that. After all, it's not much of a community if bots are doing a lot of things and we can't tell who the bots are.
0 -
@marcoreid1 I have not come across that user before, but will have a look to see if they appear to be BYU RLL related. As @sc woz and I were discussing above, every non-BYU-RLL user of automated FT update mechanisms is covered by strict FS modification rules (I am hoping BYU RLL are too, but have yet to get to the bottom of that). I can perhaps see whether your identified user appears to be compliant with those rules (proper use of reason statements, proper person matching pre profile creation, etc.) Unfortunately the Change Log data does not identify in any way whether an update was made in an automated manner, and, if it did, there are many, many automated changes made via 3rd party Solutions Gallery products (AncestralQuest etc.) which are compliant with the rules just mentioned and which are almost certainly just as trustworthy, if not more so, than the average manual update made via the main FS user interface.
P.S. the only BYU RLL automated usernames I know of are TreeBuilding Project, USCensusProject, and CommunityCensus Project (see the PDF linked to in my Data Quality report mentioned above).
UPDATE: I don't currently have any changes made by your identified user in my analysis database. Can you provide some example PIDs, please, and I will investigate further. Incidentally Google AI thinks that this user has done a lot of Memory uploads - if that's their specialism, they are unlikely to be doing the changes on behalf of BYU RLL, who have never to my knowledge tinkered with Memories (let's be grateful for small mercies).
2 -
Thank you to everyone who has taken the time to share your comments, experiences, and concerns.
This conversation has moved considerably beyond the original topic and into several separate issues, so we will be closing the discussion for now.
AI-assisted features and related technologies are still being developed, evaluated, and improved. Specific examples and well-documented feedback are especially helpful in identifying areas that may need attention.
We recognize that several detailed suggestions and supporting materials concerning the BYU Record Linking Lab have already been submitted through the Ideas process. We appreciate the time and effort involved in documenting those concerns.
Those submissions are the appropriate place for the relevant teams to evaluate the examples, consider possible improvements, and determine what action may be appropriate. Submitting an idea ensures that the concern can be reviewed, but it does not guarantee a particular outcome or immediate change.
The Community team cannot investigate individual projects, make decisions regarding development work, or provide updates on the status of submitted ideas. Repeating the same concerns in additional discussion threads will not create a separate review or expedite the process.
For new or substantially different suggestions for improving FamilySearch, please continue to use Suggest an Idea. Include as much supporting information as possible, such as specific examples, Person IDs, screenshots, links, dates, usernames or project names, and a clear explanation of the improvement being requested. Detailed documentation gives the reviewing teams the information they need to understand and properly evaluate a suggestion.
We appreciate everyone’s interest in protecting the accuracy and integrity of FamilySearch. Because the discussion has moved well beyond the original question and the primary concerns have already been formally submitted for review, we will now close this thread.
0
