A bid record is evidence, so someone who does not trust us must be able to check it
A bid file is read later by people who were not in the room: an auditor, a challenger, a security reviewer. Klarum keeps a tamper-evident record and encrypts customer documents, and the two are different kinds of protection. One part of the record can be checked by an outsider without our help. The rest rests on our word, and we say which is which.
A bid record is read by people who were not there
A bid is written under deadline and examined long afterwards. A challenge, a post-award review or an internal audit asks what was decided, by whom, and in what order. The answer is the record, and the record is only worth as much as the reader's reason to believe it has not changed. "Our system says so" is a weak reason when the system belongs to the party being examined.
Two readers, two questions
The bid manager wants to defend a submission: show that an approval came before the submission, that a figure was not edited after sign-off. The security reviewer sitting behind them asks something different. Who can read our documents, and what do we have to take on trust? We keep the questions apart because the answers differ in strength, and a summary that blends them stops being true.
What Klarum does today
Auditable events are written to a tamper-evident chain, so altering an old entry breaks everything after it. Batches are summarised into a signed root, and a receipt for an event can be checked offline with a standalone script, without contacting us. That is the same idea as the append-only logs that Certificate Transparency made auditable by outsiders[1], and it is the standard we mean by "a third party can check". Customer documents are encrypted at rest, so a stolen storage credential or a stray backup does not yield readable files. The construction is described in the deeper note on confidentiality and verifiability, and in our whitepaper[2], and we do not repeat it here.
| Claim | Who can check it | Without trusting us? |
|---|---|---|
| An entry in the global coverage chain is unaltered and in position | Anyone with the receipt and the script | Yes, for inclusion in a signed root |
| That root was published publicly | Anyone, on a test network | Partly; a test network is not durable evidence |
| An entry in a customer workspace trail is unaltered | Anyone with a receipt | No; we hold the only signing key |
| Documents are unreadable if storage is exposed | Customer and reviewer, by inspection of terms | No; it is our control, not a proof |
| Klarum cannot read customer documents | Not claimed | Not true; we hold the key |
Discussion
Limitations
We start with what this does not give you. Only the global coverage chain is anchored publicly, and only on a test network, which has no commitment to continuity and can be reset. That shows the mechanism works end to end. It is not a durable third-party timestamp, and we do not present it as one.
The record of a single customer workspace is the one a bid manager most wants to defend, and it is not independently verifiable today. We hold the records and the signing key, so an actor with both could rewrite a history and sign the rewrite. The chain forces that rewrite to be wholesale rather than piecemeal. It does not remove the assumption. What a receipt there proves is that we signed a batch containing the entry, not that your team did a thing at a given moment.
On confidentiality, encryption at rest is an operational control under keys we hold. It is not zero-knowledge, and we can read customer documents. A security reviewer should read it as protection against exposure of storage, and nothing wider. We make no certification or compliance claim here, and none should be inferred.
Next steps
A signature the customer controls would remove the assumption on the workspace trail, and anchoring somewhere durable would turn a demonstration into evidence. Neither is shipped.
Ask what you can check without us
The question to put to any vendor is not whether records are protected, since the answer is always yes. It is which part an outsider can verify alone. For us, today, that is inclusion of an entry in the global coverage chain, checked offline. For the rest, you are relying on us, and the deeper note sets out exactly where. Read it before you rely on any of this.
References
- [1]RFC 6962: Certificate Transparency. IETF. The Merkle tree construction our audit roots follow, including the leaf and node hash prefixes.
- [2]Confidentiality and Verifiability, v1.3. Klarum. Our own security whitepaper: every control, its status, the claims we decline to make, and a revision history that records what earlier editions got wrong.