@@ -1,1 +0,0 @@ 
-450B

@@ -2,3 +2,4 @@ 2026-06-07: +100D # Initial release
 2026-06-07: +3005 # Adjusted dependability score, alternative representations
 2026-06-07: +380F # Changed metadata dimensions, renamed stages
 2026-06-10: +4107 # Simplified dependency management, improvements
+2026-06-11: +450B # Changed size to impact, added FAQs

@@ -1,1 +1,1 @@ 
-4107+450B

@@ -3,6 +3,7 @@ 
 ### v450-B (2026-06-11)
 
 - BREAKING: replaced "size" metadata dimension with "impact".
+- Added FAQs section and moved SemVer conversion algorithm there.
 
 ### v410-7 (2026-06-10)
 

@@ -1,6 +1,6 @@ 
 ## Convergent Versioning (ConVer)
 
-The current version of this document is **v410-7**.
+The current version of this document is **v450-B**.
 
 ### Summary
 
@@ -190,7 +190,7 @@ Note that a score of 1000 MAY NOT be represented by Convergent Versioning, as it MAY NOT be reached.
 
 #### Dependency Management
 
-Assuming that two projects "A" and "B" both follow Convergent Versioning, if "B" depends on "A", then "B" MUST be compatible exactly with a specific version of "A", unless "A" is in _consolidated_ or _bedrock_ stage, in which case "B" MAY be compatible with any version of "A" with a score of 801 or higher (and therefore at least in _consolidated_ stage).
+Assuming that two projects "A" and "B" both follow Convergent Versioning, if "B" depends on "A", then "B" MUST be compatible exactly with one or more specific versions of "A", unless "A" is in _consolidated_ or _bedrock_ stage, in which case "B" MAY be compatible with a specific version of "A" and all subsequent versions of it, since the project cannot break compatibility once it enters _consolidated_ stage.
 
 #### Alternative Decimal Format
 
@@ -205,15 +205,75 @@ - The third letter identifies the purpose, and MUST be either E (enhancement) or M (maintenance).
 
 For example, **v13B-F** MAY be represented as **v0315-CBE**.
 
-#### Converting a ConVer release to SemVer
+### FAQs
+
+This section lists some frequently-asked questions concerning Convergent Versioning.
+
+#### Why ConVer?
+
+Convergent Versioning is designed specifically for those projects (both software and non-software) that aim to reach eventual completeness, stability, and maturity. It doesn't pressure you to reach version "1.0", or release often — it is a system aimed at _finishing_ what you start, and be happy with that. Some famous projects that could be a good fit for ConVer are:
+
+- [SQLite](https://sqlite.org)
+- [Zig](https://ziglang.org)
+- [Vim Classic](https://vim-classic.org)
+- [Uxn/Varvara](https://100r.co/site/uxn.html)
+- ...the [Semantic Versioning](/https://semver.org) specification ;)
+
+Therefore things that are stable, mature, feature complete and not likely to change too frequently in the future.
+
+#### Why _not_ ConVer?
+
+If your project is meant to keep evolving and adapting to the latest and greatest technologies, then Convergent Versioning doesn't make sense. Such projects may never be truly complete by design.
+
+Examples include:
+
+- All major modern browsers like Chrome, Firefox, Edge, etc.
+- Most commercial/enterprise software
+- the Linux kernel
+- NodeJS
 
-In situations where a SemVer like version is expected, such as in formats used by package managers and similar, a ConVer release MAY be converted into the corresponding SemVer-compliant release provides that the entire history project releases is known. 
+These types of software are meant to continuously evolve. It doesn't mean that they are not stable or mature, just that they will never be _complete_.
+
+#### What's the best way to explain ConVer to my users?
+
+You should add a VERSIONING or VERSIONING.md file at the root of your project explaining briefly what ConVer is and link to this page for more information, if necessary. Something similar to the following:
+
+> This project uses the Convergent Versioning system. 
+>
+> The version number is a 2-byte hexadecimal integer from 0x0000 to 0xFFFF, with the first three digits indicating the project _dependability score_ and the last digit encoding the version impact, compatibility, and purpose. 
+>
+> A version number compliant with Semantic Versioning can be derived from the project history, and will still be used if required by package managers or similar software.
+> 
+> For more information, see the [Convergent Versioning specification](https://h3rald.com/conver).
+
+#### Can my first release be in the 0000 - 000F range?
+
+Yes, it can. This is best explained using the words of [and null](https://www.sheeeeeeeep.art/about.html):
+
+> If you immediately version a project before any line of code is made, then you have true 0x0000. The world is unchanged, there is nothing written yet, it's merely a design you haven't broken ground on. 
+>
+> If you start versioning after a week-long bender of coding, then perhaps 0x000F is a more appropriate start. Could be used to signal how explosive the proof-of-concept stage was. 
+>
+> Did you carefully plan it out (0x0000) or was this a fever dream idea you forced into existance (0x000F)?
+
+#### How do you manage backports and fixes to previously-released versions?
+
+You do not. There is no concept of version branching, and that's by design. While this may sound strange to those used to depend on a specific version of a project _and all subsequent minor or patch versions_, it would start to make more and more sense as a projects stabilizes and becomes more and more feature complete.
+
+If you remove branching, dependency management becomes more straightforward, and in ConVer:
+
+- if you depend on a project that is in _prototype_ or _operational_ state, you must specify the exact versions you are aware that are known to work.
+- If you depend on a project in _consolidated_ or _bedrock_ stage, you can specify a single version and _any version after that_ since projects in those stage cannot break compatibility.
+
+#### Can I convert a ConVer release number to SemVer?
+
+In situations where a SemVer like version is expected, such as in formats used by package managers and similar, a ConVer release can be converted into the corresponding SemVer-compliant release provides that the entire history project releases is known. 
 
 To determine the exact SemVer version number of a ConVer project, do the following:
 
-- Count the number of _breaking_ releases; that SHALL be your major version number, unless the project is in _prototype_ stage, in which case the major version SHALL be set to 0.
+- Count the number of _breaking_ releases; that SHALL be your major version number, unless the project is in _prototype_ stage, in which case the major version should be set to 0.
 - Count the number of _enhancement_ releases after the last _breaking_ release (if any, or all if none); that SHALL be your minor version.
-- Count the number of _maintenance_ releases after the last _enhancement_ release (if any, or all if none); that SHALL be your patch version.
+- Count the number of _maintenance_ releases after the last _enhancement_ release (if any, or all if none); that should be your patch version.
 
 ### About