Requra

Open Live Demo  ·  Frontend  ·  Backend  ·  Mobile  ·  AI Pipeline

API Documentation  ·  Figma Product Design

_{104 seconds · real product UI, real mixed-source project · also available in 4K}

Requra.AI turns fragmented project knowledge—documents, notes, transcripts, meeting audio, and stakeholder context—into structured requirements, user stories, acceptance criteria, executive summaries, evidence, quality findings, and delivery-ready export data.

Unlike a generic LLM wrapper, the AI workflow retrieves source support and then performs a separate grounding step that verifies final evidence quotes against the original chunks. Business analysts and product teams can review results, invite stakeholders, resolve feedback, and keep delivery artifacts connected to their source.

The recruiter demo is an explicit synthetic runtime. The current Flutter runtime is also partly mock-backed; neither should be presented as the deployed production integration.

The implemented platform boundary is React web application → ASP.NET Core backend → FastAPI AI service. The Flutter client is implemented and published, while its current API environment remains partly mock-backed.

• The ASP.NET Core backend owns application identity, projects, documents, meetings, recordings, stakeholder feedback, PostgreSQL persistence, and AI-run orchestration.
• The AI service owns request validation, deterministic fingerprinting, durable AI jobs, retrieval, grounding, quality controls, and the V1 result contract.
• The Flutter mobile client implements product surfaces and backend-shaped contracts, but project/result and meeting traffic still uses mock configuration in parts of the current runtime.
• The direct browser-to-AI processor is an explicit two-flag emergency/demo fallback, not the normal customer path.
• Chat, STT, embedding, hybrid-retrieval, callback, and repair behavior remains configuration-dependent where marked.

Editable source: profile/diagrams/platform-architecture.mmd

1. The web client starts analysis through POST /api/projects/{projectId}/ai/runs.
2. The backend validates project and document ownership, then persists an AnalysisRun in QUEUED state.
3. The current backend worker combines text from backend-owned project documents.
4. It submits the protected internal request through POST /internal/process (bearer-token authenticated).
5. The AI service validates and fingerprints the request, persists durable job state, and dispatches configured worker execution.
6. The AI worker runs the 13-node graph and persists evidence, quality data, and the terminal result.
7. The backend polls GET /internal/jobs/{jobId} for status, then reads GET /internal/jobs/{jobId}/result and stores AnalysisResult.RawJson plus the terminal run state.
8. Clients read run status and the project results dashboard from the backend.

Polling is the currently implemented backend integration. Submission uses the protected internal compatibility endpoint; status and result reads use the authenticated /internal/jobs production endpoints. Callbacks are an optional AI-service capability, not the current backend completion path.

Editable source: profile/diagrams/analysis-sequence.mmd

The current graph contains 13 nodes:

detect_file_type → prepare_sources → build_source_index → extract → dedupe_requirements → retrieve_evidence → classify → evidence_grounding → generate → quality_gate → repair_stories when eligible and enabled → summarize → format

Key implementation characteristics:

• PDF, DOCX, text, and backend transcripts converge on the same graph; prepare_sources fans out over heterogeneous documents and audio concurrently, transcribes accepted audio through configured Groq or Deepgram speech-to-text, masks detected PII, and merges everything into one chunk corpus before it reaches the graph's shared stages.
• Rejected, errored, or empty input short-circuits straight from prepare_sources to format.
• BM25 is the deterministic primary retriever; pgvector-backed hybrid retrieval is optional.
• Evidence grounding verifies that attached quotes occur in source chunks.
• The only loop is the bounded quality_gate → repair_stories → quality_gate cycle.
• Chat providers are configurable through OpenRouter, OpenAI, or Groq; no single model is hard-coded as the product identity.

Editable source: profile/diagrams/ai-pipeline.mmd

Retrieval improves recall; grounding verifies that the final quote exists in the source. Final results can preserve document identity, page/speaker/timestamp-aware chunks, quotes, requirement confidence, story coverage, acceptance criteria, and aggregate quality findings.

The gallery reuses current privacy-safe frontend showcase assets. Open the interactive demo for the complete synthetic recruiter workspace.

• Published multi-client platform: React, ASP.NET Core, Flutter, and FastAPI repositories expose the current implementation boundaries.
• Project-scoped backend orchestration: the backend validates project documents, persists analysis runs, submits AI work, polls status, and stores normalized results.
• Separated AI API and worker execution: request handling does not perform the long-running graph inline.
• Idempotent AI submission: production-relevant request identity is fingerprinted so retries do not silently become different jobs.
• Durable lifecycle state: jobs, attempts, events, chunks, evidence, results, quality findings, and terminal state can persist in PostgreSQL.
• Secure mobile token storage: access and refresh tokens use Flutter Secure Storage, while shared mock API configuration remains clearly separated from production claims.
• Evidence grounding: retrieved support is not treated as proof until the quote is checked against source chunks.
• Quality gates: coverage, source mapping, story structure, acceptance criteria, duplicates, and aggregate scores are validated.
• Honest operating modes: mock, in-memory, in-process, conditional-provider, and production-shaped paths are identified rather than presented as equivalent.

Current gaps include finishing mobile-to-production-backend integration, replacing the backend's current in-process analysis task with fully durable orchestration, completing real device meeting capture, AI-service rate limiting, a durable callback outbox, scheduled retention cleanup, and broader prompt-injection defenses. Reliability controls reduce risk but do not guarantee perfect correctness or zero hallucinations.

# Web
git clone https://github.com/Requra/frontend.git
cd frontend && npm ci && cp .env.example .env && npm run dev

# Mobile
git clone https://github.com/Requra/mobile.git
cd mobile && flutter pub get && flutter run

# AI service
git clone https://github.com/Requra/ai-pipeline.git
cd ai-pipeline && docker compose up --build

Review each repository's environment configuration before connecting to real services. In particular, replace mobile mock endpoints and authorization fixtures rather than treating them as production defaults.

Requra.AI is a coordinated multidisciplinary graduation project spanning web product engineering, ASP.NET Core backend and integrations, Flutter mobile development, AI and data intelligence, and shared testing and quality work. Current implementation ownership should be taken from repository settings and contribution history rather than inferred from historical role assignments.

Capture context. Verify evidence. Align stakeholders. Deliver clearly.

Proprietary software · All rights reserved by the Requra.AI team