DEV Community: Ashish Pagariya

# TrustForge: A Hackathon Judging System That Shows Its Work

Ashish Pagariya — Thu, 01 Oct 2026 18:35:27 +0000

When we started building TrustForge for DogFood 2026, I assumed the judging dashboard would be the hard part. It turned out to be the easy part. What actually took thinking was a question I hadn't planned for: how do you explain a hackathon result after it's already been published?

Most judging platforms store scores and pick a winner. We wanted the process behind the winner to be inspectable too, and that one decision ended up shaping almost everything else.

Why we stayed with a monolith

My first instinct was to split it all up: auth, judging, assignment, scoring, audit and notifications, each as its own service. It sounds scalable, but for a hackathon it would have been a lot of overhead for no real gain.

So TrustForge is one Spring Boot app with clearly separated modules (authentication, authorization, submissions, judging, normalization, anomalies, audit, results), and a separate React frontend that talks to versioned REST APIs. I cared less about "monolith vs microservices" than about keeping the boundaries explicit without taking on distributed-systems problems we didn't have.

Everything runs through one pipeline, and it became the mental model for the whole project:

SubmissionVersion → Assignment → Evaluation → NormalizationRun
      → Anomaly → AuditEvent → ResultSnapshot

"Assign judges to projects" is not a simple requirement

On paper it's one line. In practice you have to handle judge capacity, minimum coverage per project, declared conflicts, workload balance, and the fact that rerunning the algorithm should give the same answer.

We also didn't want an assignment to just say Judge A → Project 12. We wanted it to carry its reasoning:

Judge A → Project 12
Eligible: yes | Conflict: none | Capacity: 12/20
Coverage: satisfied | Fairness: 0.94
Algorithm: v1.2 | Seed: 8f91c7

The seed and algorithm version matter more than they look. If an organizer reruns the assignment and gets something completely different, you can't debug it and you definitely can't explain it. Every run records both, and the acceptance tests check that declared conflicts are excluded and coverage is met.

Judges don't use the same scale

Say Judge A usually gives 8.5, 9, 9.5, 10 and Judge B usually gives 6, 6.5, 7, 7.5. If you just average, Judge A's habits carry more weight, even though neither judge is wrong. The numbers look comparable, but they aren't.

So we added per-judge normalization:

z = (score - judge mean) / judge standard deviation

We kept the raw score. Normalization is an interpretation of the data, and I didn't want to throw away the original evidence just because we'd built a transformed version. A judge with zero standard deviation is handled explicitly instead of crashing into a divide-by-zero, and missing evaluations are left missing, never filled in.

The scoring formula was wrong, and it looked fine

This is probably the most useful thing I learned on the project.

Our methodology says the result combines normalized judging with community voting. While reviewing the implementation, we noticed the two inputs weren't on compatible scales. One was a z-score and the other was a raw vote count. Adding them directly gives you something that looks sophisticated and quietly lets one side dominate.

That made us ask what "80% judging, 20% community" actually means. It only means something if both signals are mapped to the same range first:

final = (judging, scaled 0–100) × 0.80
      + (community, scaled 0–100) × 0.20

The takeaway went beyond this one formula: a score can look reasonable in the UI and still be mathematically off, so check the units, the ranges, the edge cases, and whether the code matches the documented method. It's also why the results page shows the methodology instead of just a final number.

An audit table isn't the same as a trustworthy audit log

A normal audit table tells you what's stored. It doesn't tell you whether someone edited the history.

So we chained the audit events with SHA-256, starting from a GENESIS value, where each event's hash includes the previous one. Each record stores the previous hash, current hash, actor, action, entity, timestamp, request ID and payload. Verification recomputes the whole chain from the start.

We also wrote a test that deliberately edits an earlier payload and confirms verification fails. I trust that test far more than one that only checks the happy path returns true.

Security lives on the backend

It's easy to treat a hidden button as access control. if (user.role === "ORGANIZER") showButton() is a UX choice, not a security boundary. The backend decides what's allowed:

Organizer: assignment management
Judge: their own assigned evaluations
Participant: the public gallery and voting

In acceptance testing, a judge trying to reach organizer-only assignments got a 403. Access tokens expire, refresh tokens rotate, and reusing an old refresh token after rotation gets rejected.

Docker, and the difference between "written" and "run"

Docker didn't magically solve deployment. The more useful lesson was keeping the design of the deployment separate from the verification of it.

The repo has a Compose setup with PostgreSQL, Redis, the Spring Boot API, and Nginx serving the React frontend, with health checks gating the startup order. But our acceptance environment didn't have Docker, so we didn't call Compose verified. The acceptance report has two buckets: VERIFIED and NOT VERIFIED / BLOCKED BY ENVIRONMENT.

It's a small documentation choice, but it's one of the easiest ways to stop a project looking more finished than it is. "I wrote the config" and "I ran the config" are not the same sentence.

The acceptance suite became part of the product

We didn't want the demo to rest on "trust me, it works." The smoke test covers the seeded gallery, login, dashboard, assignment coverage, normalization, audit verification, results, certificate verification, and role isolation. The live run passed ten checks against the local API. We added focused tests for deterministic normalization, audit tamper detection, assignment conflicts and capacity, and duplicate voting.

Somewhere along the way the suite stopped being just a test suite and became another way of stating what TrustForge promises.

What I'd change

A runnable demo can make the underlying model look finished, and ours isn't. The demo uses a deterministic in-memory store as a replaceable persistence layer. PostgreSQL and Flyway are part of the deployment design, but the demo shouldn't be mistaken for a production persistence setup.

If I built it again, I'd:

Move the judging model fully into PostgreSQL
Persist assignment runs and normalization datasets
Make result snapshots immutable at the database level
Build a real pairwise ranking model in place of the current read-model placeholder
Add property-based tests around assignment and scoring
Make the final weights and normalization ranges explicit in code and tests

None of these are hidden gaps. They're documented.

What it changed for me

Before this, my question for a feature was "does it work?" TrustForge added two more: can someone understand why it worked, and can they verify that explanation without taking my word for it?

Those questions changed the architecture, the tests and the UI. They also changed how I think about trust in software: you can't bolt it on at the end. Reproducibility, explainability, versioning, testability and auditability have to be there from the first decision.

So the idea behind TrustForge is simple: don't just publish the result, preserve the process that produced it.

I Built a Privacy Scanner With Zero Dependencies —SafeSearch

Ashish Pagariya — Wed, 02 Sep 2026 20:48:48 +0000

DESCRIPTION

SafeShare is a simple security tool that helps prevent accidental sharing of sensitive information. It scans text and files and looks for things like API keys, Bearer tokens, JWTs, passwords, and other credentials that should not be publicly shared.

The idea came from a common problem: developers can accidentally expose sensitive information while sharing code, logs, screenshots, configuration files, or uploading projects to GitHub. SafeShare acts as an extra check before that happens.

PROBLEM STATEMENT

Sensitive information is often exposed accidentally during development. A developer might copy a token into a message, commit a secret to GitHub, or share a configuration file containing credentials.

Many existing security tools can be complicated to set up or depend on multiple external packages. For a small and focused security check, I wanted something lightweight that could run locally with minimal setup.

SOLUTION

SafeShare scans the provided content and checks it against patterns for different types of sensitive information. When something suspicious is detected, the tool identifies what was found and assigns an appropriate severity level.

The scanning happens locally, so the content does not need to be sent to an external service just to perform the basic security check.

KEY FEATURES

Detects Bearer authentication tokens
Detects JWTs
Detects API keys and other credential-like patterns
Helps identify passwords and sensitive values
Provides severity levels for detected risks
Can scan text and files
Runs locally
Has zero external dependencies
Includes automated tests for the detection system

WHAT MAKES IT DIFFERENT

The main focus of SafeShare is simplicity. It does not try to be a complete enterprise security platform. Instead, it focuses on one practical problem: catching sensitive information before it gets shared.

Another important part of the project is that it uses zero external dependencies. This keeps the project lightweight, reduces setup requirements, and makes it easier to understand and run.

TECHNOLOGY USED

JavaScript
Node.js
Regular Expressions
Node.js built-in File System APIs
Node.js built-in testing tools

HOW IT WORKS

The user provides text or a file to SafeShare. The tool scans the content using detection patterns designed for different types of credentials and sensitive information.

If a possible secret is found, SafeShare reports the type of information detected along with its severity. This gives the user an opportunity to remove or secure the information before sharing the content.

TESTING

I also created automated tests to check whether SafeShare can correctly identify different types of sensitive information.

The tests include cases such as Bearer tokens and JWTs, along with other credential patterns. This helps make sure that changes to the detection logic do not accidentally break existing functionality.

PRIVACY

SafeShare is designed with local processing in mind. Sensitive content can be checked locally instead of being uploaded to a third-party service for scanning.

This is especially useful when working with private source code, configuration files, logs, or other information that should not leave the user's system.

PROJECT GOAL

The goal of SafeShare is not to replace professional security scanners. The goal is to provide a lightweight first layer of protection that can catch obvious credential leaks quickly and with almost no setup.

FUTURE IMPROVEMENTS

Some improvements I would like to add in the future include:

More credential detection patterns
Better handling of false positives
Support for additional file formats
Configurable detection rules
Git pre-commit integration
CI/CD integration
More detailed security reports

PROJECT OUTCOME

SafeShare demonstrates that a useful security-focused tool can be built using a small amount of code and built-in Node.js functionality. The project currently detects several common types of exposed credentials, provides severity information, and has automated tests to validate its core functionality.

GITHUB

https://github.com/ashuuakk06/SafeShare

DEMO VIDEO

https://youtu.be/xdCAfbfUNfI?si=durWKlty9wn2q2-C