Development reference

Evidence bundles

Know what was checked. Understand what the record establishes.

From device to decision

Verification with a record.

01
Check authenticity
We read the device evidence, follow its trust chain to a pinned root, and confirm it answers a challenge issued moments earlier.
02
Evaluate requirements
Compare verified claims with the customer's policy. Authentic evidence can still describe an unsuitable device.
03
Sign the decision
The result, the policy decision and a digest of the evidence go into a record you can export. So do the limitations.

Two signatures. Two meanings.

The device evidence is signed within its attestation trust chain. The bundle signature is SEVEN KG's statement about the verification it performed. Checking the bundle signature establishes integrity and attribution to the expected signing key.

A record of placement.

The current customer API makes a bundle available after job placement. It does not prove that the job completed, that its output was correct, or that its data was hidden from the hardware owner.

Inside the signed payload

Context travels with the evidence.

Issuer & verifier version: Who made the statement, and which version of the verifier made it.
Time & job reference: When the verification happened, and which job it belongs to.
Attestation result: What the evidence claims, where each claim came from, and what it cannot establish.
Policy decision: The requirements applied, and why the result was accepted or refused.
Evidence & digest: A SHA-256 digest. The original evidence bytes as well, when they are included.
Limitations: The caveats, written into the signed content rather than left to the reader.

Inspect the format

A signed demonstration bundle

This synthetic example uses invented data and a dedicated demonstration key. It shows the envelope and signature-checking process. It is not a hardware test, production verification record, or proof of a completed job.

Download demo bundle Read the payload →

Bundle version      1
Signature           Ed25519
Issuer              SEVEN KG website demonstration
Device evidence     Synthetic
Hardware verified   false
Policy outcome      reject
Execution proof     None

Verify the demonstration locally.

Download all three files into one folder: the bundle, the demo public key, and the verification script. With Node.js installed, run this command from that folder:

node verify-demo.mjs demo-bundle.json demo-public.pem

The script checks three things: that the key identifier is the one expected, that the Ed25519 signature covers the exact payload bytes, and that the embedded evidence digest matches. It then prints the synthetic result. It does not validate a hardware certificate chain.

For production records, obtain the expected public key through an independently authenticated channel. Trusting a public key solely because it is inside the bundle lets an attacker replace both the content and its signing key. The key supplied here is for this demonstration only.

Download the example notes →

Why timestamps matter

Evidence has a time context.

During development, one Samsung attestation leaf certificate was observed with a lifetime of roughly 33 minutes. The bundle preserves the issuer's recorded verification result and time. Its signature can still be checked after the underlying certificate expires; that does not renew the certificate or establish the device's current state.