Verification & trust
From Sensors to an Attestation Record: How Reactor State Is Confirmed

A reactor state attestation record is what you get when raw telemetry is turned into signed, independently checkable evidence, rather than a screen the vendor controls. The chain runs in four steps: the reactor reports its state, an independent party appraises that state, the appraisal is cryptographically signed and written to a transparency log, and a third party verifies the record later. Each of those steps already exists as an open standard.
That is the question behind this post. A dashboard shows what a vendor's software wants to show right now. It is not, by itself, evidence a regulator, insurer, or lender can rely on years later. The interesting work is the chain that sits between a sensor reading and a record an outside party can check without asking the vendor to vouch for itself. The building blocks are not exotic. Remote attestation, transparency logs with signed receipts, and post-quantum digital signatures are published standards from the IETF and NIST [1][2][3].
RankShield Energy is a pre-applicant with the U.S. Nuclear Regulatory Commission (NRC), which means we are engaged in early regulatory interaction and hold no license or approval. This article is educational, and the chain it describes is design intent for how RankShield Energy applies these standards, not a system that has been demonstrated to or accepted by the NRC.
Key takeaways
- A reactor state attestation record turns raw telemetry into signed, independently checkable evidence, so trust does not rest on a vendor's live dashboard.
- The chain has four stages: measure state, appraise it independently, sign and log the appraisal, and let a third party verify the record later.
- Signing plus a transparency log makes the record tamper-evident, meaning later changes to the record are detectable by anyone who checks.
- Post-quantum signatures matter because a reactor record may need to stay verifiable for decades, longer than today's classical signatures can be assumed safe.
- If a vendor claims a trustworthy record, ask what signs it, where it is logged, and who can check it without the vendor's help.
Why raw telemetry is not proof
Raw telemetry is a stream of numbers a system reports about itself. It answers what the operator's equipment currently says, not whether that report is complete, unaltered, or independently confirmed. A vendor dashboard is a rendering of that stream, styled and filtered by the same party whose performance is in question. Nothing in a plain data feed stops a value from being changed, dropped, or replayed before it reaches a viewer, and nothing lets an outsider prove after the fact that what they were shown is what actually happened.
This is the gap the rest of the chain is built to close. Evidence, in the sense a regulator or lender needs, is not the same as data. Evidence is data that has been appraised by a party with no stake in the outcome and recorded so the appraisal can be rechecked. Telemetry is the input to that process. Treating the input as if it were the finished record is the mistake this post is about.
Signing, receipts, and transparency logs
Turning appraised state into a trustworthy record uses three published mechanisms. First, remote attestation: the IETF RATS architecture (RFC 9334) defines a Verifier that appraises evidence about a system and produces results a separate relying party can use, keeping the checker distinct from the thing being checked [1]. Second, signing and receipts: a transparency service registers a signed statement about that appraisal and returns a receipt, the model standardized in RFC 9943 for supply-chain transparency using COSE-signed statements and embedded receipts [2]. Third, a transparency log: an append-only record where each entry is committed so that later tampering with an entry is detectable by anyone who checks. Together these make a record tamper-evident, meaning alterations are exposed rather than prevented. RankShield Energy's approach is designed around this chain, so that an independent appraisal of reactor state is signed and logged rather than left inside vendor software. All of this is design intent, subject to analysis, testing, and NRC review.
The practical payoff is separation of roles. The party that measures state is not the party that signs the appraisal, and neither one gets to quietly edit the log afterward. A receipt in someone's hands is a claim they can recheck. Not a screenshot.
Post-quantum signatures and why they matter for long-lived records
A signature is only as durable as the math behind it. A reactor record may need to stay verifiable for decades, across a plant's operating life and any dispute that follows, which is far longer than a typical software signature is expected to matter. That long horizon is why signature choice is a design decision, not a detail. In August 2024, NIST issued its first post-quantum digital signature standards, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), built to resist attack by future quantum computers [3].
The concern these address is sometimes described as record now, verify later: a record signed today must still be checkable, and its signature still trustworthy, against tools that do not yet exist. The two standards suit different jobs. Hash-based SLH-DSA is a conservative choice for records that must survive for a very long time, while lattice-based ML-DSA fits higher-volume signing. RankShield Energy's design intent is to use standardized post-quantum signatures for long-lived reactor records, subject to testing and NRC review.
What a third party can independently verify
The point of the whole chain is what an outsider can do with the result, alone, later, without the vendor's cooperation. Given a signed record and a receipt, a third party can check three things. It can verify the signature, confirming the record was signed by the claimed independent Verifier and has not been altered since. It can check the transparency log, confirming the entry was registered when it claims and has not been removed or rewritten. And it can compare the appraised state in the record against what the operator reported for that moment, confirming the two agree.
In my view, a record a lender cannot check without the vendor's help is not really independent, whatever it is labeled. The value here is durable trust: a signed, logged record tells an insurer or regulator in three years what the reactor's state was, in a form they can confirm themselves. This is design intent and is subject to analysis, testing, and NRC review; nothing here has been demonstrated to or accepted by the NRC.
Interactive · illustrative
Follow the chain, from a sensor reading to a checkable record
Select each step. This is an educational illustration of the concept, not a live system, a control interface, or a safety function.
Measure
Instruments capture reactor state: power level, temperatures, control-element positions, and the status of each safety function. On their own these are numbers on the operator's own system, and nothing yet makes them trustworthy to an outside party.
Appraise
An independent verifier, separate from the operator, compares the measured state against what the operator reports and what the design permits. Both agreement and disagreement are recorded, so a later reviewer can see what was checked.
Sign and log
The verifier's result is signed with a post-quantum digital signature (NIST FIPS 204 and 205) and written to an append-only transparency log, which returns a receipt. The record is designed so it cannot be quietly changed after the fact.
Verify
Later, a regulator, insurer, lender, or grid operator checks the receipt against the log and the signature, and confirms the record independently, without asking the operator to vouch for itself. This is the property that a plain dashboard cannot provide.
Frequently asked questions
Why can't I just trust the vendor's dashboard?
A dashboard renders the vendor's own data through the vendor's own software, so it shows what that party chooses to show, right now. It is not signed evidence, it is not independently appraised, and it usually cannot be rechecked later by an outside party. An attestation record is different: an independent Verifier appraises the reactor's reported state, the appraisal is cryptographically signed, and it is written to a log that others can inspect <sup><a href="#src-1">[1]</a></sup><sup><a href="#src-2">[2]</a></sup>. The dashboard answers what the vendor says at this moment; the record answers what an independent party confirmed and can prove afterward. The two are not substitutes, and only the second is something a regulator or lender can rely on without taking the operator's word.
What makes a record tamper-evident rather than just stored?
Tamper-evident means later changes to the record are detectable, not that changes are impossible. Two mechanisms combine to achieve it. A digital signature binds the record's contents to a signing key, so altering the contents breaks the signature <sup><a href="#src-3">[3]</a></sup>. A transparency log, an append-only structure where each entry is committed, means that removing or rewriting an entry is exposed when anyone checks the log against its published state <sup><a href="#src-2">[2]</a></sup>. The property is detection, not prevention: an attacker might still alter a copy, but an independent checker can tell that the altered copy does not match the signed, logged original. That is a deliberately narrower claim than words like unbreakable, which this method does not support and which no honest system should promise.
Who can check the record later, and how?
Any party holding the signed record and its receipt can check it, without contacting the vendor. Using the public standards involved, they verify the signature to confirm the record is authentic and unaltered, verify the log entry to confirm when it was registered and that it has not been removed, and compare the appraised state against what the operator reported <sup><a href="#src-1">[1]</a></sup><sup><a href="#src-2">[2]</a></sup>. This is exactly the property a regulator, insurer, lender, or grid operator needs: the ability to confirm what happened from the record itself. Independent verification of this kind supports, and does not replace, the NRC's regulatory oversight of the reactor.
Why do post-quantum signatures matter for a reactor record specifically?
Because reactor records are long-lived. A signature that is safe today may not be safe against the computers of the coming decades, and a record that must stay verifiable across a plant's life and beyond needs a signature chosen for that horizon. NIST's FIPS 204 and FIPS 205, issued in August 2024, are standardized signature schemes designed to resist quantum attack <sup><a href="#src-3">[3]</a></sup>. Using them for long-retention records is a design choice aimed at keeping a record checkable far into the future. For RankShield Energy this is design intent, subject to testing and NRC review, not a demonstrated or certified capability.
Sources
- Internet Engineering Task Force (RFC Editor). RFC 9334: Remote ATtestation procedureS (RATS) Architecture. January 2023
- Internet Engineering Task Force. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains (SCITT). June 2026
- Federal Register / National Institute of Standards and Technology. Announcing Issuance of Federal Information Processing Standards FIPS 203, FIPS 204, and FIPS 205. August 14, 2024
This guide reflects the state of attestation and post-quantum signature standards as of July 2026. This area is evolving; check back if the referenced standards are revised or if the NRC issues new guidance relevant to operational recordkeeping.
About this article. RankShield Energy is a pre-applicant engaged in early regulatory interaction with the U.S. Nuclear Regulatory Commission (NRC). Nothing here should be read as a representation that any RankShield Energy design, product, or facility is NRC-approved, licensed, or certified, or that any safety, performance, or operational characteristic has been demonstrated or accepted by the NRC. Descriptions of reactor and system behavior reflect design intent and are subject to analysis, testing, and regulatory review. This article is for general educational purposes and is not engineering, legal, regulatory, or investment advice.
A note on how we write about our own reactor
HELIX is in pre-application development. Where this article touches our design, every figure is a design target and every physics result is unqualified screening, labeled as such. We cite authoritative sources (NRC, DOE, IAEA, national laboratories) and never invent statistics.
RankShield Energy · HELIX · pre-application