Siddarth Srinivas

Closing the Loop on Automated Escalation

When a support ticket arrives in an enterprise environment, the first question an engineer asks is: what has already been tried? Without a clear answer, they duplicate effort, lose time, and often start from scratch on problems that were partially solved. That gap — between what an automated system does and what a human engineer can see — was the problem I was brought in to address.

The system I worked on sits between the client and the engineer. A bot handles initial troubleshooting autonomously and escalates only when it cannot resolve the issue. The problem was that when escalation happened, the bot's entire decision trail was invisible. Engineers had no way of knowing which steps had been attempted, which had failed, or why the bot had given up. Every handoff started blind.

My work was to fix that. I built out the logging layer that made the bot's reasoning visible and traceable — so that by the time a ticket reached a human engineer, they had a complete record of what the bot had already tried. The handoff became informative rather than abrupt.

Enterprise networking and the codebase were both new to me when I started. I treated the first few weeks as a structured orientation — knowledge transfer sessions, research into the problem space, and studying how similar automation challenges had been approached elsewhere. I also spent time learning the IT Infrastructure Library and IT Service Management frameworks that govern how enterprise service operations actually run — not just the technical mechanics, but how organisations formally think about incidents, escalation, and service continuity. Understanding that process layer shaped how I approached the logging design, because the output had to be useful to engineers operating within those frameworks, not just technically correct.

From Raw Simulation Data to Structured Surgical Coaching

Surgical simulation generates enormous amounts of raw performance data. The problem is that data alone tells a trainee surgeon very little — it doesn't explain what went wrong, why it went wrong, or what to do differently. At Simulatory, which builds robotic surgical simulators for spinal procedures, that gap between raw output and actionable insight was the problem I was asked to solve.

I built a pipeline that ingests the raw data produced by each simulation, processes and structures it, and generates coaching feedback that tells trainee surgeons specifically where they performed well and where they need to improve. The system is now in production and actively used in surgical training. The feedback it generates is the kind that previously didn't exist in a structured form — surgeons had intuition, but not a systematic, data-driven account of each trainee's performance.

The technical challenge was significant, but the harder problem was organisational. I was the only person in the company who could build this. No senior engineer to review my architecture, no technical peers to pressure-test my thinking, no safety net for the decisions I got wrong. In that environment, being mostly confident wasn't enough — every architectural and technical decision had to be fully stress-tested before I committed to it. That constraint changed how I approach problems. I stopped looking only for solutions and started looking for the failure modes in my solutions before anyone else could find them.

Alongside the core pipeline, I built an annotation model that identifies anatomical structures on screen during simulations in real time, and explored generative medical imaging as a route to synthesising training data — though resource constraints kept that work at the research stage.

Working in medical technology also recalibrated my sense of pace. In a domain where the end user is a surgeon and the product is someone's spine, speed is never the primary objective. Every change went through rigorous testing before deployment. Knowing when to slow down and verify — not just how to move fast — turned out to be the more important skill.

Automating SBOM Extraction and Version Compliance in Container Deployments

In enterprise software deployment, version mismatch is one of the most silent failure modes. A single dependency running one version off from what the requirements document specifies can break systems in ways that are difficult to trace and expensive to fix after the fact. At MyCom, that risk was being managed entirely by hand — before every deployment, engineers manually cross-checked every package version across every file against the requirements document. The process was slow, dependent on individual thoroughness, and fundamentally unscalable.

The problem I was asked to solve was straightforward to state but non-trivial to build: eliminate that manual check entirely, and replace it with something automatic, reliable, and fast.

I built a system that extracts a Software Bill of Materials from container images, compares every package version against the requirements document automatically, flags every mismatch, and compiles the results into a structured report — in a fraction of the time the manual process required. A version comparison script existed in a basic form when I arrived, but the final system was so fundamentally rearchitected that it was effectively built from scratch.

The part I'm most satisfied with wasn't in the original brief. Beyond the core compliance check, I added individual package-level breakdowns, an overall compliance summary table, and additional codebase health metrics that gave the team a richer picture of their deployment readiness. These additions weren't requested — I included them because the data was already there and the insight seemed worth surfacing. They became the most referenced sections of the report.

The next stage was integrating the system into GitLab CI/CD so compliance checks would run automatically on every build — making version verification a permanent, invisible layer of the deployment pipeline rather than a pre-deployment ritual. The internship ended before that integration was complete, but the architecture was designed for it and the foundation was in place.

Finding What Slips Through: Software Quality Assurance at Scale

Production bugs in web platforms rarely originate from core functionality — they surface in edge cases, incomplete user flows, and untested state transitions that pass code review but fail under real usage conditions. At Aster Digital Health, the problem was identifying these failure points in a live healthcare web platform before they reached end users.

My role was systematic black-box testing across the platform. This involved mapping user flows, designing test cases around boundary conditions and edge cases, reproducing reported and discovered bugs, isolating root causes, and producing structured defect reports that development teams could action directly.

The work built a testing mindset that has carried into every technical role since — treating every assumption in a system design as a potential failure point, and verifying rather than inferring how a system behaves under conditions it wasn't explicitly built for.

Ground-Up Chatbot Development: Neural Architecture to Client Deployment

In 2023, most teams building with Large Language Models were focused on what they could ship. The harder problem — and the more important one — was understanding what was actually happening inside these systems: how information flows through transformer layers, where models fail, and what architectural decisions determine whether something is robust enough to deploy to a real client.

At Flipick, that was the problem I set out to solve for myself before writing a single line of production code. The internship was structured around deep technical grounding first — neural network architectures, attention mechanisms, how information propagates through layers, and how chatbot frameworks function beneath their abstractions. Not as background reading, but as the foundation every subsequent decision would rest on.

The culminating project was building a client-deployable chatbot from scratch — designing the architecture, handling failure modes, and making the system robust enough to hand off to an external client. The system didn't go into production, but the objective was never deployment. It was building something that could be deployed, and understanding every decision that distinction requires.

That architectural foundation has carried directly into every system I've built since — Large Language Model feedback pipelines, annotation models, Retrieval-Augmented Generation systems. The difference between knowing how to use a tool and understanding how it works is the difference between building something that functions in a demo and building something that holds up in production.

Content Strategy and Digital Presence Management for a Specialist Motorcycle Service Workshop

Indimotard had an audience worth reaching — serious motorcycle enthusiasts who treat high-end bikes as a lifestyle, not just a vehicle. The problem was that their social media presence wasn't converting that potential into measurable growth or consistent footfall. The brand had a story worth telling, but no systematic approach to telling it across platforms.

I took over their social media operations across Instagram, Facebook, and YouTube with a clear objective: grow an engaged following and translate that following into customers walking through the door.

The approach was strategic before it was creative. That meant identifying what content resonated with the target audience — documentation of high-end service work, behind-the-scenes garage content, and brand collaboration posts — and building a consistent publishing cadence across platforms. Each piece of content was planned around what to shoot, how to frame it, and when to publish it to maximise reach and engagement within a niche but highly engaged audience segment.

The results were concrete. Instagram following grew from 6,000 to 13,000 in six months. More significantly, inbound footfall attributable directly to Instagram increased over the same period — the follower growth translated into real customer acquisition, not just reach metrics.

Audience Segmentation and Paid Campaign Management for a Niche Medical Education Platform

Reaching medical professionals with online advertising is a distinct and difficult problem. The audience is highly educated, time-poor, and resistant to generic marketing — broad reach strategies don't work because the signal-to-noise ratio for this demographic is extremely low. At Medvarsity, which produces online courses for medical professionals, the problem was designing and executing campaigns precise enough to cut through to a highly specific audience without wasting budget on irrelevant reach.

Before running anything live, I spent the first phase of the internship building the technical foundation properly — Google Ads certification, Facebook AdSense, Search Engine Optimisation strategy, and keyword research methodology. The objective was to understand the mechanics of each platform well enough to make deliberate decisions rather than default ones.

By the end of the internship I was managing a live campaign independently with a real allocated budget — applying audience segmentation, keyword targeting, and conversion-focused copy to reach Medvarsity's target demographic. The work required thinking precisely about who the audience was, what they were searching for, and how to position the product in a way that was relevant to their specific professional context.