1. The check mark and the disputed sentence
Imagine a public project report that says twenty units were scheduled, eighteen were completed and the project is complete. A signature check succeeds. What should a reader conclude? The tempting answer is that the report has been verified. But that sentence conceals several different questions: which data was checked, which key was used, who is associated with that key, and whether eighteen completed units satisfy the project's stated requirements.
A digital signature has a valuable but bounded job. NIST's FIPS 186-5 describes signatures as supporting detection of unauthorized data changes and authentication of the signatory. The standard was published February 3, 2023; its official page also carries a May 12, 2025 planning note about issues intended for future correction. This article uses that narrow description of purpose, not a claim that a test program is government-certified or that a signature establishes every statement in a document. NIST FIPS 186-5
The project in this article is fictional. Call its records the Larch packet. Its offices, staff roles, quantities, approval rules, observations and corrections are invented for the exercises. A small local program actually signed selected text and performed seven checks using freshly generated demonstration keys. Nothing was submitted to a real authority, no outside document was authenticated, and no private key was copied from a person, certificate or published test vector.
The distinction matters because public records often contain several kinds of statements at once. A report can identify its preparer, reproduce a contractor's estimate, state a measurement, recommend a payment and quote an earlier decision. Those sentences do not acquire the same evidentiary status merely because they share a file. A reader still has to ask who asserted each proposition and what supports it.
For the opening example, stipulate that Larch's completion rule requires all twenty scheduled units. Eighteen divided by twenty is 90 percent. The word complete therefore conflicts with the stipulated count and rule. That is an internal consistency finding within the invented record. It does not depend on guessing a real contractor's motives or accusing a signer of wrongdoing.
There are several possible explanations even inside the fiction: the status was copied from an earlier draft, the count was not updated, or the stated rule was later changed in a document the reader has not seen. Finding the inconsistency establishes a question. It does not select an explanation. The signature can help preserve the exact statement being questioned while the factual investigation proceeds separately.
2. What the local signature experiment actually did
RFC 8032, published in January 2017 as an informational document, describes EdDSA, including Ed25519. Its verification operation involves the message, signature and public key. The local exercise used an existing library implementation rather than implementing the specification's curve arithmetic or copying its test vectors. It is a demonstration of particular inputs and results, not a cryptographic conformance or security certification. RFC 8032
The executed environment contained Python 3.12.14 and the cryptography package version 50.0.0. That version's documentation provides key generation, signing and public-key verification operations; unsuccessful verification raises InvalidSignature, while success returns without that exception. The program converted those outcomes into explicit true or false fields in its saved results. A reader should not mistake the library's ordinary return value for a document-truth score. Version-matched Ed25519 API documentation
The original message was an eighty-seven-byte JSON record with four fields: the identifier Larch-P17, reported completion of eighteen units, twenty scheduled units and the status complete. The program created demonstration key A, signed that exact byte sequence and checked the result with A's public key. That first check succeeded. The program did not inspect a project site, consult an acceptance record or decide what the status should mean.
Next it changed the reported count from eighteen to twenty while keeping the original signature. The check failed. Both messages happened to contain eighty-seven bytes; equal length did not make them equal inputs. Replacing a two-digit value with another two-digit value was enough to create a different message in this particular test.
The program also checked the original signature with a second freshly generated key's public component, B. That check failed. It then created a new signature over the altered record using A, and that check succeeded. Finally, a new signature over the original record using B succeeded when checked with B's corresponding public component. These are actual local observations, not imagined outputs from a production document viewer.
The remaining two checks changed representation rather than the reported quantity: pretty-printing the JSON and adding a trailing newline. Both failed against the original signature. Across all seven cases, three succeeded and four failed. Those totals describe this deliberately selected demonstration, not a measured error rate for signatures, a security benchmark or the proportion of public documents that are truthful.
The saved packet contains the harmless message bytes, public keys, signatures, package version and outcomes needed to inspect the exercise. Private keys existed only in the process and were never serialized, printed or saved. A rerun generates new demonstration keys, so its signatures need not match the saved run even when the expected pass and fail pattern does.
3. The same apparent record can have different bytes
The pretty-printed Larch record occupied 104 bytes rather than eighty-seven. Parsing each representation with the local JSON parser produced equal data values, yet the original signature did not verify against the longer representation. Adding one newline produced an eighty-eight-byte input and another failed check. These results show exactly what the small program tested; they do not establish that every signed-document format treats all formatting changes in the same way.
RFC 8785's JSON Canonicalization Scheme addresses a different, explicitly specified representation problem. The June 2020 informational document defines a constrained, deterministic JSON representation and requires preserving string data rather than treating Unicode normalization as an implicit cleanup step. The Larch script did not implement or test JCS. Its ordinary JSON serialization should not be advertised as a standards-conformant canonicalizer. RFC 8785
This boundary is important when someone sends a reader a reformatted copy of a signed record. Suppose Larch's archive supplies the original compact file, while a public-facing page displays an indented transcription. The page can be easier to read without being the exact input used in the recorded check. A clear presentation can identify the original artifact and distinguish it from the reading copy, instead of letting visual resemblance carry an unearned verification claim.
The opposite mistake is to call every failed check proof of a false statement. In the local exercise, the pretty-printed copy retained the same parsed values. Its failure against the original signature did not demonstrate that eighteen had become twenty or that a project had changed. It demonstrated a mismatch under the deliberately chosen raw-byte procedure. A report about that result should describe the failed relationship, not invent an event outside the test.
Now consider an independent transcription exercise. A clerk copies the four Larch fields into a spreadsheet and accidentally enters eighty rather than eighteen. That is a content error, not merely indentation. The correction process should compare the displayed value with the source record. If someone silently fixes the spreadsheet but keeps an old screenshot, the packet can contain two inconsistent reading copies even though the original artifact never changed.
A useful reconciliation therefore names the objects: original file, formatted display, spreadsheet extraction and screenshot. It can state which comparison was performed for each. The reader does not need a tutorial on every serialization standard to understand why an authentic source file and an inaccurate transcription can coexist. The important question is whether the published assertion comes from the checked input or from a later transformation that has its own opportunity for error.
4. A key label is not an independent identity check
NIST SP 800-89 separates several assurances relevant to digital signatures, including public-key validity, possession of the corresponding private key and the identity of the key-pair owner. The November 2006 publication remains identified as final on its official page. This separation is useful here: obtaining a successful local calculation and establishing who controls the relevant key are not the same evidence-gathering step. NIST SP 800-89
In the Larch fixture, A and B are arbitrary labels assigned by the author. Neither key belongs to a real office. The sixth check succeeded using B because the message had been signed with B's corresponding private component. For a separate fictional registry exercise, stipulate that Larch's editor recognizes only A for project-status submissions. The B result can be mathematically successful while remaining outside that invented registry's recognition rule.
That registry exercise is not a certificate authority or an identity-proofing service. It simply exposes an assumption that a polished interface can hide. If a page labels a supplied key Larch Works Office without an independent basis for the label, the name is an assertion in the page. Repeating it beside a check mark does not create the missing attribution evidence.
Suppose the fictional packet contains a key-registration letter, an office directory and an approval log. The letter refers to A, the directory identifies the relevant office, but the approval log uses the label A-test. A reader should not silently treat A and A-test as the same item because their names look related. The packet needs the actual identifiers and an explanation of the relationship. The discrepancy might be a harmless label, or it might mean the wrong environment was used.
Now change the facts of the exercise: the registration letter clearly identifies A, but the document's author field names a contractor rather than the office. This is not necessarily a contradiction. The contractor might have prepared text that the office later endorsed. It does mean that prepared by, submitted by and signed on behalf of are different claims. A report should preserve those roles rather than compress them into a single authorship label.
The purpose of examining these records is not to make readers distrust every signature. It is to locate the evidence that gives a successful computation its intended institutional meaning. Once that connection is documented, the attribution can be stated more precisely. When it is missing, the honest result is a limited one: the local relationship was checked, but the proposed real-world identity was not established by that check alone.
5. An identified signer can still have a limited role
RFC 5280 describes certificate-path validation as checking a binding between a subject name and a public key, using a trust anchor supplied as an input. That is a specific technical purpose. The May 2008 base specification is cited here only for that boundary, not as a complete account of all later PKI updates or a rule about who may approve a public expenditure. RFC 5280, section 6.1
For a separate fictional Larch workflow, stipulate three roles. A field clerk records quantities, a project manager accepts completed work, and a finance officer authorizes payment. These are invented responsibilities, not a description of any jurisdiction's law. A document associated with the clerk can establish that the clerk submitted a count without establishing that the manager accepted it or that finance approved an invoice.
Suppose the record shows eighteen installed units at a stipulated price of two hundred dollars each. The multiplication is $3,600. A schedule for twenty units would total $4,000. The four-hundred-dollar difference can be described as the price associated with two units under the invented assumptions. It is not automatically an overpayment, debt, fraud loss or approved deduction. Those conclusions would require additional terms and transaction records.
Now add a manager's note accepting sixteen units, with two installed units awaiting inspection. The installation count and acceptance count need not contradict each other. Under the stated fictional roles, they measure different stages. The corresponding accepted-work amount would be $3,200 if the stipulated unit price and payment basis apply. A signed installation report should not be relabeled an acceptance certificate merely because it is the easiest file to retrieve.
The same distinction applies to a recommendation. A manager may recommend paying $3,200 while finance later authorizes a different amount for a documented reason. The recommendation is evidence of the proposed decision. It is not evidence that money left an account. If a public story concerns payment, the story needs the payment record rather than a succession of documents that all precede it.
A useful account can place these records alongside one another without declaring that one must be fake. Eighteen installed, sixteen accepted and a proposed payment for sixteen form a coherent sequence under the fictional assumptions. What would be misleading is putting all three beneath one label, verified completion, and leaving the reader to infer that every stage has the same authority and consequence.
The reporting question is therefore not merely who signed. It is what that identified person or office was asserting in that document, in that role, for that decision. Establishing attribution is important. Extending its meaning beyond the documented scope can undo the value of having established it carefully.
6. A signed payload and the page around it are different objects
RFC 7515 distinguishes protected and unprotected header information in its JSON Web Signature format. Its JSON serialization can contain both, while the compact form has no unprotected header. That is a format-specific reminder to establish coverage rather than assume every visible field is protected. The Larch program did not create JWS objects or evaluate their conformance. RFC 7515
Instead, consider a separate fictional display built around the eighty-seven-byte Larch record. The display adds a title saying All Twenty Units Approved, a thumbnail of a project plan and a summary prepared by an editor. None of those additions was an input to the actual local signature checks. The source message still reported eighteen units. A successful result for the source message cannot establish that the added title accurately summarizes it.
This is an editorial mismatch, not an attempt to exploit a real viewer. It can be found by comparing the known input with the displayed claim. The correction is equally specific: revise the unsupported title and preserve a clear relationship between the reading page and the source artifact. Reissuing the same inaccurate title in a more official-looking style would not resolve the mismatch.
Suppose the display also shows a green status icon beside the whole page. A reader could reasonably interpret that placement as an endorsement of the title, thumbnail and summary together. A more informative report would identify the object checked and describe the result in words. For example, the original Larch message passed the local test under demonstration key A; the surrounding editorial text was not part of that test. That statement is longer, but it is also inspectable.
Now imagine a printed copy containing only the title and the icon, with the source message omitted. The printout preserves the page's visual claim while removing the material needed to understand its scope. A public archive can address that problem by making the source relationship visible in the reading copy. This is an evidence-design recommendation for the fictional example, not a claim that a particular document format has been attacked or that a real archive uses such a display.
The basic comparison is concrete. Which bytes went into the saved operation? Which additional words did the publisher add? Where does the reader encounter each one? Keeping those answers separate prevents a narrow technical result from spreading across an entire page by visual association.
7. A reference to an annex is not the annex itself
The W3C Verifiable Credentials Data Model 2.0, a Recommendation dated May 15, 2025, warns that material referenced through URLs is not cryptographically protected by default. Its advice concerns the boundaries of credential protection; the Larch records are not claimed to be conforming credentials. The useful question for this exercise is simply whether the evidence packet contains the particular related material on which a conclusion relies. W3C Verifiable Credentials Data Model 2.0, content integrity
Imagine that a separate fictional Larch cover note refers to Annex One for the list of inspected units. The packet includes the cover note and an annex bearing that title, but the note does not identify which revision it means. One annex lists sixteen accepted units; another lists eighteen. A reader cannot resolve the ambiguity just by finding the words Annex One in both places. The versions must be connected through the actual record of what was supplied or approved.
Suppose a transmittal email in the invented packet lists a filename and a byte count. The attached file in the archive has the same name but a different length. That is a discrepancy worth explaining, not proof of an altered inspection. The attachment might have been reformatted, replaced with a corrected copy or incorrectly associated with the email. The evidence needs to distinguish those possibilities. Naming one as fact before the comparison is complete would outrun the record.
For a concrete inventory exercise, give Larch's packet six expected components: the cover note, quantity sheet, acceptance sheet, invoice, payment authorization and payment confirmation. Five are present; the payment confirmation is missing. Five divided by six is approximately 83.33 percent of this stipulated inventory. That percentage does not mean the project's claims are 83.33 percent true. It describes the availability of six specifically named items, one of which may be essential to a particular conclusion.
A later discovery of the missing confirmation changes the completeness count to six of six. It still does not guarantee agreement among the records. The confirmation could relate to another invoice, or its amount could require reconciliation. Conversely, an unavailable attachment does not establish that no payment occurred. Availability, relevance and consistency are separate questions even when the same file helps answer more than one of them.
The practical benefit of this inventory is that it makes the next question precise. Rather than asking whether the whole packet is authentic, the reader can ask whether the confirmation for a named invoice is present and what it records. That is a narrower inquiry, but it is more likely to produce an answer that can be checked against the documents.
8. An attributable claim still needs evidence about its subject
The same W3C Recommendation explicitly separates credential verification from evaluating whether its claims are true. It also treats a verifier's decision to rely on a claim for a particular use as a distinct validation question. This is not a declaration that credentials are useless. It is a boundary between checking a secured assertion and establishing the proposition that assertion expresses. W3C Verifiable Credentials Data Model 2.0, terminology
Return to Larch's completion count. To test the factual statement rather than its local signature, invent a separate field sheet listing twenty numbered units. Eighteen have completion marks, one is explicitly marked unfinished and one has no recorded observation. The sheet supports eighteen recorded completions. It does not support treating the unobserved unit as either complete or unfinished without further evidence. The distinction matters even though both unresolved entries prevent a clean claim that all twenty have documented completion.
If an editor divides eighteen by the nineteen units with recorded observations, the result is approximately 94.74 percent. Dividing by all twenty scheduled units yields 90 percent. Neither calculation can replace the other without changing the question. The first is the share completed among the observed units in the fictional sheet; the second is the share with recorded completion among the scheduled units. A signed summary using the first denominator cannot silently become a statement about all scheduled work.
Now suppose another sheet records eighteen completed units, but two entries refer to the same unit identifier. Eighteen rows would then represent seventeen distinct units if every other identifier is unique. A total based on rows can be arithmetically correct while overstating the number of distinct objects. The reader needs the meaning of a row, not only confidence that the file arrived intact.
This example also shows why an independently observed fact can be narrower than a broad project claim. A photograph might document one identifiable installation at a stated visit. It would not automatically establish every installation in a twenty-unit project. A receipt might show that materials were purchased without showing where they were installed. The role of each item should be described rather than letting the strongest-looking document absorb the meaning of the others.
None of these exercises implies that a real public report is false. They explain how to investigate a particular proposition without demanding that a signature do an observational job. The report's origin can remain established while its count is corrected. The factual assessment becomes stronger when it identifies the relevant units, observations, denominator and unresolved entries instead of treating authenticity as a substitute for measurement.
9. Two successfully checked versions can disagree
The local experiment contains a particularly useful pair. The original record reports eighteen completed units. The altered record reports twenty. Each was separately signed with demonstration key A, and each succeeded when checked with its own signature and the corresponding public key. The program did not choose one as the true account. It recorded two successful checks of two different messages.
In a fictional publication history, that difference could reflect a genuine update, a correction or an error introduced in the second version. To decide among those explanations, give the Larch packet a revision note. Suppose the note says that two previously unfinished units were completed after the first report. That explanation can be tested against the new inspection records. If the note instead says that the first count was a transcription mistake, the relevant comparison is with the earlier underlying observations.
These are different factual histories even though both produce a change from eighteen to twenty. An update says the subject changed. A correction says an earlier description was wrong. The same numerical difference of two cannot tell the reader which history occurred. A headline that calls every revision newly completed work would conflate changes in the world with changes in a record.
The status field creates another useful comparison. The original local record said complete despite its count of eighteen. The altered record kept complete while changing the count to twenty. Under the opening exercise's twenty-unit completion rule, the first is internally inconsistent and the second is internally consistent. Internal consistency is still not an independent observation that twenty units were actually completed. The later message can remove one contradiction without supplying missing field evidence.
Now add a publication index that points to the first version while a press summary discusses the second. The archive may contain both correct files but associate the summary with the wrong one. Fixing that association is a different action from changing either signed message. A clear correction note can identify the affected link, the intended version and whether any underlying quantity changed.
A useful version comparison therefore reports the exact changed field, the explanation offered and the evidence examined for that explanation. It need not repeat every byte of a document in the article. It should retain enough identification that another reader can find the same versions and reproduce the comparison. The signature results become part of that record, not an automatic rule for selecting whichever version is newer, larger or more convenient for the story.
10. Two endorsements are not necessarily two independent observations
Consider another deliberately fictional Larch packet with a clerk's signed quantity report and a manager's signed summary. The summary repeats the clerk's count. If the manager relied entirely on the clerk's sheet, the packet contains two attributed statements but only one stipulated source of the quantity. Counting endorsements as independent measurements would double-count the evidentiary foundation.
This distinction is not an accusation of collusion or improper approval. A manager may be expected to review another person's work rather than repeat every observation. The question for the article is what that review actually did. Did it recalculate a total, inspect a sample, compare invoices or merely acknowledge receipt? Each activity can be useful, but they supply different reasons for confidence in the specific factual claim.
For a numerical exercise, suppose the manager checks four of the twenty scheduled units and records that all four match the quantity sheet. Four matches out of four selected items is the observed result. It is not proof that the other sixteen match, and the example supplies no random sampling design from which to derive a population accuracy estimate. The proper description preserves the selection rule and the unexamined remainder rather than converting a limited check into complete verification.
Now suppose a second reviewer examines the same four units. The packet contains eight inspection entries but still only four distinct units inspected. If instead the second reviewer examines four different units, the combined coverage becomes eight distinct units. Both situations have eight entries. The number of distinct objects and the overlap among checks determine what coverage can honestly mean.
A disagreement can be equally informative. Imagine that two reviewers record different quantities for one unit because one counts installed components and the other counts accepted components. The discrepancy may disappear when the definitions are aligned, while a genuinely unresolved disagreement about another unit remains. Treating every difference as either fraud or harmless terminology would discard the work needed to separate the two.
The value of a second endorsement therefore depends on its scope and basis, not merely its visual presence. A public account can recognize review effort without inventing independent corroboration. It can also identify where another observation would be useful: the uninspected units, the disputed definition or the missing acceptance record. That is a more actionable conclusion than adding another badge to a document whose central quantity has not been examined.
11. Describe a failed check without inventing its cause
The seven local checks were deliberately chosen to produce different outcomes. A changed count, different representation, wrong public key and added newline all failed against the original signature. Those failures arose from known changes in this controlled exercise. A real packet with a failed result would not necessarily supply such an explanation. The report would need to distinguish the observed outcome from a hypothesis about how it arose.
For a fictional support record, imagine an operator reports failure while another reports success. Before treating the reports as contradictory, compare their inputs. One may have checked the compact original and the other the formatted reading copy. One may have used A and the other B. If the inputs differ, the outcomes do not describe the same test. Identifying that difference is a concrete resolution, not an excuse to disregard an inconvenient failure.
Suppose instead both reports identify the same message, public key and signature, but one omits its software version and error details. The incomplete report should be labeled incomplete. It does not establish which implementation is correct or that an attacker altered the document. Additional reproducible evidence is needed. This article's small demonstration is not a test of such a disagreement and cannot supply its result in advance.
A reporting template for the Larch exercise can be brief: the input record's identifier and byte count, the demonstration key label, the operation attempted, the observed result and the scope not evaluated. For the first case, that means an eighty-seven-byte record, key A and a successful local signature check; the project's physical completion and the signer's real-world identity were not evaluated. The sentence gives readers more information than a standalone green icon.
It is also useful to distinguish a computation that failed from one that was never performed. If an attachment was unavailable, the report should not list it among tested failures. If an unsupported format prevented processing, that limitation is different from a completed check rejecting a supplied signature. No unsupported-format test was executed here; these are proposed reporting distinctions, not additional experimental results.
Finally, a saved record of the successful checks should not expose private signing material. This demonstration retained public verification inputs and outcomes while leaving its fresh private keys unsaved. That is a statement about this local run, not a claim that the script is a production key-management solution. Its purpose is to make the narrow observations inspectable without turning an explanatory article into a deployed trust service.
12. Build the public claim from the records that actually support it
The completed fictional Larch packet now supports a more careful account than the opening check mark. One local message reported eighteen of twenty scheduled units and labeled the project complete. A later message reported twenty. Both messages passed their respective local checks under demonstration key A. The first conflicted with the stipulated completion rule; the second removed that internal contradiction. Neither local computation inspected the work.
Separate field, acceptance and payment records answer separate questions. An installation sheet can report eighteen installed units. A manager's sheet can accept sixteen. Under the invented two-hundred-dollar unit price, those counts correspond to $3,600 and $3,200 respectively. A proposed payment based on the latter is not evidence that $3,200 was paid. The packet needs the actual fictional payment confirmation to support that next statement.
An editor could accurately write that the office's attributed report states a quantity, while a reviewed field sheet documents a narrower count or leaves an item unresolved. That wording does not pretend the document is worthless, and it does not present the document's assertion as the journalist's independently established fact. It identifies where the claim originates and what additional evidence was examined.
The same approach handles a correction without drama. If the publication linked the wrong version, correct the association and say so. If a total counted a duplicated unit twice, correct the count and explain the unit-level reconciliation. If the physical work later changed, distinguish that update from an error in the earlier report. These are specific documentary findings, not general verdicts about the honesty of every person associated with the file.
The narrowness of the local experiment is part of its usefulness. Its seven cases can be inspected because the inputs and outcomes are explicit. It does not evaluate a PDF signing product, a certificate chain, a timestamp service, a credential issuer or a real public agency. It does not prove that every implementation handles altered bytes correctly. It shows how several different evidentiary questions can remain open after an actual, successful cryptographic operation.
A public reader should be able to move from the published sentence back to the record that supports it. That path may lead to a checked source message, a registration record, a role assignment, an observation sheet or a payment entry. Different sentences may lead to different records. Keeping those paths visible is how a technically sound signature can contribute to accountability without being asked to manufacture factual certainty.
The appropriate conclusion is neither trust every signed claim nor ignore every signature. Preserve the verified relationship, identify the assertion's scope, and investigate the fact being asserted. A signature can make it harder to substitute a different message unnoticed. It cannot replace the work of finding out whether the message describes the world correctly.