How SolveGRC thinks
The guides tell you how to use each module. These pages explain the ideas underneath — the handful of principles that make the whole platform behave consistently, so a number you see in Frameworks means the same thing when it shows up in a report, and an answer the AI drafts can be trusted the same way whether it lands in a questionnaire or an audit.
You do not need to read these to get value out of SolveGRC. Read them when you want to know why the product did something — or when you are about to stake a compliance claim on a number and want to know exactly what stands behind it.
The principles
- How AI answers are grounded — where the AI's answers come from, why every one carries a citation, why a human still approves them, and why it sometimes refuses.
- How evidence quality and freshness work — what makes a piece of proof strong or weak, why evidence goes stale, and what that does to the things it backs.
- How crosswalks satisfy many frameworks — why assessing a control once can credit several frameworks at once, and how a suggested mapping becomes a trusted one.
- What runs automatically — the work SolveGRC does on its own between your logins, in plain language.
One rule holds all of them together
Every conclusion SolveGRC shows you is traceable to its inputs. A score shows the controls beneath it. An AI answer cites the passage it read. A derived number carries a provenance affordance — one click to see what fed it and when.
That is the line we hold: SolveGRC will tell you what it concluded and why, in terms of your own data. What it does not expose — to you or to anyone else — is the internal weighting, thresholds, and prompts that turn those inputs into outputs. You get a defensible, explainable result without the recipe leaving the building. If you ever hit a number you cannot trace back to something concrete, that is a bug we want to hear about.