Why we are building Time Evidence

Time Evidence (working name) is our system for generating NTP audit evidence. This is not a product sheet: it is a set of field notes, and the place where we tell the story of the project as it progresses.

The problem: a snapshot, where the auditor wants a film

When facing an auditor on time synchronization, most teams can only produce an ntpq screenshot taken on the day of the audit. That is a snapshot. It says nothing about the state of the estate the previous week, or over the past quarter.

As a result, three blind spots come back every time:

• No historical evidence: the auditor has to trust the self-declaration and sample by hand.
• No documented drift: nothing shows that a deviation was detected — neither when, nor for how long.
• No integrity guarantee: nothing proves the history was not rewritten after the fact.

Why a history is explicitly required

No serious framework settles for a clock that is "on time" on a given day. They all ask for consistency monitored over time:

• ISO/IEC 27001 — A.8.17: approved time source, active drift monitoring, correlatable logs.
• PCI-DSS 10.6 / 10.4: accepted UTC source, consistency and peering of time sources.
• NIS2, DORA: reliable logging and the ability to reconstruct incidents — which presupposes consistent, traceable timestamps over time.

What the auditor wants is the internal consistency of the estate — machines synchronized with each other, on an approved source, drift detected, logs correlatable. We detail these obligations on our UTC time traceability audit page and on the reference sheets ISO 27001 A.8.17 and PCI-DSS 10.6.

The technical choices (without giving it all away)

Time Evidence does not "redo" monitoring. It produces third-party, independent, time-stamped evidence of the consistency of a time infrastructure. A few decisions are already settled:

• Independent observation. The measurement comes from outside your estate: neutral observers, not your own server declaring itself on time.
• Sealed history (tamper-evident). The history is designed so that any later rewrite is detectable: that is what turns a chart into a piece of evidence.
• IP-only principle. We need neither your machine names nor your inventory. We observe addresses and synchronization behaviour — not your topology. RDEM does not know your IT inventory.
• Anchored on real infrastructure. The system relies on our authenticated NTS references and our GNSS Stratum 1 — not on an improvised root of trust.

Why not wait for launch?

Because a product built for audits must be transparent about how it is designed. We chose to publicly document the reasons that led us to build Time Evidence, the technical choices made, and the lessons learned from running it on our own infrastructure — before opening it to the public. A tool that claims to produce evidence must itself be verifiable: this page is the first piece of it.

Where we stand today

The engine is already running — on our own infrastructure, in production:

The living proof: the real-time state of our servers and their NTS certificates is already public on our NTS pool status page. Time Evidence adds, on top of that, long-term history, multi-probe correlation and report generation.

Project progress

This page is updated as the project reaches real milestones. No fictional roadmap: each entry is added the day it becomes true. This page will be updated regularly until launch to document the project's main steps.

• 27 June 2026 Why this project exists: publication of these field notes and the first observation probes brought online on RDEM infrastructure.

What's next?

Once this development phase is complete, Time Evidence will automatically generate historical evidence for PCI-DSS, ISO 27001, NIS2 and DORA audits. A full product page will be published when it opens to the public.