How it works, in one minute
What to have in your head before you present it. Everything else in this guide hangs off these five boxes.
The one sentence to say
“These records cannot be changed after they were recorded, and a public timestamp proves when they existed. You check this yourself, in your own browser, without trusting us.”
What a green tick means — and what it does not
| It proves | It does not prove |
|---|---|
| No reading has been edited, deleted, reordered or back-dated since it was recorded. | That the reading is correct. A probe in the wrong place reports honestly and still passes. |
| Every expected reading is there, or the gap is visible. | That the device was honest at the moment of capture. Device signing needs a security chip that is not fitted yet. |
| The records already existed when a named Bitcoin block was mined. | That the storage was compliant. That is still a judgement for the inspector. |
Two clocks to know
- A “day” is a UTC day: 05:30 IST to 05:30 IST the next morning. Times on the dashboard are shown in IST.
- A day is closed automatically at about 05:35 IST. Its Bitcoin timestamp usually confirms 1–2 hours later. So yesterday's day is normally ✅ by about 08:00 IST.
Readiness check
Run this the evening before and again an hour before you present. It runs in this browser against the live service, using the same checking code as the dashboard. It changes nothing.
Not run yet. Opened from the dashboard, the address and token are filled in for you.
Preparation checklist
Ticks are remembered in this browser only. Clear them before the next demo.
Demo script — about 25 minutes
Scenes 0–6 for everyone. With C-DAC in the room, add scene 4b and the technical extension at the end. Open with the problem, not the technology.
“Today an inspector asks for the temperature log and gets a spreadsheet or a printout. It could have been tidied the night before, and nobody could tell. We want to make that impossible to do quietly.”
The four tiles at the top of the dashboard.
“Live” with the green dot, the last reading a few minutes old, and the countdown to the next one.
“That is a real probe on a board in our lab. It reads every ten minutes. Nothing on this screen is simulated.”
Choose the sensor → Finished day → pick the day the readiness check recommended. It verifies straight away. Then open the 🔗 Proof tab.
✅ Verified, the reading count (for example “145 readings of 144 expected”), and the Bitcoin block number. Read two or three of the checks aloud. They are written to be read.
“This check ran in your browser, not on our server. If our server just said ‘verified’, you would have to trust us. Your browser redid the maths itself.”
The 📈 Readings tab (open by default). Then change the Storage limits preset at the top of the page, for example to “Store below 25 °C”, and watch the count change.
Out-of-limits count, the longest excursion and when it started, and mean kinetic temperature. Flagged readings are listed first.
“The limits are yours to set, not the company's. And notice that changing them moved the excursion count, but not the verdict. Whether the data is intact and whether it is within limits are separate questions.”
🧪 Try to break it → Cool a reading by 2 °C. Then Edit the data and the summary to match. Then Put it back.
Which check caught it. On the last one, pause: changing the records and the summary together is what a sceptic thinks of, and it still fails.
“Nothing was uploaded. You hold the file, you can change anything in it, and it still will not verify. To make it agree, you would have to rewrite a Bitcoin block.”
On the server: change one reading with SQL, verify on the dashboard (❌ Tampered, check 1
only), then restore it. Full commands and the restore step are in DEMO.md §3b.
Write the original value down first — there is no undo.
In the 🔗 Proof tab: Check it without trusting us →. Follow section 5 of this guide. Let them choose which Bitcoin explorer to open.
“That block was mined at a time none of us controls, and the records you just looked at were already inside it. They cannot have been written afterwards.”
In the 🔗 Proof tab: ⬇ Download the evidence file. Then 📂 Open an evidence file and choose it.
“This is what you would receive by email for an inspection. Open it here and it is checked in your browser. Our server is not asked anything.”
Read the yellow note under the verdict aloud. Then the questions in section 7.
Technical extension for C-DAC (10 min)
- Why the browser: the checks are the same Rust code the service uses, compiled to WebAssembly. The verifier and the prover cannot drift apart.
- Why it scales: one timestamp covers the whole chain behind it. The cost is one timestamp per interval, however many sensors there are.
- Completeness: the device numbers its own readings, so a deletion leaves a hole (check 2). An outage leaves a gap in time instead (check 4).
- The limits we know about: no device signature yet (needs the ATECC608A
chip), a server-side signing key, and hash algorithms that will one day need re-anchoring.
See
problems.md.
Verify on OpenTimestamps — step by step
This route takes our software out of the check entirely. It uses two websites that have nothing to do with us. No installation, no commands.
Before you start
- Pick a day whose verdict is ✅ Verified. A day showing ⏳ Awaiting anchor has not reached Bitcoin yet. OpenTimestamps will then only say “pending”.
- Use a normal browser with internet access. Both sites are public.
Step 1 — get the two files from the dashboard
- On the dashboard, choose the sensor and the day. Wait for the verdict.
- Open the 🔗 Proof tab, then Check it without trusting us →. A new tab opens.
- Click both download buttons. You get two small files:
ledger-head-<block>.bin— 32 bytes. The fingerprint of the whole record chain at the moment it was stamped.ledger-head-<block>.bin.ots— about 4 KB. The proof about that file.
- Do not rename them. OpenTimestamps pairs the proof with its file by name.
Step 2 — let OpenTimestamps check them
- Open opentimestamps.org.
- In the stamp-and-verify area, drop in the
.otsfile, then the.binfile when it asks for the original. Dropping both together also works. - Expect a success message that names a Bitcoin block and the date it attests. The block number should match the one on the dashboard.
Step 3 — look the block up on a Bitcoin explorer
- Use the explorer links on the dashboard's proof panel (blockstream.info, mempool.space, blockchair.com), or type the block number into any explorer you prefer.
- Confirm the block exists and note when it was mined.
- Optional: compare the explorer's Merkle root with the value the dashboard shows under “This proof says block … has the merkle root below”. They should be identical.
How the day connects to that fingerprint
OpenTimestamps proves the chain's fingerprint existed by that block. The dashboard checks that the day's summary is sealed inside that chain (checks 6a and 6b). One timestamp covers every day behind it, which is why the file is named after the block and not the day.
Anyone who wants to check that link without our code can recompute it
with sha256sum. Use the “Show the hash-by-hash walkthrough” button at the bottom of
the same page.
What you might see, and what it means
| You see | Meaning / what to do |
|---|---|
| “Pending” or “not yet confirmed” | The timestamp is not in a block yet. This is normal for 1–2 hours. Pick an older day. |
| It asks for the original file | Drop the .bin file, the one without .ots. |
| “File does not match” or similar | A renamed or mismatched pair. Download both again from the same day and keep the names. |
| “Not stamped yet” on our page | This day has no proof yet. Stamping runs every few minutes, then Bitcoin takes an hour or two. |
For technical reviewers — the command line
pip install opentimestamps-client ots info ledger-head-<block>.bin.ots # shows the operations and the block ots verify ledger-head-<block>.bin.ots # needs a local Bitcoin Core node
Do not try ots verify live unless you run your own Bitcoin
node. Name it for anyone who does.
What the checks mean
A finished day gets ten checks. Each answers a plain question, and a failure accuses someone of something specific.
| # | Check | Question it answers | ALCOA+ |
|---|---|---|---|
| 1 | These are the readings that were recorded | Do the readings add up to the day's published fingerprint? | Original, Consistent |
| 2 | Nothing has been deleted | Does the device's own counter run unbroken? | Complete |
| 3 | Every expected reading is here | At least as many readings as the 10-minute interval requires? | Complete |
| 4 | The sensor never went quiet unexplained | Any gaps in time longer than allowed? | Complete |
| 5 | This period joins on to the one before it | Could a whole day have been dropped? | Consistent |
| 6a | The summary was sealed when the period closed | Is the day's summary itself inside the sealed record? | Enduring |
| 6b | The record's own history is unbroken | Does the chain verify link by link? | Enduring |
| 6c | Timestamped into a Bitcoin block | Is the proof valid and about this record? | Enduring |
| 6d | Bitcoin itself agrees | Do independent explorers confirm the block? | Enduring |
| 7 | Published on time, not written later | Was the day's summary published promptly after the day ended? | Contemporaneous |
Accurate is not proven by any check. It needs calibration and inspection. Attributable is partial until the device signing chip is fitted.
Marks and verdicts
| You see | Meaning |
|---|---|
| ✅ Verified | All ten held. Unaltered since recorded, and in Bitcoin. |
| ⏳ Awaiting anchor | Everything checkable passed. Bitcoin is still confirming. Not a fault. |
| ⚠️ Summary published late | Readings are intact. The day's summary went out later than the rules allow. |
| ⚠️ Under-reported | Fewer readings than required, or the sensor went quiet. Ask what happened. |
| ❌ Sequence break | The counter has holes inside this day. |
| ❌ Tampered | The data no longer matches what was committed. |
⋯ on a check | Not checkable yet, usually waiting on Bitcoin. Never counted as a failure. |
Storage limits and excursions
The Storage limits switch in the Readings tab decides which readings are listed as excursions. It never feeds a check, so it cannot change a verdict. Presets are common label conditions (for example “Store below 30 °C”). Confirm them against the product label and the site SOP. Mean kinetic temperature uses ΔH = 83.144 kJ/mol.
Questions you will get
“Is this cryptocurrency? Do you hold Bitcoin?”
No wallet, no coins, no fees. Only a 32-byte fingerprint is sent out, through the free OpenTimestamps service. No sensor data leaves the premises. Bitcoin is used purely as a public clock that nobody involved controls. The same fingerprint could also be anchored to a national or permissioned ledger alongside it.
“Couldn't you just change the database?”
Yes, and the dashboard catches it, as shown in scenes 4 and 4b. You can change the data. You cannot change the data and keep the proof.
“Can't you change the summary as well?”
Show the fifth tamper button. The summary is sealed inside the chain, whose fingerprint is already in Bitcoin.
“What if the company switches the sensor off?”
The silence is visible. The day shows ⚠️ Under-reported, with the time the sensor went quiet.
“What if the probe is in the wrong place, or out of calibration?”
Nothing in software can catch that. Calibration certificates and physical inspection still matter. This proves the records were not changed afterwards.
“Does this make us Schedule M / Part 11 compliant?”
It provides the data-integrity evidence trail. Compliance comes from validating the whole system, not from one feature.
“Is the sensor itself signed?”
Not yet. That needs a security chip (ATECC608A), which is not fitted. Say so plainly. The other checks still hold without it.
“Why every ten minutes, not every second?”
The interval is a setting, held on the regulator's side. At ten minutes the device's hardware counter lasts about 40 years; at one per second it would run out in 24 days.
If something goes wrong mid-demo
| Symptom | What to do |
|---|---|
| The header says “Offline”, or nothing loads | Open ⚙ at top right and check the address and token. Behind the login, sign in again and reload. |
| Everything says ⏳ Awaiting anchor | Normal for anything from the last 1–2 hours. Pick an older day. Never present it as a failure. |
| A day shows ⚠️ you did not expect | Read the detail line aloud and explain it. An honest warning is better than a dashboard you cannot explain. |
| “Bitcoin block not looked up” | The venue network blocks the explorers. The proof is still verified. Use the explorer links on a phone. |
| opentimestamps.org will not load | Switch to a phone hotspot, or show the explorer links. Have the backup video ready. |
| The sensor stopped reporting | The device buffers to disk, so nothing is lost. Readings arrive when it reconnects. Carry on with a finished day. |
| You tampered with the database and did not restore | Put the original value back (DEMO.md §3b), then re-verify. Never edit the period or ledger tables. |