Titanic Survival Prediction
AI Model
Objective
As cloud computing and artificial intelligence reshape the technology landscape, it becomes important to bridge the gap between traditional coding and modern ML workflows. This project was born out of my school's IT Club’s initiative to move beyond theoretical concepts and actively build applied AI solutions. By utilizing accessible, cloud-based tools and collaborative version control, we were empowered to take ownership of our learning, proving that high-level ML concepts are accessible and achievable while still learning.
The Start
Our professor, Gustavo Alatta at Wilbur Wright Collge, encouraged me and my classmate Dakota to build a machine learning model that predicts Titanic survival chances based on real passenger data from the Titanic.
Users can enter details such as their age, gender, ticket class and the model compares them against the historical dataset to make a prediction of survival. Building it meant cleaning the original data, selecting and training the model, and wrapping it all in a custom interface hosted on a server to be accessible and usable from anywhere.
The project originated from our school’s It club exploring databases in the cloud using AWS RDS, creating S3 buckets, and running introductory SQL queries in JetBrains’ DataGrip.
From there, we built an initial Python workflow in Google Colab to train a Random Forest classifier on the Titanic dataset. That early prototype was a simple command-line interface (CLI) that returned survival predictions alongside static Matplotlib charts, a comprehensive library for creating visualizations in Python. We took that proof of concept and re-engineered it into a live web application with a responsive multi-step form, a Flask backend, and a cloud-hosted infrastructure.
Data Cleaning
The original dataset from 1912 includes 891 records of passenger names, their age, sex, title, class, relatives on board, ticket fare, cabin number, departure port and whether they survived the disaster or not. The following table represents the kaggle dataset we worked with, without Ticket, Fare, Cabin and Embarked.
ID
Survived
Class
Name
Sex
Age
Sib/Sp
Par/Ch
1
0
3
Braund, Mr. Owen Harris
male
22
1
0
2
1
1
Cumings, Mrs. John Bradley (Florence Briggs Thayer)
female
38
1
0
3
1
3
Heikkinen, Miss. Laina
female
26
0
0
4
1
1
Futrelle, Mrs. Jacques Heath (Lily May Peel)
female
35
1
0
5
0
3
Allen, Mr. William Henry
male
35
0
0
6
0
3
Moran, Mr. James
male
0
0
0
7
0
1
McCarthy, Mr. Timothy J
male
54
0
0
Some records were missing fields; about 20% did not have an age (as indicated in the table as "0"), so the first step was to fill the gaps of relevant fields. To handle this, we temporarily flagged missing values with a placeholder of -0.5 so they were categorized as "unknown" during binning. From there, we assigned guessed ages based on the typical age range of each passenger's title.
For the purpose of developing the AI model, the departure port and cabin number were irrelevant to the survival of a passenger, unlike the other information. The ticket fare might have reflected how much a person was respected or worth saving on the titanic, yet we decided to drop it from the training data because the class (1-3) gave a more accurate and precise insight about the importance and location of the passengers.
Because decision trees require numerical inputs, categorical features like titles and class preferences were mapped into discrete integer encodings before training the model.
Modern users have no way to meaningfully answer what departure port they would use or what ticket fare in 1912 currency they would pay, so removing them prevented users from guessing or relying on silent defaults. We also restructured the questions so separate inputs for siblings, spouses, parents, and children get consolidated on the server into the dataset's SibSp + Parch format. The dataset we used is inaccurate in a way that it doesn’t distinguish between marriage, child-parent or sibling relationships, which means it’s impossible to tell which of these relationships multiple passengers with the same family name indicate.
The architecture
For this project, we built a Flask back-end in Python that serves a single-page HTML/JavaScript frontend designed as a multi-step form, along with two JSON-based API routes.
/predict: When a user completes the form, JavaScript's fetch() asynchronously transmits the passenger attributes (ticket class, sex, age, family size, and title) as a JSON payload to the Flask backend without triggering a full page reload. The server formats and aligns these inputs into the exact feature vector order expected by the pre-trained RandomForestClassifier which is loaded into memory on startup with Python’s joblib library and returns the resulting prediction immediately using jsonify.
/stats: The /stats endpoint uses Python's Pandas library to compute real-time survival rates from the training dataset on the fly, grouping aggregate outcomes across passenger class, sex, age groups, and family size to populate the interactive comparison charts.
the model
The core prediction is done using RandomForest, a popular supervised machine learning algorithm that combines the predictions of multiple individual decision trees to make highly accurate and stable predictions. It was trained separately in the Google Collab notebook and serialized using joblib. When Flask initializes, it loads the pickled model once into memory (joblib.load()), allowing the app to generate predictions in milliseconds on demand without retraining the model on every user submission.
The accuracy of the prediction model is about 80%, which is the ratio of total correct predictions to all predictions. For this purpose, that is enough. However, whether an accuracy score is good enough depends on the relevance of a model and the consequences of a false prediction.
Based on the cleaned-up data set, we were able to create statistics to later show to the user that help explain the reasons for their outcome.
Age
63
Sex
Male
Class
3
Parents on Board
No
Siblings
No
Partner/ Spouse
1
Children
4
Age
14
Sex
Female
Class
1
Parents on board
2
Siblings
1
Partner/ Spouse
No
Children
No
These two examples show a guaranteed outcome for both options based on survival statistics. Males in 3rd Class had only a 13.5% chance of survival, and adult men traveling with large families faced the lowest odds due to cabin location and staying behind to assist family members. On the other hand, 1st Class females had a 96.8% survival rate in the dataset and young females were given top priority during evacuation. This goes back to the historical social convention "Women and children first" which was enforced during the evacuation process of the titanic.
On a side note, which explains the extremely low number of male survivors on the Titanic: Captain Edward Smith explicitly ordered "women and children first" but his officers interpreted it differently: Second Officer Lightoller enforced it as "women and children only", while First Officer Murdoch allowed men into lifeboats if no women or children were waiting. ¹
Historical Limits
The original Kaggle data only recorded binary male/female entries due to the historical conventions of 1912. Official records and societal norms at the time offered no recognition outside of a strict binary framework.
To modernize our model and therefor make our project more inclusive we decided to add a third option for sex. Handling non-binary gender selections was a key design decision. The starter notebook silently defaulted unspecified inputs to male. Rather than assigning an arbitrary category that might distort the historical data, we had to make a choice on how to handle non-binary user inputs in the best possible, and more importantly, most accurate way.
Selecting "Other" runs the model twice, once as male and once as female. The interface displays both results side by side and explains whether the outcomes agreed or diverged as a reflection of historical data limits. To support this, a "None" title was created that dynamically maps to "Mr." during the male run and "Ms". during the female run, while titles like Professional and VIP evaluate across both.
The Interface
The frontend handles step-by-step navigation and input validation dynamically in JavaScript, showing or hiding form sections based on prior inputs. For example, the title field automatically hides if a user enters an age under 13. This client-side logic ensures users only see inputs relevant to their demographic tier before sending the final sanitized payload to the server.
The interface was designed as a multi-step form to have a more interesting build up to the eventual result by displaying 1 or 2 questions at a time while a css-animated water level is rising with each click on "Next". Eventually the water level rises to the top or drops low based on the outcome. We chose to keep the UI simple but fun because we wanted to do all HTML, CSS and JavaScript on our own instead of having AI generate something for us.²
Hosting
The prediction model was deployed using AWS Elastic Beanstalk to host the Flask backend and interactive frontend without a manual server configuration. Elastic Beanstalk is a popular service by Amazon Web Services that automatically manages the underlying EC2 provisioning, load balancing and dependency installation. During deployment, the platform parses the requirements.txt manifest within an isolated Python virtual environment, automatically installing essential machine learning and web dependencies (scikit-learn, pandas, joblib) to ensure the pickled model loads consistently in production.
Cloud hosting provides a secure, reliable and scalable infrastructure for public access and Elastic Beanstalk's easy deployment allowed us to focus entirely on application logic and user experience.
THE Presentation
Dakota and I are honored to be able to present our prediction model at the National Summit of Artificial Intelligence in Phoenix, AZ on October 15 2026.
[More to come after presentation]
THE Summary
[More to come after presentation]
Sources and Citations
¹British Wreck Commissioner's Inquiry. (1912). Report on the Loss of the "Titanic" (S.S.). Parliamentary Papers, Cd. 6352. (Day 11–12, Testimony of Second Officer Charles H. Lightoller)
Lord, W. (1955). A Night to Remember. Henry Holt and Company. (Chapters 4–5: Lifeboat protocol and evacuation disparities)
Collaboration with AI
We both believe that AI should serve as a collaborative tool and not a comfortable substitute for critical thinking. While we consulted Large Language Models to troubleshoot specific bugs, break down unfamiliar concepts, and refine phrasing in our documentation, we never relied on any AI to build this project for us. The core architecture, data decisions, design philosophy and code are our own, reflecting what we actively learned and built throughout the process of this project.