VERIBUS — VerifiedVERIFIED

Concept pilot · RTO Kashmir / J&K Transport Department

VERIBUS

School Transport Integrity Platform

Every trip, verified.

Tracking a school bus is a solved problem. What is not solved: when a bus overspeeds, the RTO has no evidence it can act on. VERIBUS turns raw GPS into tamper-evident, explainable evidence — while proving, in the database, that it collects the minimum and never over-reaches on a child's privacy.

Tracking is the input.
Evidence is the product.

EVERY TRIP VERIFIEDSIGNALEVIDENCEALERTSLEDGERTAMPER-EVIDENTSHA-256 SEALEDTRACKING IS THE INPUTEVIDENCE IS THE PRODUCT

The SEAL engine

Signal · Evidence · Alerts · Ledger

Four modules that turn a GPS fix into court-grade evidence. Each step builds on the one before it. The engine is pure — no database calls — and the same code evaluates live telemetry and replayed test tracks identically.

SSignal

Every GPS fix is quality-graded — GOOD, DEGRADED, or REJECTED — before it enters the pipeline.

EEvidence

Trip events are chained into a SHA-256 ledger. Change one record and every hash downstream breaks.

AAlerts

Seven alert types, each with a versioned policy. No magic numbers. No hardcoded thresholds.

LLedger

A line-by-line compliance score: each deduction cites the alert and the policy version in force.

07 alert types

all policy-versioned

017 tests passing

pure engine, no DB

SHA-0SHA-256

hash chain per trip

04 roles, RLS-enforced

parent · driver · school · RTO

The evidence chain

Seven records from one trip, each hash sealed to the record before it. One record was altered after the fact — the chain notices, and everything downstream of the break stops being trustworthy.

Illustrative records. Verify a real memo at /verify.

Seven trip records in a SHA-256 evidence chain, each hash sealed to the previous record. Record 5 was altered after the fact: its recomputed hash no longer matches the one its neighbour sealed, the chain visibly breaks at that link, and every record downstream of the break is no longer trustworthy.

How it works

Seven alerts, zero magic numbers

Every rule reads from a versioned policy, never a hardcoded constant. The engine evaluates only good-quality fixes, and downgrades — never escalates — on poor signal.

  1. 01Overspeedsustained above the operator-set limit, not a one-second spike
  2. 02Long stopstationary beyond a stop's allowed dwell
  3. 03Route deviationoff the corridor — surfaced, never escalated on bad GPS
  4. 04Delaybehind the route's own historical median
  5. 05Signal losta coverage gap (network) is never punished like a tampered blackout
  6. 06SOSdriver or attendant escalation; never auto-resolves
  7. 07Repeat complainta pattern of upheld complaints on one vehicle

An evidence hash-chain

Each trip event is appended to a SHA-256 chain — change one record and every hash after it stops matching. Anyone can confirm a trip is intact at /verify, with no login and no personal data shown.

Chain integrity check
#1 TRIP_START
#2 FIX_BATCH
#3 FIX_BATCH
#4 ALERT
#5 FIX_BATCHTAMPERED

An explainable compliance ledger

A vehicle's score is a line-by-line ledger: each deduction cites the alert that caused it and the policy version in force. Nothing is a black box a school or a driver has to take on faith.

Compliance score87
OVERSPEED (HIGH) · policy v2.1−8
ROUTE_DEVIATION (LOW) · policy v2.1−3
FITNESS expired · manual entry−2

The problem

When a school bus overspeeds, the RTO has no evidence it can legally act on.

A parent's complaint is hearsay. A tracking dashboard is not admissible. By the time anyone reviews a screenshot, the data behind it could quietly have changed. The missing piece was never more tracking — it was evidence that stands up.

Safeguards — by design

These are not settings. They are properties of how the system is built, and most are enforced below the interface where they cannot be quietly switched off.

No public live map

There is no page anywhere that shows a bus moving in real time to the public. Live position is visible only to the one parent whose child is on that trip, and only while it runs.

Track the bus, not the child

The vehicle is tracked; children are not. There is no location column on a student, by design. Children's data is processed only on verifiable parental consent, which can be withdrawn.

RTO sees summary and compliance only

The department reads scores, alerts and evidence — never raw location traces. This is enforced in the database itself, not merely hidden in the interface.

Manual document entry

Vehicle papers are entered by hand and marked "pending departmental verification". No Vahan, Sarathi or AIS-140 integration is built or implied — only the seam where a real feed would connect.

Speed limit is operator-set and cited

The system never asserts a legal speed limit on its own authority. An operator sets the limit and cites its source; with no limit configured, overspeed simply is not evaluated.

A concept pilot

Built for RTO Kashmir

VERIBUS is a concept pilot for the J&K Transport Department — not a finished product. It demonstrates a complete evidence pipeline on synthetic data near Srinagar, with real SHA-256 cryptography, real Row Level Security, and a real compliance ledger.

It states its own limits plainly — that is the version of a system a department can trust.

Pilot scope

  • Synthetic routes near Srinagar, labelled SYNTHETIC
  • Demo fleet: 2 schools, 4 vehicles, 5 replay tracks
  • Deliberate pilot gaps stated out loud at /limitations
  • No invented statistics or legal section numbers
  • Replay posts to the same ingest endpoint, chipped REPLAY