Verify Evidence
PNTMAP™ evidence is designed as an append-only, tamper-evident log. This page publishes the trust model and the planned verification record format. No PNTMAP™ record is independently verifiable today: signing and anchoring are planned capabilities on every node, and verification artefacts become available per node as ML-DSA signing goes live.
PNTMAP is an intelligence and situational-awareness service. It is not an authorised navigation source and must not be used as the sole basis for flight planning, navigation or aviation safety decisions.
Current status
Every node currently reports ML-DSA telemetry signing and external evidence anchoring as planned on its capability badges. Until a node's badge reads live, records from that node carry no signature, no inclusion proof, and no anchor reference, and nothing on this site should be treated as cryptographically verifiable.
Trust model — what the log is
The primary construct is an append-only, tamper-evident evidence log. Each accepted telemetry record is hashed on receipt and appended; periodic Merkle roots summarise the log over a fixed interval. Tamper-evidence means a later alteration of a published record is detectable, not that alteration is physically prevented. A permissioned blockchain is the intended anchoring implementation for those roots — it is a publication mechanism for the log, not the log itself.
Trust model — keys
- GenerationPlanned: node signing keys generated on the node at commissioning, never transported. The private key does not leave the node and is not held by the platform.
- StoragePlanned: hardware-backed key storage on the node where the platform supports it, with file-based storage under OS access control as the interim fallback. The chosen mode will be published per node.
- RotationPlanned: scheduled rotation with overlapping validity, so records remain verifiable against the key that was current at signing time. Key IDs are carried in every record for this reason.
- RevocationPlanned: a published revocation list keyed by key ID and effective timestamp. Records signed before the revocation timestamp remain verifiable; records after it are rejected.
Trust model — node compromise
A signature proves a record came from a node's key and has not changed since. It does not prove the node reported the truth. A compromised node can sign false telemetry. This is why multisensor corroboration sits above single-node observation on the evidence ladder, and why no single node's output can reach a corroborated class on its own. Suspected compromise is handled by revoking the node's key and marking its historical records as disputed rather than deleting them — the log is append-only.
Trust model — anchoring and control
- CadencePlanned: a Merkle root published at a fixed interval, with the interval and the covered period stated on each anchor record. Not yet operating; no anchor has been published.
- ValidatorsPlanned: a permissioned validator set. At launch this is expected to be operator-controlled, which means the anchor alone does not provide independent trust. Widening the validator set beyond the operator, and naming the participants publicly, is required before an anchor carries third-party weight.
- Can the operator rewrite the log?Stated plainly: until anchors are published to a validator set the operator does not solely control, the operator could in principle rebuild the log and re-anchor it. Independent anchoring is what removes that possibility, and it is not in place yet.
Planned verification record format
- Record hashSHA-256 digest of the canonicalised telemetry record.
- Node IDThe PNTMAP™ node identifier that produced the record.
- Timestamp sourceThe clock the timestamp came from (GNSS-disciplined or network time), stated explicitly, since GNSS disruption is the subject being measured.
- ML-DSA parameter setThe FIPS 204 parameter set used to sign.
- Key IDIdentifier of the signing key, for rotation and revocation.
- SignatureThe ML-DSA signature over the record hash.
- Merkle inclusion proofThe path proving the record hash is included in the published root.
- RootThe Merkle root covering the record's interval.
- Anchor referenceWhere that root was published, with the anchoring transaction identifier.
- Methodology versionThe version of the published methodology in force when the record was produced.
Related
The detection parameters behind each record are published on the Data Methodology page.