Skip to content

Technical Architecture

From intake to seal, six stages.

Every report runs the same pipeline: who does what, where each datum comes from, which key signs it — all of it below.

Ed25519 signature · SHA-256 chain · RFC 3161 timestamp · 15 modules

Pipeline

Six stages. Each with a named owner, an input and an output.

A typical report is finished in 42-50 minutes. The measurement stage takes most of that; every other stage together stays under 15 minutes.

  1. 01

    Intake

    Reception · < 5 min

    InVIN, plate, odometer, customer identityOutWork order ID · chain-root entry

    The vehicle enters the centre; reception records the VIN and the odometer. That first record becomes the root of the chain — everything after it references this record's hash.

  2. 02

    Assignment

    Branch manager · < 2 min

    InWork order ID, an available technicianOutAssignment record · notification

    An available technician is assigned. The technician's tablet syncs the work order and queues the modules. Offline mode can take over.

  3. 03

    Measurement

    Technician · ~35 min

    InVehicle · measuring equipment · technician tabletOut15 module outputs · photo evidence · OCR output

    The 15 modules are completed in order. The technician photographs the reading on the instrument's own display and types the value into the tablet form; on some modules OCR suggests it automatically. Every entry is stored in structured fields and the photographs are attached to the module.

  4. 04

    Quality control

    Branch manager · ~8 min

    InCompleted module outputsOutApproval · or a return with a note

    The manager reviews each module and compares the form entries against the attached photographs. Anything missing or inconsistent sends the work order back to the technician; every return is written into the chain with its reason.

  5. 05

    Sealing

    Branch manager · < 1 s

    InApproved report payloadOutEd25519 signature · SHA-256 root · RFC 3161 timestamp

    The manager signs the report with an Ed25519 private key. The report hash references the hash of the previous attested report; the chain grows. The timestamp comes from an independent TSA.

  6. 06

    Publication

    System · < 2 s

    InSigned reportOutQR · shareable URL · VIN history entry

    The report is published at the public verification endpoint. A QR code is generated, the dealer panel receives it, and the VIN history is extended. A buyer can verify it from any device.

Test Modules

15 modules, 183 separate checkpoints.

Each module's data source — a form entry, photo evidence, or both — is written into the report explicitly. Photographs are attached to their module and bound into the report chain under the same hash.

Code
Module
Source
Method
Checks
  • M01Body panelsForm + photoPanel gauge + photo22
  • M02PaintForm + photoPaint thickness gauge + photo18
  • M03EngineForm + photoOBD device display + photo34
  • M04DynamometerForm + photoDynamometer display + photo6
  • M05BrakesForm + photoBrake tester display + photo8
  • M06SuspensionForm + photoTester display + photo4
  • M07Side slipForm + photoTester display + photo2
  • M08OBD / faultsForm + photoOBD scanner display + photo15
  • M09TyresForm + photoTread depth + photo8
  • M10ChassisPhotoPhoto set from under the lift12
  • M11Road testForm entryTechnician observation form9
  • M12InteriorPhotoTablet photo set14
  • M13Exterior bodyPhotoTablet photo set11
  • M14Seals & fluidsForm + photoObservation form + photo7
  • M15Airbag & electricsForm + photoScanner display + photo13

Cryptographic Layer

Break the chain once and everything breaks.

Every attested report carries a payload, a signature and a chain hash. The payload is serialised field by field as canonical JSON; it is signed with the manager's Ed25519 private key; then a SHA-256 chain hash is computed that references the previous report's root hash.

Keys live on the branch manager's own device. The Centre package includes HSM support; the signing operation can be delegated to a hardware module.

Security architecture in detail →
rapor.sign() · pseudocoderev 2 · sha256 chain

1. Canonicalise the payload

> canonical = rfc8785(rapor)

// → deterministic bytes, keys in alphabetical order

2. Ed25519 signing

> digest = sha256(canonical)

> sig = ed25519.sign(signer_priv, digest)

// → 64-byte signature, verifiable with the public key

3. Chain hash

> prev_root = chain.tail_for(vin)

> root = sha256(canonical || sig || prev_root)

// → a separate Merkle-like chain per VIN

4. Timestamp

> stamp = rfc3161.stamp(root)

// → trusted time from an independent TSA

5. Publication

> publish(rapor, sig, root, stamp)

// → publishes to the public verification endpoint + QR

Data Residency

Every data type has a place, a period and a named reader.

All customer data is held active-active in two data centres inside Türkiye (TR1: İstanbul, TR2: Ankara). Data does not leave the country; our subprocessor chain is KVKK compliant — KVKK is Türkiye's data-protection law.

Data
Location
Retention
Access
  • Report dataTürkiye · TR1/TR210 yearsReport owner + inspection centre + public verification (summary only)
  • Personal data (PII)Türkiye · TR1/TR22 years (KVKK)Authorised centre staff + the vehicle owner
  • Signing keysLocal device / optional HSMFor the life of the keyThe signer alone (branch manager)
  • Photo archiveTürkiye · TR1/TR25 yearsCentre audit staff + system auditor
  • Verification logsTürkiye · TR1/TR2Aggregate counter, no individual recordNone — the counter is public

Service Level

A stated commitment, a measured uptime.

Live status page →

Public verification endpoint

12-month rolling

99.95%

Centre panel (signing)

12-month rolling

99.9%

Technician tablet (offline-first)

operating hours

99.5%

API (dealer / integration)

12-month rolling

99.9%

SLA targets are contractual for the Branch and Centre packages. A best-effort principle applies during the pilot. Credit rules in the event of an outage are set out in the Terms of Use document.

Change one byte and the chain breaks.

API documentation, webhook events and the OpenAPI 3.1 definition live in the developer portal; for a security review, talk to the solutions team.

Talk to a solutions architectAPI documentation