See what already exists, what needs to change and what needs clarification.
The same comparison read from the other end: not "what does this document say" but "what would we actually have to do". Each phrase in the requirements is sorted into recognised, ambiguous or unknown, and the recognised part comes with how much of the product a change like that would touch and how risky it is.
Bring the requirements in as text, against a repository GitMir has read.
Read the recognised list — that work already has somewhere to land.
Settle each ambiguous phrase once; the answer is recorded with the name of the person who gave it and is not asked again.
Treat the unknown list as the conversation to have before anyone estimates.
It never picks between two candidates on its own — an ambiguous phrase stays a question until a person answers it, and that is deliberate. The reach figure counts only the phrases that landed, so a document full of unknowns produces a smaller number than the real job. It compares wording against what the code says the product does; it cannot tell you whether the requirement is a good idea, and it does not estimate hours.
Three models are published in full and open without an account. Ask one of them the question this page is about.