The "Quality Cornerstones Percent" graph approximates how much of the teams' energies are being spent toward maintaining tests and documentation, relative to features and bug fixes.
The Industry benchmark lines shown here can be enabled as described on their help page
There is certainly an upper limit on the utility of time spent on add/updating/deleting Tests and Documentation, but, practically speaking, very few teams approach those limits. Much like the average lawyer or doctor rarely aspires to write on behalf of helping their colleagues, you will struggle to discover a developer who prefers "documenting their work" vs. creating new features. Unless there are senior voices on the team advocating for Tests and Documentation, the visceral reward of "seeing new features take shape" will prove a stronger incentive to human nature than the reward of "incrementally increasing the reliability of the code to future generations." As long as hyperbolic discounting shapes human behavior, the Quality Cornerstones Percent can be a useful counterbalance against the natural human tendency to prefer immediate rewards over their "gradually accruing" sibling.
linkWhat are desirable levels of "test percent" and "documentation percent"?
As of this feature's debut in 2024, the median team dedicates about 15-25% of their Diff Delta toward writing tests, and 2-6% of their Diff Delta on writing and maintaining system documentation (including both standalone documentation files, and documentation that precedes a method, but not code comments elsewhere).
Spending more than 25% of Diff Delta writing tests could indicate an environment where code reliability is paramount. It may also indicate an environment that suffers from intermittent test failures that require persistent attention from the team. In general, seeing more than 30% of energy spent writing tests should be interpreted as an indicator that a team is dedicating an atypically large outlay of attention to writing and maintaining test coverage. On the other hand, if the team's cumulative "Test percent" is less than 10%, there is an increased risk that adding new features will create bugs in existing code. The team should probably be encouraged to dedicate a greater attention to writing automated tests of their code.
When it comes to Documentation code, spending more than 10% of Diff Delta on documentation has never been observed in real-world repos, so it's extremely unlikely your team will experience "too much time spent documenting." However, if your team's "Documentation percent" is less than 2%, there is a case to be made that the developers could be doing more to help their code be maintainable for future teammates.