CONVERA: Evidence-Driven Project Validation System

01The Problem: Jumping to Code Before Proving the Need

In university computing classes and student startup hackathons, teams come up with ideas quickly. They collect notes, chat messages, links to papers, and interview quotes across scattered group chats and shared documents.

Moving from that initial excitement to a solidly justified software proposal is usually where projects struggle:

• Arguing Without Real Evidence: Teams debate feature lists based on personal opinions rather than verified interviews or actual gaps in existing literature.
• Writing Code Too Early: Students frequently spend weeks building a full-stack web app before confirming whether anyone actually needs it, or whether an open-source solution already handles the use case.
• Unverified AI Answers: Relying on standard chatbots to summarize research papers often leads to fabricated citations and unverified claims being accepted as facts.

02Dual Validation Workflows

CONVERA structures project evaluation into two distinct pathways depending on whether the team is building a startup product or an academic research thesis:

The Research Track follows the Design Science Research (DSR) framework (March & Smith, 1995), categorizing technical contributions into Constructs, Models, Methods, and Instantiations, while aligning proposals with CHED computing guidelines.

03Decoupled Architecture with 38 Relational Tables

Evaluating long requirement documents, running literature searches, and checking rubric rules are computationally heavy tasks that should not freeze the user interface.

04Interactive Evidence Graph & Requirements Lineage

To prevent features from being added on a whim, CONVERA connects every proposed requirement back through an evidence graph:

KNOWLEDGE TRACEABILITY CHAIN:
  1. Published Literature & Field Interviews (DOIs, User Quotes)
     └── 2. Specific Problem Claims (Friction, Frequency, Cost)
           └── 3. Testable Assumptions & Validation Checks
                 └── 4. Technical Specifications & Software Requirements
                       └── 5. Final Proposal Canvas

The web interface includes an interactive SVG graph with layered columns, smooth curved connectors, pan/zoom navigation, and clear edge indicators showing whether evidence supports, refutes, or extends an assumption.

05Connecting to Researcher Tools: Notion, Zotero, and GitHub

Research outputs are only useful if they can easily flow into the tools teams already use:

To keep the codebase maintainable and avoid bloated dependencies, these integrations were built directly with Python's standard httpx library rather than bundling heavy third-party vendor SDKs. Every sync action records a SHA-256 payload hash in SQLite (ecosystem_sync_records) so exports remain verifiable.

06Deterministic Scoring & Keeping Humans in Control

CONVERA deliberately avoids asking an AI chatbot to decide whether an idea is good. Instead, it uses clear math for ranking:

Key engineering decisions enforced in the code:

• Zero AI Approval Weight: AI suggestions are strictly advisory. In code, AI confidence ratings carry zero weight in gate passage. Only human developers and mentors can mark a validation phase as passed.
• Protected Ranking Invariant: A post-processing check ensures that narrative summaries generated by language models can never change the mathematically calculated rankings.
• Offline Fallbacks: If external AI APIs time out or hit rate limits, the system provides offline mock responses flagged with is_evidentiary = False, ensuring test data never pollutes actual research findings.

07Working Code Today vs. Future Roadmap

To maintain honesty about project scope, here is what is fully functional in the repository today versus what is planned:

08Engineering Takeaways

Building CONVERA taught me three practical lessons about designing data-heavy validation software:

• Rules in Code, Not in Prompts: Enforcing validation steps through relational database states and explicit transition logic proved far more reliable and reproducible than trying to instruct an LLM with long system prompts.
• SQLite for Fast Local Development: Using SQLite WAL with 38 normalized tables gave instant test spin-up times (338 tests run in seconds), zero server configuration, and clean test isolation.
• Resisting Dependency Bloat: Solving problems with simple deterministic math, database queries, and existing standard libraries before reaching for heavy AI frameworks kept the codebase fast, testable, and easy to maintain.