# Tuning audit scoring **URL:** \ **Category:** Storage Node feature requests - voting\ **Created:** [May 31, 2021, 7:27pm UTC](https://forum.storj.io/t/tuning-audit-scoring/14084 "2021-05-31T19:27:54Z")\ **Posts on this page:** 1\ **Showing post:** 82
**Author:** ![jammerdan](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jammerdan/32/1121_2.png) [@jammerdan](https://forum.storj.io/u/jammerdan)\ **Post date:** [July 28, 2022, 4:07am UTC](https://forum.storj.io/t/tuning-audit-scoring/14084/82 "2022-07-28T04:07:40Z")
Maybe this would also help to find a better DQ approach: > [@Design Draft - Refactor pending audits to allow for increasing the number of audit workers](https://forum.storj.io/t/design-draft-refactor-pending-audits-to-allow-for-increasing-the-number-of-audit-workers/19189): > > This is a working draft but would like your feedback: [https://review.dev.storj.io/c/storj/storj/+/8041](https://review.dev.storj.io/c/storj/storj/+/8041) A node must successfully complete a certain number of audits to pass the vetting process. As more nodes join the network, the vetting process for each node may take longer because the satellite is limited by how many total audits it can perform. We need to be able to scale auditing depending on how many new nodes recently joined. We can’t safely scale the number of audit workers with the curr… Because as I read it today, there is a limit on how many audits can be performed. Maybe in the future, when more audits can be performed a better DQ process is possible for example: If a node gets disqualified but the issue was something the node operator could not see or because disqualification was to fast, a node operator could apply for a requalifying. This could mean that the node gets no ingress for like a month and gets hammered with audits around the clock or something like that to reinstate the reliability. I cannot make exact proposals here, but the idea should be clear. --- _[View the full topic](https://forum.storj.io/t/tuning-audit-scoring/14084)._