Seal1618
Pilot-readyThe enterprise protocol for authenticated, stamped, independently checkable records
Seal1618 is the enterprise protocol our sealed evidence is checked against: a published, versioned format that authenticates a record, stamps it with an independent date, and lets anyone verify it offline. The specification, the reference verifier and the samples are public; verification is free and stays free. Adopt it and your records become checkable outside your walls, by parties who have never met you, against a rule neither of you controls. Acceptance follows — and your records keep their value after every contract ends.
- Product line
- Seal1618
- Sectors
- Government & public sector, Finance & investment, AI & digital
- Independent timestamping
- Specified as receipt formats — carried per document
- Open to check
- 5 public surfaces
What it is for
Every vendor invents its own export and its own “verified” badge, so evidence stops being checkable the moment it crosses an organisational boundary. A check is only worth something when the rule it runs against is published — and implementable by someone who is not the vendor. Open the rule, and acceptance follows.
- Platforms and vendors that want their records checkable outside their own walls
- Receiving institutions who would rather re-run a check than accept a screenshot
- Government agencies and standards-minded teams evaluating evidence formats
- Developers implementing verification in their own language and toolchain
What you get
One public rule instead of a thousand private ones
Two parties who have never spoken can agree on whether a document verifies, because the rule they are applying is the same published one. Agreement without a meeting.
Free to verify, open to implement
Nothing about verification is metered, gated or watermarked, and no permission is asked. Implementation is open under the published licence, with conformance shown against the published vectors — and the Seal1618 name is reserved for implementations that conform. The free check is how a protocol earns its keep, and how your records earn trust.
The check outlives the vendor
Verification runs offline against a published rule, so a sealed document stays checkable whether or not its producer — or we — are still around to ask. Your records keep their value after every contract ends.
Honest about its limits
The specification says what a seal proves and what it cannot, the verifier reports what it did not check, and the kit carries a written list of claims we refuse to make. Precision is the point.
What you can check for yourself
Read the specification at creation1618.com/verify, then run the reference verifier over the samples — alter one byte and watch it refuse.
Open the sample receipt in any browser: nothing installed, no network, and it re-checks its own seal in front of you.
Fetch the third-party receipts in the sample history — they resolve against authorities we do not run.
Hold an implementation of your own to the published conformance vectors — every verdict a conforming verifier must reach is in the kit.
Paste an autonomous software agent’s audit-trail export into the browser verifier and watch it check the chain — and print, unprompted, what a self-kept trail cannot show.
Seal1618 is a protocol, not a deployment. It specifies how a sealed document carries independent third-party receipts, and the sample history in the kit carries real ones. Whether a given document carries them is a fact about its producer — the verifier checks what is there and counts what is not.
What a demonstration shows
- The published specification — versioned, with its version history and format-support policy in the document itself
- A reference verifier: one dependency-free file, readable in full before you run it
- Sample sealed documents — the fixtures an independent implementation checks itself against
- A self-checking receipt format any browser can open, offline
- A profile of an IETF Internet-Draft for tamper-evident logs of autonomous software agents — an agent’s own audit trail verifies with the same kit, in the draft’s native export or sealed into a document
Built on
- Published, versioned specifications with stable identifiers
- Plain, open documents — nothing proprietary needed to read them
- Offline verification: no account, no network, no involvement from us
- Standard cryptography; independent timestamps carried in-document
- Free to verify; open to implement under a published licence
This names what the platform is built on, not how it is built. The how is shown in a technical deep-dive, under a mutual NDA.
Where this actually is
Built end to end and exercised against real external checks. Ready for a first pilot on your own data.
Seal1618 is pilot-ready.
Seal1618 is a document format and a verification recipe. A verified seal proves integrity — never that the facts inside are true. Implementation is open under the published licence and is not an endorsement; every sealed document names its own issuer, and the Seal1618 name is reserved for implementations that conform.
Why this travels across the two markets
A format crosses a border the day both sides agree to read it. A platform, a university or an agency can implement the published protocol under its licence and prove conformance against the published vectors; verification needs no relationship with us at all. Research and standards collaboration on the format is an open invitation.