What your customer checks before sending you their data

"We run it in a TEE" is a claim. On the other side of the table there is someone whose job is to turn claims into checks, and they will ask three questions: what code is running, who says so, and what does that code do with my data?

The good news is that all three have mechanical answers. The work is publishing them before the meeting rather than during it.

The checklist they run§

1. Fetch the identity. An attested service publishes GET /.well-known/attestation: the platform's signed document, the public key, the hash of the program and the hash of the configuration it runs under.

2. Verify the document. Signature, certificate chain to the platform's root, validity window — failing closed at the first doubt. With Synsema on the client this is one call, with the clock passed in explicitly rather than read from the host:

let v be attestation_verify(bytes(seen["document"], "base64"),
    {"format": seen["format"], "now": floor(now()),
     "expect": {"measurements": {"pcr0": PINNED}}})

3. Recompute the binding. The document commits to sha256(public_key ‖ program_sha ‖ config_sha). A document that verifies but binds a different key or program is worthless; a key that matches but has no document is just a key. The order matters: verify, recompute, compare, then send.

4. Read the configuration. config carries the ceiling the program ran under, whether information-flow labels were on, the profile, and whether the announced key is the one terminating TLS. Its hash is inside the signed payload, so a hardened configuration cannot be attested and a loose one served.

5. Ask what comes out. This is the question the hardware does not answer, and the one that decides the deal. synsema code check --json lists every declassify in the program with its line and the sentence the author wrote for it:

"declassify": [
  {"line": 11, "reason": "the yes/no is what the lender asked for; the score stays inside"}
]

One entry, one sentence, enforced at runtime: everything else that is private is refused at the response, the log and the file — before the effect happens.

What your side publishes§

Put these four things where a stranger can find them without asking you:

• program_sha of the release, and the expected platform measurement (PCR0 on Nitro, MRTD/RTMRs on TDX, measurement on SEV-SNP) taken from the platform's own build step.
• The provenance of the engine. gh attestation verify synsema-linux-x86_64 --repo kitecosmic/synsema answers with the workflow, the commit and the tag that produced those exact bytes. Attesting a program run by an interpreter of unknown origin attests the wrong half, and a good reviewer knows it.
• The declassify list for the version you are running, in words.
• A verifier they can run — twenty lines, no SDK, no account.

A page with those four is worth more in a procurement conversation than any amount of prose about hardware isolation.

The limits — say them first§

Stating the boundary yourself is what separates an engineering claim from a marketing one, and reviewers notice:

• An attestation proves which code runs, not that the code is good. That is exactly why the declassify list belongs next to it.
• It does not stop the operator from refusing service, dropping a request or shutting the machine down. Confidentiality and availability are different properties.
• Side channels are not covered by a signature. Timing, sizes and the number of lines a program prints leak, which is why the language treats a print inside a branch that depended on private data as a violation rather than redacting it — but no one should claim the class is closed.
• Verification support varies by platform. Synsema verifies Nitro documents against the pinned AWS root today; TDX and SEV-SNP quotes are produced by the engine and verified with the vendor's collateral on the client side. Tell the counterparty which one they are getting.

Who asks for this§

The pattern repeats across industries that look nothing alike:

• Data clean rooms — two companies cross their customer lists and each sees only the overlap.
• Confidential AI — a hospital runs a third party's model over records the vendor must not retain, and the vendor's weights stay unreadable too.
• Custody and signing — a key that may be used and never exported, with every use recorded.
• Private matching — orders matched without anyone seeing the book before the match.

They are the same architecture: a small program, data nobody outside may read, and one value that comes out with a reason attached.

Where to start§

Build the small version first: one route, one decision, labels on, an identity document, and the verifier in the hands of one friendly customer. Everything else — the site, the sign-up, the dashboard, the jobs, the billing — is ordinary product work that belongs outside the box, and deploys here in one command.

The engine-side reference is Attestation and Information-flow labels.