I guess, having read many readme files, manuals and overviews, and also read help files & faqs in various formats, html & text & chm, the answer is in the structures you create around the software.
Eg. An online download is usually packaged, and you can't update a readme or help or doc without repackaging which creates a different checksum or hash, which is regardless of what you would like, seen as a different version of the download file, even if you don't increment a version number or filename.
So, what websites usually do is have the download file versioned, and then have the readme or patch notes as an independent 'no versioned' file, and I guess they update the checksum or hash if the readme has that available. This allows the solution to be rapidly posted, and later any changes to disclosure or detail can be adjusted and improved.
What often occurs is that help files are put on the internet, and apps refer to help files, so the manuals and more comprehensive technical details are easily updated without ever needing to update the application or any complied downloads. You explicitly state that the bundled information is subject to change, and to seek and refer to the latest available online version.
Having used software for a reasonable time as a somewhat technical user who helps other often non-technical users, it's very annoying when you need internet access for faqs, docs, readme or help files, instructions, manuals and the like.
So I'd suggest you be as comprehensive as you can, version AND bundle those versioned files with the software in any downloads or distribution system, but internally, within the software, or on the homepage or download page where you describe it, have links to updated versions that can be improved independent of the already-published detail. I've even seen this (rarely) as 'google this' rather than a hyperlink, as maintaining URLs, even permalinks, over years or decades can be expensive and difficult and a security risk.
It's not uncommon to need to rush a release but not have complete documentation, though it's bad form, especially for free or low cost software, or software that has no margins until it's popularity improves, software that has intrinsic demand by virtue of being unique, bespoke or specific to a vertical that has a real demand. If you're making something for free, it's usually 'take it or leave it' and 'as is'.
Also, remember the FAQ is supposed to be questions asked of users. So you can't write the FAQ, until you get feedback and people actually start asking the question more than once, so they become 'frequently asked' and you actually get tired of answering them, and have answered them enough to be able to write a good answer.
Perhaps, imagine it from the perspective of the FAQ.
You are wanted, needed. So you are written 'in anticipation' from guesses the devs or other associates hint or suggest, or on experience. Then, you are weak, as you're not real. You're a fake faq. But at least you perhaps have some marginal value, as you help define or sent bounds or help with context, either directly or by what you omit.
Later, you get attention & are edited. Some parts of you are removed, then new parts added. As you become more valuable, you are adjusted and edited over and over again. and more often. You might find that comprehension is low for some of the answers or the questions in your body. So you're constantly massaged and tweaked and groomed, until you shine like you have a fresh coat and have had a really good summer.
From beginning to end, you, the FAQ, may undergo thousands of changes! Some of those might be by the devs, but often it's by sales personnel or assistants or volunteers or community champions.
Now, do you really need a version number? How about a date-stamped changelog if not a version?
The answer, probably is no. As you're an FAQ, likely on a website, indexed and a part of the marketing and sales, and the sets of text that help the software be understood and valued. You're not the software. You might frequently never even be needed until something fails or works unexpectedly well or poorly.
It's different if you're a manual, and it's an aircraft, or a vehicle, or I guess, high speed bicycles, such as lithium powered ebikes. These may have faqs, but will still need manuals which detail what the different hardware does, as they are human safety devices.
The legal aspects would be associated mostly with the manual, and they tend to be kept relatively simple and free of detail, because that creates legal risk. The more you put in a readme or a manual or a faq, the more mistakes you may make, or the greater the chance of misunderstanding.
So typically, for legal liability reasons, I guess manuals are a very different thing to readmes or faqs or guides. Perhaps this excludes quick-start guides for printers, which tend to be more IKEA-like, with pictures to again, hopefully reduce ambiguity and multiple meanings being a liability.
Ok, having strayed beyond the scope, to bring the answer back, you need to put more detail in on what the software purpose is, and what it's inputs and outputs are, and what connection it has to physical matter, and if that's related to human safety, or probably, given we're in an extinction event with climate change and rising seas from AGW and greenhouse gases, flora and fauna safety, particularly with respect to habitat preservation and climate migration options.
Even if you have a software licensing agreement that excludes liability or ownership of loss or damage, you still have an obligation to be respectful and considerate, and that means you need to anticipate what problems may occur, and try to in a premeditated way, reduce the chance that those problems in software become actual problems for people or matter or material goods. Everything can be misused or fail, so it's typical to engineer around that.
Good explanations and documentation that can be searched, indexed, skimmed, spidered, assessed by date, and I guess, now ingested and analyzed and quantified and regurgitated by AI, have broad value, often beyond the software that they are inspired by, or written to accompany.