diff --git a/docs/FAQ.md b/docs/FAQ.md
index b34900e37..7535c3ed9 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -14,6 +14,7 @@
 - [Copied or Migrated Repos FAQ](#copied-or-migrated-repos-faq)
   - [What repos have been copied into Boxo?](#what-repos-have-been-copied-into-boxo)
   - [What will happen if there is a security issue in one of the legacy ipfs/\* repos that has been copied into boxo?](#what-will-happen-if-there-is-a-security-issue-in-one-of-the-legacy-ipfs-repos-that-has-been-copied-into-boxo)
+  - [How does Boxo make sure it doesn't miss any important changes that are in the original/source/copied repos?](#how-does-boxo-make-sure-it-doesnt-miss-any-important-changes-that-are-in-the-originalsourcecopied-repos)
   - [I don't like the "deprecated" warnings in "not maintained" repos that have been moved to boxo.  What can be done about this?](#i-dont-like-the-deprecated-warnings-in-not-maintained-repos-that-have-been-moved-to-boxo--what-can-be-done-about-this)
   - [How does one claim ownership of a "not maintained" repo?](#how-does-one-claim-ownership-of-a-not-maintained-repo)
   - [Will the "not maintained" ipfs/\* repos be left around to rot?](#will-the-not-maintained-ipfs-repos-be-left-around-to-rot)
@@ -154,6 +155,9 @@ The authoritative list is in https://github.com/ipfs/boxo/blob/main/cmd/migrate/
 ### What will happen if there is a security issue in one of the legacy ipfs/* repos that has been copied into boxo?
 @ipfs/kubo-maintainers (which primarily maps to [PL EngRes IPFS Stewards](https://pl-strflt.notion.site/IPFS-f3c309cecfd844e788d8b9e13472a97b) as of 202203) will certainly handle patching boxo. If there are maintainers for the original/source repos, they will need to handle patching/disclosing. @ipfs/kubo-maintainers will certainly coordinate and share work, but they won't handle communication with or updating of the affected consumers of the original repos that boxo copied from. If there are no maintainers for the original/source repos, there will likely be internal/private PL EngRes chats analyzing which projects are impacted, and it will then be up to those projects to determine whether they want to patch the existing repos or update to use boxo.  (We understand and expect that the "update to boxo" option will often not be possible under tight timelines given boxo's plans to upgrade its dependencies frequently and refactor the existing code.)
 
+### How does Boxo make sure it doesn't miss any important changes that are in the original/source/copied repos?
+A mechanism for this is being tracked here: https://github.com/ipfs/boxo/issues/270
+
 ### I don't like the "deprecated" warnings in "not maintained" repos that have been moved to boxo.  What can be done about this?
 The intent of the "deprecated" warnings was to be clear to consumers about the status of the repo: that it isn't maintained and that there is a repo where similar code is being maintained.  If another maintainer comes along, then they can [claim ownership](#how-does-one-claim-ownership-of-a-not-maintained-repo) and the state of the repo can be adjusted.  This satisfies the requirement about being clear to users about who owns a repo and its status.