Sobre

1. PROJECT OVERVIEW This project consists of the development of two integrated modules: • Playbook Contract Analyzer It will be powered by a continuously updated legal knowledge base that includes applicable laws, regulations, and jurisprudence. The solution will provide intelligent legal assistance for public procurement analysis, 2. FUNCTIONAL MODULES & KEY REQUIREMENTS 2.1 Playbook Contract Analysis 1. Automatically reads and interprets unstructured contract documents (PDF, DOCX, XLSX). 2. Extracts answers to 20–40 predefined questions per playbook (total: 4 playbooks to start). 3. References the knowledge base (laws + jurisprudence) to verify legal compliance and enrich answers with recommendations. We will create a small document to summarize knowledge base 4. Supports document uploads for complementary inputs. 5. Responses will be contextual, legally coherent, and structured for reuse. To optimize performance and reduce token-related costs, all responses generated from playbooks must be persistently stored in our database. This allows the system to reuse previous results without re-executing the same prompts. Each playbook execution must be uniquely identified by a composite key formed by the combination of the following elements: • Public entity code (entity_code) • Procurement process number (procurement_number) • Playbook ID or version (playbook_id) Together, this composite key should act as a unique identifier for a specific playbook instance. If another user later requests the same playbook for the same procurement process and same public entity, the system must automatically reuse the previously stored responses, instead of querying the language model again. This mechanism is critical to: • Avoid unnecessary token consumption. • Guarantee consistency in responses across users and teams. • Improve response time and scalability of the platform. 3. BACKEND & ENGINEERING REQUIREMENTS • Document ingestion pipeline for long-format contracts (up to 70+ pages). • OCR + parser for extracting structure, sections, metadata, and tables from PDF/DOCX/XLSX. • Data pipeline to extract relevant context, transform it, and store responses indexed per playbook. • Develop APIs to store, retrieve, and version playbook responses. 4. AI / LLM Integration • Integration with OpenAI’s LLM (or equivalent open-source alternatives). • Use of semantic search over a vector-based knowledge base • Design and implementation of prompt engineering strategies tailored to legal question-answering. • The system must be capable of dynamically incorporating updates into the knowledge base. 5. KNOWLEDGE BASE EXPANSION • The legal base will include: o Laws and decrees governing procurement. o Jurisprudence – interpretations and decisions made by administrative or judicial bodies. • The system must allow automatic ingestion of new documents. • All playbooks and the chatbot must leverage the updated central knowledge repository in real time. 6. USER INTERACTION WORKFLOW • Users must be able to upload contracts and supporting documentation. • A set of custom questions (defined by the Govy team) will be presented to users to refine the AI's understanding of each case. 7. ACCURACY CONTROL & QA • After development, responses generated by the models will undergo review and validation by the Govy legal and product teams. • target : o The current module reaches a minimum 90% accuracy rate (as validated by Govy). • A robust bug-reporting and feedback cycle must be in place for rapid iteration. 8. INTERNAL REVIEW & IMPROVEMENT LOOP FOR AI-GENERATED OUTPUTS To ensure the highest quality, accuracy, and legal soundness of all AI-generated responses — particularly in sensitive domains like procurement defense and contract interpretation — the system must incorporate a native review and feedback mechanism within the Govy platform. 8.1 Objective Establish a structured internal workflow that enables legal experts and team members to evaluate, comment, and suggest improvements on the AI-generated answers before final delivery to clients or usage in official documentation. 8.2 Key Functional Requirements 1. In-Platform Review Panel The UI must present AI-generated responses alongside: Source document snippets used Cited knowledge base entries (laws, jurisprudence, etc.) Confidence score (optional) o Reviewer can highlight, annotate, or flag sections for revision. 2. Categorized Feedback Options Allow reviewers to classify each correction as: Incorrect interpretation Missing context Unclear language Satisfactory (no change needed) 3. Editable Text with Version Control The platform must store: Original AI output Reviewer modifications Timestamps and user ID 4. Reinforcement Learning from Human Feedback Over time, the system should learn from accepted corrections to improve prompt behavior or fine-tuning datasets. This may be done via: Structured correction tagging Submission of validated outputs to fine-tuning pipelines