In the third blog featuring our “30 Apps in 30 Days: AI Hackathon” winners, we spotlight Rajashekar Sabbani, who won the “Most Innovative Use of AI” award. Rajashekar shares his hackathon journey and the thinking behind his approach to building AI that knows when to make a decision and, just as importantly, when not to.
Winning the Most Innovative Use of AI award at Sky Solutions’ 30 Apps in 30 Days: AI Hackathon was a rewarding experience, but the real takeaway for me was not simply what AI can do. It was learning what AI should not do.
My project, the UCM-AI Triage System, started with a straightforward question: How can we use generative AI to make high-volume alert triage faster and more effective without giving AI authority over decisions that carry real consequences? The answer became architecture built around a simple principle: let AI accelerate the work, but keep people and policy in control.
From information gathering to decision-making
In many complex workflows, analysts spend significant time bringing information together before they can actually make a decision. Data may reside across multiple systems, while policies, procedures, case histories, and other evidence need to be reviewed separately. This creates repetitive work, slows response times, and can make decisions inconsistent.
I saw an opportunity to automate much of that preparation. The system I designed brings together relevant information automatically, checks for duplicates, retrieves supporting evidence and applicable policies, and produces a recommendation. It can suggest four outcomes: create a new case, link an alert to an existing case, close it under an approved exclusion with a recheck date, or send it to a human for review.
The goal isn’t to replace human judgment; it’s to make that judgment more informed.
Putting guardrails before intelligence
The most challenging part of the project was deciding where AI belongs in the workflow.
I deliberately kept authoritative facts, calculations, policy enforcement, and authorization outside the language model. Deterministic systems retrieve the facts, code calculates the scores, and a versioned rules engine determines whether an action is eligible for automation. Only after those steps does AI generate a plain-language explanation based on the evidence it has been given.
That distinction became one of my biggest learnings from the hackathon: confidence is not authorization.
A model can be highly confident and still be wrong. So, in my design, even a high-confidence recommendation cannot independently trigger a consequential action. Human review remains a deliberate part of the workflow for uncertain, sensitive, or high-impact situations.
Making every AI answer defensible
Another important design principle was explainability. I didn’t want the system to produce a plausible-sounding answer that users simply had to trust.
Every material statement in the generated rationale is required to point back to its source. The output is validated to ensure citations exist, numbers match the underlying calculations, and the response stays within the information the user is authorized to access. If the evidence isn’t sufficient, the system is designed to say so rather than manufacture an answer.
Security was equally important. The architecture applies access controls before retrieval, rather than trying to filter sensitive information after it has already been retrieved. It also treats ingested content as untrusted data and incorporates multiple defenses against prompt injection.
The biggest lesson I’m taking forward
The hackathon changed how I think about building AI solutions. Prompt engineering isn’t just about finding clever instructions. In a high-stakes environment, it is closer to contract design: clearly defining what the model can do, what it cannot do, what evidence it must use, and how its output will be validated.
I also learned that reversibility matters. Instead of automatically merging records, for example, the design uses a reversible linking approach. Idempotency is built into the workflow so retries and replays don’t create duplicate actions.
For me, the most important moment came when I realized that the real value wasn’t in making AI more powerful. It was in making it accountable.
That is what I hope this project represents: not just an AI application that can make recommendations, but a practical model for building AI that is governed, explainable, secure, reversible, and human-centered.
The AI wasn’t the hardest part. The guardrails were. And those guardrails are what made the idea work.
About the Author
Rajashekar Sabbani is a Technology Lead and Solutions Architect at Sky Solutions, with nearly two decades of experience designing and developing distributed, enterprise-scale applications. He specializes in Java full-stack development and multi-cloud architectures and has led solution design and delivery for clients across the federal and healthcare sectors. Rajashekar holds a master’s degree in computer applications.
