# How Verifiable Legal AI Security Works

> From draft to verifiable certificate: how RankShield resolves citations, attests privilege isolation, signs with post-quantum crypto, and seals every result.

[Home](https://rankshieldlegal.com/) / The mechanism The mechanism
# From draft to proof, in one pipeline.
**RankShield Legal sits between the draft and your signature.** Cited authorities are resolved against live case-law, privileged material is checked for isolation, and every result is signed with post-quantum cryptography and sealed to a tamper-evident transparency log — producing proof that you, a court, or an auditor can verify independently.
[Try the citation checker](https://rankshieldlegal.com/ai-legal-citation-checker/) [Request early access](https://rankshieldlegal.com/contact/)

## What happens when you certify a filing?
The pipeline has five stages, and each one produces a record you can point to later. Nothing here changes how the document reads or what it argues. The work product is yours; RankShield operates on the citations and the interactions around them, then hands you a certificate that describes exactly what was checked and what the checks found.
The stages run in order — resolve, verdict, sign, seal, verify — and the first two are where the substantive checking happens. The last three are what turn a checking result into evidence that survives scrutiny. A firm that only ran the first two stages would have a useful internal QA step. Running all five is what lets a third party trust the result without trusting you, which is the entire point of a [verifiable](https://rankshieldlegal.com/why-verifiable/) approach rather than a reassuring one.

- **Resolve** — every cited authority is matched against live case-law for existence; quoted passages are matched against the published opinion; good-law standing is overlaid from your firm’s citator.
- **Verdict** — each citation is marked clean, flagged (fabricated, misquoted, or bad law), or incomplete, with the coverage of the check recorded honestly.
- **Sign** — the certification is signed with composite post-quantum signatures (ML-DSA + SLH-DSA, NIST FIPS 204/205).
- **Seal** — the result is appended to an RFC 6962 Merkle transparency log, making any later alteration detectable.
- **Verify** — anyone with the receipt can independently check the inclusion proof; no trust in RankShield required.

## How does the resolver actually check a citation?
The resolver treats a citation as three separate claims and tests each one on its own terms. The first claim is existence: the authority you cited is a real, published authority and not an invented one. The second claim is fidelity: the passage you quoted or paraphrased actually appears in that authority and says what your filing implies it says. The third claim is standing: the authority is still good law and has not been overruled, vacated, superseded, or narrowed out from under your argument. A citation can pass one of these and fail another, which is why they are reported separately rather than collapsed into a single pass or fail.
Existence is checked by exact-match resolution against a live case-law source, not against a model’s memory of what a citation should look like. This distinction matters. A language model can produce a citation that is formatted perfectly, reads plausibly, and refers to nothing at all. The resolver does not ask whether a citation looks right; it asks whether the named authority resolves to a real record in the corpus. Fidelity is checked by comparing the quoted language in your filing against the text of the published opinion, so a quotation that has drifted, been trimmed misleadingly, or been attributed to the wrong authority is surfaced rather than assumed correct.
Good-law standing is the one stage RankShield does not adjudicate itself. Whether an authority is still controlling is a judgment that belongs to a citator, and it belongs to *your* citator — the treatment service your firm already licenses and trusts. RankShield overlays that citator’s signal onto the resolved citation rather than substituting its own opinion about whether a case is still binding. This keeps the tool honest about where its competence ends: it can tell you a case exists and that your quotation matches, and it can carry your citator’s verdict forward, but it does not replace the treatment analysis your firm relies on. This is covered in more depth on [citation certification](https://rankshieldlegal.com/citation-certification/).

## What does the verdict actually mean — and what are its limits?
Once a citation has been resolved, it receives a verdict: clean, flagged, or incomplete. Clean means the authority resolved, the quoted language matched, and the citator signal came back as good law. Flagged means at least one of those tests failed, and the verdict names the failure mode so you know whether you are dealing with a fabricated authority, a misquotation, or a case that is no longer good law. Incomplete is the honest third option, and it is the one that separates this from a tool that pretends to omniscience.
A verdict is marked incomplete when the resolver could not fully test a claim — most often because the cited authority falls outside the corpus available at the time of the check, or because a citator signal was unavailable for that authority. Incomplete does not mean the citation is bad. It means RankShield will not certify something it did not actually verify. Every certificate records coverage: which citations were fully checked, which were partially checked, and which could not be reached. You are told the shape of what was examined, not handed a green light that quietly papers over the gaps.
This is the central honesty commitment of the product, and it is worth stating plainly. RankShield does not make your filing hallucination-free, and no vendor can honestly promise that. What it does is certify which of your citations are real, which quotations are accurate, and which authorities are good law, to the extent the corpus and your citator can establish those facts. The resolver is only ever as complete as the corpus it resolves against. A certificate is a description of what was verified, with its boundaries recorded — not a warranty that nothing was missed.

## How is privilege handled along the way?
Privileged material takes a parallel path from ordinary citation checking. Depending on the firm’s policy, privileged content is withheld from any third-party model entirely, redacted before it leaves the firm’s environment, tokenized so that only non-substantive references travel, or processed exclusively on a local model that never transmits the content outward. The goal of this path is architectural: privileged substance should not reach an external AI service in retrievable form. Each of these routes is described on [privilege isolation](https://rankshieldlegal.com/privilege-isolation/).
Around that handling, RankShield produces an attestation. The attestation binds together the digest of the interaction, the specific tool that was approved to handle it, the policy in force at the time, and the client’s informed consent to that handling. That bundle is signed and sealed the same way a citation certificate is, so that later — during a dispute, an audit, or an ethics inquiry — there is a durable record of which tool touched which interaction under which policy, with consent on file.
It is important to be precise about what this attestation proves and what it does not. The attestation is evidence about architecture and consent: it demonstrates that a defined isolation path was configured, that an approved tool was used, and that the client agreed to the handling. It is not, and cannot be, a legal determination that privilege was preserved. Whether privilege attaches or survives is a question of law and of facts a court weighs — waiver, crime-fraud, subject-matter scope, and more — and no cryptographic attestation resolves it. RankShield gives you a verifiable record of how information was handled. Whether that handling preserved privilege remains a legal judgment for counsel and, ultimately, a court.
One further point applies across the whole pipeline. The certification stores digests, not content. Your filing’s substance never enters the log, and neither does privileged material. What is sealed is a cryptographic fingerprint of the interaction, together with the metadata describing what was checked — never the words themselves.

## What exactly gets signed, and why post-quantum?
When the verdicts are settled, the certification is signed. The signature covers the certificate’s contents: the citations checked, their verdicts, the recorded coverage, and the digests that fingerprint the underlying material. Because the signature covers those contents, any later change to the certificate — swapping a verdict, quietly widening a coverage claim, altering a fingerprint — invalidates the signature. A tampered certificate does not silently pass; it fails verification.
The signatures are composite and post-quantum. RankShield signs with a combination of ML-DSA and SLH-DSA, the lattice-based and hash-based signature schemes standardized by NIST as FIPS 204 and FIPS 205. Using two independent schemes together means a certificate remains verifiable even if a weakness is later found in one of them; an attacker would have to defeat both constructions to forge a signature. The reason to reach for post-quantum schemes now, rather than later, is the long life of legal records. A certificate signed today may need to hold up years from now, and a signature scheme chosen for the threat environment of the coming decade should not depend on cryptography that a future quantum computer could unwind.
The honest framing here is quantum-safe, not quantum-proof. These schemes are designed to resist the attacks a large-scale quantum computer is expected to enable, and they are the standards a serious system should adopt today. But no one can promise that any cryptographic scheme is permanently unbreakable, and RankShield does not make that promise. Choosing composite post-quantum signatures is a deliberate hedge against a known future risk — not a claim of eternal security. The standards this rests on are set out on [security and standards](https://rankshieldlegal.com/security/).

## Why does sealing to a transparency log matter?
A signed certificate proves that a certificate has not changed since it was signed. It does not, on its own, prove when the certificate was created or stop someone from quietly discarding an inconvenient one and signing a friendlier replacement. Sealing closes that gap. Once a certificate is signed, its entry is appended to an append-only Merkle transparency log, and that is what turns a claim into evidence.
The difference between a record you keep in your own database and an entry in a transparency log is the difference between something a skeptic must trust and something a skeptic can check. A database row can be edited or deleted, and anyone relying on it has to take your word that it has not been. In an append-only Merkle log, each entry is hash-chained to those before it, so deleting or altering a past entry breaks the chain in a way that is visible to anyone who looks. You cannot rewrite history in this structure without the rewrite announcing itself.
This is the same transparency-log construction, RFC 6962, that the web’s certificate infrastructure relies on to keep certificate authorities honest. Every secure website you visit depends on certificates that are logged this way, so that misissued certificates can be detected after the fact by anyone auditing the log. RankShield applies that proven construction to legal AI accountability: the same mechanism that makes the public key infrastructure auditable makes a citation certificate auditable. There is more on this on the [transparency](https://rankshieldlegal.com/transparency/) page.

## How does independent verification work?
The final stage is the one that makes the rest worth doing. Anyone holding the receipt for a certification can verify it independently, and verification does not require an account with RankShield, access to your systems, or any cooperation from us. This is what "verify, don’t trust" means in practice: the proof stands on its own math, not on anyone’s assurances.
Verification checks two things. First, the signature on the certificate is checked against the published verification keys, which confirms the certificate’s contents have not been altered since signing. Second, the certificate’s inclusion in the transparency log is confirmed by checking its inclusion proof — a short cryptographic path that ties the single entry to the log’s overall state without needing to download the entire log. If both checks pass, the verifier knows the certificate is authentic, unaltered, and was genuinely committed to the log at the recorded position.
The consequence is that trust never has to route through RankShield. A court clerk, opposing counsel, a malpractice carrier, or a bar investigator can confirm a certificate for themselves. Even if RankShield were unavailable, hostile, or gone entirely, a certificate already issued would remain verifiable, because everything needed to check it — the signature, the log structure, the inclusion proof — is either in the holder’s hands or in a public log. That independence is the property that distinguishes evidence from a vendor’s say-so.

## What does RankShield store — and what does it never store?
Because certificates are meant to be verifiable by outsiders, it matters a great deal that they do not leak what the filing says. The design goal is proof without exposure. A third party should be able to confirm that the checks ran and what they found without ever learning the content of the filing or the client’s material. That is only possible if the substance never enters the record in the first place.
So the distinction between what is stored and what is not is deliberate and strict. It is not a setting or a default that can be toggled toward more retention; it is the shape of the system. What follows is a plain accounting of both sides.

- **Stored:** cryptographic digests (fingerprints) of the interaction and the certified material.
- **Stored:** the citations checked and each one’s verdict — clean, flagged, or incomplete.
- **Stored:** the coverage of the check, recording what was fully verified, partially verified, or unreachable.
- **Stored:** the attestation metadata — the approved tool, the policy in force, and the record of client consent.
- **Stored:** public citation metadata, such as the identity of a published authority that was resolved.
- **Never stored:** the substance of your filing — its arguments, drafting, or text.
- **Never stored:** privileged client material in retrievable form.
- **Never stored:** the words behind a digest; a fingerprint cannot be reversed back into the content it fingerprints.

## Where are the honest boundaries of this system?
A tool that describes only its strengths is not one a careful lawyer should rely on, so the boundaries deserve to be stated as plainly as the capabilities. RankShield certifies facts about citations and interactions. It does not certify that your legal reasoning is sound, that your argument will prevail, or that your filing is complete. It checks whether the authorities you cited exist, whether your quotations match, and whether those authorities are good law by your citator — and it records how privileged material was handled and consented to. Everything beyond that remains the work of counsel.
Several limits follow directly from how the pipeline works. The resolver is only as complete as its corpus: an authority outside the corpus is reported as incomplete, not as verified, and never quietly assumed good. Good-law standing reflects your citator’s treatment analysis, not an independent judgment by RankShield, so it inherits both the strengths and the timing of that service. The privilege attestation evidences architecture and consent; it does not adjudicate whether privilege legally attached or survived. The post-quantum signatures are quantum-safe by current standards, not quantum-proof for all time. And a certificate is a description of what was verified within recorded coverage — not a warranty that a filing contains no errors of any kind.
Stated the other way around: RankShield turns "trust me, I checked" into "here is a record of exactly what was checked, which you can verify yourself." That is a meaningful shift, and it is also a bounded one. The value is in making the checking honest, durable, and independently confirmable — not in claiming the checking is perfect. A firm that understands where the boundaries sit gets the full benefit of the tool without being misled by it.

## How does this fit into an existing drafting workflow?
For a small or mid-sized firm, the practical question is whether adopting this means changing how people work. It does not. Drafting continues exactly as it does today, with or without AI assistance, in whatever tools the firm already uses. RankShield does not sit inside the drafting process telling anyone how to write; it sits at the end of it, as a checkpoint before signing.
At that checkpoint, the filing’s citations are resolved and given verdicts, and any AI interactions that touched privileged material are attested. If everything comes back clean, the certificate is signed and sealed and the filing proceeds — now with a verifiable record attached. If a citation is flagged, the failing citation is identified by its failure mode and returned for correction before the signature goes on the page. Either way, the drafting itself is untouched. What changes is the ending: a filing concludes with proof of what was checked rather than an unverified assumption that it was fine.
The pipeline is designed so that adding it costs the firm workflow disruption, not workflow reinvention. The checkpoint is a step, not a system to migrate onto, and it produces an artifact — the certificate — that lives alongside the filing rather than inside it.

## Who is the proof actually for?
The certificate is built to be read by more than one audience, and each audience checks it the same way. For the filing attorney, it is a pre-signature safeguard: the failure surfaces before the signature, not in a show-cause order afterward. For a court, it is an independently verifiable record that the cited authorities were checked against live case-law, available without any need to trust the firm or the vendor. For opposing counsel, an auditor, a malpractice carrier, or a bar investigator, it is the same — a receipt that stands on its own cryptography.
That single shared object is what makes the approach durable. Because verification requires no account and no cooperation, the certificate means the same thing to everyone who examines it, whenever they examine it. The firm does not have to be present to vouch for it, and RankShield does not have to be present either. The proof is portable, and it says exactly what it says: here is what was checked, here is what was found, and here is how you can confirm both for yourself.

Ask anything
## The mechanism, answered
The questions law firms ask, answered directly. **No forms, no sales pitch.**

JAMIE KLONCZ · SEO AGENCY NAPLES ************** ONLINE
Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it.

← PREV NEXT → [REQUEST ACCESS →](https://rankshieldlegal.com/contact/)

- **Do I have to change how my team drafts?** No. Drafting stays exactly as it is — with or without AI assistance. RankShield adds a checkpoint before signing: the filing’s citations are certified and privileged interactions are attested. The work product flows through; what changes is that you end each filing with proof instead of hope. There is no new drafting environment to adopt and no migration. The checkpoint runs at the end of your existing process and produces a certificate that lives alongside the filing rather than inside it, so the way your team writes is untouched.
- **What does RankShield store about my filing?** Digests and public citation metadata, not privileged content. Certificates record cryptographic fingerprints, the citations checked and their verdicts, and coverage — never the substance of your filing or client material. The design goal is proof without exposure: a third party can verify the checks ran without learning what the filing says. A digest is a one-way fingerprint and cannot be reversed back into the content it represents, so even the record of a certification does not disclose the words behind it.
- **What happens when a citation fails?** The filing is held and the failing citation is identified with its failure mode — fabricated (does not exist), misquoted (quotation does not match the opinion), or bad law (overruled or superseded). You correct it and re-certify. The point is that the failure surfaces before your signature, not in a show-cause order after. A citation may also come back incomplete rather than failed, which means the resolver could not fully verify it — for instance, because it sits outside the available corpus — and that is reported honestly rather than passed off as clean.
- **Does this make my filings hallucination-free?** No, and any vendor promising that would be overstating what is possible. RankShield certifies which of your citations are real, which quotations are accurate, and which authorities are good law by your citator — to the extent the corpus and your citator can establish those facts. The resolver is only as complete as the corpus it checks against, and anything it cannot reach is marked incomplete rather than assumed correct. A certificate is a description of what was verified, with its limits recorded, not a warranty that nothing was missed.
- **Does the privilege attestation prove privilege was preserved?** No. The attestation is evidence about architecture and consent: it shows that a defined isolation path was configured, that an approved tool handled the interaction, and that the client consented to that handling. Whether privilege legally attached or survived is a question of law that turns on facts a court weighs — waiver, scope, crime-fraud, and more — and no cryptographic attestation resolves it. RankShield gives you a verifiable record of how information was handled; whether that handling preserved privilege remains a judgment for counsel and, ultimately, a court.
- **Are the signatures really unbreakable?** They are quantum-safe by today’s standards, not quantum-proof for all time. RankShield signs with composite post-quantum signatures — ML-DSA and SLH-DSA, standardized by NIST as FIPS 204 and FIPS 205 — so a certificate stays verifiable even if a weakness is later found in one scheme. Choosing these schemes now is a deliberate hedge against the long life of legal records and a known future risk from quantum computing. It is a serious, standards-based choice, not a claim that any cryptography is permanently unbreakable.
- **Can someone verify a certificate without trusting RankShield?** Yes, and that is the entire point. Anyone holding the receipt can check the signature against published verification keys and confirm the certificate’s inclusion in the transparency log using its inclusion proof — no account, no access to your systems, and no cooperation from us required. This is the same RFC 6962 transparency-log construction the web’s certificate infrastructure uses. Even if RankShield were unavailable or gone, an already-issued certificate would remain verifiable, because everything needed to check it is in the holder’s hands or in a public log.

Keep exploring
## Related
[Citation certificationExplore →](https://rankshieldlegal.com/citation-certification/)[Privilege isolationExplore →](https://rankshieldlegal.com/privilege-isolation/)[Security & standardsExplore →](https://rankshieldlegal.com/security/)[The transparency logExplore →](https://rankshieldlegal.com/transparency/)[Why verifiableExplore →](https://rankshieldlegal.com/why-verifiable/)