Every sealed record carries an Ed25519 cryptographic signature over its content hash. Any change to the record — even one character — produces a different hash and breaks the signature. The reviewer can verify this independently.
Security & trust architecture
Evidence records the other side can trust.
Here is exactly how.
When you send a dispute file or claim record to a reviewer, they need to know it has not been altered since sealing. This page explains the technical and operational controls that make that guarantee possible.
Ed25519 signed
SHA-256 integrity
Hash-only — no raw file upload
Zero tracking
Replay-protected
What security means in practice
Three things buyers and reviewers need to know.
Vraimony hashes files client-side before any network operation. Only the hash is submitted — never the raw file. This means Vraimony never holds your invoice, contract, or evidence document.
The review link is read-only. No cookies, no fingerprinting, no analytics on the reviewer. They open the link, see the record, and act — privately.
Technical controls — what is actually running
Not a policy document. An implemented architecture.
Ed25519 signing on every sealed record
Each sealed record is signed with an Ed25519 private key. The signature covers the full payload hash. Anyone with the public key can verify the record has not changed since sealing — no Vraimony server required.
SHA-256 content hashing — client-side first
Files are hashed in the browser before submission. The server receives sha256:abc123... — not the file. This is the hash-only model: Vraimony can verify integrity without ever holding your document.
Replay protection — ±5 minute window
Every API request carries an X-Vraimony-Timestamp header. Requests older than 5 minutes are rejected. This prevents replay attacks — where an attacker captures a valid request and resends it later.
Idempotency keys — no duplicate operations
Every sealing operation requires a Vraimony-Request-Id header. Duplicate requests with the same ID are detected and deduplicated. A network retry cannot accidentally create two sealed records.
72-hour token expiry
Submission tokens expire after 72 hours. If a token is captured in transit, it becomes useless after 3 days. An expired token produces TOKEN_EXPIRED — not INVALID — so the submitter knows to request a new one.
Service isolation — seal, GA, verify run independently
The sealing service, the GA Machine, and the verify surface are independently fused. If one component fails, the others keep running. A verify link stays accessible even if the sealing endpoint is under maintenance.
HMAC-SHA256 webhook signatures
Every outbound webhook is signed with HMAC-SHA256. Receiving systems can verify the signature before processing. Stripe and Paddle webhooks use the same model — an industry standard for webhook integrity.
How records are assessed — the Verdict Stack
Every sealed record gets four independent checks. Not one binary pass/fail.
Inspired by antivirus architecture: no single layer decides the outcome. Four layers run independently, then combine into a single verdict with a score and optional flags.
Is the record correctly formed? All required fields present? Types correct? A malformed record is rejected before anything else runs.
Does the Ed25519 signature match? Does the SHA-256 hash match the content? Is the timestamp anchor valid? This is the tamper-detection layer.
Does the record comply with the Rules Registry? Are there overclaims? Disallowed phrases like "legally binding" or "court admissible"? Policy violations are flagged or quarantined — never silently passed.
Can an external reviewer act on this record? Is there at least one PASS item? Is there a verify URL? Is the reviewer path complete? This is the layer that prevents incomplete records from being presented as review-ready.
VERDICT OUTCOMES
SEALED
All four layers pass. Record is review-ready. Reviewer sees a clean, complete file.
SEALED WITH FLAGS
Record passes but carries soft risk signals — for example, a low ratio of PASS items. Reviewer sees the flags and can decide how to proceed.
QUARANTINED
Structurally sound but a policy concern was detected — overclaim, display safety issue, or a missing One Invalidate document. Record is sealed but flagged. Reviewer sees the flag and the clearance path.
REJECTED
Hard structural or integrity failure. Record cannot be sealed. The submitter receives a specific error — never a silent failure.
One Invalidate — the single document that blocks a case
Every dispute type has one document that, if missing, stops the reviewer completely.
Vraimony knows which document that is for each case type. If it is missing, the record is flagged before it reaches the reviewer — not after.
The One Invalidate is: invoice or delivery proof. Without it, the reviewer cannot calculate the disputed amount or confirm delivery. Vraimony flags this before sealing.
The One Invalidate is: Bill of Lading. Without it, cargo interest cannot be established — no release path exists regardless of other documents.
The One Invalidate is: official JWC/BIMCO/IMO advisory predating the deviation. Without it, the insurer treats the reroute as voluntary — not force majeure.
This is not a manual checklist. The One Invalidate logic runs automatically as part of the Verdict Stack every time a record is sealed.
Privacy — what is collected and what is not
By design, not by policy.
WHAT VRAIMONY DOES NOT COLLECT
- ✕ Raw file content — only SHA-256 hash
- ✕ Reviewer behaviour — review page is read-only
- ✕ Reviewer identity — no account required
- ✕ Analytics cookies on review pages
- ✕ Fingerprinting or device profiling
WHAT IS STORED
- ✓ The sealed record (structured JSON)
- ✓ The content hash (not the file)
- ✓ The Ed25519 signature
- ✓ The timestamp anchor
- ✓ The verdict and readiness score
Questions about security or integration?
If you are evaluating Vraimony for enterprise use, a pilot integration, or want to review the technical architecture in more detail — start here.