AI Jurisprudence Research Bot Development
Budget: $250 – $750 USD
Project Title
AI-powered Brazilian Case Law (Jurisprudence) Research Bot (TJSP + STJ + STF) with Word (.docx) Output
Background (for a non-Brazilian developer)
In Brazil, lawyers frequently cite jurisprudência (case law decisions) to support legal arguments in lawsuits, motions, and legal opinions. The most relevant sources depend on the court:
• STF (Supreme Federal Court): Brazil’s highest court for constitutional matters.
• STJ (Superior Court of Justice): highest court for federal law interpretation (non-constitutional).
• TJSP (São Paulo State Court): the most important state appellate court for matters in São Paulo.
Brazilian lawyers typically search these courts’ jurisprudence portals for decisions related to a topic (e.g., “contract termination”, “real estate registry”, “condominium disputes”), then cite the ementa (official summary/headnote) and provide the official link to the decision.
This tool will help lawyers by allowing them to describe what they want in natural language (Portuguese), and the system will automatically query those three tribunals, collect results, and generate a Word report (.docx) containing only ementas and official links.
⸻
Objective
Build a Windows-based system that:
1. Accepts a user query in Portuguese (text, optionally voice later), describing what jurisprudence they want.
2. Automatically searches TJSP, STJ, and STF jurisprudence portals.
3. Extracts and consolidates results (decision metadata + ementa + official link).
4. Generates a .docx report with ementas + links only (no full decision text).
5. Runs on a dedicated Windows machine connected to the internet through a VPN, operating autonomously.
⸻
Required Sources (Scope is ONLY these 3)
1. TJSP – São Paulo State Court (state-level decisions)
2. STJ – Superior Court of Justice (federal law decisions)
3. STF – Supreme Federal Court (constitutional decisions)
The system must be designed so that if these sites change layout, we can update scrapers without rewriting everything (modular connectors per court).
⸻
Deliverable Summary
A) Working application (Windows)
A complete system that can be installed and run on Windows, on a dedicated PC.
B) Court connectors / scrapers
Separate “connector modules” for:
• TJSP connector
• STJ connector
• STF connector
Each connector:
• Receives a structured query object
• Performs search on the official site
• Returns standardized results
C) AI query understanding module
A module that converts the lawyer’s natural language into:
• Keywords / synonyms
• Optional date range (e.g., “from 2020 onwards”)
• Exclusion terms
• Court selection (default: all 3)
• (Optional) decision types if the portal supports it
D) Word (.docx) report generator
Generates a .docx file containing:
• Search parameters used
• Timestamp
• Results grouped by court
• For each result: minimal metadata + ementa + link
E) Logging & audit trail
• Logs of queries, URLs accessed, results count, errors, and export path
• Optional “debug mode” to save raw HTML of result pages for maintenance
⸻
Functional Requirements (Detailed)
1) Inputs
A simple UI (desktop or local web UI) where the user can:
• Paste/type a query in Portuguese
• Choose courts (checkboxes): TJSP / STJ / STF (default all selected)
• Optional filters:
• Date range (start year / end year)
• Maximum results per court
• “Only the most relevant” vs “collect as much as possible”
• Click “Run Search” and “Export to Word”
Minimum required input: a single free-text query.
2) Output (.docx)
The report must include only:
• Ementa (headnote/summary)
• Official link to the decision
And basic metadata if available:
• Court (TJSP/STJ/STF)
• Decision title / case identifier (process number or decision ID)
• Judge/Justice (“Relator”) if available
• Decision date / publication date if available
No full text / no PDF content should be inserted into the report.
3) Consolidation rules
• Deduplicate results (the same decision may appear multiple times due to pagination or repeated queries).
• Provide a clean list.
4) Performance expectations
• First working version can be slower (web scraping is variable), but must:
• Provide progress feedback (e.g., “Searching STJ… page 2/10”)
• Avoid freezing UI
• Must handle “no results” gracefully and still generate a report stating that no decisions were found.
5) Robustness and site variability
• Websites may:
• Change layout
• Rate-limit
• Use pagination and dynamic content
• Build connectors using a robust automation framework (recommended: Playwright).
• Use a modular design so each connector can be updated independently.
6) Language and relevance
• User queries are in Portuguese.
• Output remains in Portuguese (ementas are Portuguese).
• AI query module should:
• Keep the original query
• Add relevant synonyms/variants where helpful
• Avoid hallucinating legal citations: it must only search and collect what exists.
⸻
Non-Functional Requirements
1) Windows machine / VPN
• The system will run on a dedicated Windows PC that connects to the internet via VPN.
• The app should not depend on any cloud-only environment for basic operation.
• If you use external AI APIs (OpenAI or other), it must be configurable with an API key and clearly documented.
2) Security
• No hard-coded credentials.
• Configuration stored in a local .env file or encrypted config file.
• Logs must avoid storing sensitive content beyond the query itself (or allow turning that off).
• Basic anti-injection rules:
• The AI module should not be able to execute OS commands.
• Do not allow AI-generated instructions to control the browser outside allowed domains (whitelist only the official court domains).
3) Maintainability
• Clean codebase with:
• Readme + setup instructions
• Clear separation: UI / orchestration / connectors / docx generator
• Unit tests for query parsing and docx generation (at least minimal)
⸻
Proposed Technical Approach (Developer can adjust, but must meet requirements)
Recommended stack
• Python 3.11+
• Playwright for court site navigation/scraping
• python-docx for Word report generation
• FastAPI + local web UI (optional) or desktop UI (optional)
• Local SQLite for caching/deduping (optional but recommended)
System architecture
• app_orchestrator: receives user query → calls AI parser → dispatches to connectors → merges results → generates Word
• connectors/tjsp.py, connectors/stj.py, connectors/stf.py: isolated court-specific logic
• report/docx_builder.py: consistent formatting and grouping
⸻
Word Report Formatting Requirements
The .docx must be readable and professional (law-firm style). Suggested structure:
1. Title page:
• “Jurisprudence Search Report”
• Query text
• Courts searched
• Date/time
• Applied filters (date range, max results, etc.)
2. Sections:
• TJSP
• STJ
• STF
For each decision entry:
• Case identifier + date (if available)
• Ementa (full)
• Official URL (clickable hyperlink)
⸻
Acceptance Criteria (How I will test)
The developer must provide:
1. A working Windows installation (script or installer) and a step-by-step guide.
2. A demo run with at least 3 different queries (Portuguese), showing results from:
• TJSP
• STJ
• STF
3. Generated .docx files that:
• Include ementas + official links
• Are grouped by court
• Do not include full text
4. Logging file showing:
• Start/end time
• Courts queried
• Count of results per court
• Errors (if any)
5. Modular connectors: I should be able to disable one court and still run the others.
⸻
Known Risks / Constraints (Developer must plan for this)
• Court portals may have anti-bot measures, CAPTCHAs, or layout changes.
• The tool must be built in a way that allows future maintenance.
• If a CAPTCHA appears, at minimum the system must:
• Detect it
• Pause and prompt the user to solve it manually in the browser automation window (or fallback to a manual step)
• Continue after resolution
⸻
Project Phases (Suggested milestones)
Milestone 1 — MVP
• Working UI + orchestration
• Working connector for 1 court (pick easiest)
• Working .docx output
Milestone 2 — Add remaining courts
• 3 connectors complete
• Deduplication + pagination
Milestone 3 — Hardening
• Better query parsing/synonyms
• Logs, retry logic, timeouts
• Packaging for Windows
⸻
What I Need From You (Developer)
• Portfolio/experience with web automation (Playwright/Selenium)
• Experience generating Word reports (python-docx or equivalent)
• A brief plan explaining:
• How you will scrape each court reliably
• How you will handle pagination/rate-limits/CAPTCHA
• How you will package it for Windows
⸻
Optional Enhancements (Not required, but nice)
• Scheduler mode (run nightly and generate reports automatically)
• Email sending (or integration with Outlook) to deliver the Word file
• Local database of past searches and results
• Export to PDF in addition to .docx
⸻
Notes on Legal/Ethical Use
This tool will be used by lawyers for legitimate legal research. The system must query only official public jurisprudence pages and comply with reasonable access limits (delays between requests, respectful scraping).
AI-powered Brazilian Case Law (Jurisprudence) Research Bot (TJSP + STJ + STF) with Word (.docx) Output
Background (for a non-Brazilian developer)
In Brazil, lawyers frequently cite jurisprudência (case law decisions) to support legal arguments in lawsuits, motions, and legal opinions. The most relevant sources depend on the court:
• STF (Supreme Federal Court): Brazil’s highest court for constitutional matters.
• STJ (Superior Court of Justice): highest court for federal law interpretation (non-constitutional).
• TJSP (São Paulo State Court): the most important state appellate court for matters in São Paulo.
Brazilian lawyers typically search these courts’ jurisprudence portals for decisions related to a topic (e.g., “contract termination”, “real estate registry”, “condominium disputes”), then cite the ementa (official summary/headnote) and provide the official link to the decision.
This tool will help lawyers by allowing them to describe what they want in natural language (Portuguese), and the system will automatically query those three tribunals, collect results, and generate a Word report (.docx) containing only ementas and official links.
⸻
Objective
Build a Windows-based system that:
1. Accepts a user query in Portuguese (text, optionally voice later), describing what jurisprudence they want.
2. Automatically searches TJSP, STJ, and STF jurisprudence portals.
3. Extracts and consolidates results (decision metadata + ementa + official link).
4. Generates a .docx report with ementas + links only (no full decision text).
5. Runs on a dedicated Windows machine connected to the internet through a VPN, operating autonomously.
⸻
Required Sources (Scope is ONLY these 3)
1. TJSP – São Paulo State Court (state-level decisions)
2. STJ – Superior Court of Justice (federal law decisions)
3. STF – Supreme Federal Court (constitutional decisions)
The system must be designed so that if these sites change layout, we can update scrapers without rewriting everything (modular connectors per court).
⸻
Deliverable Summary
A) Working application (Windows)
A complete system that can be installed and run on Windows, on a dedicated PC.
B) Court connectors / scrapers
Separate “connector modules” for:
• TJSP connector
• STJ connector
• STF connector
Each connector:
• Receives a structured query object
• Performs search on the official site
• Returns standardized results
C) AI query understanding module
A module that converts the lawyer’s natural language into:
• Keywords / synonyms
• Optional date range (e.g., “from 2020 onwards”)
• Exclusion terms
• Court selection (default: all 3)
• (Optional) decision types if the portal supports it
D) Word (.docx) report generator
Generates a .docx file containing:
• Search parameters used
• Timestamp
• Results grouped by court
• For each result: minimal metadata + ementa + link
E) Logging & audit trail
• Logs of queries, URLs accessed, results count, errors, and export path
• Optional “debug mode” to save raw HTML of result pages for maintenance
⸻
Functional Requirements (Detailed)
1) Inputs
A simple UI (desktop or local web UI) where the user can:
• Paste/type a query in Portuguese
• Choose courts (checkboxes): TJSP / STJ / STF (default all selected)
• Optional filters:
• Date range (start year / end year)
• Maximum results per court
• “Only the most relevant” vs “collect as much as possible”
• Click “Run Search” and “Export to Word”
Minimum required input: a single free-text query.
2) Output (.docx)
The report must include only:
• Ementa (headnote/summary)
• Official link to the decision
And basic metadata if available:
• Court (TJSP/STJ/STF)
• Decision title / case identifier (process number or decision ID)
• Judge/Justice (“Relator”) if available
• Decision date / publication date if available
No full text / no PDF content should be inserted into the report.
3) Consolidation rules
• Deduplicate results (the same decision may appear multiple times due to pagination or repeated queries).
• Provide a clean list.
4) Performance expectations
• First working version can be slower (web scraping is variable), but must:
• Provide progress feedback (e.g., “Searching STJ… page 2/10”)
• Avoid freezing UI
• Must handle “no results” gracefully and still generate a report stating that no decisions were found.
5) Robustness and site variability
• Websites may:
• Change layout
• Rate-limit
• Use pagination and dynamic content
• Build connectors using a robust automation framework (recommended: Playwright).
• Use a modular design so each connector can be updated independently.
6) Language and relevance
• User queries are in Portuguese.
• Output remains in Portuguese (ementas are Portuguese).
• AI query module should:
• Keep the original query
• Add relevant synonyms/variants where helpful
• Avoid hallucinating legal citations: it must only search and collect what exists.
⸻
Non-Functional Requirements
1) Windows machine / VPN
• The system will run on a dedicated Windows PC that connects to the internet via VPN.
• The app should not depend on any cloud-only environment for basic operation.
• If you use external AI APIs (OpenAI or other), it must be configurable with an API key and clearly documented.
2) Security
• No hard-coded credentials.
• Configuration stored in a local .env file or encrypted config file.
• Logs must avoid storing sensitive content beyond the query itself (or allow turning that off).
• Basic anti-injection rules:
• The AI module should not be able to execute OS commands.
• Do not allow AI-generated instructions to control the browser outside allowed domains (whitelist only the official court domains).
3) Maintainability
• Clean codebase with:
• Readme + setup instructions
• Clear separation: UI / orchestration / connectors / docx generator
• Unit tests for query parsing and docx generation (at least minimal)
⸻
Proposed Technical Approach (Developer can adjust, but must meet requirements)
Recommended stack
• Python 3.11+
• Playwright for court site navigation/scraping
• python-docx for Word report generation
• FastAPI + local web UI (optional) or desktop UI (optional)
• Local SQLite for caching/deduping (optional but recommended)
System architecture
• app_orchestrator: receives user query → calls AI parser → dispatches to connectors → merges results → generates Word
• connectors/tjsp.py, connectors/stj.py, connectors/stf.py: isolated court-specific logic
• report/docx_builder.py: consistent formatting and grouping
⸻
Word Report Formatting Requirements
The .docx must be readable and professional (law-firm style). Suggested structure:
1. Title page:
• “Jurisprudence Search Report”
• Query text
• Courts searched
• Date/time
• Applied filters (date range, max results, etc.)
2. Sections:
• TJSP
• STJ
• STF
For each decision entry:
• Case identifier + date (if available)
• Ementa (full)
• Official URL (clickable hyperlink)
⸻
Acceptance Criteria (How I will test)
The developer must provide:
1. A working Windows installation (script or installer) and a step-by-step guide.
2. A demo run with at least 3 different queries (Portuguese), showing results from:
• TJSP
• STJ
• STF
3. Generated .docx files that:
• Include ementas + official links
• Are grouped by court
• Do not include full text
4. Logging file showing:
• Start/end time
• Courts queried
• Count of results per court
• Errors (if any)
5. Modular connectors: I should be able to disable one court and still run the others.
⸻
Known Risks / Constraints (Developer must plan for this)
• Court portals may have anti-bot measures, CAPTCHAs, or layout changes.
• The tool must be built in a way that allows future maintenance.
• If a CAPTCHA appears, at minimum the system must:
• Detect it
• Pause and prompt the user to solve it manually in the browser automation window (or fallback to a manual step)
• Continue after resolution
⸻
Project Phases (Suggested milestones)
Milestone 1 — MVP
• Working UI + orchestration
• Working connector for 1 court (pick easiest)
• Working .docx output
Milestone 2 — Add remaining courts
• 3 connectors complete
• Deduplication + pagination
Milestone 3 — Hardening
• Better query parsing/synonyms
• Logs, retry logic, timeouts
• Packaging for Windows
⸻
What I Need From You (Developer)
• Portfolio/experience with web automation (Playwright/Selenium)
• Experience generating Word reports (python-docx or equivalent)
• A brief plan explaining:
• How you will scrape each court reliably
• How you will handle pagination/rate-limits/CAPTCHA
• How you will package it for Windows
⸻
Optional Enhancements (Not required, but nice)
• Scheduler mode (run nightly and generate reports automatically)
• Email sending (or integration with Outlook) to deliver the Word file
• Local database of past searches and results
• Export to PDF in addition to .docx
⸻
Notes on Legal/Ethical Use
This tool will be used by lawyers for legitimate legal research. The system must query only official public jurisprudence pages and comply with reasonable access limits (delays between requests, respectful scraping).