Cybersecurity Research Intern
Bhabha Atomic Research Centre (BARC) — Mumbai, India
November 2025 -- January 2026
- Evaluated open-source SBOM and SCA toolchains, mapping analytical findings to offline vulnerability databases.
- Executed deployment tests in a strictly air-gapped environment, preventing data exfiltration to secure infrastructure.
PyTorch Contributions
Open Source Ecosystem
- Contributed to the PyTorch ecosystem, focusing on compilation pipelines and GPU acceleration.
- Worked on PyTorch/TorchScript/FX compilers targeting NVIDIA GPUs via TensorRT.
Arch Testing Team
Arch Linux — WFH / FOSS Work
June 2025 -- Current
- Coordinated package signoffs for [core] and [extra] repositories, validating stability on bare-metal and virtual setups.
- Identified and reported critical kernel regressions, ensuring release quality for the global Arch Linux userbase.
Forest-Fire Prediction & Simulation Platform
Overview
Forest-Fire is an integrated platform designed to assist in wildfire management and prevention. By leveraging satellite data, deep learning (U-Net), and pathfinding algorithms (D* Lite), this tool provides actionable insights into fire spread and safe evacuation routes.
The system consists of a robust FastAPI backend that serves predictions from a PyTorch-based model, and a modern Next.js frontend that visualizes data in 2D, offers simulation controls, and provides an interactive dashboard for decision-makers.
Research & Architecture: Read the comprehensive project documentation, including dataset engineering and model architectures, in the docs/project_overview.md file.
Key Features
- Deep Learning Predictions: Utilizes a U-Net architecture to predict fire spread probability based on environmental factors (temperature, humidity, wind, rain).
- Geospatial Simulation Engine: An interactive
react-leaflet mapping interface allowing users to view dynamic Cellular Automata spreading atop real-world geographic bounds (Uttarakhand).
- Safe Path Planning: Implements the D* Lite algorithm to calculate dynamic safe paths for rescue teams or evacuation based on real-time AI probabilities.
- Historical Validation: Side-by-side temporal playbacks comparing the model's predicted 48-hour fire spread against actual historical MODIS satellite sequences.
- Data Upload Portal: An interface for government or organizations to upload raw
.nc, .tiff, or .geojson disaster snapshots for instant AI inference and routing.
- AI Assistant: Integrated chat interface for querying system data and insights.
Architecture
The project follows a modern microservices-like architecture:
graph TD
User[User] -->|Interacts| Client[Next.js Frontend]
Client -->|HTTP/JSON| API[FastAPI Server]
subgraph "Backend Services"
API -->|Inference| Model[PyTorch U-Net]
API -->|Pathfinding| Algo[D* Lite]
API -->|Data| Store[Artifacts/Cache]
end
subgraph "Data Processing"
Raw[Satellite/Weather Data] -->|Preprocessing| Model
end
Tech Stack
Frontend
- Framework: Next.js 15
- Language: TypeScript
- Styling: Tailwind CSS, Shadcn UI
- Visualization: React Three Fiber, Recharts, Leaflet
- State/Network: Axios, React Hook Form
Backend & Server
- Framework: FastAPI
- Server: Uvicorn
- Language: Python 3.10+
- Validation: Pydantic
Machine Learning
- Deep Learning: PyTorch, TensorFlow (Legacy)
- Architecture: U-Net (Custom implementation)
- Data Processing: NumPy, Pandas, Scikit-learn
- Pathfinding: D* Lite Algorithm
Project Structure
/
├── Frontend/ # Next.js Web Application
│ ├── app/ # App Router pages (Dashboard, Simulation, etc.)
│ ├── components/ # Reusable UI components (Three.js scenes, Charts)
│ └── ...
├── Server/ # FastAPI Backend
│ ├── app/
│ │ ├── main.py # API Entry point
│ │ ├── d_star_lite.py # Pathfinding logic
│ │ └── ...
│ └── ...
├── Model/ # ML Research & Training
│ ├── src/ # Model definitions (UNet)
│ ├── weights/ # Trained model checkpoints
│ ├── dataset/ # Training data
│ └── ...
└── ...
Getting Started
Follow these instructions to set up the project locally.
Prerequisites
- Node.js (v18+ recommended)
- Python (v3.10+)
- Git
1. Clone the Repository
git clone https://github.com/AceofStades/Forest-Fire.git
cd Forest-Fire
2. Backend Setup (FastAPI)
Navigate to the Server directory, create a virtual environment, and install dependencies.
cd Server
# Create virtual environment
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
# Install dependencies
pip install -r requirements.txt
# Run the server
uvicorn app.main:app --reload --port 8000
The API will be available at http://localhost:8000.
3. Frontend Setup (Next.js)
Open a new terminal, navigate to the Frontend directory.
cd Frontend
# Install dependencies
npm install # or pnpm install / yarn install
# Run the development server
npm run dev
The application will be running at http://localhost:3000.
4. ML Model Setup (Optional)
If you wish to retrain the model or explore the datasets:
cd Model
pip install -r requirements.txt
# Check src/ for model definitions and train.py for training scripts
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature)
- Commit your Changes (
git commit -m 'Add some AmazingFeature')
- Push to the Branch (
git push origin feature/AmazingFeature)
- Open a Pull Request
Credits
This project is brought to you by:
License
Distributed under the MIT License. See LICENSE for more information.
title: openenv-dsc-co
emoji: 📦
colorFrom: indigo
colorTo: red
sdk: docker
app_port: 7860
pinned: true
license: apache-2.0
tags:
- openenv
- rlvr
- rlve
- grpo
- trl
- unsloth
- supply-chain
- long-horizon
- mcp
- milp
short_description: 30-step supply chain rlvr env with pulp milp oracle
openenv-dsc-co
dynamic supply chain combinatorial orchestration. a meta openenv-compliant rlvr/rlve environment. a 30-step multi-echelon supply chain graph verified by a deterministic pulp/cbc mixed-integer linear programming oracle. 100% api/json driven. single unprivileged docker container. hf space.
links
docs index
start here, then jump into whichever md interests you most:
try the public env
Open the runnable environment Space: https://huggingface.co/spaces/AceofStades/dsc_co
Click Reset, then use Step with these exact values:
Type:
call_tool
Tool Name:
query_network
Arguments:
{"source_id": "S0", "dest_id": "W0"}
Then ship inventory on the discovered edge:
Type:
call_tool
Tool Name:
dispatch_inventory
Arguments:
{"routes":[{"src":"S0","dst":"W0","qty":20}]}
Then advance the simulator:
Type:
call_tool
Tool Name:
advance_cycle
Arguments:
{}
Equivalent raw action payload:
{"type":"call_tool","tool_name":"query_network","arguments":{"source_id":"S0","dest_id":"W0"}}
tl;dr
| aspect |
value |
| action space |
3 mcp tools, strict pydantic v2 validation |
| observation |
typed json, partial-observable via query_network |
| horizon |
30 discrete steps |
| reward |
dense shaping (≤ 0.4) + terminal clip(opt/agent, 0, 1) |
| verifier |
coin-or cbc milp, zero-variance signal |
| trainer |
trl grpo + unsloth + llama-3.2-3b-instruct qlora |
| curriculum |
4 procedurally-generated tiers with ema gating |
why this environment
plain english: this is a store-shelf problem. the planner has to keep retailers stocked without wasting warehouse and supplier inventory too early. a bad planner panic-ships whatever is closest, looks good for a few turns, then runs out later and pays shortage penalties. a better planner sends smaller shipments early enough for lead time and keeps replenishment moving.
llms default to step-wise greedy decisions. give a 7b instruct model a 30-step supply chain and early moves permanently truncate the viable solution space. this env measures and trains through that failure mode with a zero-variance, math-optimal reward.
reward path diagram
before and after behavior trace
caption: concrete tier-1 seed-7 replay. the reactive baseline over-ships early and ends at terminal reward 0.423; the planned verifier replay sends smaller timed batches and reaches 0.959. see docs/behavior-trace.md. the final trained run improved terminal MILP reward from 0.052 to 0.226; raw trained completions were not preserved because DSC_LOG_COMPLETIONS=0.
| measurement |
value |
| baseline greedy gap (tier 1, n=5) |
159% |
| baseline zero-op gap (tier 1, n=5) |
448% |
| milp-replay gap (tier 1, n=5) |
7% |
| gradient headroom |
~0.55 terminal reward points |
baseline terminal reward
final training results
Final GRPO evidence run: 400 steps, 2,000 prompts, 8 generations per prompt, max_completion_length=768, Llama-3.2-3B-Instruct 4-bit QLoRA via Unsloth on an A100 Space. Raw artifacts are committed under results/ and mirrored in the LoRA repo.
| metric |
first logged step |
final step |
best / aggregate |
| combined reward |
0.622 |
1.304 |
max 1.365 |
| cumulative env reward |
0.505 |
0.852 |
last-25 mean 0.855 |
| terminal MILP reward |
0.052 |
0.226 |
max 0.241 |
| reward std |
0.387 |
0.079 |
frac_reward_zero_std=0 at final |
| GRPO train loss |
— |
-0.049 |
400-step run |
| runtime |
— |
4h 51m |
0.023 steps/sec |
final GRPO training curve
caption: the model moves from sparse/low terminal verifier reward to stable non-zero MILP terminal reward while maintaining non-zero reward variance and gradients. The high completion clipping rate reflects inefficient stopping, but terminal reward remains active because valid parsed actions reach the 30-step verifier.
reward components
caption: the final metrics CSV is preserved under results/, so this plot is reproducible without relying on transient Space logs or screenshots.
training health
caption: reward variance remains non-zero and KL stays controlled through the final run.
completion diagnostics
caption: the model often uses the full completion budget, but parsed action sequences still reach terminal verifier scoring.
quick start
For a full setup guide, including local environment checks, OpenEnv deployment, and the intended Hugging Face A100 training workflow, see BOOTSTRAP.md.
make install
make test
make eval N=10 TIERS="1 2"
make viz
make serve
then from a second shell:
python client.py reset --tier 1 --seed 7
python client.py query S0 W0
python client.py dispatch S0 W0 50
python client.py advance
python client.py tools
hf space deployment
live hf space: https://huggingface.co/spaces/AceofStades/dsc_co
reproduce the deploy:
huggingface-cli login
openenv push -r AceofStades/dsc_co --exclude .openenvignore
-r (aka --repo-id) takes username/env-name. --exclude .openenvignore is required — the cli's default ignore is only .*, __pycache__, *.pyc, so your local env/ venv would otherwise upload (~400 mb of compiled .so + cbc binaries = 500 error from hf).
optional flags: --private, --base-image ghcr.io/meta-pytorch/openenv-base:latest, --hardware cpu-basic, --env-var KEY=VAL, --secret KEY=VAL.
manual docker alternative:
docker build -t openenv-dsc-co .
docker run --rm -p 7860:7860 openenv-dsc-co
the hf space uses port 8000 by default (openenv.yaml). the root Dockerfile is wired for port 7860 if you deploy directly as a plain docker space.
training on huggingface spaces
we use huggingface spaces as on-demand, high-vram gpu compute nodes for grpo training. The intended full training path is the root Dockerfile on a Hugging Face A100 Docker Space. The notebooks in notebooks/ are provided for reference and experimentation, but the final evidence run was trained through the Docker Space workflow.
workflow:
- create a new space on huggingface (select A100 gpu hardware for the final/full run, Docker sdk).
- configure space secrets:
- push this codebase to the space:
git remote add space https://huggingface.co/spaces/<your-user>/<your-space>
git push space master:main
- the space will build the
Dockerfile, spin up a lightweight fastapi server (app.py) to satisfy the space's port 7860 health check, and kick off train.py in the background. check the space logs to watch unsloth run!
training stack:
unsloth/Llama-3.2-3B-Instruct-bnb-4bit 4-bit qlora, r=32- defaults:
num_generations=4, max_completion_length=512, beta=0.04; override with DSC_NUM_GEN, DSC_MAX_COMPLETION, DSC_BETA
- final-run knobs:
DSC_MAX_STEPS, DSC_DATA_N, DSC_BATCH_SIZE, DSC_GRAD_ACCUM, DSC_LR, DSC_EPOCHS, DSC_TEMP, DSC_SAVE_STEPS
- checkpoint recovery: set
DSC_RESUME=1 to resume the latest checkpoint in DSC_OUT_DIR
- vllm/fast inference is enabled only when the GPU supports it and
vllm is installed; otherwise training falls back to the standard unsloth path
- when TRL does not pass environments into reward functions,
train.py locally replays JSON tool actions through DSCToolEnv so rewards, loss, and gradients remain non-zero
- final model uploads include
training_metrics.json, training_metrics.csv, and training_curve.png alongside the LoRA adapter
trackio.log({...}) streams metrics to the trackio dashboard.- set
DSC_LOG_COMPLETIONS=1 on future runs to preserve exact trained JSON action traces for side-by-side qualitative demos.
final HF Space evidence run preset:
DSC_MAX_STEPS=400
DSC_DATA_N=2000
DSC_NUM_GEN=8
DSC_MAX_COMPLETION=768
DSC_SAVE_STEPS=50
DSC_RESUME=0
DSC_DEBUG=0
DSC_LOG_COMPLETIONS=0
DSC_TRACKIO=openenv-dsc-co
DSC_TRACKIO_SPACE=AceofStades/dsc-co-trackio
reload the trained adapter anywhere with:
from unsloth import FastLanguageModel
model, tok = FastLanguageModel.from_pretrained(
"AceofStades/dsc-co-grpo-lora",
max_seq_length=8192, load_in_4bit=True, fast_inference=True,
)
FastLanguageModel.for_inference(model)
repo layout
canonical openenv multi-mode deployment layout:
openenv-dsc-co/
├── BOOTSTRAP.md full setup, local eval, deployment, and A100 training guide
├── pyproject.toml package metadata, OpenEnv/core deps, pytest pythonpath
├── uv.lock pinned local/OpenEnv dependency resolution
├── openenv.yaml OpenEnv manifest: app server.app:app on port 8000
├── __init__.py package marker for OpenEnv packaging
├── models.py root re-export shim for OpenEnv structural checks
├── client.py CLI for reset/query/dispatch/advance/tools/health
├── app.py training Space health server that starts train.py in a thread
├── README.md main judge-facing overview, links, examples, results
├── BLOG.md short submission writeup / narrative
├── Makefile common install/test/eval/viz/serve/docker/train commands
├── Dockerfile GPU training Space image; launches app.py then train.py
├── .gitignore local cache/output ignore rules
├── .dockerignore keeps local envs, outputs, and trackio_space out of training image
├── .openenvignore keeps training-only/local files out of OpenEnv env pushes
├── requirements.txt environment/runtime deps: fastapi, openenv, pulp, matplotlib
├── requirements-train.txt cuda training deps: torch, trl, unsloth, trackio
├── server/
│ ├── __init__.py
│ ├── app.py OpenEnv/FastAPI app; browser JSON-argument adapter; fallback routes
│ ├── Dockerfile openenv-base multi-stage build for `openenv push`
│ ├── dsc_environment.py DSCEnv(MCPEnvironment) + 4-tier curriculum + 3 fastmcp tools
│ ├── models.py pydantic v2 schemas (DSCAction RootModel, strict int qty)
│ ├── solver.py pulp time-expanded min-cost flow + greedy baseline
│ └── policies.py zero_op, greedy, optimal_replay baseline rollouts
├── tests/
│ ├── __init__.py
│ ├── test_models.py strict-int qty, action envelope parsing, observation schema
│ ├── test_env.py reset shapes, anti-hack gates, valid flow, horizon termination
│ └── test_solver.py milp correctness, tier shapes, bipartite edges
├── notebooks/
│ ├── train_hf_space.ipynb reference notebook; final training used root Dockerfile on HF A100
│ └── train_kaggle.ipynb alternate experiment notebook, not the canonical final run path
├── docs/
│ ├── architecture.md
│ ├── reward-spec.md
│ ├── milp-formulation.md
│ ├── curriculum.md
│ ├── behavior-trace.md
│ └── anti-hacking.md
├── assets/
│ ├── before_after_trace.svg qualitative reactive vs planned behavior trace
│ ├── reward_path.svg reward/verifier flow diagram
│ ├── completion_diagnostics.png completion length and clipping diagnostics
│ ├── gap_hist.png baseline optimality gap histogram
│ ├── reward_components.png final run reward component curves
│ ├── training_health.png reward variance and KL diagnostics
│ ├── terminal_bars.png baseline terminal reward comparison
│ └── training_curve.png final GRPO reward/loss curve
├── results/
│ ├── training_metrics.csv final LoRA repo metrics export
│ ├── training_metrics.json final LoRA repo metrics export
│ └── training_summary.json final run summary
├── stufftodo/
│ └── demo_animation.html local animation page used for the demo video
├── trackio_space/
│ ├── README.md Trackio dashboard Space card/deploy notes
│ ├── app.py live Trackio dashboard app
│ └── requirements.txt Trackio dashboard dependency
├── train.py HF Space GRPO training, local replay fallback, artifact upload
├── eval.py deterministic baseline rollout harness -> eval.json
└── viz.py renders gap, terminal, trajectory, and training curves
mcp action space
deep dive: docs/architecture.md
| tool |
args |
semantics |
query_network |
source_id: str, dest_id: str |
returns {exists, lead_time, unit_cost, capacity} |
dispatch_inventory |
routes: [{src, dst, qty}], max 8 |
strict int qty ≥ 1; deducts inv, schedules shipment |
advance_cycle |
none |
ticks time, processes arrivals, deducts demand, accrues costs; finalize at step 30 |
max 5 calls per cycle; advance_cycle resets the per-cycle counter.
observation
{
"step": 0,
"network_status": "nominal" | "disrupted",
"nodes": [
{"id", "type": "supplier" | "warehouse" | "retail",
"inventory", "max_capacity", "holding_cost", "demand_forecast"}
],
"pipeline": [{"src", "dst", "qty", "arrival_step"}],
"reward": float, "done": bool,
"metadata": {"tier", "agent_cost", "optimal_cost", "terminal", "calls_this_cycle"}
}
reward rubric
deep dive: docs/reward-spec.md
| component |
type |
value |
trigger |
cap |
| r_schema |
dense |
+0.05 |
valid pydantic-parsed tool call |
sum dense ≤ 0.4 |
| r_valid |
dense |
+0.10 |
dispatch with existing edge + inv sufficient |
sum dense ≤ 0.4 |
| r_terminal |
sparse |
clip(opt/agent, 0, 1) |
step == 30 |
— |
| r_neg_exploit |
terminal |
−1.0 + done |
qty ≤ 0 or float |
— |
| r_phantom_edge |
terminal |
0 + done |
dispatch over edge not in adjacency |
— |
curriculum
deep dive: docs/curriculum.md
| tier |
suppliers |
warehouses |
retail |
lead time |
demand |
disruptions |
| 1 |
1 |
1 |
1 |
L=1 |
static |
none |
| 2 |
3 |
5 |
10 |
L=1 |
gaussian |
none |
| 3 |
5 |
10 |
20 |
L∈[1..5] |
gaussian |
capacity jitter |
| 4 |
7 |
14 |
28 |
L∈[1..7] |
seasonal |
severe strikes |
milp formulation
deep dive: docs/milp-formulation.md
min Σ_{e,t} c_e · x[e,t]
+ Σ_{n,t} h_n · I[n,t]
+ Σ_{n,t} P · u[n,t]
s.t. I[n, 0] = I0_n
I[n, t+1] = I[n, t] + arrivals(n, t) − departures(n, t) − d[n, t] + u[n, t]
I[n, t] ≤ cap_n
x[e, t] ≤ cap_e
Σ_{e: src=s, t} x[e, t] ≤ sup_cap (supplier)
arrivals(n, t) = Σ_{e: dst=n, t−L_e ≥ 0} x[e, t − L_e]
solver: pulp.PULP_CBC_CMD(msg=0, timeLimit=30).
anti-hacking hard-gates
deep dive: docs/anti-hacking.md
| vector |
defense |
| negative / zero / float qty |
pydantic strict=True, ge=1 + pre-mutation _is_underflow_qty check → reward −1.0, done |
| cyclic reward farming |
MAX_CALLS_PER_CYCLE=5 + DENSE_CAP=0.4; holding cost > dense reward |
| phantom edge hallucination |
immutable _adjacency: frozenset built at reset → dispatch off-graph ends episode |
evaluation
make eval N=20 TIERS="1 2 3"
make viz
produces:
eval.json with per-rollout cost, gap, terminalassets/gap_hist.png per-tier gap histogramsassets/terminal_bars.png mean terminal reward bars by policy × tier
baseline optimality gap histogram
caption: non-trained baseline policies leave large optimality gaps; optimal_replay is the MILP-derived upper-bound behavior.
baseline terminal reward by policy
caption: terminal reward has clear headroom for RL; greedy behavior is far below the MILP replay ceiling on tier 1.
baseline numbers on 5 seeds (tier 1 / tier 2):
| policy |
tier 1 gap / terminal |
tier 2 gap / terminal |
| zero_op |
4.48 / 0.19 |
1.01 / 0.51 |
| greedy |
1.59 / 0.39 |
0.35 / 0.75 |
| optimal_replay |
0.07 / 0.94 |
0.02 / 0.98 |
greedy ↔ optimal_replay gap is the rl learning target (~0.55 terminal reward points on tier 1).
tests
make test
43 tests across models, env, solver:
- strict-int qty rejection (5 cases)
- action envelope parsing (3 tool kinds + rejection)
- tier 1/2 shape invariants + determinism
- all 3 anti-hack gates under step()
- horizon termination with milp finalize
- milp correctness:
optimal_cost ≤ greedy_cost on random tier-1 scenarios
- bipartite edge topology
credits
meta pytorch openenv team. huggingface trl team. unsloth team. coin-or cbc. apache-2.0.
Neural Network in Rust
A lightweight, from-scratch Neural Network library implemented in Rust, featuring a built-in real-time interactive GUI visualizer built with Macroquad.
Watch the network learn the MNIST dataset in real-time with color-coded neuron activations, and control the training dynamically through the UI.
Features
- From-Scratch Implementation: Neural network core built entirely in Rust without relying on heavy external deep learning frameworks. Features dense layers, Tanh/Sigmoid activations, MSE/CCE cost functions, and backpropagation.
- Real-Time Visualization: See the learning process unfold. Neurons are color-coded based on their activation levels.
- Interactive GUI:
- Pause and resume training at any time.
- Dynamically adjust the learning rate via a slider.
- Control training speed to closely inspect the learning process.
- Reset the network to start over.
- Multithreaded Architecture: Training runs smoothly in a background thread, communicating with the main thread via MPSC channels, ensuring the UI remains responsive and fluid.
- CLI Configurability: Highly customizable through command-line arguments (topology, batch size, epochs, etc.).
- Model Serialization: Save and load trained models using JSON (
serde).
Getting Started
Prerequisites
- Rust (edition 2024)
- MNIST Dataset (The
mnist-dataset folder containing the idx-ubyte files should be present in the root directory).
Installation & Building
Clone the repository and build using Cargo:
cargo build --release
Usage
You can run the application directly with default settings:
cargo run --release
Command Line Arguments
Rust-NN is highly configurable via CLI arguments:
Options:
-t, --topology <TOPOLOGY>... Network layer sizes [default: 784 320 100 10]
-w, --screen-width <WIDTH> Initial screen width [default: 1440.0]
-e, --screen-height <HEIGHT> Initial screen height [default: 900.0]
-l, --learning-rate <LR> Initial learning rate [default: 0.1]
-b, --batch-size <SIZE> Training batch size [default: 32]
-E, --epochs <EPOCHS> Number of training epochs [default: 5]
-p, --path <PATH> Path to save/load the model JSON file
-h, --help Print help
-V, --version Print version
Example:
Train a smaller network with a larger batch size and save it to model.json:
cargo run --release -- -t 784 128 10 -b 64 -l 0.05 -p model.json
GUI Controls
- Left Panel:
- Play/Pause: Toggle training execution.
- Reset: Re-initialize the network weights and restart training from epoch 1.
- Learning Rate Slider: Adjust the learning rate on the fly.
- Speed Slider: Add artificial delay (in ms) between batches to slow down the visualization.
- Bottom Panel:
- Displays real-time training statistics including Epoch progress, Batch count, Loss, and Accuracy.
- Legend:
- Color map explaining neuron activation intensity (Low, Medium, High, Very High).
License
This project is licensed under the MIT License - see the LICENSE file for details.
ENCS Banking Simulator: Systematic Risk & Contagion Engine
Created for Datathon 2026 at K. J. Somaiya College of Engineering by Team Low Taper Fade.
An advanced financial stability platform combining Graph Neural Networks, Strategic Agent Modeling, and High-Performance Simulations.
This project is a comprehensive toolkit for analyzing systemic risk in banking networks. It goes beyond static stress testing by modeling the dynamic, endogenous nature of financial contagion—where one bank's distress triggers fire sales, liquidity runs, and defaults across the entire system.
Project Demonstration
Watch the entire demonstration of this project on YouTube:
https://youtu.be/uk9riC6LneA
Key Features & Deep Dive
1. High-Fidelity Contagion Simulation (Rust + Python)
At the heart of the engine lies a Monte Carlo-based Intraday Liquidity Model. Unlike traditional static models, we simulate the banking system in discrete time steps to capture the rapid unfolding of a crisis.
- Monte Carlo Uncertainty: We model "solvency signals" with Gaussian noise. Creditors don't know a bank's true health perfectly; they receive noisy signals. If the signal drops below a
panic_threshold, they withdraw funding.
- Exponential Fire Sales: When banks face liquidity withdrawals, they must sell assets. We model price impact using an exponential decay function: $P_{t+1} = P_t \cdot e^{-\alpha \cdot \text{Volume}}$, creating a feedback loop where selling drives down prices, forcing more selling.
- Eisenberg-Noe Clearing: At every time step, we solve the fixed-point clearing vector to determine exactly how much each bank can pay its obligations given its current liquidity.
- Rust Acceleration: The core simulation loop is implemented in Rust using
ndarray for matrix operations, offering 10-50x speedups over pure Python. This allows us to run thousands of Monte Carlo trajectories in seconds.
2. Strategic "Game Theory" Agents
- Bayesian Decision Making: Implements the Morris & Shin global game framework. Banks (agents) receive private and public signals about their counterparties' solvency.
- Endogenous Runs: Liquidity runs aren't just random events—they emerge from rational banks deciding to withdraw funding based on their risk aversion and beliefs about others' actions.
- Regime Analysis: Compare "Opaque" vs. "Transparent" information regimes to see how disclosure impacts stability.
3. AI-Driven Risk Prediction (GNN)
- Graph Neural Networks: Uses a Principal Neighbourhood Aggregation (PNA) network to analyze the topology of the banking web.
- Early Warning System: Predicts "Risky" vs. "Safe" status for banks based purely on their network position and balance sheet, even before a crash occurs.
- Explainable AI: Integrated with GNNExplainer to identify exactly why a specific bank is flagged as high-risk (e.g., "High leverage combined with exposure to Bank X").
4. Climate & Transition Risk ("Green Swans")
- Carbon Tax Shocks: Simulates the impact of sudden policy shifts on banks' "Brown" (carbon-intensive) assets.
- Green Bubbles: Models the effects of subsidies and crowding into "Green" assets.
Dataset & Visualization Details
We utilize a curated dataset of approximately 4,500 banks from the USA and European Union, constructed to reflect real-world interbank connectivity distributions.
Visual Coding: In our simulation visualizations:
- 🔵 Blue Nodes: US Banks
- 🟣 Purple Nodes: EU Banks
- 🔴 Red Nodes: Defaulted Banks
- 🟠 Orange Nodes: Distressed Banks
Simulation Scale: While our backend dataset contains ~4,500 nodes, the interactive 3D simulation renders a sub-graph of the top ~500 most systemic nodes to ensure smooth performance in the browser while capturing the most critical contagion channels.
Interactive Simulation
Watch contagion spread in real-time. The visualizer shows shock propagation, capital depletion, and the resulting defaults.
Static view of a contagion cascade:
Bank Explorer
A detailed view of individual bank balance sheets, leverage ratios, and computed GNN risk scores.
Tech Stack
Backend
- Core Logic: Python 3.9+ (FastAPI, NumPy, Pandas)
- High-Performance Compute: Rust (via PyO3 & Maturin) for the Monte Carlo/Intraday engine.
- Machine Learning: PyTorch, PyTorch Geometric (GNNs).
- LLM Integration: Modules for generating natural language explanations of simulation results.
Frontend
- Framework: React 19 (Vite)
- Visualization: Three.js, React Three Fiber (
react-force-graph-3d), Recharts, Plotly.js.
- Styling: Tailwind CSS, Framer Motion.
Project Structure
/
├── backend/
│ ├── api.py # FastAPI entry point
│ ├── ml_pipeline.py # GNN training and inference logic
│ ├── simulation_engine.py # Core contagion physics (Python fallback)
│ ├── strategic_model.py # Bayesian game agents
│ ├── encs_rust/ # Rust source code for high-perf simulation
│ │ ├── src/lib.rs # Monte Carlo & Intraday logic in Rust
│ │ └── Cargo.toml # Rust dependencies
│ └── data/ # Network datasets and models
├── frontend/
│ ├── src/
│ │ ├── components/ # React components (NetworkGraph3D, etc.)
│ │ ├── pages/ # Main application views
│ │ └── services/ # API integration
└── .github/ # CI/CD and Agent definitions
Quick Start
Prerequisites
- Python: 3.9 or higher
- Node.js: 18+
- Rust: (Optional) Required only if you want to rebuild the accelerated simulation engine.
1. Backend Setup
The backend handles the simulation logic and API.
cd backend
# Create a virtual environment
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
# Install dependencies
pip install -r requirements.txt
# (Optional) Build the Rust extension for maximum performance
# Requires Rust toolchain (cargo)
# pip install maturin
# cd encs_rust && maturin develop --release && cd ..
# Start the API server
uvicorn api:app --reload --port 8000
2. Frontend Setup
The frontend provides the interactive dashboard.
cd frontend
# Install dependencies
npm install
# Start the development server
npm run dev
Open your browser to http://localhost:5173 (or the port shown in your terminal).
Contributing
We welcome contributions! Please see the issue tracker for outstanding tasks.
- Fork the repo.
- Create your feature branch (
git checkout -b feature/AmazingFeature).
- Commit your changes.
- Push to the branch.
- Open a Pull Request.
License
Distributed under the GNU General Public License v3.0. See LICENSE for more information.
DZap: Secure Drive Wiper
DZap is a cross-platform utility designed to securely sanitize storage media (HDDs, SSDs, NVMe, USBs) to NIST 800-88 standards.
WARNING: This software is designed to permanently and irretrievably destroy data. Use with extreme caution. The developers are not responsible for accidental data loss.
Screenshots
Key Features
- Modern Tech Stack: Built with Electron, React, & Tailwind CSS for a responsive UI, backed by Go for high-performance hardware interaction.
- NIST 800-88 Compliance:
- Clear: 1-pass and 3-pass overwrite algorithms for HDDs.
- Purge: Firmware-based
ATA Secure Erase and NVMe Format for modern SSDs.
- Secure Architecture: Uses a Privileged Helper pattern. The UI runs as a standard user, while the backend runs securely via Linux PolicyKit (
pkexec) only when necessary.
- Certified Destruction: Generates a verifiable HTML/PDF certificate upon successful completion.
- Hot-Plug Support: Automatically detects drives connected via USB or SATA/NVMe interfaces.
Prerequisites
Before installing, ensure your Linux system has the following dependencies:
- Runtime Tools:
smartmontools, hdparm, nvme-cli, polkit
- Build Tools:
go (v1.21+), npm / node, gcc
- AI Runtime:
libonnxruntime (often available as onnxruntime or libonnxruntime-dev) (Disabled for now)
Arch Linux:
sudo pacman -S go npm smartmontools hdparm nvme-cli onnxruntime
Ubuntu/Debian:
sudo apt install golang nodejs npm smartmontools hdparm nvme-cli libonnxruntime-dev
Installation & Build
Because DZap uses a system-level backend service, installation is a two-step process.
1. Build the Application
Clone the repository and build the source code.
npm install
npm install cross-env --save-dev
npm run start:frontend
In another terminal run:
cd server
sudo go run .
2. Install the Backend Helper
Run the provided installer script. This copies the Go binary to a secure system location (/usr/local/bin) and installs the PolicyKit rules allow the UI to communicate with it.
sudo ./install.sh
Usage
Once installed, you can run the application like any other Linux program.
- Navigate to the
dist/ folder (or wherever you moved the AppImage).
- Run the application:
./DZap\ Secure\ Wiper-1.0.0.AppImage
(Note: You do NOT need sudo to run the AppImage).
- When the backend needs to start (usually immediately upon launch), the system will prompt you for your password via a secure GUI dialog.
Development
For developers contributing to DZap, use the development mode which enables hot-reloading.
Recommended Workflow:
- Terminal 1 (Backend):
cd server
sudo go run .
- Terminal 2 (Frontend):
npm run start:frontend
Project Structure
DZap/
├── electron/ # Main process logic (window creation, IPC)
├── frontend/ # React UI (Tailwind, Components, State)
├── server/ # Go Backend
│ ├── api/ # HTTP Handlers
│ ├── core/ # Drive detection, Wiping logic, AI prediction
│ └── realtime/ # WebSocket hub
├── model/ # ONNX AI models and feature maps
└── install.sh # System installer script (In Development)
Contributing
Contributions are welcome! Please follow these steps:
- Fork the repository.
- Create a feature branch (
git checkout -b feature/AmazingFeature).
- Commit your changes (
git commit -m 'Add some AmazingFeature').
- Push to the branch (
git push origin feature/AmazingFeature).
- Open a Pull Request.
License
Distributed under the MIT License. See LICENSE for more information.
No README found for this repository.
🌊 FloatChat - AI-Powered Ocean Data Exploration
🔴 Live Demo: FloatChat Web App (Hosted on Amazon S3)
FloatChat is an advanced ocean analytics platform designed to transform oceanographic research. By combining interactive 3D visualization with AI-driven natural language processing, FloatChat allows researchers and enthusiasts to explore complex ARGO float data, visualize global ocean monitoring networks, and uncover insights through simple conversation.
📸 Project Previews
| Landing Page |
Interactive Globe |
 |
|
| AI Chat Interface |
Data Dashboard |
|
|
🚀 Key Features
- AI Conversational Interface: Query ocean data using natural language. The system translates questions into SQL/Data queries using LLMs (Large Language Models).
- Interactive 3D Globe: Visualize ARGO float locations and trajectories on a rendered 3D Earth using
Three.js and @react-three/fiber.
- Dynamic Dashboards: View real-time charts, salinity maps, and temperature profiles utilizing
Recharts.
- NetCDF Data Processing: Upload and process raw
.nc (NetCDF) files directly through the platform.
- Authentication System: Secure login, registration, and guest access modes.
- Research Grade Data: Tools for analyzing temperature, salinity, and biogeochemical profiles.
☁️ AWS Cloud Architecture
FloatChat is deployed using a decoupled, highly scalable, and secure 10-service AWS architecture, designed to balance performance with strict security and auditing compliance.
The 11 AWS Services Integrated:
- Amazon S3 (Frontend & User Data): Dual-purpose object storage. It hosts the compiled Next.js frontend as a static website, providing infinite scalability. A separate secure bucket completely isolates user-uploaded NetCDF files and their processed SQLite database states to ensure zero data cross-contamination between chat sessions.
- Amazon CloudFront (CDN): A global content delivery network serving the S3 frontend. It dramatically accelerates page load times for international researchers by caching assets at edge locations and automatically enforcing HTTPS encryption.
- Amazon Cognito (Authentication): Enterprise-grade identity management. It handles the complete lifecycle of user registration, login authentication, password recovery, and the issuance of secure JSON Web Tokens (JWT) required to access the API.
- AWS WAF (Web Application Firewall): Attached directly to the API Gateway, WAF acts as an advanced Layer 7 security shield. It inspects all incoming traffic for malicious payloads, blocks SQL injection attempts, mitigates DDoS attacks, and enforces strict rate-limiting.
- Amazon API Gateway (Routing): The highly optimized HTTP/REST ingress layer. It receives all secure backend requests from the Next.js frontend, validates CORS headers, and dynamically triggers the appropriate serverless compute resources.
- AWS Lambda (Compute): The core serverless "glue" of the application. Containerized via Docker, this Python backend processes incoming
.nc files into dataframes, queries the DynamoDB state, constructs the LLM prompts, and streams the AI response back to the client. It scales instantly to zero, costing absolutely nothing when the app is idle.
- Amazon EC2 (AI Engine Proxy): A persistent
t2.micro instance running the Ollama engine. Instead of crashing a low-memory instance with heavy local model weights, it acts as a lightweight proxy interface to the glm-5:cloud LLM, ensuring 100% stability and sub-second generation speeds.
- Amazon DynamoDB (State Management): A high-performance NoSQL database. It replaces transient local memory by permanently storing individual user chat histories, session identifiers, and metadata schemas, giving the AI continuous, stateless "memory" across user visits.
- Amazon ECR (Elastic Container Registry): A highly available docker registry storing the custom Python 3.12 image required to run our FastAPI application and its complex scientific dependencies (like Pandas and Xarray) inside Lambda.
- AWS CloudTrail (Governance): Continuous security and compliance auditing. It acts as an immutable ledger, tracking and recording every internal API call (like S3 bucket access or DynamoDB queries), proving that user scientific data is handled securely and transparently.
- Amazon CloudWatch (Observability): Centralized telemetry. It automatically ingests all output logs, tracebacks, and execution metrics from Lambda and API Gateway, enabling rapid debugging and system health monitoring without ever SSHing into a server.
Architecture Data Flow
graph TD
User([User / Browser]) -->|HTTPS Request| CF[Amazon CloudFront]
CF -->|Static Assets| S3_Front[Amazon S3: Frontend Hosting]
User -->|Authentication| Cognito[Amazon Cognito]
User -->|API / Chat Request| WAF[AWS WAF]
WAF --> APIGW[Amazon API Gateway]
APIGW -->|Trigger| Lambda[AWS Lambda: Python Backend]
Lambda <-->|Fetch/Store User State| DynamoDB[(Amazon DynamoDB)]
Lambda <-->|Upload/Download Data| S3_Data[(Amazon S3: User Data)]
Lambda -->|LLM Prompt| EC2[Amazon EC2: Ollama AI Proxy]
EC2 -.->|External API| LLM[Cloud LLM Model]
Lambda -.->|Logs| CW[Amazon CloudWatch]
subgraph Audit & Governance
CT[AWS CloudTrail] -.->|Logs Activity| S3_Front
CT -.->|Logs Activity| S3_Data
CT -.->|Logs Activity| DynamoDB
end
For more detailed information, see the Deployment Architecture Documentation.
🛠️ Tech Stack
Frontend (Client)
Built with modern React ecosystem tools for performance and interactivity.
- Framework: Next.js 15 (App Router)
- Language: TypeScript / React 19
- Styling: Tailwind CSS & Shadcn/UI
- Animations: Framer Motion & GSAP
- 3D Visualization: @react-three/fiber, @react-three/drei
- State Management: React Context API
- AI Integration: Google Generative AI SDK
Backend (Server)
A robust Python backend handling data processing and AI logic.
- Framework: FastAPI
- Server: Uvicorn
- Data Processing: Pandas, Xarray (for NetCDF), NumPy, SciPy
- Database: SQLite
- AI/ML: FAISS (Vector DB for similarity search), Custom NLP-to-SQL logic
📂 Project Structure
FloatChat/
├── public/ # Static assets (images, textures, models)
├── server/ # Python FastAPI Backend
│ ├── app/ # Application logic
│ │ ├── ai_core.py # LLM & Vector DB handling
│ │ ├── database.py # Database connection & queries
│ │ ├── processing.py # NetCDF & Dataframe processing
│ │ └── visualizations.py # Map & Graph generation
│ ├── main.py # Server entry point
│ ├── requirements.txt # Python dependencies
│ └── *.nc / *.db # Local data storage
├── src/ # Next.js Frontend Source
│ ├── app/ # App Router pages & layouts
│ ├── components/ # React Components
│ │ ├── ui/ # Shadcn reusable UI elements
│ │ └── ... # Feature components (Globe, Chat, etc.)
│ ├── contexts/ # Global state providers (Auth)
│ ├── hooks/ # Custom React hooks
│ ├── lib/ # Utility functions
│ └── styles/ # Global CSS & Tailwind config
├── package.json # Frontend dependencies
├── tailwind.config.ts # Tailwind configuration
└── tsconfig.json # TypeScript configuration
🏁 Getting Started
Prerequisites
- Node.js (v18+)
- Python (v3.9+)
Installation
Clone the repository:
git clone [https://github.com/vishalbarai007/floatchat.git](https://github.com/vishalbarai007/floatchat.git)
cd floatchat
Setup Backend:
cd server
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
pip install -r requirements.txt
uvicorn main:app --reload
Setup Frontend:
# Open a new terminal in the root directory
npm install
npm run dev
📖 Usage
- Open the App: Go to http://localhost:3000.
- Upload Data: Navigate to the "Upload Data" page and upload a NetCDF (
.nc) file (e.g., ARGO float data).
- Start Chatting: Go to the "Chat" page. Ensure the backend is running.
- Example Query: "Show me the temperature profile for the last month."
- Example Query: "Map the location of the floats."
- Explore Globe: Visit the "Globe" tab to see the 3D representation of data points.
🤝 Contributing
Contributions are welcome! Please follow these steps:
- Fork the project.
- Create your feature branch:
git checkout -b feature/AmazingFeature
- Commit your changes:
git commit -m 'Add some AmazingFeature'
- Push to the branch:
git push origin feature/AmazingFeature
- Open a Pull Request.
📄 License
Distributed under the MIT License. See LICENSE for more information.
Built with 💙 by Jr. Coding Saints
No README found for this repository.
No README found for this repository.
Meta PyTorch OpenEnv Hackathon
Top 100 out of 800 Teams
April 2026
- Engineered a dynamic supply chain combinatorial orchestration environment to train and verify agentic reasoning via GRPO.
e-Yantra Hackathon (EYantra Herd Link)
Region Finalist
2025
- Engineered an edge-computing smart collar (ESP32-C3) with IMU behavioral inference and on-device FFT audio processing.
- Developed a Rust-based edge server (Tokio, Axum) for real-time analytics, robust data buffering, and async Supabase syncing.
- Built an offline-first Android app using an ONNX-optimized EfficientNet-B0 and YOLOv8-nano cascade for local classification.
Datathon 2025 (KJSCE)
1st Runner-up (2nd Place)
February 2025
- Developed predictive XGBoost models to identify customer churn risk, achieving high precision on raw user behavior datasets.
CideCode Hackathon (CID Karnataka)
Consolation Place
March 2025
- Built a multimodal deepfake detection system utilizing MTCNN for facial extraction and CNNs for authenticity scoring.
Machine Learning Specialization
Coursera
View Certificate →
Deep Learning
Coursera
View Certificate →
B.E. in Computer Engineering
MCT's Rajiv Gandhi Institute of Technology, Mumbai
Expected graduation: 2027
Class XII
Prakash College of Commerce and Science
Completed in 2023
Class X
SVKM's CNM School (Chatrabhuj Narsee Memorial School)
Completed in 2021
Languages
- Rust: async services, simulation engines, neural-network tooling, and edge work.
- Python: machine learning, computer vision, data processing, and automation.
- Go: systems utilities and hardware-facing applications.
- C++: systems programming and performance-oriented development.
Machine Learning
- Deep learning: PyTorch, U-Net, LSTM, CNNs, and representation learning.
- Computer vision: MTCNN, EfficientNet, YOLOv8, and image-processing pipelines.
- Inference: ONNX and TensorRT optimization for deployment on NVIDIA and edge hardware.
- Reinforcement learning: GRPO, TRL, Unsloth, and environment design.
- Classical ML: XGBoost and predictive modeling for structured data.
Systems & Infrastructure
- Linux: Arch package testing, kernel regression analysis, and system configuration.
- Async systems: Tokio, Axum, MPSC pipelines, buffering, and edge services.
- Security tooling: SBOM and SCA workflows, offline vulnerability databases, and air-gapped deployment testing.
- Hardware utilities: secure storage sanitization and embedded system integration.
Hardware & Embedded
- Visualization: Macroquad applications and real-time data exploration.
- Embedded: ESP32-C3, IMU-based inference, FFT audio processing, and offline-first device workflows.
- Hardware: ZMK firmware, custom keyboards, and 3D-printed components.
