samar siddiqui

A BMC diagnostic collector and report viewer for NVIDIA GB200 NVL72 servers. One run produces a self-contained HTML report a field technician can email, drop on OneDrive, or attach to a support ticket — colleagues open it anywhere with zero install, no server, no driver, no admin rights.

Purpose

GB200 NVL72 is NVIDIA's flagship AI-training platform: 4 GPUs per sled, 72 GPUs per rack, ~$4M+ per rack, liquid-cooled. When a unit fails in the field, every minute of downtime is expensive — and existing options for triage all had real gaps:

• The vendor BMC web UI works, but it's browse-one-screen-at-a-time. No way to archive a snapshot, no way to share, no comparison across systems.
• Raw Redfish curl scripts are fast for one engineer and useless for a team.
• nvidia-bug-report.sh is in-band — it requires the host OS booted with NVIDIA drivers loaded. Useless during pre-OS issues, OS-install failures, or bare-metal triage.
• NVIDIA Field Diagnostics is heavyweight, environment-specific, and not aimed at the kind of fleet-wide triage Dell field operations runs daily.

What was missing was a single command that captures everything an engineer might need — Redfish state, IPMI events, sensor readings, leak detectors, BMC logs, firmware versions — and bundles it into one portable artifact you can attach to a JIRA ticket or send to NVIDIA L3 without giving them BMC credentials.

I built FusionProbe to fill that gap, and to make the resulting data actionable rather than just dumped on the reader.

Goals

• Out-of-band only. Must work even when the host OS is wiped or has no drivers loaded — diagnostics shouldn't depend on the very thing being diagnosed.
• Zero installation on the technician's laptop. No package manager, no admin rights, no Python, no Node. Drop a folder onto the machine, double-click .bat, go.
• Single shareable artifact. Output one file the recipient can open without unzipping, running a server, or trusting an installer.
• Read-only by design. The collector cannot reset the BMC, clear logs, modify configuration, or alter system state — verified at the command level on every release.
• Educational. Junior technicians reading the output should be able to learn what each IPMI command means and what each finding implies, without leaving the viewer.

Constraints

• Field laptops run Windows with PowerShell 5.1 (no PS7, no Node, no admin rights, no internet during runs).
• BMCs are on isolated management networks reachable only via a "repair jumper" — so all traffic gets tunneled over a single SSH session.
• Many BMCs flake under load (TLS handshake failures, mid-session connection drops, "Stream was not readable" errors). Reliability had to be engineered in.
• Distribution is manual — sync the bundle through iCloud or OneDrive, copy to a colleague's laptop. No app stores, no auto-update.
• The viewer has to render gracefully from file://, OneDrive web preview, and a local HTTP server — without three different code paths.

Architecture

Two halves: a PowerShell collector, and a self-contained HTML viewer.

Field laptop (Windows)
  └─ Run-FusionProbe.ps1   (Windows Forms GUI)
       └─ SSH tunnel session → repair jumper
            ├─ TCP port-forward → BMC:443 (Redfish over HTTPS)
            └─ remote shell    → ipmitool over IPMB
       └─ writes <serial>-<timestamp>/  +  viewer.html  (self-contained)

The collector walks every relevant Redfish endpoint (firmware, inventory, GPU, sensors, leak detectors, 13 log services), runs 19 read-only ipmitool commands on the jumper, parses output, and produces a structured zip bundle. The viewer is built by a final New-Viewer.ps1 step that inlines every bundle JSON and log file as a window.BUNDLE script block at the top of viewer.html. The renderer prefers that embedded data and falls back to fetch() when the bundle is served over HTTP — same file, both modes.

Development Process

This was an iterative, feedback-driven build. Every release was triggered by a real problem someone hit in the field — not a roadmap I wrote up front:

Engineering Decisions

• PowerShell over Python — Windows-native, no install, runs on every field laptop. Shipping a Python interpreter would have meant vendor approval and ~50 MB of bundled binaries.
• Self-contained HTML viewer over Electron — I prototyped an Electron desktop app first. It was a 100 MB installer with code-signing pain and a parallel codebase. I deleted it. The viewer is now a single 3–5 MB HTML file that works everywhere, including environments where you can't install software.
• JSON-driven viewer with embedded fallback — Single source of truth (the bundle JSONs), rendered identically whether served over HTTP or opened from disk. The renderer's fetchJson() checks window.BUNDLE first, then network — one indirection, two modes.
• Rule-based verdict, not ML — Findings come from hand-curated rules with explanations a technician can read and override. Auditable, deterministic, no model drift, no opaque "the algorithm says X" failures.
• Read-only by design — Every IPMI command audited; destructive variants (mc reset, sel clear, chassis power off, raw 0x..) explicitly excluded so the tool can run on production systems without authorization friction.

Challenges Solved

A few representative ones:

• PowerShell 5.1 + UTF-8 encoding — Em dashes in source files were mangled by the system codepage, breaking the parser at runtime on Windows-1252 hosts. Fixed by sanitizing all .ps1 files to ASCII; documented as a maintenance rule.
• </script> inside a JS comment — Closed the surrounding <script> tag prematurely (the HTML parser doesn't understand JS comments) and rendered the rest of the JS as page text. Fixed with <\/script> escape.
• TLS handshake failures through SSH tunnels — BMCs would close pooled connections mid-collection, surfacing as "Stream was not readable." Fixed by forcing fresh TCP+TLS per request via -DisableKeepAlive and proactive ServicePoint.CloseConnectionGroup() on retry.
• Empty-string args dropped by pwsh -File — Couldn't pass an empty jumper password through the script-bundle GUI. Fixed by passing secrets via env vars (FUSION_PROBE_USER / FUSION_PROBE_PASS / FUSION_PROBE_JUMPER_PASS), matching the pattern Microsoft uses for Get-Credential.
• Windows Forms UI freezes on cleanup — Stop-SshTunnel and Remove-Job -Force block the message pump for several seconds, leaving text boxes unable to take focus. Fixed by reordering: switch panels first, pump the queue with Application::DoEvents(), defer cleanup off the user-perceived path.

Outcomes

• One command, complete diagnostic snapshot of a $4M+ system in ~90 seconds.
• One file (3–5 MB viewer.html) that works on any reviewer's machine, including OneDrive web preview, with zero install.
• Triage that's actionable — every finding maps to a recommended action with evidence linked back to the source data.
• Fleet-aware — N bundles in a folder become a row-per-system dashboard with severity rollups.
• Trend-aware — repeated snapshots of the same system render as sparklines and a snapshot table.
• Trainee-aware — every IPMI command and BMC concept is explained inside the tool.
• Read-only and auditable — safe to run on production hardware without sign-off.

Tech Stack

• PowerShell 5.1 / 7 — collector, GUI, watcher
• Windows Forms — local GUI on the technician's laptop
• Posh-SSH (SSH.NET) — bundled SSH library for the jumper tunnel
• Redfish (DMTF) API over HTTPS — primary BMC interface
• IPMI / ipmitool — secondary, run remotely on the jumper over SSH
• Vanilla HTML + CSS + ES2020 JavaScript — viewer; no framework, no build step
• SVG sparklines — trend visualization
• Markdown export — support-packet format

Built and maintained by Samar Siddiqui. Designed to make BMC diagnostics shareable, actionable, and educational — turning a structured data dump into a triage assistant.

A native Android valet platform with a hardened Node.js backend — designed so an attendant can pull out a phone at the curb, point at a license plate, and create a complete, encrypted, audit-ready record in under a minute, even with no internet.

Purpose

I built the Airport Valet Management System to solve a real operational problem I saw at airport valet stands: vehicle intake is still done with paper tickets and handwritten plates, which leads to slow check-ins, lost records, and disputes when a car gets damaged or misplaced. I wanted to design a single tool that a valet attendant could pull out at the curb, point at a license plate, and have a complete, encrypted, audit-ready record created in under a minute — even with no internet.

The goals I set going in:

• Speed at the curb. Intake had to be faster than paper, not slower. That ruled out long forms and pushed me toward camera-first capture with OCR auto-fill.
• Works without signal. Airport garages have terrible connectivity, so the app could never depend on a live network. Records had to queue locally and sync later without the user thinking about it.
• Treat customer data like it matters. Names, plates, and vehicle photos are sensitive. I wanted field-level encryption and short-lived signed URLs from day one rather than bolted on later.
• Realistic enough to deploy. I wanted the project to demonstrate that I can ship a system, not just a demo — admin accounts, role-based access, lockouts, TLS termination, certificate pinning, Docker Compose for the backend.

It also gave me a chance to work end-to-end across a stack I cared about: native Android with modern Jetpack libraries on the client, and a hardened Node.js + PostgreSQL service on the back end.

Development Process

• 1. Problem framing and architecture. I started by mapping the valet workflow on paper — drop-off, photo capture, retrieval, handoff — and identified the two hardest constraints: offline-first behavior and field-level encryption. Those two requirements shaped almost every later decision. I sketched the architecture (Android client → Nginx/TLS → Node/Express → PostgreSQL + S3) before writing any code.
• 2. Backend first. I built the Node.js/Express API with PostgreSQL 16 and a SQL-migration setup so the schema would be reproducible. Auth was JWT with rotating refresh tokens, account lockout after configurable failed attempts, and per-route rate limiting. Sensitive fields use AES-256-GCM at rest, and license plates are also HMAC-indexed so I can search without decrypting. Vehicle photos go to a private S3 bucket and are only ever served through short-lived presigned URLs.
• 3. Android client with offline-first as a non-negotiable. The app is Kotlin + Jetpack Compose with MVVM and Hilt for DI. Room is the source of truth on the device — every check-in is written locally first, then WorkManager handles sync with retry/backoff when connectivity returns. CameraX drives photo capture; ML Kit's on-device OCR reads license plates and pre-fills the form so the attendant just confirms.
• 4. Security hardening pass. Once the happy paths worked, I did a dedicated security pass: certificate pinning in release builds, tokens stored in EncryptedSharedPreferences, FLAG_SECURE to keep the app out of recents and screenshots, allowBackup=false, and CORS + secret-management cleanup on the backend.
• 5. Deployment ergonomics. I containerized the backend with Docker Compose (Postgres + API + Nginx) so the whole stack stands up with one command, wrote a seed script for the initial admin, and documented the production path including TLS, cert-pin extraction, and signed release builds.
• 6. Iteration. Recent work focused on UX polish — a redesign pass and edit/delete functionality for existing records — based on walking through the flow myself and noticing where the original screens slowed me down.

Stack at a glance: Kotlin, Jetpack Compose, CameraX, ML Kit, Room, WorkManager, Hilt, Retrofit · Node.js 20, Express, PostgreSQL 16, AWS S3, Nginx, Docker.

Senior capstone built for an industry sponsor — a Note Generation Service that turns a few high-level clinical inputs into a structured, reviewable EMR note via Google Gemini, exposed through a hardened API gateway and reused by both the UI and an automated batch job.

Purpose for Developing This Project

This was my senior capstone project (SE 4485 – Software Engineering Project) at The University of Texas at Dallas, completed for an industry sponsor. The sponsor maintains a Behavioral Health Center (BHCC) Simulator used to model patient encounters and electronic medical record (EMR) workflows. In its original form, clinicians using the simulator had to type every clinical note from scratch — selecting a patient, choosing a note category and sub-category, and manually composing the body of the note. That manual step was slow, inconsistent across users, and a poor reflection of the kind of AI-assisted documentation that real EMR systems are starting to adopt.

Our team was asked to bridge that gap. The purpose of the project was to:

• Reduce documentation burden by generating structured clinical notes from a few high-level inputs — the patient's current state, the type of note needed, and a short summary of the patient journey — instead of forcing a clinician to write every line.
• Introduce a Note Generation Service as a middleware layer that sits between the simulator UI and an LLM (Google Gemini), so note-related logic lives in one well-defined place and can be reused by both the UI and automated jobs.
• Expose a clean RESTful API so the same note-generation capability could be triggered manually from the UI or driven on a schedule by an automated job — enabling the second objective of the project, batch / automated note creation on top of the same architecture.
• Demonstrate production-grade engineering practices — secure API key handling, an API gateway pattern, full test coverage (unit, integration, functional, performance, security), peer-reviewed pull requests, and configuration management — at a level appropriate for a real client deliverable, not a class demo.

Beyond the technical goals, the project gave me a chance to work end-to-end on a problem with real stakeholders: a sponsor with opinions about scope, a faculty advisor evaluating engineering rigor, and a small team that had to coordinate across documents, code, and reviews.

Development Process

• Team & cadence. I worked on a four-person team under the SE 4485 capstone framework. We followed an iterative process with weekly sponsor syncs, a written project management plan (revised across multiple versions and tracked in documents/), and a CHANGELOG.md that recorded every meaningful change with version numbers, difference highlights, and named peer reviewers. Every change required at least two reviewers before it could land — a hard rule from our configuration management plan.
• Configuration management. We used GitHub as our CM tool, with kebab-case naming for all files, descriptive PR titles linked to tickets, and Husky + lint-staged enforcing ESLint and Prettier on every commit so style never became a code-review topic. Branching followed a simple model: feature branches off dev, peer review, then merge.

Architecture decisions. Two choices defined the shape of the codebase:

• 1. API Gateway pattern. Rather than calling Gemini and the BHCC API directly from the React app, we built an Express gateway (server/index.ts) that proxies both. This kept the Gemini API key strictly server-side, gave us a single place to add rate limiting (100 req/15 min in production), CORS rules, input validation, and request size limits, and let us version the Gemini endpoints behind RESTful resource URLs (/api/gemini/models/:modelId/content) instead of leaking Google's URL scheme into the frontend.
• 2. Feature-oriented React structure. The UI is React 19 + TypeScript + Vite, with MUI for components, TanStack Query for server state, Formik + Yup for form handling, and React Router for navigation. Code is organized by pages/, features/, components/, services/, and hooks/ so that note-generation logic, patient-census logic, and shared UI live in clearly separated layers.

Building toward the two objectives:

• Objective 1 – AI-assisted notes. We built dynamic, schema-driven forms that capture only the high-leverage inputs for each note type, ship them through the gateway to Gemini with a tuned prompt, and return a structured note the user can review and edit before submission to the simulator.
• Objective 2 – Automated batch generation. Because the gateway exposes the same RESTful endpoints the UI uses, the batch flow reuses the exact same note-generation pipeline. We added a batch results dialog in the UI to surface per-patient outcomes, but the core logic didn't have to fork.

Testing Strategy

Testing was treated as a first-class deliverable, not an afterthought. The repo has six distinct test suites wired up through Vitest:

• tests/unit — component and utility-level tests
• tests/integration — gateway + API integration, including a dedicated security suite
• tests/functional — user-flow tests through the rendered UI
• tests/performance — performance budgets
• tests/quality — code-quality assertions
• tests/live — tests that hit live services for end-to-end verification

A separate npm run test:security target runs only the security validation and gateway-security integration tests, which proved useful when reviewing input validation and CORS behavior.

Deployment

The frontend deploys to Azure Static Web Apps via the GitHub Actions workflow in azure-static-web-apps-gentle-rock-0e36fee10.yml, and the gateway runs as a separate Node service. Local development uses npm run dev:full to bring up both processes together.

What I personally took away: the capstone forced me to balance three things at once — writing code a sponsor would actually use, documenting decisions for a faculty review, and coordinating with teammates whose review I couldn't bypass. The hardest, and most valuable, part wasn't the AI integration; it was the discipline of small, reviewed, well-described changes flowing through a CHANGELOG and a CM plan, the way real engineering teams actually ship.

An internal deal-execution CRM for a real estate construction firm — a single source of truth that mirrors how the team actually works deal by deal, rather than a generic sales CRM bent into the shape of construction.

Purpose

GridIron Construction CRM is an internal deal-execution tracker built for a real estate construction firm that needed visibility into properties as they move from sourcing to exit. Off-the-shelf CRMs are tuned for sales pipelines (leads, contacts, opportunities) and don't model the operational reality of a construction-and-investment shop: a property sitting in "Under Contract" has different obligations than one in "Execution," and skipping steps causes real financial and legal exposure.

I built this to solve three concrete problems the team was hitting with spreadsheets:

• 1. Properties getting stuck without anyone noticing. A deal could sit in the same status for weeks because there was no system-of-record flagging it. The CRM auto-generates alerts when a property has been in the same stage for more than 14 days.
• 2. Inconsistent execution between deals. Each status (Sourced → Underwritten → Offer/Negotiation → Under Contract → Owned → Execution → Exit) has a required checklist. The pipeline is gated — you cannot advance a property until every required item for its current stage is completed, which enforces process discipline at the database level rather than relying on memory.
• 3. Operational data scattered across tools. Documents lived in Drive, budgets in Excel, permits in email threads, investor splits in another spreadsheet. The CRM consolidates documents, budgets (with budget-vs-spent tracking), permits, investor assignments with ownership percentages, and per-checklist-item notes against a single property record.

The goal was a single source of truth that mirrors how the team actually works deal by deal — not a generic CRM bent into the shape of construction.

Development Process

• Stack & shape. TypeScript + Express on the backend, vanilla HTML/CSS/JS for the UI served as static files, and SQLite via libSQL/Turso for the database. I deliberately kept the frontend dependency-free — no React, no build step on the client — because the user base is small and internal, and a single-binary Express server with static assets is dramatically easier to deploy and maintain than a full SPA pipeline.
• Schema-first design. I started with the data model rather than the UI. The pipeline's invariants — linear progression, single current status, full status history with durations — are encoded directly in the schema and enforced via triggers. When a property's current_status_id changes, a trigger automatically closes the previous property_status_history row (stamping exited_at and computing duration_seconds) and opens a new one. This means the timer logic is correct even if a developer forgets to call a service method, because the database itself owns the invariant.
• Layered backend. The server is organized as routes → services → query layer → connection. The service layer (e.g. StatusTransitionService, ChecklistService) holds the business rules — "can this property advance?", "are all required checklist items complete?" — so the HTTP routes stay thin and the same logic is reachable from scripts or future clients. Status transitions are wrapped in transactions to keep the history table and the property row consistent.
• Iterative feature build-out. Once the core pipeline + checklist gating worked end-to-end, I layered features on as separate, optional schema extensions (schema-extensions.sql) so existing deployments could opt in without re-migrating: per-checklist-item notes, document uploads (Multer + local uploads/ directory), investor assignment with ownership percentages, budget tracking with budget-vs-spent progress, permit status tracking, and the stalled-deal alert system. Each feature got its own table, its own route file, and its own tab in the property detail UI — which kept blast radius small when iterating.
• Database portability. The project initially targeted Postgres, then I migrated to libSQL/Turso for easier deployment and a serverless-friendly footprint. I kept both schema files (schema.sql and schema-turso.sql) in the repo as documentation of the migration path, and the connection layer abstracts the client so the rest of the codebase didn't need to change.
• Auth added later, deliberately. The first version had no user model — the team wanted to validate the pipeline mechanics before adding accounts. Once the core was stable, I layered in bcrypt-based auth, roles, cookie sessions, and per-user tracking on properties (schema-auth-*.sql, schema-property-user-tracking.sql) as additive migrations rather than a rewrite.

Tradeoffs I'd Call Out in an Interview

• Triggers over application-level enforcement for status history — gains correctness, costs portability if we ever switched databases. Worth it here because the invariant is load-bearing.
• Vanilla JS over a framework — gains simplicity and zero build pipeline, costs ergonomic state management as the UI grew tabbed and stateful. The tradeoff is still right for the user count, but it's the first thing I'd revisit at scale.
• Service-layer gating instead of a DB constraint for advancement — a check constraint can't easily reference a count from another table. Documented as "Business Rules Enforced" so the constraint is visible to readers of the schema.

A first-person horror game that inverts a familiar children's rule-set: in Simon Says the threat is social embarrassment, in Simon Sees the threat is a physical presence in the room with you — dread emerging not from the unknown but from breaking a rule you fully understand.

Purpose

The goal of this project was to translate a familiar, low-stakes children's game into a horror experience by inverting its core tension. In Simon Says, the threat is social embarrassment; in Simon Sees, the threat is a physical presence in the room with you. We wanted to explore how horror can emerge from rules the player already knows, where dread comes not from the unknown but from breaking a rule you fully understand.

Beyond the design experiment, the project served as a hands-on opportunity to:

• Practice end-to-end production of a small game, from prototype to packaged build.
• Apply concepts from class — scene management, animation, audio mixing, lighting, and gameplay scripting — in a single cohesive product rather than isolated exercises.
• Collaborate as a team on a shared Unity project, navigating the realities of source control, asset conflicts, and merging work across contributors.

Development Process

The project was developed in Unity (URP) using C# and built around several interconnected systems:

• 1. Pre-production and design. We started by defining the core loop: the player must keep a generator running (a timing-based mini-game) while obeying Simon's color cues on the floor tiles. Looking at the wrong tile, or running out of power, escalates the threat. We mapped out scenes early — Menu, Game, Jumpscare, FailScene, and SuccessCutscene — so each team member could own a slice of the experience.
• 2. Core gameplay systems. Implementation was broken into focused scripts, each owning a single responsibility:
  • PlayerMovement, MouseLook, HeadBob, and WallDetection for first-person traversal.
  • TileController and Tile for the Simon-style color memory mechanic.
  • GeneratorController and MiniGameController for the timing-based power-restoration mini-game.
  • Simon, EyeTracking, and ProceduralLegManager to make the antagonist feel reactive — he tracks the player's position with his eyes and shifts forward as the player accumulates errors.
  • LightsFlickering, Announcer, and the AudioMixer for atmosphere.
• 3. Atmosphere and presentation. Horror lives or dies on presentation, so significant time went into lighting (URP spotlights tied to the generator state), audio layering (ambient, voice lines, idle/start/stop sounds for the generator), and Timeline-driven cutscenes for the success and fail outcomes. The jumpscare was implemented as a dedicated scene transition (SimonJumpscare, Jumpscare Scene Transition) to keep its triggering logic isolated and reliable.
• 4. Iteration and polish. Late in development we focused on Simon's texture and animation pass, the jumpscare integration, and final build settings — tuning the experience so the pacing of escalation and payoff actually landed. Playtesting drove most of these changes; numbers like generator drain rate, bob frequency, and the threshold for Simon's movement were tuned by feel rather than spec.
• 5. Collaboration. The team coordinated through GitHub, with feature branches for individual contributions and pull requests for integration. Working in a shared Unity project taught us as much about scene merging and asset discipline as it did about gameplay programming.

Tech Stack

• Engine: Unity (Universal Render Pipeline)
• Language: C#
• Tools: Unity Timeline, ProBuilder, TextMesh Pro, Unity AudioMixer
• Source control: Git / GitHub