Questions, answered

No. Nothing scans your folders, monitors your Word documents, or sits in the background looking for changes. LoomSeal is a format. Software adopts it and writes its own records through it as it works: a deploy tool writes an entry for every deploy, who ran it, what changed, when. Each entry is chained to the one before it and signed as it is written, not inspected later.

The seal covers those records and nothing else. It cannot prove the software wrote down everything that happened, only that nothing written was changed or removed after the fact.

One ordinary JSON file. Open it in a text editor and you will see the records, the chain links, the anchors, and the signature. There is no special package and no proprietary container.

You can email it, attach it to a ticket, archive it for years, or hand it to an auditor. Checking it involves no service, no account, and no vendor. The file is the whole thing.

Verification fails, and the verifier says where. Every record is chained to the one before it, so changing a character, deleting an entry, or reordering anything breaks the chain arithmetic from that point on, and the verdict names the break.

That is the point, not a bug. Nobody can stop a person from opening a JSON file in an editor. The format makes sure any change shows.

Anyone, with free tools: a command line tool, a Python reference implementation, or the browser verifier on this site. The browser one installs nothing and keeps working with the network off once the page has loaded. No account anywhere, and nobody at KordLoom is involved in the check.

Each one answers with a verdict: signed, chained, anchored, spanned, or it names exactly what broke.

Say your deploy tool writes its records through LoomSeal. The auditor asks for the change history, so you export bundle.json and attach it to the ticket. The auditor drags the file into the browser verifier on a laptop with WiFi off, and it answers VERIFIED, or names the entry that broke and why.

No portal logins and no screen shares. The file carries the evidence, and the arithmetic settles it.

Because generating convincing artifacts became free. Screenshots, logs, dashboards, and compliance documents can all be produced or edited in seconds, which means none of them are evidence anymore. When anything can be fabricated, the scarce and valuable thing is a claim a stranger can check.

LoomSeal is the format for such claims: one file that carries what happened, the digests of the evidence behind it, its position in an append-only chain, the external anchors that fix that chain in time, and a signature. The verifier checks all of it offline, with no account and no trust in the producer or in KordLoom.

The claim that makes it worth having is narrower than tamper evidence, which a timestamp already gives you. It is completeness. The entries are linked to one another, so you are not only shown what happened, you are shown that nothing was removed.

Three things happen while your software runs, and one happens when somebody asks.

1. Your software records what it did, which it already does.
2. Each entry is hashed together with the one before it, so entry three's link covers entry three and entry two's link. Alter or delete anything earlier and every link after it changes.
3. Every so often the current head of that chain, one 64-character string, is published somewhere you do not control: a git commit, a timestamp authority, a transparency log.
4. When somebody asks for evidence, you export a bundle: the claims for the window they care about, the digests of any files behind them, the chain coordinates, the anchors, and one ed25519 signature over the whole document.

The verifier runs that backwards, offline. It checks the signature, recomputes every link from the claim contents, confirms each entry points at the one before it, and matches the anchors against links in the chain. A break is named, not merely detected.

The anchor is the part doing the real work. A chain on its own only proves internal consistency, and anyone could sit down and build a consistent one this afternoon. Publishing the head as you go is what makes that worthless to a forger, because a convincing fake would have required lying from the first entry and publishing the false heads the entire time. Worked through at length on how it works.

Three things.

1. The producer holding the signing key assembled these exact claims.
2. Any artifacts supplied match their recorded digests.
3. The claims sit in an append-only order that has not been reordered, rewritten, or trimmed since its heads were anchored.

The third is the point, and it is the one that is hard to get any other way. It is completeness: not merely that these entries are genuine, but that they are all of them. The LoomSpan profile takes that further with continuously attested population counts. The conformance wording is exactly four words: signed, chained, anchored, spanned.

That the producer observed the world honestly at capture time. A chain fixes the record, not the character of the recorder. A dishonest producer can record fiction. What it cannot do is rewrite that fiction later without breaking the chain, or backdate a history it never kept.

Two limits in the current verifier, stated plainly rather than buried.

• Keyed chains verify structurally for third parties, and fully for the key holder.
• An rfc3161 anchor proof is opened and checked against the link it attests to. Anchors of other types are confirmed by fetching what they reference, so relying parties confirm those references out of band.

Proof that overclaims is just marketing.

A trusted timestamp proves one document existed at one moment. That is genuinely useful, and LoomSeal uses timestamps as one kind of anchor rather than competing with them. But a timestamp says nothing about the documents you chose not to stamp.

Nobody can tell from a stamped file whether it was the only record or the flattering one out of nine. Stamp the clean deploys and skip the incident, and every stamp you hand over is individually valid and collectively a lie by omission.

A chain closes that gap, because the entries are linked to each other rather than each standing alone. Remove one and every link after it fails to recompute, and the verifier names where. So the set is either whole or visibly broken. A timestamp answers did this happen. A chain answers is this all of it, and that is the question an auditor is really asking.

Because the property needed is tamper evidence, not distributed consensus. An append-only keyed chain plus anchors published where the producer cannot rewrite them, a timestamp authority, a public repository, a transparency log, delivers that property without gas fees, without volatility, and without asking an auditor to believe in a coin.

Anchoring borrows exactly one idea from that world, publishing a commitment where you cannot take it back, and leaves the rest.

Use them where they fit. They answer a different question well, and if you are signing container images or build provenance you should reach for cosign and SLSA rather than this.

They attest to artifacts. Each attestation stands alone and says what one thing is. That is the right model for a supply chain, where the unit of interest is a build or an image.

An operational record is not a set of artifacts. It is an ordered stream, and the question an auditor asks is not whether entry 40 is genuine but whether anything is missing between 1 and 40. Independent attestations cannot answer that, because nothing in the thirty-ninth says a fortieth should exist. LoomSeal entries carry sequence numbers and each link is computed over the one before it, so a gap inside a declared range has nowhere to hide.

The second difference is what verification costs. Checking a Sigstore signature usually means reaching a certificate authority, a transparency log, or a trust root, and the guarantee lasts as long as those services do. A LoomSeal bundle verifies from the file with nothing running and no network. Evidence that has to satisfy an auditor on a segregated network, or still verify in ten years, is a different requirement from evidence checked during CI.

None of this makes them alternatives. A bundle can travel inside a DSSE envelope for tooling that expects one, and rekor is a declared anchor type: publish a chain head to a transparency log and the anchor is as strong as that log. This verifier confirms a rekor anchor by reference rather than fetching it, so the relying party checks the log itself.

You stop asking people to believe you. When an auditor, a security reviewer, a customer, or a regulator asks how you know your controls ran, you send a file they can verify in seconds instead of a deck they have to take on faith.

And because chained history cannot be created retroactively, every quiet month you record is evidence a competitor who starts later can never manufacture. The record compounds.

You verify instead of trusting. Drag the file into the browser verifier or run the command line tool. No vendor portal, no screenshots, no phone calls to confirm a PDF. Offline, in seconds, the math either holds or it does not. If the bundle was altered, verification fails loudly and names the break.

Adopting the format means your software writes its own records through LoomSeal as it works. Nothing watches from outside. The producer does the writing.

Import the seal package from the repository to sign bundles and compute generic chain links, follow the bundle shape in the spec and the schema, and register new claim types through the registry. Producers own their payloads. The envelope, chain profiles, and verification procedure stay common so one verifier checks everyone. SwitchTender was the first producer to ship, if you want to see the format in real use.

You should not have to, which is the design. The verifier is small, Apache-2.0, and built on the Go standard library alone, so every line that touches a verification decision is in the repository and readable in an afternoon.

If you would rather not run our binary, build it from source, or implement your own verifier from the spec and the schema. The format belongs to anyone who implements it.

A sealed format cannot be a standard, and proof that only its vendor can check is not proof. KordLoom's products are the business. The proof language they speak is public on purpose.

The license tiers are deliberate: the products carry their own licenses, while the format, schema, and verifier are Apache-2.0 so adopting them requires no negotiation and carries an express patent grant. The LoomSeal name and mark are trademarks, not part of the code license.

SHA-256 for content digests, HMAC-SHA256 for keyed chains, ed25519 for signatures. Boring on purpose: every primitive is decades-tested, standardized, and available in every mainstream language.

There is no blockchain, no token, no consensus, and no network dependency. The security model is a private ledger with a maker's mark, not a coin.

The chain key is the secret that prevents forgery, it is generated on the producing install, and it never travels: not in bundles, not to KordLoom, not anywhere. Signing keys likewise stay on the install. Only the public key travels, and relying parties can pin its fingerprint from the operator's trust page.

Verification is offline by design, so there is no service to compromise between the evidence and the person checking it.

The chains and digests rest on SHA-256, which known quantum algorithms do not meaningfully weaken, so the part of LoomSeal that carries history is built on the quantum-resilient half of cryptography.

The ed25519 signature is the component a large future quantum computer would break, and the format is ready for that: signatures carry an algorithm field, so a NIST-standardized post-quantum signature can be added beside ed25519 without a new envelope.

Anchoring already bounds the damage, because a signature forged years from now cannot rewrite history whose heads were published outside the producer's control before such forgery was possible. A quantum computer does not un-publish a hash.

Nothing happens to your proof. Bundles verify offline forever, the spec and schema and verifier are Apache-2.0 and forkable, and no verification step ever contacts KordLoom. Records you anchored stay anchored, because the anchors live outside KordLoom too.

A proof format you could lose in a vendor's shutdown would not be worth adopting, so LoomSeal is built to outlive its author.