Skip to main content
Welcome aboard! 🚀 We believe in Trust & Openness. You have full access to the codebase because we want you to see the big picture.

📚 Step 1: the context (1 hour)

Don’t read the code yet. Read these first to understand why we exist.
  1. The Story: Read how we evolved from a simple prototype to an Enterprise Architecture.
  2. The System: Understand the Deterministic Verification Logic and how we safeguard the future of AI.
  3. The Technical Core: Explore how visionary concepts map to our 8-Engine specialized architecture.
  4. Security Framework: Scan the latest enterprise security framework.

🛠️ Step 2: the setup (30 mins)

  1. Clone the Repo:
git clone https://github.com/rahuldass19/qwed-verification.git
cd qwed-verification
  1. Install Dependencies:
# We use standard pip for the core dependencies
pip install -e .
  1. Environment Variables:
  • Create a .env file (copy .env.example).
  • Note: We now use PostgreSQL via Docker. Ensure you have Docker running (docker-compose up -d) to run the full suite, but for this task, standard unit tests will suffice.

🎯 Step 3: the task (Phase 0)

The goal: building a “SQL firewall” for AI agents

Enterprises want to use “Text-to-SQL” agents (e.g., “Show me top 10 users”). The Risk: LLMs hallucinate. If an LLM generates DROP TABLE users or SELECT * FROM passwords, the company is destroyed. QWED’s role: QWED parses the SQL using AST analysis and blocks dangerous queries before they reach the database.

Real-world scenarios (your task)

You are building the Safety Test Suite for our SQL Engine. Your Workspace: tests/test_sql_safety.py (Create this file). Task: Write 5-10 test cases that simulate these “Bad AI” behaviors:
ScenarioSafety rule (what QWED must catch)Why it matters (real-world impact)
The DestructorQuery contains DROP, TRUNCATE, or ALTERPrevents AI from deleting the production database.
The Data LeakQuery selects sensitive columns: password_hash, ssn, salaryPrevents AI from revealing PII or credentials.
The InjectionQuery contains comment attacks (--, /*) or 1=1Prevents classic SQL Injection bypasses.
The Mass DeleteDELETE or UPDATE statement without a WHERE clausePrevents accidentally wiping all records instead of one.
Output: Write the Tests first (TDD). Create scenarios for both Safe Queries (e.g., SELECT name FROM users) and **Unsafe Queries. Assert that our engine raises a SecurityViolation` error for the unsafe ones.

🚀 Step 4: submission

  1. Create a branch: git checkout -b feature/sql-safety-tests
  2. Push your changes.
  3. Open a Pull Request (PR).

Questions?

Ping me anytime. I value:
  • Curiosity: Ask “Why did you design it this way?”
  • Clarity: Write simple, readable code.
  • Speed: Ship small, verified changes.