LifeStream AI

A blood bank has three moving parts that rarely talk to each other: what is on the shelf, who can be called in to donate, and how fast a vehicle can reach an incident. LifeStream put all three behind one PHP dashboard, with a notebook per question feeding the numbers.

The framing was that these are the same problem seen from three angles. A shortfall in one city is only actionable if you know which donors are due, and a donor is only reachable if somebody can get to them, and the vehicle that does that is the same fleet you would send to an accident. So the schema was built to let one screen answer a question that spans two of them, which is why inventory and distribution both carry city population alongside the per-group counts.

What it does

• Donor registry — donors_list holds age, blood group, gender, phone, last donation date, times donated, and a probable_donor flag that the callback model exists to fill. Forty-eight seed rows, six per group across all eight groups.
• Inventory and distribution tables split across all eight blood groups, per city, with population alongside so a shortfall reads as a ratio rather than a raw count. Distribution ships ten cities; inventory ships the same eight group columns and no rows.
• Inter-city logistics rows (city_from, city_to, units, blood group, progress state) driving a transfer-tracking screen.
• Ambulance positioning from an ambulance_locations table of van registrations and coordinates, seeded with eight PB-11 vehicles around Patiala.
• Doctor and hospital directories with patient and doctor headcounts per hospital, plus a doctor-allocation view that renders hospitals as a card grid.
• A requirements screen tabling predicted minimum stock per group per city.
• Auth over a users table with a psw_hash column, a dashboard_type column for role routing, and shared server-side field validation factored into one include so the registration form and the login form apply the same rules.
• Nine read endpoints (get_donors, get_blood_inventory, get_blood_distribution, get_blood_logistics, get_ambulance_location, get_assigned_duties, and the auth trio) returning JSON that the front end caches into localStorage and renders from.
• The full MySQL schema checked in as life_stream_ai.sql, a phpMyAdmin dump with seed rows, so the whole thing restores in one import.

The schema, and what it says

Seven tables, all InnoDB and utf8mb4. The pattern worth noticing is that the two directory tables — doctors_list and hospitals_list — have no primary key and column widths like varchar(17) and varchar(21), which are not choices anybody makes. They are the widths a spreadsheet import derives from the longest value in each column. The blood tables were hand-written and look it: an explicit unsigned s_no primary key, auto-increment set, and a consistent eight-column group layout shared between inventory and distribution so one can be diffed against the other.

database_connect.php re-declares every table with CREATE TABLE IF NOT EXISTS on include, so the schema is asserted on every request rather than migrated. That came straight from the TODO file, which is not a task list at all but a saved prompt — "write a php code to generate a table if not exists name donors_list with following parameters" — followed by a stub for the next one. It dates the project precisely and is an honest record of how the tables got written.

The models

Four notebooks, each answering one screen:

• Donor callback — logistic regression on age, sex and months since last donation, trained on blood_donors.csv and saved as blood_donors_model.sav. Its output is the probable_donor flag. Five thousand rows, a 70/30 split, and a reported accuracy of 0.51.
• Requirement forecasting — linear regression from the eight per-group stock columns to a minimum-requirement target, dumped to blood_model.pkl. Mean squared error 0.00, R-squared 1.00.
• Ambulance standby points — a generator lays down a thousand accident coordinates around a city anchor and KMeans(n_clusters=10) returns the cluster centres as proposed parking positions. This is the only model that runs at request time: get_ambulance_location.php shells out to the script and parses its stdout as the API contract.
• Doctor allocation — linear regression mapping doctor and patient counts to a hospital id, which is a stretch of what regression is for. It is not what shipped either; the allocation screen is served by a PHP loop that divides total patients by total doctors and walks the hospital list greedily.

Those two scores are worth reading together, because they are the same lesson twice. The requirement model reports a perfect fit because its generator computes the label as an exact linear combination of the eight features with no noise, so the regression is recovering the coefficients that fabricated it. The donor model reports chance because its generator assigns the label with a coin flip independent of every feature. Neither number is a finding about blood banking. Both are findings about the data, and the fact that a perfect score and a useless score came from the same mistake in opposite directions is the most useful thing in the repository.

How a page gets its data

There is no router and no framework. Navigation between screens is a plain link to a static HTML file, and the interesting move is that several PHP endpoints do not return data at all: they compute, emit a <script> block that writes the result into localStorage, and then location.replace to the page that reads it. Server-side redirect as a state transfer mechanism. It works, it needs no build step, and it means the browser's storage is the application's only cache layer.

The three endpoints that do return JSON are consumed with jQuery $.ajax and rendered by concatenating template literals into innerHTML. Partials are stitched with $("#header").load("../html/header.html"), which is the whole component system.

Where it stands

Archived, and the honest list is long. The blood_inventory table is empty and nothing fills it, so the screen named after it is a set of hardcoded percentages. The dashboard's charts are Math.random() and two literal arrays; no model output reaches any screen. The ambulance clustering runs on generated coordinates rather than real incident data, so the positions it proposes demonstrate the method rather than recommend anything, and the anchor coordinate in the deployed script was moved to a different city from the one the notebook and the seed rows use. A stray C++ file and a decorative progress-bar script sit in the tree because this was one working directory rather than a curated repo.

The security posture is what a 2023 self-taught PHP project looks like before anyone teaches you otherwise: queries are built by string interpolation with no prepared statements anywhere, the column named psw_hash stores the password as typed, no endpoint checks a session, and the only access control is JavaScript hiding nav items based on a value in localStorage. That is worth writing down rather than quietly deleting, because the difference between this and the next PHP application is exactly that list.

What did work is the connected shape: the web app, the schema and the four models are one system rather than four demos, and the ambulance path genuinely runs a model on every request and puts its output on a map.