Development reference

Evidence bundles

Know what was checked. Understand what the record establishes.

From device to decision

Verification with a record.

01
Check authenticity
Check the device evidence, its trust chain, and its binding to a fresh challenge.
02
Evaluate requirements
Compare verified claims with the customer's policy. Authentic evidence can still describe an unsuitable device.
03
Sign the decision
Preserve the result, policy decision, evidence digest, and limitations in an exportable record.

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 verifier version it identifies.
Time & job reference: When verification was recorded and which job the record concerns.
Attestation result: The source, claims, provenance, and properties the evidence cannot establish.
Policy decision: The applied requirements and the reasons behind acceptance or rejection.
Evidence & digest: A SHA-256 digest and, when included, the original evidence bytes.
Limitations: Explicit caveats included in the signed content.

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 the expected key identifier, Ed25519 signature over the exact payload bytes, and the embedded evidence digest. 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.