What does "verifiable" actually mean here?
In ordinary use, "verifiable" gets thrown around to mean "we checked it, trust us." That is not the sense we mean, and the distinction is the whole point of this page. When we say a claim is verifiable, we mean a third party who does not trust RankShield, does not have an account with RankShield, and cannot see your systems can still confirm the claim is true using only the artifact in front of them and public cryptographic math. The verification does not route back through us. It does not require our cooperation. If we vanished tomorrow, the proof would still check.
That is a higher bar than most software ever has to clear, and it is worth being precise about why law needs it. In most industries, a mistake is a cost. In litigation and transactional practice, a mistake in the record is often the last word — a fabricated authority in a brief, a privileged document that reached the wrong system, a log that cannot be produced when a court asks for it. The remedy for those failures is not a better dashboard. It is evidence that can be examined by people who owe you nothing.
So the working definition we hold ourselves to is narrow and testable: a verifiable claim carries its own proof, and the proof can be checked by an adversary. Everything on this page follows from that one commitment. If a claim cannot meet that bar, we do not dress it up in the language of proof. We say what it is — a policy, a promise, an architecture — and we let it stand on its own terms. You can read how the mechanics work on our how it works page, and you can check this very site against its own log on the transparency page.
What does typical legal AI leave you with?
The market is full of capable drafting and research tools, and this page is not an attack on any of them. Many are genuinely useful, and the firms building them are solving hard problems in good faith. But structurally, most share the same posture, and it is the posture — not any particular product — that this section is about. In the common design, hallucination risk is managed by grounding the model in a document set and hoping it stays inside that set. Confidentiality is managed by a zero-retention or no-training contract. Accountability is managed by internal logs the vendor keeps and can produce on request.
Every one of those is a claim someone must take on trust. Grounding reduces the odds of a fabricated citation; it does not certify that the citation in your brief exists, was quoted accurately, and is still good law. A no-training contract is a promise about behavior; it is not an artifact you can hand a client to show that privileged material never left an isolated boundary in retrievable form. An internal log is a record kept by the party who would be blamed if it read badly; it proves very little to a court precisely because the party who benefits from it is the party who wrote it.
None of that is dishonest on the vendor's part. It is simply the ceiling of what "trust me" architectures can offer. And the reason the ceiling matters is that peer-reviewed research has now measured it. A Stanford RegLab study published in the Journal of Empirical Legal Studies in 2025 found that leading legal AI research tools still answer incorrectly on a meaningful share of queries — on the order of roughly 17 to 33 percent depending on the tool and task. Read that number carefully: these are the specialized, retrieval-grounded legal products, not general chatbots. The lesson is not that the tools are bad. The lesson is that the model is not the thing you can afford to trust. The checkpoint after the model is.
Why does "the checkpoint matters more than the model" hold up?
If the best legal-specific tools still miss a meaningful share of the time, then improving the model is necessary but not sufficient. No responsible person signs a filing on the strength of "the vendor says their accuracy is high this quarter." What a professional needs is a way to check the specific output in front of them — this brief, these authorities, this matter — independent of how the model performed in aggregate.
That is the shift verifiability forces. It moves the trust boundary from the model, which is probabilistic and improving and opaque, to the checkpoint, which is deterministic and inspectable. You are no longer asked to believe the system is reliable in general. You are handed an artifact about your particular output, and you can confirm or refute it yourself. The model can be a black box; the checkpoint cannot. That inversion is the entire value proposition, and it is why we lead with the certificate rather than the accuracy statistic.
It also changes who holds the burden. In a "trust me" model, the burden of doubt sits with the person relying on the output — the associate who has to re-check every cite by hand, the partner who has to take the vendor's word, the client who has no way in at all. A checkpoint that produces independently checkable evidence moves that burden onto math. The associate still exercises judgment, but the tedious, high-stakes question of "is this authority real and current" now has an answer that does not depend on anyone's good intentions.
What does verifiable add, concretely?
Three things, and each is designed to be handed to a skeptic rather than displayed on a screen for the person who already believes it.
- Citation integrity you can prove — every authority resolved for existence, accurate quotation, and good-law standing, delivered as a signed certificate rather than a dashboard flag. A flag says "this looks off, take a closer look." A certificate says "this authority resolves, the quoted language matches the source, and its treatment status is what the certificate records," and it carries the cryptographic proof to back that statement to anyone who checks it. See citation certification for the mechanics.
- Privilege isolation you can prove — a signed attestation that privileged material was handled inside a defined isolation boundary and never reached a third-party model in retrievable form, bound to a record of the informed consent under which the work was done. This attests the architecture and the consent. It is not, and does not claim to be, a legal determination that privilege was preserved. See privilege isolation.
- Records that survive skepticism — certificates and attestations signed with post-quantum digital signatures (ML-DSA and SLH-DSA, standardized as FIPS 204 and FIPS 205) and sealed into an RFC 6962 tamper-evident transparency log. That combination is built so the proof outlives two separate risks: the end of your relationship with us, and the cryptographic transition to quantum-capable adversaries. See security and standards.
How is a certificate different from the flag I already get?
A flag is a statement about the tool's internal state: the system noticed something and surfaced it. It is genuinely useful, and it is also entirely on the tool's authority. If a flag fails to appear, you have no way to know whether the tool checked and cleared the item or simply never looked. If a flag does appear, you still have to do the underlying verification yourself before you can rely on it. The flag is an opinion — an informed one, but an opinion.
A certificate is a statement you can test without the tool. It records the specific facts checked — that an authority exists, that a quotation matches its source, that a citation's treatment status is what the certificate says — and it carries a signature and an inclusion proof that any third party can verify against a public log. The certificate does not ask you to believe the tool did its job. It lets you confirm the result, or catch it lying, using cryptography that neither party controls.
The practical consequence shows up when something is contested. A flag that was or was not shown leaves you arguing about the tool's behavior after the fact, with no durable record. A certificate leaves you with an artifact whose authenticity and timestamp can be established independently, months or years later, by someone who was not in the room. In a profession where the record is frequently the whole ballgame, that difference is not cosmetic.
Why not just trust the vendor's own logs?
Because a log controlled by one party proves the least exactly when it matters most — when that party's interests are on the line. Conventional application logs can be edited, selectively retained, backfilled after the fact, or simply never written for the event you care about. None of that requires bad faith; ordinary retention policies and storage limits produce the same gaps. And the person relying on the log has to trust the person who kept it, which is the dependency the whole exercise was supposed to remove.
An append-only, hash-chained transparency log changes the structure. Once an entry is included, it cannot be quietly altered or removed without breaking the cryptographic chain, and the break is detectable by anyone auditing the log. Independent parties can confirm that a given record was present at a given time. The vendor is no longer both the author and the guarantor of its own accountability record. That is the difference between "we logged it" and evidence — and it is why we built on RFC 6962 rather than a private audit trail we could edit.
This is also why we do not ask you to take the transparency claim itself on faith. The transparency page lets you verify this site against its own log. The invitation is deliberate: a company that talks about verifiability should be the first thing you verify.
Who can verify a RankShield receipt, and what do they need?
Anyone holding the receipt. Your firm, your client, a court, an insurer, opposing counsel, a regulator, a future version of you reopening a matter years later. Verification checks two things: the post-quantum signature on the artifact, and the inclusion proof that places the artifact in the tamper-evident log at a specific point in time. Both checks are public math. Neither requires an account with us, credentials from us, or any access to your systems.
That independence is not a convenience feature; it is the design constraint everything else bends around. The moment verification requires our cooperation, the proof is only as trustworthy as we are — which puts you right back in the "trust me" world the product exists to leave. So the receipt is built to be self-contained. It travels with its own proof. It can be checked by a party who actively distrusts everyone involved, which is the only kind of check that means anything in an adversarial setting.
Concretely, this means a client can confirm your accountability record without calling us, opposing counsel can confirm an artifact's authenticity without deposing our engineers, and a court can treat the record as something it can examine rather than something it has to take on representation. The value of a proof is measured by who can check it against your wishes. We optimized for exactly that.
Where this is going: an agent-clearing layer
The direction the platform points toward — and this is a roadmap direction, not a shipped product, so read it as intent rather than a claim — is a neutral clearing layer for legal AI. The idea is a single attested record that a firm, opposing counsel, and a court can each trust without trusting one another. Every party would be able to check the same receipt, reach the same conclusion, and rely on it, precisely because no party controls it.
The reason this is a natural destination rather than a leap is that the primitive it requires is already running: a receipt anyone can verify. A shared, adversary-checkable record is what you get when you take that primitive and let multiple parties point at the same artifact. The clearing layer is that pattern generalized — from "I can prove my own work" to "we can all rely on one proof none of us owns." It is the difference between a stack of separate "take our word" assurances and a single source of truth that sits outside all the parties who might dispute it.
We want to be honest about status. As of today this is a design goal. There is no clearing product to buy, no consortium to join, no live multi-party settlement running in production. What exists is the foundation it would be built on. We describe it here because it explains why the architecture is shaped the way it is — independence, public verification, no vendor chokepoint — and because you deserve to see where the honest version of "trust no one" leads. When it is real, we will say so plainly and you will be able to check it. Until then, it is roadmap.
What does this change for a small or mid-size firm?
Larger firms can sometimes absorb AI risk with headcount — a review layer, a dedicated cite-checking process, an internal policy nobody has time to enforce. Smaller firms usually cannot, which is exactly why the checkpoint model fits them. When the proof travels with the output, you do not need a second team to re-verify the first team's tools. The associate runs the work, the certificate confirms the specific facts it is scoped to confirm, and the partner reviews an artifact instead of re-deriving trust from scratch.
It also changes the conversation with clients. Sophisticated clients increasingly ask how their outside counsel uses AI and how confidential material is handled. "We use a reputable vendor with a good contract" is an answer, but it is an answer built on someone else's promise. "Here is a signed attestation that privileged material stayed inside a defined isolation boundary, under recorded consent, and you can verify it yourself" is a different kind of answer. It moves the discussion from reassurance to evidence, which is the register the client's own risk and compliance people already speak in.
And it lowers the cost of a bad day. If a citation is ever challenged, or a handling question is ever raised, the firm that kept independently verifiable records is in a fundamentally stronger position than the firm reconstructing what happened from memory and vendor emails. None of this makes AI risk-free. It makes the residual risk documented, bounded, and checkable — which, for a firm without a compliance department, is often the difference between adoption and abstention.
The honest boundary
Verifiability is not a promise of perfection, and a page about honesty has to hold that line hardest. RankShield does not claim an AI that never hallucinates. There is no such thing, and anyone selling one is selling the thing this page exists to warn you about. What we do is narrower and checkable: we certify which of the citations in your work are real, accurately quoted, and good law, so a fabricated or misquoted authority is caught at the checkpoint rather than in front of a judge.
On confidentiality, we are equally precise. We do not guarantee that privilege is preserved — that is a legal conclusion that depends on jurisdiction, waiver, the facts of the matter, and judgments only counsel can make. What we attest is the isolation architecture and the consent under which work was done: that privileged material was handled within a defined boundary and did not reach a third-party model in retrievable form. That attestation is evidence you can use in a privilege analysis. It is not the analysis, and it is not a substitute for one.
On cryptography, we say quantum-safe, not quantum-proof. The signatures we use are the NIST-standardized post-quantum algorithms, chosen because they are designed to resist attack by quantum-capable adversaries. "Safe" reflects the current standardized state of the art; "proof" would claim a certainty about the future that no serious cryptographer asserts. The whole architecture is built to be re-checkable as that field evolves, which is the responsible posture, not an unbreakable guarantee.
The through-line is simple. In a profession built on evidence, your AI accountability should be evidence too — and evidence is honest about what it does and does not establish. Every claim on this page is scoped to what a third party can independently confirm. Where we cannot offer that, we tell you it is a policy, an architecture, or a roadmap, and we let it stand as exactly that.
