Identity Architect Rupesh Kumar Prasad on Why Every Promise a Platform Makes Rests on Who the Server Thinks You Are

Identity Architect Rupesh Kumar Prasad on Why Every Promise a Platform Makes Rests on Who the Server Thinks You Are

Ask most people what makes a judging system fair and they will talk about the scoring: the rubric, the weights, the arithmetic that turns a dozen opinions into a ranking. Those things matter. But underneath every one of them sits a quieter question that decides whether any of it means anything. When a request reaches the server and says it comes from a judge, how does the server know? If the answer is weak, the rubric, the weights and the arithmetic are decoration. A system that cannot tell who is speaking cannot keep a single promise it makes about who may see, change or decide anything.

Rupesh Kumar Prasad has built his career on that question. A Technical Architect and Senior Manager at Analog Devices, he has spent more than ten years there leading a global team that builds large-scale, performance-critical client and server applications. Across nearly two decades in enterprise software, beginning as a Technology Analyst at Infosys, his work has covered identity and single sign-on, cloud architecture, API design, data platforms, DevOps and web application security. He set up technology review boards and architectural templates to drive design standards across his organization. He is an IEEE Senior Member, a reviewer for technical conferences and journals, and a published author on browser privacy and authentication challenges.

He served on the panel for DOGFOOD 2026, a hackathon whose brief put his specialty at the centre of the problem.

For an identity architect, a judging platform is first an access control problem, and only then a scoring problem.

A Platform Built to Judge Its Own Builders

DOGFOOD 2026, organized by Hackathon Raptors and held online from September 26 to September 29, 2026, gave every team the same 72-hour brief: build a self-hosted hackathon platform that handles registration, teams, submissions, judging and results. The winning project is meant to be forked and run for a real event. Teams were, in a literal sense, building the system that could one day judge them.

The brief laid out a ladder of four tiers. The first covered the core of any event: accounts, sessions, roles, event and team setup, and project submission with a deadline the server enforces. The second covered judging: invitations, assignment, weighted rubrics, isolation between judges, and normalization of scores across judges. The third added community voting with abuse controls. The fourth held stretch goals, including an API-first design that lets other tools build on the platform.

Scoring rested on four criteria. Tier Completion and Correctness carried 40 percent. Judging Integrity carried 25 percent and asked about backend role isolation, documented and defensible normalization, an audit trail, and whether vote abuse had been considered. Adoptability and Operability carried 20 percent and asked for one command to a running system, realistic seed data, documentation a stranger could follow, and a clean path in and out. Code Quality and Innovation carried 15 percent.

Read with an identity architect's eye, almost every line of that brief is about trust boundaries.

Five Roles, One Server, No Shortcuts

The first tier of the brief began with authentication, sessions and a model of roles: the organizer who runs the event, the participant who submits, the judge who scores, the public who browses and votes, and the platform owner above them all. On paper a role model is a table. In a running system it is a set of decisions the server has to make correctly on every request, for every route, without exception.

Prasad's background is in exactly this layer. He has designed identity and single sign-on across Azure Active Directory and Azure AD B2C, working with OAuth, OpenID Connect, SAML and federation between organizations. That work teaches a hard lesson early. The interface is not a security boundary. Hiding a button from a participant does nothing to stop that participant from sending the request the button would have sent. The only place a role can be enforced is where the request is handled, and the only way to know it is enforced is to send the forbidden request and watch it fail.

The DOGFOOD brief made the same point in its own words, asking for backend role isolation rather than front-end paint. It is a distinction that separates working software from demonstrations. A platform can look entirely correct in a browser while allowing anyone who knows the shape of an API call to become an organizer, read another judge's scores or change a result. Nothing on screen reveals the problem. Only a test from the server's side does.

The published results show how central this layer turned out to be. The public record on dogfoodhack.com publishes every project's scores on all four criteria, including Judging Integrity, together with the organizers' notes. The submissions that rose to the top of the field described isolation as something they had tested rather than something they had drawn. ballotbench, which finished fourth, describes isolation that "is enforced in the queries, and 94 curl attacks prove it." That sentence is the kind of evidence an identity architect looks for: not an assertion that roles are separate, but a count of attempts to break the separation and a statement that none succeeded.

Fairness Is an Access Control Property

It is tempting to treat Judging Integrity as a statistics problem. Several of the strongest DOGFOOD submissions did impressive statistical work, modelling how lenient or harsh each judge was and correcting for it. The overall winner, Verdict, describes "an additive judge-leniency model with shrinkage" that evens out harsh and generous judges, and the runner-up, RAPTOR DESK, describes a similar correction for judge bias.

But every one of those models assumes something that only the identity layer can guarantee. It assumes that the scores attributed to a judge were entered by that judge. It assumes that no judge saw another's scores before entering their own. It assumes that nobody altered a score after it was submitted without leaving a record. If any of those assumptions fails, the statistics are computing a precise answer to the wrong question.

This is why a security architect reads Judging Integrity differently from a data scientist. The data scientist asks whether the normalization is sound. The security architect asks whether the inputs to the normalization can be trusted, and that question is answered by sessions, roles, isolation and audit trails. Prasad's work on enterprise design standards across a large engineering organization is, in practice, the work of making sure that question has a reliable answer before anyone builds on top of it.

The brief's request for an audit trail belongs to the same family. An audit trail is only as useful as the identity attached to each entry. A log that records that a score changed, without recording reliably who changed it, cannot settle a dispute. A log that records who changed it, on top of an identity layer that anyone can impersonate, settles disputes incorrectly, which is worse. The winning project's audit trail is described on the public results page as hash-chained, so that an entry cannot be silently altered after the fact. That is a sound design, and it is sound precisely because it sits on an identity layer that holds.

Abuse Is a Design Input, Not an Afterthought

The third tier of the brief added community voting, and with it a class of problem that identity architects meet constantly in public-facing systems: abuse. The brief asked for rate limits, duplicate detection and controls against ballot stuffing. These sit in the third tier, but they feed directly into Judging Integrity.

Prasad's experience spans web application security from the application layer down to the network, including web application firewalls, rate control and load balancing. Work at that layer teaches that abuse is not an edge case. Any system that accepts input from the public will receive hostile input, and the volume and creativity of that input will exceed what its designers imagined. Without rate limits, a vote count measures who wrote the best script.

The useful question for a team, then, is not whether they added a rate limit, but whether they decided what an attacker would try and designed against it. A one-vote-per-person rule is only as strong as the system's idea of a person. Duplicate detection is only as strong as the system's idea of what counts as the same submission. Both come back to identity. Raptorgate, a submission in the field, describes public voting with "verified identities" and a rule of one vote per person, each vote receipt-verified. Whatever the details of a given build, that framing shows the right instinct: the vote is protected by the identity behind it, not by the interface in front of it.

APIs Are Promises to Strangers

The fourth tier of the brief rewarded an API-first design, so that other tools could build on the platform. For a judging system this matters more than it might appear. An event organizer may want to import registrations from another tool, export results to a spreadsheet, connect a notification service or build a custom dashboard. Each of those connections is a stranger making requests to the platform.

Prasad has spent much of his career on service-oriented and REST API architecture, and on moving large-scale applications, databases and scheduled jobs from on-premises infrastructure into the cloud. That kind of migration forces a discipline on API design that greenfield projects can skip. Every interface becomes a contract that other systems depend on. Every endpoint becomes an attack surface. Every change has to be made without breaking someone downstream. An API that was designed only for the platform's own front end tends to trust its caller too much, because its caller was always friendly. An API designed for strangers has to authenticate, authorize and validate every request on its own terms.

The DOGFOOD brief connected this to the Adoptability and Operability criterion, which asked for a clean migration path in and out. A platform that an organizer cannot leave is, in the brief's terms, a trap. A clean export and import path is partly a data modelling problem and partly an identity problem, since moving records between systems means moving the relationships between people and the things they own. Getting that right is the difference between a tool that an organization can adopt with confidence and one it will regret.

The Offline Rule and the Identity Layer

One rule set DOGFOOD apart from most hackathons. The platform had to start from a singledocker compose upand keep working with the network switched off once it was built. No cloud account, no hosted service, no external identity provider.

That rule has a direct consequence for identity design. Much of modern enterprise authentication delegates the hard parts to an external provider: a corporate directory, a social login, a managed identity service. Prasad's own work with Azure AD and federation is an example of that model done well at scale. An offline, self-hosted platform cannot lean on any of it. It has to manage its own users, its own sessions, its own password storage and its own invitation flow, and it has to do so safely on hardware that the organizer controls.

That is a harder brief than it sounds. Every shortcut a team might take, such as trusting a role sent from the browser, storing a session in a form the client can edit, or issuing an invitation link that can be reused, becomes a real vulnerability once the platform is deployed for an actual event. The brief asked teams to do in 72 hours what identity providers spend years getting right, without the safety net of a provider at all. The teams that took that seriously, and documented what they had and had not secured, produced the most trustworthy platforms in the field.

Review Boards in Miniature

Prasad's practice of setting up technology review boards and architectural templates speaks to a broader point about how a panel like DOGFOOD's works. A review board does not exist to approve designs. It exists to ask the questions a team is too close to its own work to ask: what happens when this fails, who can call this endpoint, where is the trust boundary, how do we know.

A hackathon panel plays the same role in miniature. DOGFOOD's published scoring treats every judge as one equal vote and adjusts for judges who score consistently high or low, so that no single reviewer's temperament decides a result. Within that structure, the value a panel brings is the range of questions its members know how to ask. A panel that includes people who think first about identity, access and abuse will catch failures that a panel focused only on features would miss, and the teams receive a sharper picture of what production readiness actually requires.

What the Brief Teaches

DOGFOOD 2026 asked teams to build a system whose central product is trust. Participants had to trust that their submissions were received before the deadline and judged fairly. Judges had to trust that their scores were private and recorded as entered. Organizers had to trust that the results could be defended if anyone challenged them. Every one of those forms of trust rests on the same foundation: a server that knows, reliably, who is making each request and what that person is allowed to do.

That is the lesson an identity architect brings to a brief like this, and it applies far beyond hackathons. The features users see are built on guarantees they never see. When the guarantees hold, the features work and nobody notices. When they fail, every feature on top of them fails at once, and the failure is usually discovered by the wrong person at the worst moment.

The platforms that led the DOGFOOD field were the ones that treated the identity layer as the foundation rather than a formality, and tested it from the server's side instead of trusting the interface. For engineers who have spent careers like Prasad's making sure large organizations can answer the question of who is on the other end of a request, that is the right order of priorities. Get identity right first. Everything else is built on it.

DOGFOOD 2026 was organized byHackathon Raptors. Results and the full public scoring record are published at dogfoodhack.com/winners.

For more on practical software delivery and technical ownership, read Frontend Delivery Models Explained for Non-Technical Decision Makers.