A claims ledger is a shared table listing each statement a vendor makes during an evaluation, who said it, when, and how you checked it. Keep one from the first call. At decision time it shows which claims were verified, which were not, and which should become contract terms.
Why a ledger helps
Evaluations produce many spoken promises. "That is on the roadmap." "It works with your build system." "We never store source code." Weeks later, nobody remembers who said what, and the decision rests on impressions.
A ledger fixes this at low cost. It also changes behaviour: vendors who know their statements are recorded tend to be more precise.
The columns
| Column | What goes in it |
|---|---|
| ID | A running number |
| Date | When the claim was made |
| Source | Person, and channel: call, email, deck, website |
| Claim | The statement, in near exact words |
| Why it matters | Which requirement or risk it touches |
| Verification | Test run, document seen, reference call, or none |
| Status | Verified, partly verified, unverified, contradicted |
| Follow up | Written confirmation requested, contract term, retest |
Keep it in a spreadsheet the whole evaluation team can edit. Do not bury it in meeting notes.
How to use it
- Capture quickly. After each call, spend ten minutes adding claims. Stick to specific, checkable statements. Skip general enthusiasm.
- Prioritise. Mark claims that would change your decision. Those get tests first.
- Verify in the cheapest way. A document check is cheaper than a pilot test, and a pilot test is cheaper than a reference call. Pick the cheapest method that gives real evidence.
- Request writing. For anything you plan to rely on, ask the vendor to confirm it in an email.
- Review weekly. Count verified against unverified claims, and watch for contradictions.
Handling contradictions
When one claim conflicts with another, or with your test, note it neutrally and ask the vendor. Often there is a simple explanation, such as two different product tiers. Occasionally there is not. Either way, you now have a record rather than a hunch.
Turn the ledger into contract language
Claims you could not verify but that matter should not vanish. For each, consider one of three actions: drop it from your decision, test it during an extended pilot, or ask for a contract term that makes it a commitment, with the vendor's legal team involved. Your own counsel decides wording. The ledger simply tells them which statements carried weight in the decision.
A worked example
Suppose a vendor says on a call that their scan handles monorepos well. You log it with the date and speaker, mark it as important, and plan a test on your largest repository. The test shows a long first scan but fast later ones. You update the row to partly verified, note the timings and ask the vendor to explain the first scan. The ledger now holds a fact, not an impression.
Where Safeguard fits
If Safeguard is in your evaluation, put its statements in the ledger like any other vendor's, and verify what you can on your own repositories, starting with the free scan at gold.safeguard.sh/scan.
Quick check
Is a claims ledger too heavy for a small evaluation?
No. It can be a ten row spreadsheet. The habit matters more than the size.
Should I share the ledger with the vendor?
Share the unverified items and ask them to confirm or correct. Keep your internal notes private.
Last reviewed: 19 October 2026.
