Schema first, then policy

PORTA is a permit scheduling layer for King Abdulaziz Road: priority tiers and live congestion status that decide which trucks still move.

The wrong question

King Abdulaziz Road carries about 1,260 trucks a day between Dammam and the seaport. The surge is predictable: vessels arrive early morning, containers free up a few hours later, and the road fills hard between roughly 10 AM and 2 PM.

Showing that on a map is easy. The useful question is harder: when the road tips into congestion, which trucks still move, and who gets a new departure window instead of sitting forever?

Today a vaccine shipment and a bulk steel load can follow the same rules. That is the gap PORTA targets.

Orchestration, not another silo

Customs clearance, vessel schedules, and road monitoring already exist in separate systems. None of them alone decide when a truck should leave or which cargo is protected when the corridor is jammed.

PORTA sits in that gap as a scheduling layer: read the signals you have, issue priority-aware permits, notify drivers. Live government APIs are a later phase. The MVP runs on schedules you can enter and a local vision feed for road status.

FIG. 03 · CONTROL LOOP

signals → policy → surfaces

Inputs

Clearance & vessels

Schedules / release events

Road status

Vision count or traffic feed

Cargo priority

Emergency → low tiers

Core

PORTA

Shared schema, API, priority engine, slot scheduler

One model decides who still moves when the corridor is congested. The UI only displays that decision.

Outputs

Operator dashboard

Traffic · vessels · permits

Driver mobile

Window · QR · status alerts

Vision updates the backend; operators and drivers see the same policy.

Schema first, then the screens

I led the team and owned system architecture and API contracts, then built the backend and the web platform on top of them: admin dashboard, organisation portal, and the permit/priority model underneath.

Four tiers live in data: EMERGENCY (medical, vaccines, perishables; never halted), ESSENTIAL, NORMAL, and LOW. Booking slots and congestion state share the same model so the UI cannot invent policy the API does not enforce.

When truck count crosses 150 in a monitoring cycle (CONGESTED), NORMAL and LOW halt and get alternative windows. EMERGENCY and ESSENTIAL stay active. Below that, MODERATE (100-150) warns; NORMAL (under 100) leaves all permits open.

Vision wired into the stack

The computer vision layer (YOLOv11, truck-aware counts, status every ~30 seconds) is not a side demo. I connected that AI pipeline to the backend so CONGESTED / MODERATE / NORMAL updates drive real permit policy, and the frontend shows operators the same state drivers feel when slots change.

Plate reading is there to cross-check against active permits later, not the core of the loop. Drivers get the window and QR on mobile; operators see traffic, vessels, and permits in one place. Status → policy → notify only works if AI, API, and UI share one model.

How to read the numbers

A 30-40% peak congestion cut is a design target from hackathon modelling, not a measured pilot result. Same honesty for “zero emergency delay”: that is the tier rule, not a live SLA yet.

Built for Sharqia Urban Development Hackathon 2026. Screens and the fuller walkthrough are in the PORTA case study.