A run that already happened, and a receipt you can check.

On 18 October 2026 the quickstart script read a small sample PostgreSQL database of a robot-fleet service log. The data is synthetic. It fingerprinted 4 tables (2048 rows) and refused 1 table. It then made a receipt and checked it.

• Read-only. The script used a read-only login (SELECT only) and a read-only session. The database stayed as it was.
• One table refused, and named. calibration_files has a binary column (payload, bytea), so it was refused with UNSUPPORTED_COLUMN_TYPE. The message names the option that would allow it (--binary-as sha256). A refused table is always named.
• Counts and digests. The receipt holds counts, table and column names, logical types and SHA-256 digests.

The input sample

firmware_versions       4 rows
robots                 40 rows
service_visits       2000 rows
sites                   4 rows
calibration_files    refused: UNSUPPORTED_COLUMN_TYPE -> payload (bytea)
total                2048 rows in 4 tables

dataset fingerprint
44a7055a96db0a7dbcb7b5e18be5842e0c582f232afb2c038aa55e91395f0e4b

The verify output

VALID: the receipt is unchanged since it was signed. 4 tables, 1 refused, created 2026-10-18T11:20:03+00:00.
  dataset fingerprint 44a7055a96db0a7dbcb7b5e18be5842e0c582f232afb2c038aa55e91395f0e4b
  signing key fingerprint fd21234e26464ce2718f03d75e002e1a6ef2fc3a81cbba26bc244b41420a20c4
  (Self-signed: this does not show who made it, nor that the data is correct. Compare the key fingerprint with the one you were given.)

What VALID means. VALID means the receipt file is unchanged since it was signed. The receipt is self-signed: compare the key fingerprint with the one you were given to see who made it. Whether the data is correct, complete or compliant is a separate question.

Download

• sample_pg.sql, the public sample input (synthetic data), so you can run the same thing yourself
• sample-summary.txt, the input sample and the result, as the script printed them
• aarloven-intake-receipt-2026-10-18.json, the receipt
• verify-output.txt, the verify output
• full-log.txt, the whole run, start to end
• SHA256SUMS, the SHA-256 of each file above (sha256sum -c SHA256SUMS)

In the text files we replaced the folder paths of the machine that ran it with the bare file name. The receipt is exactly as it was made, because any change to it would make it fail the check.

Check it yourself

Use the quickstart script that made the receipt, and give it the receipt file:

quickstart.sh verify aarloven-intake-receipt-2026-10-18.json

On 17 October 2026 (19:52 Oslo time) we ran a test room on a real AWS Nitro Enclave in Stockholm and sent it three requests. The first reply, reply-good.json, is a PASS on 4 tests (T1 to T4). Dataset fingerprint 921056c113dd…f25c1.

• The input was a public robot dataset (the-future-dev/pusht-image-v1, Apache-2.0). This was a test run on public data, separate from any customer run.
• The reply was signed inside the enclave and carries an AWS Nitro attestation document that chains to the AWS Nitro root certificate.
• The other two replies are VOID, on purpose: one bit of the sealed data was flipped, and the room was started in debug mode. VOID means the room refused to give a result, and the reply says why.

Download

• reply-good.json, the reply that passed
• reply-tampered.json, the reply after one bit was flipped (VOID)
• reply-debug.json, the reply from debug mode (VOID)
• nitro-root-G1.pem, the AWS Nitro root certificate the chain is checked against
• SHA256SUMS, the SHA-256 of each file above (sha256sum -c SHA256SUMS)

How to check these replies (AWS's root certificate, the room's published build and the receipt itself) is in How you can check for yourself on the Security page.

What this shows. One run on public data, from a test room whose code is still under review. The production room is a different image, with a different PCR0.