A valid digital signature proves that a specific private key approved specific data. It does not prove that the person named on the screen controlled that key, understood the document, or had authority to sign it.
On Friday afternoon, the founder watched the SDK return a clean result. The payload matched. The cryptographic check passed. The launch checklist showed green.
Then someone asked the question the team had never tested: how would they prove who had actually used the key?
When correct data carries the wrong meaning
In September 1999, NASA’s Mars Climate Orbiter reached Mars after a journey of more than nine months. The spacecraft was supposed to enter orbit while engineers at the Jet Propulsion Laboratory in Pasadena monitored its progress.
Then communication stopped.
The numbers used during the mission had passed through the software. The calculations ran. The spacecraft responded to commands. Yet one team had produced thruster data in pound-force seconds while another system expected newton seconds.
NASA’s Mars Climate Orbiter Mishap Investigation Board, chaired by Arthur Stephenson, documented the mismatch in its 1999 Phase I report. The failure was not a missing number. It was missing meaning around a number.
That distinction matters in any system where one technical result is expected to support a larger claim.
A signature SDK can establish that the signed content has not changed and that the matching private key produced the signature. The product may still lack evidence connecting that key to a verified person, an authorized company representative, or a specific signing session.
The test passed because the test asked a narrower question than the customer would ask.
The launch claim was larger than the proof
The founder’s team had built around the sentence “the document was signed.”
That sentence contained several separate claims:
- The document remained unchanged after signing.
- A particular private key created the signature.
- A known person controlled that key.
- The same person completed the signing flow.
- That person had authority to approve the agreement.
- The team could reconstruct the evidence later if the signature was challenged.
The SDK covered part of that chain. The interface quietly implied the rest.
This gap often stays hidden during development because the happy path uses a test account, a familiar email address and a developer who already knows who clicked the button. Identity feels obvious inside a small team. It becomes contested when a customer’s procurement lead, lawyer or auditor reviews the record months later.
I have seen the same pattern in AI and automation work. A model returns the expected field, so the team treats the workflow as complete. Then a real approval depends on where the input came from, who reviewed the result and which version was accepted.
The output can be correct while the product remains unable to support the decision built on top of it. That is the same issue behind Kojo’s broken approval step: the visible action matters less than the authority and evidence surrounding it.
Test the evidence chain before the feature
The next useful test starts after the signature succeeds.
Take one completed agreement and ask a team member who did not build the signing flow to prove what happened. Give them only the records the product would retain in production.
Can they connect the signature to an authenticated account? Can they show how that account was verified? Can they identify the document version presented at the moment of signing? Can they establish when consent occurred and which evidence was captured? Can they distinguish an authorized company signatory from someone who merely had access to an inbox or device?
These questions should shape the product before launch. They affect account recovery, delegated access, audit logs, document versioning and the language shown beside the signature button.
They also reveal where a team has confused authentication with authorization. A person may successfully access an account and still lack authority to sign for the company. A valid key can prove possession without proving employment, role or intent.
For high-consequence actions, I use a stricter test: what would we need to show a skeptical third party who was absent when the action happened? That question is also useful before an AI agent takes its first irreversible action.
Move the launch gate one layer up
The Friday decision should not depend on whether the signature function works. That question has already been answered.
The launch gate should ask whether the evidence supports the promise made in the interface, sales material and customer contract. If the product says “signed by Ama,” the team needs more than proof that a private key signed a hash. If it can only prove key possession, the product must say so plainly or add the missing identity controls.
NASA’s 1999 investigation found valid calculations carrying incompatible units. The software processed the values it received, but the wider system assigned them the wrong meaning.
A signing product faces the same class of risk when it turns “this key signed these bytes” into “this person approved this agreement.” Before shipping, export one real audit record, hand it to someone outside the build team and ask them to prove every word in that second sentence.
Comments
No comments yet.