Project Info
Inspiration
Most financial quizzes give you a number and leave you there. You get 62 out of 100, or a label such as "average," but what are you supposed to do with that? It does not tell you which ideas you understand, which decisions caused problems, or what you should learn next. We kept coming back to that problem while building AlterScore. We did not want to make another quiz that marks answers right or wrong and then produces a mysterious score. We wanted users to see where their financial knowledge stands and understand why. We also wanted to avoid judging people through their salary, identity, credit history, or personal documents. AlterScore looks at how someone thinks through practical money situations. That felt like a fairer and more useful place to start. What AlterScore does AlterScore is an educational financial-readiness assessment for students, first-time earners, and anyone trying to become more confident with money. The questions deal with situations people can recognise: paying bills, protecting savings, handling an unexpected expense, deciding whether to borrow, and managing money when income is uncertain. Some of those questions are connected. If you spend more money now, you have less available in the next situation. If you protect your emergency reserve, you may need to accept a different cost somewhere else. Earlier decisions change what happens later. Once the assessment is complete, AlterScore shows a Financial Decision Index from 0 to 100. The number is only one part of the result. Users can also see where they did well, where their understanding appears weaker, how their choices affected the outcome, and what they could work on next. AlterScore is meant for learning. It does not decide whether someone deserves a loan, predict whether they will repay one, or replace professional financial advice.
How we built it
We built the frontend with React, Vite, and CSS. The backend runs on FastAPI with Python and Pydantic. The assessment uses a mix of short calculations, judgement questions, and connected scenarios. We chose that mix because knowing a formula is different from making a decision when several priorities compete for the same money. During a scenario, AlterScore keeps track of values such as available cash, unpaid obligations, emergency savings, and added costs. Each answer updates that financial state. The next question then begins with the situation the user created. The quick trial looks at four parts of the final position: $$ S = 0.40O + 0.25L + 0.20C + 0.15P $$ In this formula: (O) measures how much of the required obligation was covered. (L) measures how much usable liquidity remained. (C) measures how well the user avoided unnecessary costs. (P) measures whether the remaining plan is still workable. There are no isolated 20-point questions hidden behind the interface. The score comes from the final financial position created by the user's full path. The full assessment is scored on the server. It uses one-time attempts so the same assessment cannot be submitted twice by accident. AlterScore also returns a signed, redacted summary that can be verified without exposing the user's identity or raw answers. How we used Codex and GPT-5.6 We used Codex with GPT-5.6 while planning, coding, testing, and polishing AlterScore. A lot of its work began with reading code that already existed. Codex traced how assessment data moved between the frontend and backend, found places where those contracts did not quite match, and helped us fix them without replacing working parts of the project. It also helped us build the quick trial, debug state and navigation problems, improve the experience on smaller screens, and test keyboard and reduced-motion behaviour. When a result page occasionally appeared blank after a route change, Codex helped trace the problem across storage, navigation, and rendering instead of treating it as an isolated UI bug. We also used it to write focused tests and check the final release. That saved us time, especially when a change touched several parts of the assessment. Codex does not score users while AlterScore is running. We used it to build and verify the product. The scoring itself stays deterministic because users should be able to understand where their result came from. Challenges we faced The hardest question was where to draw the line. We were building something related to financial readiness, but we did not want it to become a softer-looking version of a credit score. That affected almost every decision we made. Identity stays outside the scoring process. Reflection questions do not affect the result. The interface repeatedly explains that AlterScore is for education, not lending or approval. The connected scenarios caused plenty of headaches too. If a user went back and changed an earlier decision, the answers that followed might no longer make sense. We had to clear those answers, rebuild the later state, and make sure the final explanation matched the new path exactly. The result page was another difficult part. There was a lot we wanted to show: the score, calculations, financial state, trade-offs, recommendations, and a replay of each decision. Putting everything on screen at once felt like handing the user a spreadsheet. We ended up showing the main result first and placing the detailed evidence behind sections users can open when they want to dig deeper. Then there were the less glamorous problems that still mattered: narrow phone screens, keyboard focus, reduced-motion settings, expired attempts, accidental double submissions, and route changes that did not always behave as expected. Solving those issues took a surprising amount of the build time.
Accomplishments we're proud of
Seeing the full assessment work from beginning to end was a big moment for us. A user can make a decision, watch it change the next financial situation, finish the assessment, and then trace the result back through every choice they made. The score does not appear from a black box. Users can see where their financial knowledge stands and why. We are especially happy that we achieved this without asking for a login, credit history, or personal financial documents. The full assessment still has secure one-time attempts and a signed result that can be independently verified. Getting explainability, privacy, and a smooth user experience to work together took a lot of effort, and it is the part of AlterScore we are proudest of.
What we learned
We learned that an explainable score has to be designed backwards from the explanation. If the scoring system does not keep track of evidence and state changes, the interface cannot honestly explain the result later. A paragraph generated after the fact is not enough. The questions, scoring rules, API responses, and result page all need to agree. We also learned that consequences teach better than answer keys. A choice can solve today's payment problem while using up the emergency reserve needed tomorrow. Another option may protect cash but add borrowing costs. Seeing that happen makes the lesson easier to understand than simply being told that an answer was wrong. Our experience with Codex changed during the project as well. At first, it was tempting to think of it mainly as a faster way to write code. It became more useful when we asked it to trace complete user journeys, question our assumptions, test awkward edge cases, and inspect how a small change affected the rest of the system. What comes next We want to add more scenarios around budgeting, saving, borrowing, irregular income, and emergency planning. Different regions also use different currencies and talk about money differently, so localised examples are high on our list. We are interested in letting users see how their understanding changes over time, but only if we can do it without weakening the privacy choices already built into AlterScore. The next step is to put the product in front of students and first-time earners. We have tested whether the system works. Now we need to learn whether the explanations make sense to the people it was built for.
AlterScore
AlterScore is a deterministic financial decision-readiness assessment. It helps people practise practical money decisions and see how a result was formed.
Open the live app · Take the quick trial · Read the API contract
What it does
AlterScore is aimed at students, first-time earners, and anyone who wants to practise financial decisions without submitting identity or credit information. The app keeps the scoring path narrow:
- practical calculations and judgement questions;
- branching scenarios where each choice changes the next state;
- a deterministic rubric with inspectable contributions;
- no lender, underwriting, approval, or creditworthiness decision.
The production scorer is ordinary Python code. It does not load machine-learning models, serialized model files, embeddings, or research artifacts at runtime.
Two ways to try it
Quick trial
The quick trial runs five questions in the browser and returns an immediate preview. It is labelled illustrative and unsigned, so it is useful for orientation rather than as an authoritative record.
Full assessment
The full assessment is issued by the FastAPI service. The service validates opaque response IDs, consumes an attempt once, carries state through branching decisions, applies the deterministic rubric, and returns an explainable 0 to 100 Financial Decision Index. The public result is redacted and signed with HMAC-SHA256 so it can be verified without exposing scoring authority.
The layout also adapts to narrow screens. This is the same landing page at a mobile viewport:
Assessment lifecycle
The assessment lifecycle is intentionally short and explicit:
Runtime boundaries
- The public v2 API is deterministic and does not depend on ML packages or model artifacts.
- Retired model-backed v1 routes return
410 Gone; they are not part of the current scoring path. - Answer keys and rubric logic stay on the server for the full assessment.
- Attempts and verification records are bounded in memory, so a restart can invalidate active tokens.
- The product does not collect accounts, identity documents, device fingerprints, credit history, or lender data.
The boundary is documented in docs/BACKEND_RUNTIME_ARCHITECTURE.md, docs/DATA_SCHEMA.md, and docs/API_CONTRACTS.md.
Repository layout
| Area | Purpose |
|---|---|
frontend/ | React 19 and Vite application, responsive UI, and browser contract tests |
backend/app/ | FastAPI application, v2 contracts, attempt lifecycle, and scoring |
tests/ | Backend unit and integration coverage |
docs/ | API, runtime, deployment, setup, and diagram documentation |
scripts/ci/ | Release packaging, smoke checks, and provenance validation |
Dockerfile | Allow-listed backend serving image for deployment |
Run locally
Requirements: Python 3.12 and Node.js 20.19.x or >=22.12.0.
# Terminal 1: backend
python -m venv venv
# Windows: venv\Scripts\activate
python -m pip install -r backend/requirements.txt
python -m uvicorn backend.app.main:app --reload --port 8000
# Terminal 2: frontend
cd frontend
npm install
npm run dev
Copy .env.example to .env for local values. Set ALTERSCORE_SIGNING_SECRET to a generated base64url secret with at least 32 random bytes. Set VITE_API_BASE_URL when the API is not at http://127.0.0.1:8000/api.
Validate changes
# Backend
python -m pip install -r backend/requirements-dev.txt
python -m pytest
# Frontend
cd frontend
npm run lint
npm run build
npm run test:phase5
npm run test:phase6
npm run test:phase7
npm run test:phase8
Production frontend builds require VITE_RELEASE_SHA to contain the exact reviewed 40-character Git SHA. CI also checks the API contract, explainability invariants, release boundaries, serving image, and paired deployment metadata.
Deploy
The frontend is deployed to Vercel. The backend is a Docker Space on Hugging Face. Hugging Face does not need an ML model for this project: it runs the FastAPI container and its deterministic scorer. The release package intentionally excludes local data, research directories, and model artifacts.
The trusted workflow on main builds both sides from one SHA and publishes the backend package with scripts/ci/prepare_hf_release.py. Configure these backend values in the hosting environment:
ALTERSCORE_ENV=production
ALTERSCORE_API_VERSION=0.2.0
ALTERSCORE_RELEASE_SHA=<exact deployed commit>
ALTERSCORE_SIGNING_SECRET=<base64url secret with at least 32 random bytes>
ALTERSCORE_SIGNING_KEY_VERSION=<non-local key reference>
ALTERSCORE_CORS_ORIGINS=https://alterscore.vercel.app
See docs/SETUP.md for local configuration and docs/DEPLOYMENT.md for the release, smoke-test, and rollback gates.
Safety boundary
AlterScore is an educational demonstration. It is not a lender, credit bureau, underwriting system, repayment predictor, financial adviser, approval tool, or source of credit offers. Do not use it for lending, eligibility, pricing, approval, denial, or another high-impact financial decision.
License
Released under the MIT License.
Analysis
View
Metric
- 33
- 4
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- CSSIn code
- FastAPIIn code
- HTMLIn code
- JavaScriptIn code
- PythonIn code
- ReactIn code
- DockerClaimed
- VercelClaimed
6 of 8 appear in the indexed code. 2 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
781 KB
Source files
103
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
kaustubh-dot/AlterScore
147 files · 1.3 MB · @ 72a518f
Structure
Interface
45 files · 31%Screens, components and styles rendered to the user.
API & routing
7 files · 5%Request entry points: routes, handlers and controllers.
Application logic
17 files · 12%Domain rules, services and shared utilities.
Data & schema
1 file · 1%Schema definitions, migrations and data access.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- Python52%
- JavaScript26%
- CSS14%
- Markdown5%
- YAML3%
- HTML1%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
frontend/package.json
npm · 15- axios
- lenis
- lucide-react
- react
- react-dom
- react-router-dom
- +9 more
backend/requirements.txt
pypi · 3- fastapi
- pydantic
- uvicorn[standard]
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.