I believe that it is a comprehensive series of well-defined MUST-pass requirements that your RTL needs to attain before you commit the design to downstream implementation such as synthesis and physical layout. In addition to this complete set of RTL signoff requirements, you will need the means to measure them against your design as well as reports to ensure compliance.
Some examples of RTL signoff MUST-pass requirements include:
Functional coverage (including high quality assertions)
Clock domain crossings (static and dynamic verification)
Timing constraints (including false and multi-cycle paths)
Power consumption (and meeting the power budget)
Power intent (CPF / UPF correct?)
Testability (stuck-at and at-speed coverage OK?)
Routability (congestion OK; area and timing OK?)
There are other strains of thought, RE: what constitutes reliable RTL signoff. Running SoC designs through rigorous checks of a few to several critical functions certainly saves time and focuses RTL signoff resources on more critical areas where your SoC will most likely have problems.
Traditional signoff: source Atrenta
But that’s a lot like saying a car doesn't need a chassis and four wheels to roll ... that you only need three wheels and the car more than likely will roll fine. It’s a decent bet … but I also wager that a lot of SoC designers would prefer to have the chassis and four wheels approach and be absolutely sure their SoC has signed off at RTL.