Urja Arora

Overview

AI Index Australia is a public dashboard and data pipeline for AI-related research and activity in Australia. It is built through Trustworthy Digital Society, a joint UNSW and UTS initiative. The platform integrates eight external datasets and serves interactive visualisations over publications, grants, patents, and talent mobility.

I am one of two engineers on the platform. The work is shared: I own specific pipelines, linkages, and frontend architecture pieces described below. I do not claim sole ownership of every dataset integration or every chart on the site.

See the [official UNSW project page](https://www.unsw.edu.au/engineering/research-technology/research-centres-institutes/trustworthy-digital-society/projects/ai-index-demonstration) for a walkthrough of the dashboard.

My contributions

Within the engineering team, my contributions include:

• ORCID data ingestion for talent mobility analysis (researcher movement into and out of Australia).
• PATSTAT ingestion and DOCDB patent-family methodology for international patent family views.
• Linking OpenAlex publications to Scimago journal rankings and CORE conference rankings.
• DBLP XML ingestion into a local SQLite FTS5 search index, with title normalisation, token-based matching, and year proximity. Records below the matching threshold stay unranked rather than receiving an unreliable ranking.
• A configuration-driven frontend architecture used across 37 charts, so new visualisations can be added through configuration instead of one-off frontend rewrites.
• Auth0 SSO with email verification, plus a PostgreSQL-backed user allowlist that gates access to the data pages.

Conference matching needed the DBLP index because venue names are inconsistent: the same conference appears as an abbreviation, a full name, with or without a year, in forms that never match on simple string comparison. Leaving low-confidence matches unranked was a deliberate choice so quality signals stay trustworthy.

The dashboard

Researchers and stakeholders can filter by year, topic, and visualisation type, then explore the underlying data. Access uses two layers: Auth0 SSO with email verification, and an email allowlist stored in PostgreSQL. Stakeholder access is provisioned by adding professional emails to that list before sign-up.

Stack and infra

The stack includes a React and TypeScript frontend, a Python and FastAPI backend, PostgreSQL, ingestion pipelines, and chart visualisations. Everything runs on ARDC Nectar: compute VMs, the database, object storage, and the production site.

Pipeline work uses Python, pandas, SQLAlchemy, and Postgres, with OpenStack Swift for object storage. The web app uses React, TypeScript, Vite, and Tailwind, with Chart.js, Recharts, and D3. Auth0 handles authentication. Deployments go through Docker and GitLab CI. Sources include OpenAlex, ORCID, ARC, Scimago, CORE, IP RAPID, PATSTAT, and DBLP.

Overview

Global Gears is a gear manufacturer with about fourteen staff in Ghaziabad. Orders, documents, and technical drawings previously lived across a shared inbox and paper files. I was the only engineer from the first conversation through deployment.

I built a searchable work-order system with attachments. Drawings and quality documents are available to the floor. Purchase orders carry pricing and stay restricted to three authorised people. The system was deployed and the first work orders were onboarded in October 2026. I now provide ad hoc support rather than ongoing product development.

The problem

Once documents existed, nobody could find them again. Answering a question about an order meant asking whoever had opened the email.

Pricing made a shared folder unsafe. A client purchase order shows what the customer pays. Supplier purchase orders show what the company pays for forging, heat treatment, and related work. Together those numbers reveal the margin on the job. In a small industry, rates that circulate affect later quotes, so priced documents need a small authorised set. Everything else on the job still has to be open to production and quality.

I looked at Google Drive first. Two shared drives would have worked technically, but only if people filed every order correctly forever. A priced document in the open drive looks identical to one that belongs there. The client said they could not enforce that discipline, so the rules had to live in the system rather than in habits.

Access levels

Access is three privilege levels, not per-document permissions, so it stays explainable:

• Full access (director and procurement): create work orders, change status, open priced documents, manage other people's access.
• Pricing access (accounts): open priced documents, but cannot create orders or manage access.
• Standard access (production and quality): find orders, download drawings, upload documents. Never open a priced document.

Levels are named for privilege rather than department. In practice three people can open a priced document and eleven cannot. The People screen shows that count because it is the question the director keeps asking.

The security model

Access rules live in the database, not only in the UI, so a frontend bug cannot quietly expose a purchase order.

Purchase-order records sit in a separate table, and files sit in a separate storage bucket. They are not general documents behind a boolean flag. Sharing a table would mean every future query has to remember to exclude them.

The purchase-order bucket has no storage policy on purpose. In Postgres row-level security, a missing allow policy means deny. Browser requests are refused, including from administrators. The only credential that can open the bucket is the server service key, which never reaches the browser.

A purchase order is therefore only served by a server route. The route looks up the record by id, derives the storage path from that database row (never from a client-supplied path), checks the active user record and role, writes an append-only audit entry, then streams the file. If the audit write fails, the request fails closed and no bytes are sent.

Access depends on an active row in the application user table, not merely a successful Google login. Supabase issues a session as soon as Google sign-in succeeds, before application authorisation runs. A valid session only proves someone has a Google account.

The audit log cannot be written from the browser. The server key can insert and select, nothing else, so the log is append-only even to the most privileged credential. Anyone who can open a purchase order can still photograph the screen. The system does not pretend otherwise. What it does provide is traceability: a leak points at one of three named people.

Testing the model rather than trusting it

Because the schema does the security work, reading it carefully is not enough. I wrote 100 database security assertions against a local Postgres instance across five identities plus anonymous and service roles: administrator, pricing user, ordinary floor user, removed employee, and a stranger who completed Google sign-in but was never added.

The suite found the most serious bug in the project, which I had introduced myself. Early policies checked whether the caller was signed in. That would have made work orders, documents, and drawings readable by anyone with a Gmail account and the public browser key. Access now derives from membership. Against the old schema the stranger could read data; against the current one they get nothing.

A second issue came from a platform change. Supabase stopped auto-granting table privileges on new projects while the local stack kept the old behaviour. Tests would have passed locally and failed in production. Privileges are now explicit, the anonymous role has none, and the privilege test iterates every table in the schema so new tables are covered automatically.

Designing for people who won't be trained

Most staff are in their fifties and sixties and are not confident with software. One constraint was that the system could not require a training session.

Five document categories are always visible, with "None yet" under empty ones. Uploads sit inside each category, so filing is determined by which button was pressed. Priced documents use a visually distinct block rather than a confirmation dialog. For standard access that block is not greyed out; it is simply not rendered.

Legibility was treated as a requirement: minimum type size, contrast floor, and touch targets, measured rather than judged by eye. The system also generates the cover sheet that used to be typed by hand and assigns work order numbers itself.

Stack and infrastructure

Next.js App Router, TypeScript, React, Tailwind, shadcn/ui, Supabase Postgres, Auth, and Storage, SQL migrations, Google OAuth, and Vercel.

Database and serverless functions are pinned to Mumbai so priced files do not leave India in transit. The purchase-order route uses the Node runtime rather than Edge because edge functions cannot be pinned to a region.

A written decision record sits beside the code and records why choices changed, including purchase-order delivery, numbering, and the sign-in model.

Overview

This was my Software Engineering Honours thesis at UNSW Sydney, supervised by Dr Hye-Young Paik. The published paper title is Scalable and Privacy-Preserving Deepfake Detection Framework. The work investigated privacy-preserving verification of deepfake-related content on Hyperledger Fabric, using Redis, xxHash, perceptual hashing, and Idemix zero-knowledge proofs.

Deepfake content spreads quickly, but blockchain-backed detection systems struggle to stay fast without weakening privacy. The research improved an existing deepfake detection framework (DDS) with a two-stage filtering approach and a privacy-preserving voting protocol.

Results

These figures are from evaluating the framework under the experimental conditions in the thesis. They are not presented as universal benchmarks.

• 91% reduction in blockchain load through the two-stage filtration layer.
• 90% of verification operations completed in under 100 ms via caching and duplicate detection.
• Privacy properties demonstrated in evaluation: anonymity, vote unlinkability, and Sybil resistance.
• Published by Springer in the SDLT 2025 proceedings (DOI: https://doi.org/10.1007/978-981-95-9230-2_13).
• Best Paper award at SDLT 2025, the 9th International Symposium on Distributed Ledger Technology at Deakin University, Melbourne, November 2025.
• Honours Class I at UNSW for this work.

What I built

I designed and implemented a two-stage filtration pipeline using xxHash and perceptual hashing (pHash) to catch duplicate and near-duplicate content before it reaches the blockchain. I also extended the IncogniSense protocol with reputation-weighted voting using Idemix zero-knowledge proofs so participants could stay anonymous without discarding result quality.

The prototype used Redis for off-chain caching and Hyperledger Fabric for ledger operations. The main engineering tension was cryptographic privacy versus throughput: zero-knowledge proofs add cost, and perceptual-hash thresholds need careful tuning to catch near-duplicates without too many false positives.

Stack

Python, Hyperledger Fabric, Redis, xxHash, perceptual hashing (pHash), and Idemix. Evaluated as an end-to-end prototype covering filtration, privacy-preserving consensus, and blockchain integration.

Overview

I interned at VVDN Technologies on the Cloud & Apps Engineering team from March to May 2024. The brief was to replace an email-based survey workflow with a mobile-first platform where HR could create, distribute, and collect employee surveys.

I built most of the prototype myself, with mentor support through stand-ups, demos, and code review. This was not a throwaway classroom exercise: after the internship, HR adopted the application, expanded it, and continues to use it internally.

What I built

Flutter for Android and iOS from a shared codebase, with a Python Django REST Framework backend and PostgreSQL. Features included authentication, admin and employee dashboards, survey scheduling, file uploads, multilingual survey delivery, text-to-speech, and voice input.

Outcome

HR adopted the application after the internship and has continued to expand it for internal use. I do not have public user counts or performance metrics to share. Supervisor feedback noted completing the application from scratch, designing UI ahead of schedule, and delivering on deadlines. My performance evaluation rated Excellent across the criteria used by the team.

Stack

Flutter, Django REST Framework, Python, PostgreSQL, REST API design, and GitHub Actions CI/CD. The internship covered requirements, API design, implementation, demo, and handover.

Overview

DevSoc runs student project teams that ship apps used on campus. From March 2023 to November 2025 I progressed from frontend contributor to Director. Most of the work was joining existing codebases and shipping with a team, not building solo.

Freerooms · March to December 2023 · Frontend contributor

Freerooms shows which classrooms are free on campus. I redesigned and rebuilt the landing page (hero, features, FAQ, sponsors) and contributed to the Next.js migration and performance work. It was my first production app with pull requests, code review, and a shared design system.

Unilectives · March to December 2024 · Frontend contributor

Unilectives is DevSoc's course review platform. I worked on sponsor layouts for Jane Street, TikTok, and Macquarie, contributed analytics so the team could see what students used, and helped ship Unilectives Wrapped. While I was on the team, the platform received more than 10,000 pageviews in one month.

Bridges · January to November 2025 · Director

Bridges connects UNSW societies with industry sponsors. I helped take the platform from zero to its first version. My role was leadership and coordination, not hands-on coding.

Before UI work, we spent months on requirements through surveys and interviews with societies and sponsors. As Director I led the team, reviewed work, and unblocked contributors. Version one supported browsing, society login, and onboarding, built by the developers and designers on the team.

What stuck

DevSoc is where version control, CI/CD, code review, and sprint planning became normal for me, in service of apps students actually use. Freerooms taught me an existing codebase. Unilectives taught me shipping features into something already scaled. Bridges taught me leading without needing to write every line.

Overview

This is ongoing early-stage research with a colleague at Trustworthy Digital Society. Patent classification is slow expert work against a large hierarchy of codes. Large models can help, but they are expensive to run at scale, and patent applications often cannot be sent to external APIs.

The idea is a small model that can run locally, assign a code, and give a reason for it, using reasoning from a larger model as a teaching signal. The paper is still in progress. There are no published results yet, and the work is not a production system.

Status

More detail will go up when the paper is further along. Until then, treat this as research in progress rather than a finished case study.

Overview

July to December 2023. Remote from Sydney with a team based in Phoenix. Oshepro is an EHS platform for safety audits, risk assessments, and compliance reporting. Users are non-technical field and safety teams in North America who need to log hazards and close out tasks, then get back to work.

My role was UX design only: Figma, prototypes, and UI documentation. I reviewed existing product workflows and user reviews. I did not conduct direct user interviews or shadow field teams, and I did not implement frontend code. Incomplete forms in this product create audit and safety risk, so clarity mattered more than visual polish.

I worked on three modules: SHEMa (Safety, Health and Environmental Manager), AMLA (Accident Management and Loss Analysis), and TRACI (Task Risk Assessment, Control and Implementation).

The problem

People were fighting the interface. Navigation changed across modules, similar controls behaved differently, and common tasks took too many clicks. User reviews said the product was easy for some users and too complicated for less technical ones. Missed required fields and half-finished records were a data quality problem with real compliance consequences.

SHEMa

SHEMa was the module people touched most. I designed two competing flows, including accordion layouts, sticky navigation, colour-coded status, and standardised patterns, then pushed a clearer direction. Single-page layouts in these deliverables were design specifications, not implemented features.

• Next and Back behaviour was easy to misread, so people thought they had finished when they had not.
• Entered text looked too similar to placeholder text.
• After creating a task, return to the task list was unclear.
• Small click targets and inconsistent permission visibility on the task list.

AMLA

AMLA asked for important incident information, but the UI made people work too hard before they could focus on the incident. I simplified it into a more linear, consistent flow with clearer section hierarchy and standardised inputs.

TRACI

TRACI is the most complex module. Hazard screens were dense and nested. I restructured it into clearer task-level sections, cleaned up checklist interactions, and used colour-coded severity so high-risk items stand out during review.

What I took away

In compliance products, design is about helping people enter the right information at the right time. This experience sits beside my engineering work as product thinking and UX ability, not as software implementation experience.

The idea

This is one of my favorite projects because it came from a real decision in my own life: India vs Australia. I was in India for a few months while working remotely, which gave me a rare chance to test what day-to-day life actually felt like instead of deciding from a distance.

I did not want to waste that opportunity by relying on vague memory later. So I built a daily system: log where I am leaning on a 1-10 scale, tag what influenced it, and write a short note. Over time, it shows me not just what I felt, but why.

What it does

I kept the product structure simple so it is easy to use every day: Log, Patterns, Past entries, and Settings.

• Log: one entry per day with a lean slider, factor tags, and journal note.
• Patterns: trend charts, pivot count, and top factors influencing each direction.
• Past entries: reverse chronological history with quick jump back to any day.
• Settings: place names, account controls, and partner sharing.

I built it around India and Australia at first, but both sides are customizable so it works for any two-place decision.

On the Log tab, I pick factor tags and write a short journal note alongside the daily lean score.

The Patterns tab is where the analysis lives: lean over time, pivot count, and how my direction shifts across days.

The top-factors view was important for me. It shows which tags keep showing up on India-leaning vs Australia-leaning days, so I can see what is driving my decisions instead of guessing.

Past entries keeps a reverse-chronological history so I can jump back to any day and see what I logged.

Product decisions

My main product goal was low friction. If daily logging feels heavy, people stop doing it. So I optimized for speed, clarity, and momentum.

The point was not to force a decision every day. It was to run a real experiment on myself while I had the chance, collect honest data over time, and then decide with more clarity.

• One entry per calendar day to keep the habit clear and consistent.
• Optimistic save with local cache so date switching feels instant.
• Pivot detection to show when I cross from one side to the other.
• Sharp-pivot markers for big day-over-day swings.
• Read-only partner mode so someone close can follow the journey without account overlap.

Partner sharing

I added partner sharing because this decision was personal and ongoing. I wanted someone close to be able to follow my progress without logging into my account or editing anything.

• Invite by email from Settings.
• Partner accepts the invite on their own account.
• Access is read-only, so entries stay private and unchanged.
• Partner can open a summary view with lean, pivots, and top factors.

Tech and architecture

I built this as one React Native codebase using Expo, then shipped it across web, iOS, and Android. The web version runs as an installable PWA.

• Frontend: Expo, React Native, TypeScript, Expo Router.
• Web/PWA: React Native Web static export, deployed on Vercel.
• Backend: Supabase Auth + Postgres with Row Level Security policies.
• Charts: react-native-gifted-charts for lean trends and factor analytics.
• State: React Context for auth and place configuration.

I kept security policy-driven in the database with Supabase RLS. People can access their own data, and partner access is invite-only and read-only.

What I learned

I built this because I had a real question and no good way to answer it. Turning that into a daily log, then charts, then partner sharing felt natural because each step solved something I was actually running into. That is the kind of coding I care about: start from a problem that matters, ship something useful, and keep going until it works.