Why these records
hold up.
This page explains how SoilVector makes your spray records tamper-proof, independently verifiable, and defensible under regulatory scrutiny. Written for compliance officers, insurance adjusters, and anyone evaluating the integrity of our audit trail.
The short version
Every spray record your team creates is immediately locked into a chain where each entry depends on the one before it. Change any past record and the entire chain breaks — the tampering is instantly detectable.
Every hour, an independent third party — a Timestamp Authority with no connection to SoilVector — signs a proof that the chain existed in its current state at that exact time. This means even SoilVector cannot go back and change your records.
When you export a compliance package, it's digitally signed. Anyone who receives it — a regulator, insurer, or attorney — can verify that the data hasn't been modified since export. No software access needed. No trust in SoilVector required.
Four layers of protection
Each layer adds a guarantee that the previous layer alone cannot provide.
Recorded
Captured on-device with timestamp, GPS coordinates, and operator identity. Stored locally in an encrypted queue before sync.
Chained
Appended to the organization's cryptographic chain. Each entry includes a fingerprint of the previous entry — altering one breaks all that follow.
Anchored
Chain state submitted to an independent timestamp authority. External, third-party proof that the records existed at that time.
Signed
Compliance exports are digitally signed. Recipients verify authenticity independently — no SoilVector access required.
Tamper-evident hash chain
Think of it like a notarized ledger where each page references the previous page. If someone tears out a page or changes an entry, the reference chain breaks and the alteration is immediately visible.
In technical terms: every record is appended to a per-organization SHA-256 hash chain. Each entry includes the cryptographic digest of the previous entry, creating a tamper-evident sequence. Altering any past record changes its hash, which breaks the chain from that point forward.
Algorithm
SHA-256 (NIST FIPS 180-4) — the same standard used in banking, legal archiving, and government systems.
What it covers
Each hash covers the previous hash, record metadata, operator identity, and full payload. Any modification to any field in any past entry is detectable.
Immutability enforcement
Database-level triggers prevent any update or deletion of ledger rows. This isn't an application-level promise — the database engine itself rejects mutations, even from administrators with direct database access.
Independent timestamp anchoring
The hash chain proves records haven't been altered. But how do you prove when they were created? That's where external anchoring comes in.
SoilVector periodically submits the current chain state to an independent Timestamp Authority (TSA) — a third party with no connection to SoilVector or your organization. The TSA signs a proof that the chain existed in that exact state at that exact time.
Protocol
RFC 3161 — Internet X.509 PKI Time-Stamp Protocol. The same standard used in legal archiving, code signing, and regulated industries worldwide.
What it proves
That your spray records existed in their current form at a specific time. If anyone — including SoilVector — had altered records after anchoring, the chain state would no longer match the anchored proof.
Why it matters for applicators
In a drift dispute, the question isn't just "what did you spray?" — it's "can you prove this record wasn't created after the complaint?" External anchoring answers that question with third-party proof.
Verification
Anyone with the timestamp token and the ledger data can independently verify the proof. No SoilVector access required. Standard OpenSSL tools work.
Signed compliance exports
When you generate a compliance package — for a regulator, insurer, or attorney — the export is digitally signed. The recipient can verify that the data hasn't been modified since it was generated, without contacting SoilVector or having system access.
Signature algorithm
Ed25519 (RFC 8032). A modern, high-performance signature scheme used in SSH, TLS, and blockchain systems.
What is signed
The full export: activity log, hash chain verification, operator history, and integrity proof. Every SHA-256 hash is visible in the export for independent verification.
Certificate of Data Authenticity
Each export functions as a certificate of data authenticity. The digital signature proves the data originated from SoilVector's ledger and has not been modified since generation.
Deterministic output
Exports are deterministic — the same data always produces the same content hash. Re-export at any time and verify it matches a previously signed copy.
Database-level immutability
Many systems promise "immutable records" but enforce it only in application code. A bug, a compromised dependency, or an engineer with database access could still alter records. SoilVector enforces immutability at the database level.
How it works
PostgreSQL triggers fire unconditionally on any attempt to UPDATE, DELETE, or TRUNCATE ledger rows. The database engine itself rejects the operation before it can execute.
What this means
INSERT is the only permitted operation on the ledger. Even a SoilVector engineer with direct database access cannot alter or delete committed records. The triggers cannot be disabled by application code.
Production safeguard
The database role used by the production application does not have ALTER TABLE privileges on ledger tables. This prevents any code path — including bugs or compromised dependencies — from disabling the immutability triggers.
Device and transport security
The integrity of the ledger depends on the integrity of the data entering it. SoilVector secures the entire path — from the device in the field to the server that commits the record.
Login credentials stored in hardware
Authentication tokens are stored in the device's secure enclave — a hardware-isolated chip that prevents extraction even if the phone is compromised. Your login can't be copied, exported, or intercepted by other apps.
Timestamp verification
The mobile app cross-checks the device clock against network time before every record. If the clock has been manually adjusted beyond safe bounds, the record is flagged as having elevated clock skew — it's still accepted, but the discrepancy is documented transparently in the ledger. No hidden data, no silent failures.
GPS integrity
The app detects mock location providers (GPS spoofing tools) and flags them in the record metadata. A record made with a spoofed GPS isn't rejected — it's marked as having simulated coordinates, so anyone reviewing the audit trail can see it. Transparency over rejection.
Encrypted transport
All data in transit is encrypted via HTTPS/TLS. No tokens, records, or location data are ever sent in plaintext. Certificate pinning prevents man-in-the-middle interception.
Security summary
Seven layers protect your records from device to export. Each one is independently verifiable.
| Layer | Mechanism | What it proves |
|---|---|---|
| Identity | Hardware-backed credential storage | Login tokens can't be extracted, copied, or intercepted |
| Transport | HTTPS/TLS encryption | No data is sent in plaintext between device and server |
| Temporal integrity | NTP cross-check + clock skew flagging | Timestamps are verified against network time; discrepancies are documented |
| Spatial integrity | Mock location detection | GPS spoofing is detected and flagged transparently in the record |
| Record integrity | SHA-256 hash chain | No record has been altered, inserted, or reordered since creation |
| Time proof | RFC 3161 timestamp anchoring | Records existed in this state at a specific time — independently verifiable |
| Export authenticity | Ed25519 digital signatures | The compliance package has not been modified since generation |
Questions about our integrity model?
We're happy to walk through the technical details with your compliance team, insurer, or legal counsel.