Which public standards does RankShield Legal build on?
Every claim this platform makes about a record is meant to be verifiable by someone who does not trust RankShield. That is only possible if the underlying machinery is public. So the architecture is assembled from standards that a firm's security or IT owner can read, audit, and check against independent implementations, rather than a house cryptosystem we ask you to take on faith.
The four load-bearing standards are named below. Two are cryptographic (how records are signed and how they are logged), one is architectural (how verification authority is structured), and one is the obligation layer the outputs are designed to support. Each is a document you can pull and read for yourself; none of them originate with RankShield, and that is the point. Our how-it-works walkthrough traces one record end to end through these same standards.
- NIST FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) — composite post-quantum signatures on every certificate and attestation. Classical RSA and ECDSA face deprecation after 2030 under NIST IR 8547, so records that must outlive that horizon are signed with algorithms designed to survive it.
- RFC 6962 — Merkle transparency logs: append-only, hash-chained, and independently verifiable. Every sealed record gets an inclusion proof that anyone can check against the public log head without asking us for permission.
- IETF RATS (RFC 9334) — the remote-attestation architecture that defines the roles in a verification system. RankShield operates as the Verifier and trust anchor, producing attestation results about the evidence it is shown.
- FRCP Rule 11 and court AI standing orders — the obligations the certification outputs are designed to support. The outputs give a filer verifiable evidence to point at; they do not discharge the duty on the filer's behalf.
Why anchor to public standards instead of a proprietary trust scheme?
A proprietary trust scheme has a structural weakness that no amount of engineering removes: to believe its output, you have to believe the vendor. If RankShield invented its own signature format and its own log and asked courts, opposing counsel, and your own risk committee to accept them because we vouch for them, then the evidence would only ever be as strong as our reputation on the day someone challenged it. That is a fragile foundation for records that may need to hold up years after they were created.
Public standards invert that. When a certificate is signed with a NIST-standardized algorithm and logged in an RFC 6962 structure, a skeptic does not need our cooperation to test it. They can take the receipt, run an open-source verifier, and reach their own conclusion. The trust moves out of the vendor and into mathematics and published specifications that a third party can implement independently. This is the difference between asking you to trust a dashboard and giving you something checkable in the open, which is the theme of our why-verifiable overview.
There is a practical durability argument too. Standards are maintained by bodies with long horizons and broad review — NIST, the IETF — and their formats are implemented in many places. A record built on them remains checkable even if RankShield is not in the room, not under contract, or not in business. A proprietary format dies with its vendor. For legal records, whose retention and confidentiality obligations routinely outlast the technology that created them, that longevity is not a nicety; it is the requirement.
What does a certificate actually contain — and what does it deliberately leave out?
A RankShield Legal certificate is designed to prove something about a record without carrying the record. It stores digests — cryptographic hashes that stand in for content without revealing it — alongside the verdict of whatever check was run, public citation metadata, and coverage indicators that describe how complete that check could be. What it does not store is the substance: no privileged content, no filing text, no client material. The design principle is proof-without-exposure, and it is enforced by what goes into the certificate in the first place, not by an access-control setting layered on afterward.
Concretely, that means a certificate can attest that a given document was checked against a corpus of case law and record what the check found, while the document itself never enters our systems in readable form. A digest is a one-way function of the input; you cannot reconstruct the brief, the memo, or the client's name from it. The verdict and coverage indicators travel with the digest so that a later reader understands both what was found and how far the check could see.
Coverage indicators deserve emphasis because they are where honesty gets built into the data model. Where a check depends on an external source — live case law, or your firm's own citator — that dependency and its coverage are recorded alongside the result rather than hidden behind a confident-looking checkmark. A reader can therefore tell the difference between "checked against a complete corpus" and "checked against what was reachable at the time," which are very different claims that a naive system would present identically.
What do privilege attestations store, and how are they kept separate?
Privilege attestations answer a narrower question than certificates: they attest to the architecture and the consent under which a workflow ran, not to the content that passed through it. So a privilege attestation stores digests and an enumerated list of the methods that were applied — which isolation steps ran, which controls were in force — and nothing more. It does not store the privileged material it was protecting. It cannot, by construction, because the material never lands in a place the attestation could read it from.
This matters because the whole value of a privilege attestation would collapse if generating it required exposing the very thing it exists to protect. An attestation that leaked privileged content in order to prove it was handled carefully would be self-defeating. The enumerated-methods model sidesteps that: the attestation is a record that specific protective steps occurred and that specific consent was given, expressed as digests and method identifiers, which is provable without disclosure. The mechanics of that isolation are described in our privilege-isolation page.
It is worth being precise about the limit of this claim, because it is a limit that a firm's security owner will and should probe. A privilege attestation proves that the architecture and consent were as stated. It does not — and is not offered to — prove a legal conclusion about whether privilege attaches to any particular communication. That determination is a matter of law and professional judgment. The attestation is evidence about how something was handled, not a ruling about its legal status.
How does post-quantum signing work here, and why composite?
Every certificate and attestation carries a composite post-quantum signature: it is signed twice, with two different algorithms that rest on two different mathematical foundations. ML-DSA (FIPS 204) is lattice-based; SLH-DSA (FIPS 205) is hash-based. The two families are not variations on one idea — they draw their security from unrelated hard problems. A record is only accepted as validly signed when both signatures check out.
The reason for the redundancy is a hedge against cryptanalytic surprise. If a future advance weakens the lattice family, the hash-based signature still stands, and vice versa. No single break takes the record with it. That kind of defense-in-depth is usually overkill for short-lived data, but legal records are not short-lived. A certificate may need to remain verifiable for decades, across a period in which the cryptographic landscape will certainly shift. Signing with two independent foundations buys margin against that uncertainty in a way a single algorithm cannot.
The choice of post-quantum algorithms specifically is tied to a published timeline rather than to marketing. NIST IR 8547 sets out a transition in which classical RSA and ECDSA are deprecated after 2030. Records signed today with those classical algorithms inherit that expiry; records signed with ML-DSA and SLH-DSA are built for the horizon on the far side of it. That said, the honest framing is quantum-safe, not quantum-proof. These are the algorithms NIST standardized to resist known quantum attacks; standardization is a strong signal, not a guarantee of permanent immunity, and we do not claim otherwise. Our quantum-safe page goes deeper on what that phrase does and does not promise.
How does the RFC 6962 transparency log make records checkable?
A signature proves who sealed a record and that it has not changed. It does not, on its own, prove that the record existed at a particular time and was not quietly swapped or backdated later. That second guarantee is what the transparency log provides. RankShield Legal writes every sealed record into an append-only, hash-chained Merkle log built on the RFC 6962 construction — the same family of structure that underpins Certificate Transparency across the public web.
Append-only and hash-chained are the two properties that carry the weight. Append-only means entries can be added but not altered or removed without breaking the chain. Hash-chained means each entry is cryptographically bound to those before it, so tampering with any past record invalidates everything that followed and is detectable. On top of this, the log can produce an inclusion proof for any single record: a compact piece of evidence that this exact record sits in the log, checkable against a published log head without trusting the log operator's word.
The practical consequence is that the log's integrity does not depend on trusting RankShield to behave. A verifier checks the inclusion proof and the log head arithmetic themselves. If we ever tried to rewrite history, the math would not close, and independent monitors watching the log head would see it. That is the intended posture: the system is designed so that even its operator cannot silently alter the record. You can inspect the current log state directly from our transparency page.
Where does RankShield sit in the IETF RATS architecture?
IETF RATS (RFC 9334) gives remote attestation a shared vocabulary of roles, and being explicit about which role RankShield plays is part of stating the architecture honestly. In RATS terms, an Attester produces evidence about itself, a Verifier appraises that evidence against policy and issues attestation results, and a Relying Party consumes those results to make a decision. RankShield Legal operates as the Verifier and trust anchor. It appraises the evidence it is shown and produces attestation results; it is not the party that ultimately acts on them.
Naming the role this way also names its boundary. As Verifier, RankShield can attest that the evidence it received supports a stated conclusion about architecture and consent. It is not positioned to attest to things outside the evidence — it does not observe your matter, exercise legal judgment, or reach conclusions of law. The attestation result is scoped to what the evidence actually shows, and the reader who relies on it stays the Relying Party, keeping the decision and its professional responsibility with the human or firm that acts.
This separation is deliberate and worth a security owner's attention, because a common failure mode in attestation systems is a verifier that quietly overclaims — presenting an appraisal of narrow evidence as if it were a broad guarantee. Anchoring to the RATS role definitions is how we keep the claim honest: a RankShield attestation result says exactly what a Verifier is entitled to say, and no more.
Which obligations do the outputs support — and which do they not?
The certification outputs are designed with specific real obligations in mind: FRCP Rule 11, the growing set of court standing orders governing AI use in filings, client audit demands, and professional confidentiality duties. When a rule asks a filer to certify that citations were checked or that AI-assisted work was reviewed, a RankShield certificate gives that filer verifiable evidence to stand behind the representation — evidence a court or an opposing party can independently test rather than take on assertion.
The critical distinction, and the one this page will not blur, is between supporting an obligation and discharging it. RankShield is a security vendor. Its outputs support compliance; they do not make a firm compliant, and they do not substitute for the professional judgment the obligation actually demands. A certificate can show that a citation-check ran and what it found. It cannot decide, on your behalf, that the resulting filing is sound, that the argument is well-founded, or that Rule 11's standard is met. Those judgments remain the filer's, and the certificate is evidence in service of them, not a replacement for them.
Put plainly: the outputs are built to make it easier to demonstrate that you did the work and to let others verify that demonstration. They are not a compliance service, not legal advice, and not a warranty that any particular obligation has been satisfied. The value is in producing checkable evidence at the moment of the work, so that the record exists later when someone asks for it.
Can a record be verified without a RankShield account?
Yes, and this is the single most important property of the whole design, so it is worth stating without hedging: verification does not require a RankShield account, a login, or our cooperation. It uses the receipt itself. A receipt carries the composite post-quantum signature and the RFC 6962 inclusion proof, and those two artifacts are everything a verifier needs.
The check has two steps and both use open, documented constructions. First, verify the post-quantum signature against the record's digest, confirming the record was sealed by the stated key and has not changed. Second, verify the RFC 6962 inclusion proof against the public log head, confirming the record is present in the append-only log and was logged when it claims to have been. Neither step calls a RankShield API or consults a RankShield permission. A skeptic with the receipt and open-source tooling reaches the conclusion on their own.
This is precisely what makes the verification independent rather than a feature of our product. If checking a record required our dashboard, then the trust would still ultimately rest on us, and a determined challenger could always ask why they should believe our screen. Because the receipt is self-contained and the tooling is open, the answer is that they do not have to believe us — they can check. That is the whole reason the architecture is built on public standards instead of a private scheme.
The honest edges
No security architecture is all guarantee and no limit, and pretending otherwise would undermine the very credibility this page is trying to earn. These are the boundaries a firm's security or IT owner should know before relying on anything here. Each one is a place where the system's honest claim is narrower than a casual reading might assume.
- Corpus-limited existence — a citation check can only speak to what was in the reachable case-law corpus at verification time. Coverage is recorded on every certificate so a reader can see how far the check could see; a clean result over a partial corpus is not the same as a clean result over a complete one.
- Good-law standing comes from your firm's citator — we surface and record what the citator reports, and we never independently assert that a case is good law. Citator resolution is only as complete as the corpus behind it.
- Attestations prove architecture and consent, not legal conclusions. A RankShield record can show that specific protective steps ran and that consent was given; it cannot rule on privilege, on the merits, or on whether a legal obligation is satisfied. That judgment stays with the professional.
- Quantum-safe is not immunity. The signatures use NIST-standardized post-quantum algorithms designed to resist known quantum attacks. No system is quantum-proof, and standardization is a strong signal rather than a permanent guarantee. We say quantum-safe, and we mean the narrower thing.
- Supporting compliance is not being compliance. RankShield is a security vendor that produces verifiable evidence. That evidence supports obligations under Rule 11, court AI orders, and confidentiality duties; it does not discharge them, and it is not legal advice.
What is RankShield Legal, and what is it not?
To close the loop and remove any ambiguity a diligence reviewer might otherwise have to chase: RankShield Legal is a security vendor. It builds an evidence layer. Its job is to produce cryptographic proofs — certificates and attestations, signed with post-quantum algorithms and logged in a public transparency log — that let a firm and third parties verify how work was handled. That is the entire scope of what it is.
It is not a law firm. It gives no legal advice, renders no legal opinions, and forms no attorney-client relationship. It is not a compliance service; it does not certify that a firm meets any regulatory standard, and its outputs support rather than satisfy compliance obligations. It does not store privileged content or filing substance, and it is not positioned to reach conclusions of law. Where a claim would require any of those things, RankShield declines to make it, and the honest edges above spell out where those lines fall.
What remains after those subtractions is a focused and durable service: verifiable evidence, built on public standards, checkable without trusting the vendor, and designed to remain checkable for as long as the records themselves need to last. A firm's professional judgment stays in charge of every legal question. RankShield's role is narrower and more mechanical — to make sure that when someone later asks whether the work was done and how, there is a proof to point at that anyone can test.
