How it works

DevPiggy is an independent PIGI research demonstration by FreeIntelligence.Institute. It organizes publicly available gallery information and lets you explore submissions with transparent, adjustable criteria. It applies the same approach used in our ESG reporting, technical documentation and evidence-tracing work.

It does not independently verify project functionality, replace official judging, or determine competition winners. Not affiliated with or endorsed by OpenAI or Devpost.

Search allowance

DevPiggy is a limited public demonstration, not an unlimited search service. Each visitor gets five new Semantic or Hybrid questions per rolling 24 hours, enforced on the server. Comparing all three methods for one question counts once; repeating a question, switching methods, changing weights, opening projects, the three saved examples and Keyword search are free. A failed request is not counted. Visitors are recognised by an anonymous code derived from their connection; no account or IP address is stored, so the limit is approximate across devices or networks.

1. 1
   Collect

   Each public page of the OpenAI Devpost submission gallery is read one at a time, 1.5 s apart, and saved immediately. Failed pages are recorded and retried; nothing bypasses access controls or rate limits.

2. 2
   Deduplicate

   Projects are keyed by their Devpost ID and canonical URL. A project seen twice is stored once.

3. 3
   Index

   Titles and descriptions are kept exactly as published. A separate normalized search index (stemmed, case-insensitive) powers search.

4. 4
   Indicate

   Four indicators are computed from the description wording only, with documented rules. Missing evidence stays visible as missing.

5. 5
   Compare

   Results are ordered by search relevance. You can optionally sort by the experimental indicator with your own weights; every piece of supporting text is shown.

Core assumption

Every project published in the official submission gallery is treated as an eligible, complete submission. This is an explicit experimental assumption, not a verified statement about each project. Projects are not penalized because a short description omits a demo, repository or technical detail.

Three search methods

• Keyword — Baseline. Deterministic full-text search over title and description. Works without any AI service.
• Semantic — Meaning. Each project's title and description were converted once into a 3,072-number “meaning vector” (text embedding, model google/gemini-embedding-2) and stored. Your query is converted the same way, and the 100 closest projects by cosine similarity are retrieved. A nearest neighbour is not necessarily a relevant one, so each is labelled Strong, Possible or Weak/uncertain by a documented rule (below); weak ones are hidden unless you ask to see them. It can find related descriptions without your exact words, and it can also return loosely related false positives. Similarity measures closeness of wording and meaning, not quality.
• Hybrid. Merges the keyword and meaning rankings with Reciprocal Rank Fusion: each project gets 1/(60 + its rank) from each list, summed. Ranks are used instead of raw scores because the two scores are not comparable. Only strong and possible meaning matches are fused, so 100 always-present neighbours cannot crowd out clearly relevant keyword results.

See the differences side by side in Compare Methods.

The four criteria, checked against the official rules

The hackathon's official rules (section 7, Judges and Criteria) state that submissions which pass a first pass/fail viability stage are judged on four equally weighted criteria. DevPiggy uses those four names and an equal 25/25/25/25 default because the rules state the weighting. The wording below is quoted from the rules page:

• Technological Implementation — “How thoroughly and skillfully does the project use Codex? Does the code reflect genuine effort and a working, non-trivial implementation?”
• Design — “Does the project deliver a working or runnable project that has a complete, coherent product experience — not just a technical proof of concept?”
• Potential Impact — “Does the project make a credible, specific case for solving a real problem for a real audience — and does the solution actually address that problem based on what's demonstrated?”
• Quality of the Idea — “How creative and novel is the concept and does the project differ from existing concepts?”

What this tool does not copy from the rules: the first pass/fail stage (theme fit and required API use) is not modelled, the judges and their rounds are not known to us, and the rules leave scoring to the judges' discretion. The indicator here is computed from the published description only, so it is a proxy for what the text states, not the judges' score. The rules also break ties by comparing criteria in the order listed above; weights in this tool are yours to change, so that order is not applied.

Experimental Description-Based Indicator (Keyword Baseline v1)

This experimental indicator measures selected terminology in the gallery description. It is not an official judging score, does not mean 95 is technically excellent, and is never used to declare winners. Default ranking on Explore is search relevance. It is kept as a reproducible baseline; an evidence-based assessment is a planned next step.

How to read a result

• Source statement — the description exactly as Devpost shows it.
• Computed indicator — a number produced by the documented rules in the Scoring Lab.
• Inference — the explanation text, which only restates what the description says.
• Unknown — “Insufficient evidence” or “Not scorable”. Never converted to a number.

What this tool does not do

• It is not the competition jury and does not say who should have won.
• It does not test apps, audit code, watch videos or check eligibility.
• It does not use official winner labels in search or scoring. They are stored separately and never shown here.
• It does not invent competition categories; the gallery does not publish them, so they are shown as unclassified.

The four criteria (Technological Implementation, Design, Potential Impact, Quality of the Idea) and their equal weighting are taken from the official competition rules, checked on 28 October 2026 at openai.devpost.com/rules. The description-based indicator is this tool's own experimental proxy.