Firmware sits at the top of the prod.keys relationship chain. It determines which key generations and revisions exist on a console, and therefore which of them a keyset generated from that console will contain.
How firmware introduces revisions
When the console’s security system is revised, the change arrives with a system update. Some updates are routine; others introduce a new generation of key material. A keyset generated before such an update will not contain the new generation, and content protected with it may not be addressable until the keyset is regenerated.
This is the mechanism behind almost every “it worked yesterday” report in the ecosystem, and it is why the site treats a firmware date as part of a version record rather than as background detail.
What this site records
The site records a firmware relationship only when it can be confirmed for a specific keyset — for example, that a keyset was generated on a console at a particular firmware level. It does not map firmware numbers to revision numbers, because that mapping changes and a mapping published without a source is exactly the kind of unverifiable claim this site avoids.
No firmware numbers are invented here. Where a firmware relationship would be useful but has not been recorded, the field reads “not published — verify on your own hardware”. That is deliberate.
Why a mismatch produces a specific error
A firmware or revision mismatch does not usually produce a generic failure. It produces an error at the layer that could not be satisfied — a missing category, an unsupported revision, or a failed unwrap. That specificity is useful: it tells you where in the chain the problem is. The firmware mismatch and unsupported revision pages cover both cases.
Where this connects
Firmware leads to revisions, revisions are recorded in the versions hub, and the combination of firmware, revision, keyset and environment is what the compatibility hub explains. Read them in that order if you are working from first principles.