I'm not entirely sure. From what I understand based on what the lead developer has said about Auditor, it does more than Android Verified Boot.
AVB uses the boot hash only to verify boot and I believe I remember reading the firmware? This page says AVB gets hashes of read-only partitions and checks them against expected hashes.
From Auditor's website saying it does more than AVB:
It builds upon the hardware-based verification of the operating system by chaining verification to the app to perform software-based sanity checks and gather additional information about device state and configuration beyond what the hardware can attest to directly.
And this part kind of covers what extra stuff Auditor checks.
The key attestation feature provided by the hardware-backed keystore provides direct support for attesting to device properties and bootstrapping the Trust On First Use model of the Auditor app with a basic initial verification chained up to a known root certificate. The latest version of key attestation provides a signed result with the verified boot state, verified boot key, a hash of all data protected by verified boot and the version of the operating system partitions among other properties. It also has support for chaining trust to the application performing the attestation checks, which is used by the Auditor app for bootstrapping checks at the software layer.
So this is why I asked what the specific error was to help OP check if it's more of an informational thing than a real error. Some errors are easily fixed/explained, like for example this one: https://discuss.grapheneos.org/d/3113-invalid-number-of-auditor-app-signatures. The error they were getting sounds very bad, but it was caused by a known problem and fixed with a reboot. If the error continued to show up after a reboot, then that could mean something was really messed up.