# What your customer checks before sending you their data

> A confidential deployment nobody verifies is an ordinary deployment with extra cost. Here is the checklist a serious counterparty runs, what your side has to publish for it to pass, and the limits worth stating yourself before they ask.

2026-09-20 · https://synsema.com/blog/what-your-customer-checks-before-sending-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:

```synsema
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:

```json
"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](https://synsema.dev/en/0.6.x/24-attestation) and [Information-flow labels](https://synsema.dev/en/0.6.x/23-labels).