Aarloven
Use case · a robot vacuum for an office in Oslo
Test the robot on your floor. Keep the map to yourself.
A robot vacuum maps the office it cleans. This is how a buyer in Oslo tests one before accepting it, without the floor map ever reaching the robot maker. The office, the robot and every number here are synthetic.
-
1 Your office, Oslo
The robot cleans and maps
It drives itself on your real floor, on a test Wi-Fi you control.
map: with you
-
2 Your laptop
You lock the recording
The sealer checks the sealed room first, then locks the files so only that room can open them.
map: locked
-
3 Sealed room, Stockholm
The tests run inside
No disk and no login. It opens the files in memory, runs the agreed tests, then wipes them.
map: in memory, then wiped
-
4 You and the robot maker
Both get one receipt
Pass or fail for each agreed test, signed. Your IT team can check the signature offline.
map: not on it
The robot maker sends its firmware into the room (step 3) and gets the receipt (step 4). It never gets your map, your recording or a key to them.
What buyers ask before the first run.
- The robot has arrived. How do we test it?
Put it on a test Wi-Fi network you control, lay 12 marked test patches of grit on the floor, and press start. The robot maps the office and cleans it, in about an hour. That run is the recording the tests use.
- Does it run on its own, in a sandbox?
The robot drives itself on your real floor. A vacuum has to touch the real floor, so that part is not simulated.
Two things are sandboxed. Its network: the test Wi-Fi records every connection and refuses any place not on the agreed list. And its software: in the sealed room, the robot maker's firmware runs again on your recording and on simulated versions of your floor, with no network at all.
- Do we scan our floor first?
Yes, and you need no separate scanner: the robot's first run is the scan. Do it with one pilot unit before the rest of the order ships. The same locked scan is then reused for every firmware update, with no new run on your floor.
- Who sees our floor plan?
You, and the sealed room while it runs. Not the robot maker, not Aarloven, not AWS. Aarloven keeps fingerprints of the files, never the files. The full table
Day one · your office · firmware 4.2.1
Day one, the robot maps your office.
A robot vacuum knows little: where it is, which way it faces, what its sensors hear. Its lidar draws your floor plan as it drives, and that plan is the file to protect. Play the run.
Your floor, as the robot records it
10 cm cells · 28 × 16 mCleaned so far
agreed: ≥ 95 %
- Heading
- 0°
- Drift
- 0.00°/min
- Room
- Reception
- Dirt detected
- 0
- Test patches
- 0 of 12
- Bumps · stuck
- 0 · 0
- Wi-Fi
- 0 connections
The recording, live
Rotation drift, each minute
How far the gyro's heading wanders from the lidar's, in degrees a minute. Agreed limit: 2.0.
Floor cleaned over the run
Share of the floor the robot can reach, cleaned so far.
What the robot recorded in this run
| Stream | What it holds | Rate | This run | Sensitive because |
|---|
Camera frames are not part of the recording: the robot's camera turns them into labels such as “cable” or “chair leg” on the robot, and only the labels are recorded. The rates are this illustration's; a real robot records lidar 5 to 10 times a second.
Your laptop · working today
You lock the map before it leaves your laptop.
Left, the map file as it sits on your laptop. Right, the same file locked. Outside the sealed room, nobody ever holds more than the right-hand picture. Both are made in this page, from the run above.
A new key gives new noise. The fingerprint of your file stays the same, and that fingerprint is what goes on the receipt.
The package
| File | Size | Fingerprint (SHA-256 of the open file) |
|---|
- The sealer checks the room. It asks the room for a document signed by AWS's hardware, and checks that the room runs the exact code named in your contract, and that the answer is fresh.
- It locks the package. The file key is itself locked by AWS KMS under a rule that releases it only to that measured room code. The robot maker, Aarloven and AWS staff cannot open it.
- You keep it. The locked package stays with you. To test a firmware update later, you send the same package again; the room checks its fingerprint against the first receipt.
Sealed room · Stockholm · next, with design partners
The tests run where nobody can look in.
The robot maker's firmware runs again on your recording, then on likely changes to your office written by an offline model. Code checks every result against the agreed limits.
Firmware under test
Likely changes to your floor, written by the offline model
The simulator must match your run before its variants count
Floor cleaned over time: your recording, and the simulator driving the same firmware on your scanned floor.
Simulator trusted for this floor
If the simulator could not reproduce your real run within these limits, the variants would not be scored, and the receipt would say so.
Quality · firmware 4.2.1
Tested on your real floor, and on twelve likely changes.
Each criterion is scored on your real run and on every variant. It passes only if all of them pass. You and the robot maker agreed the limits before delivery.
| Criterion | Your run | Your run and the 12 variants | Decided by code |
|---|
your runa varianta variant that failsthe agreed limitHover a dot for its value.
What the offline model does, and what it may not do
| It does | It may not | How that is held |
|---|---|---|
| Reads your scanned map, room names and your notes, then writes variants: chairs on a Monday, gravel in January, a rug you plan to buy | Change what was measured on your floor | Your run's scores come from your recording only. Variants are scored in a separate column |
| Writes each variant as a short, typed proposal | Invent rooms, stairs or walls that are not on your map | A gate checks every proposal against the map before it runs. In this case it refused 2 of 14 |
| Reads the results and writes flags for a person, in plain words | Decide pass or fail | Every verdict is a number compared with an agreed limit, by code. The receipt marks what a machine checked and what a person did |
| Runs on the room's own processors | Reach the internet, or keep anything after the run | The room has no network connection except to AWS KMS, and no disk. Its weights fingerprint and seed are printed on the receipt, so the same input gives the same variants again |
One signed receipt, the same for both sides.
What the receipt says about your floor
- Its area and its fingerprint
- Counts and scores, never coordinates
- The model's flags, written without positions
What it never holds
- The map, the path or the lidar scans
- Camera frames, which never left the robot
Who can see your floor plan.
A floor map and camera images can show how a building is laid out and who is in it. Here is every copy, and who can open it.
| The data | You | Robot maker | Aarloven | AWS | Sealed room |
|---|
Nothing in this case goes to the robot maker except the receipt, so your floor never leaves the EEA. The room runs in AWS's Stockholm region. Norway's data protection authority, Datatilsynet, names strong encryption, with keys the foreign party cannot reach, as the central safeguard when data does cross a border: its guidance.
Test before you accept, and before every update.
Before the order ships
Recommended. The fleet waits for one receipt.
- Week 0One pilot unit, or the maker's demo unit, arrives
- Day 1First run on your test Wi-Fi; you lock the recording
- Day 1The room tests your floor and the variants
- PassThe rest of the order ships, or the payment milestone is released
On delivery
When the whole order is already in your building.
- Day 0The fleet arrives; the units stay on the test Wi-Fi
- Day 1Unit 1 makes the first run; you lock it
- Day 1The room tests your floor and the variants
- PassAll units go live on your normal network
Every update
No new scan: the room reuses your locked floor.
- NoticeThe maker announces firmware 4.3.0; the fleet holds
- Day 1One unit updates on the test Wi-Fi and runs once
- Day 1The room tests 4.3.0 on your locked floor and the variants
- Pass or holdPass: the fleet updates. Fail: the update stays held, and the maker gets the receipt
What works today, and what we build next.
Working in the prototype
- The sealed room runs in Stockholm (AWS Nitro Enclave, EU)
- The key is released only to the room's measured code (AWS KMS)
- You lock samples with a sealer you run yourself
- The sealer checks the room before locking
- A changed package is refused
- Tests are decided by code
- The receipt is signed in the room and checkable offline
- A test room has run on a public robot dataset (17 Oct 2026)
Next, with design partners
- Running robot firmware on a locked recording
- The floor simulator and its calibration check
- The offline open-weights model that writes variants and flags
- Test Wi-Fi traffic checks
- Holding over-the-air updates until they pass
- A named expert's separate signature on each receipt
This page is an illustration. The office, the robot, the firmware versions, the recording, the model's text and every number are synthetic, made in your browser from a fixed seed, so they are the same on every visit. The locking (AES-256-GCM) and the fingerprints (SHA-256) are real computations on that synthetic data.