Senior Python / Google Cloud Developer Needed for 72-Hour Confidential Evidence Review MVP

Senior Python / Google Cloud Developer Needed for 72-Hour Confidential Evidence Review MVP Fixed-Price Project --Target budget:-- $4,000 fixed price --Required turnaround:-- Fully operational within 72 hours after contract start and receipt of access credentials --Milestone 1:-- $2,000 --Milestone 2:-- $2,000 --Potential follow-on work:-- Yes, but this contract is strictly limited to the MVP described below Project Summary We need a senior developer to build and deploy a narrow, single-matter document and email review application on a Google Cloud Confidential VM. The application will be used by a business client and outside legal counsel to organize, search, review, classify, and export records responsive to a litigation-related document request. The matter involves: - Approximately 5 years of potentially relevant email communications - Several custodian mailboxes - Email attachments - Native PDF and Office documents - document imports via shared drive - A limited number of scanned paper records - Potentially privileged attorney-client communications - A need for attorney review before any records are exported This is not intended to replace Relativity, Everlaw, DISCO, or other full e-discovery platforms. It is a controlled internal evidence workspace for one matter. The MVP must preserve original files, extract searchable information, identify likely privilege candidates, permit human review, maintain an audit trail, and export attorney-approved records. Critical Deadline The complete MVP must be operational within --72 consecutive hours-- of project commencement. Applicants must: 1. Be available to begin immediately. 2. Confirm they can allocate sufficient uninterrupted time during the 72-hour period. 3. Provide a concise implementation plan with their proposal. 4. Identify any requested scope item that cannot reasonably be delivered within 72 hours. 5. Avoid proposing major alternative frameworks or enterprise redesigns unless a requirement is technically impossible. The project will be awarded only after a brief video interview and review of relevant prior work. --- Project Objective At completion, the client and counsel must be able to: 1. Log into a secure web application using separate named user accounts. 2. Upload or import emails, email attachments, PDFs, scans, and common Office documents. 3. Preserve an unchanged original copy of every imported item. 4. Assign each item an opaque UUID and SHA-256 hash. 5. Search documents and email metadata. 6. View emails, attachments, PDFs, and extracted text. 7. classify documents by responsiveness and potential privilege. 8. Add tags and notes. 9. Segregate likely privileged communications from ordinary records. 10. Approve selected documents for production. 11. Export approved records with an index and hash manifest. 12. Export the entire matter in a nonproprietary format if the application is later discontinued. The software must not make final legal privilege determinations. Automated classifications are recommendations only. Human users, particularly counsel, must retain final control. --- Required Technical Architecture The developer may recommend minor substitutions, but the default architecture is: Google Cloud Infrastructure - A dedicated Google Cloud project owned and controlled by the client - Google Compute Engine Confidential VM - Ubuntu LTS - Shielded VM features enabled where supported - Encrypted persistent disk - Google Cloud Storage for original evidence, working files, and exports - Google Identity-Aware Proxy or an equivalently secure Google-native access method - Google Cloud Logging for relevant infrastructure events - No publicly exposed SSH, database, or remote-desktop port - Firewall limited to required application traffic - Application access limited to individually authorized Google accounts - Separate application-level client and counsel roles The developer must deploy inside the client’s Google Cloud account. The developer may not host the application or evidence in the developer’s own account. Application Stack Preferred rapid-development stack: - Python 3.11 or later - FastAPI backend - PostgreSQL - Simple server-rendered frontend, lightweight React frontend, or Streamlit only if Streamlit can adequately support user roles and secure workflow - Docker Compose - Nginx or Caddy reverse proxy - Background task worker where required - OCRmyPDF and Tesseract for searchable scanned PDFs - Native Python email-processing libraries and appropriate open-source tools for supported mailbox formats - Apache Tika, LibreOffice headless conversion, or equivalent for supported Office-document text extraction - Optional local model through Ollama or llama.cpp - No external generative-AI API calls The developer should favor reliability and intelligibility over visual sophistication. --- Evidence Storage Model The application database must store metadata and references to files. Large evidentiary files should not be stored as PostgreSQL binary objects. Required Google Cloud Storage Areas The developer should implement at least three distinct storage locations or prefixes: 1. Original Evidence Purpose: - Stores the exact file received during ingestion - Must not be altered by OCR, conversion, annotation, or review - Accessible to the application on a read-only basis after initial ingestion - Not directly exposed through public URLs Suggested structure: `gs://[matter]-evidence-originals/[uuid]/original.ext` 2. Working Files Purpose: - Searchable PDFs - OCR derivatives - Thumbnails - Extracted text - Rendered email views - Temporary conversion outputs Suggested structure: `gs://[matter]-evidence-working/[uuid]/` 3. Production Exports Purpose: - Counsel-approved production packages - CSV indexes - Hash manifests - Privilege-candidate reports - Matter exports Suggested structure: `gs://[matter]-evidence-exports/[production-id]/` The bucket or object configuration should include appropriate encryption, restricted IAM permissions, versioning or equivalent recovery controls, and prevention of public access. Do not permanently lock an irreversible retention policy without express client approval. The developer should explain any retention or Bucket Lock setting before activating it. --- Core Data Model The exact schema may vary, but it must support the following concepts. Users Required fields or relationships: - User ID - Name - Email - Role - Active status - Created date - Last login Required initial roles: Client Reviewer May: - View collected evidence - Search records - Add factual notes - Add or correct property and issue tags - Mark documents for counsel review - Mark preliminary responsiveness - View production status Counsel Reviewer May: - Perform everything available to the client reviewer - Make final privilege classifications - Add counsel-only notes - Approve or reject production - Generate production exports - Lock completed review decisions Administrator May: - Maintain application configuration - Manage users - Monitor processing - Perform backup and restoration Administrator access must be distinguishable from counsel and client review activity. Matters The MVP may support only one active matter, but matter information must be stored explicitly. Required fields: - Matter ID - Matter name - Description - Relevant date range - Created date - Status Properties The application must permit configuration of the four relevant properties. Required fields: - Property ID - Address - Common name or abbreviation - Optional parcel number - Optional notes Documents may relate to one, multiple, or no identified properties. Custodians Required fields: - Custodian ID - Name - Email address or addresses - Position or role - Relevant date range - Notes Documents A document is the common evidentiary object. It includes: - Native electronic files - Emails - Email attachments - PDFs - Scanned paper records - Word documents - Spreadsheets - Images - Other uploaded records Required fields: - Opaque UUID - Matter ID - Original filename - MIME type - Document type - Source type - Source custodian - Source mailbox or folder, when available - Original storage URI - Working storage URI - SHA-256 hash of original - File size - Page count, where applicable - Document date - Ingestion date and time - OCR status - Text-extraction status - Processing status - Parent document or email relationship - Duplicate hash indicator - Created and modified timestamps The application must preserve separate occurrences of an attachment when the same attachment was sent with multiple emails, even if the binary file hashes are identical. Emails Required fields: - Document UUID - Native message ID - Thread or conversation identifier, where available - Sent date and time - Sender - To recipients - CC recipients - BCC recipients, when available - Subject - Plain-text body - HTML body or rendered body - Header metadata - Attachment relationships - Source custodian - Source mailbox folder Reviews Required fields: - Document UUID - Reviewer - Review date and time - Responsiveness status - Privilege status - Confidentiality status - Property tags - Issue tags - Client-visible notes - Counsel-only notes - Production approval status - Reason code or short explanation - Automated recommendation, if applicable - Human decision Audit Events Required fields: - Timestamp - User or system actor - Action - Document UUID or affected record - Previous status - New status - Event details - Source IP or session information where practical Audit events must be append-oriented. Ordinary application users must not be able to edit or delete audit records. Productions Required fields: - Production ID - Name - Creation date - Created by - Approved by counsel - Included document UUIDs - Export status - Export storage URI - Export hash - Notes --- Milestone 1 — Secure Infrastructure, Ingestion, Preservation, Viewer and Search Fixed Price --$2,000-- Deadline Target completion within the first 36 hours. Milestone 1 Deliverables A. Google Cloud Environment The developer must: 1. Create or configure the dedicated Google Cloud project. 2. Deploy a supported Google Confidential VM. 3. Configure encrypted persistent storage. 4. Configure Cloud Storage buckets or prefixes for: - Originals - Working files - Exports 5. Disable public bucket access. 6. Configure IAM using least-privilege principles. 7. Configure secure HTTPS access. 8. Configure Google Identity-Aware Proxy or approved equivalent. 9. Restrict access to named client and counsel accounts. 10. Ensure the database is not publicly reachable. 11. Ensure SSH is not publicly exposed. 12. Enable relevant logging. 13. Document the infrastructure configuration. B. Application Authentication and Roles Provide: - One named client-reviewer account - One named counsel-reviewer account - One administrator account - Secure login - Session timeout - Role-based access enforcement - Ability to deactivate users Google identity may be used as the primary authentication factor through IAP. The application must still preserve its own role assignments and user audit history. C. Matter Configuration Provide an administrative screen or configuration file for: - Matter name - Relevant date range - Four property records - Custodian names and email addresses - Attorney names, email addresses, and domains - Initial issue tags - Initial privilege terms D. File Ingestion The application must support drag-and-drop or folder-based upload of: - PDF - Searchable PDF - Scanned PDF - EML - MSG, if technically feasible within the deadline - MBOX - DOCX - XLSX - TXT - JPG - PNG - TIFF PST support should be implemented using a stable open-source parser or conversion utility if feasible. If direct PST ingestion cannot be delivered reliably within 72 hours, the developer must provide and document a tested PST-to-MBOX or PST-to-EML conversion workflow. PST support may not be represented as complete unless it has been tested against a sample PST. E. Preservation During Ingestion For every imported item: 1. Generate an opaque UUID. 2. Calculate a SHA-256 hash. 3. Store the exact original file in original-evidence storage. 4. Record the original filename and source. 5. Create derivatives only in working storage. 6. Link email attachments to their originating email. 7. Record processing errors without discarding the original. 8. Prevent normal users from replacing or deleting the original. F. OCR and Text Extraction Implement: - Text extraction from text-native PDFs - OCR processing of scanned PDFs - OCR text stored separately from the original - Basic Office-document text extraction - Basic image OCR where supported - Processing status and failure reporting The original file must never be overwritten by the OCR result. G. Basic Review Interface The review screen must display: - Internal opaque document ID - Original filename - Document type - Document date - Source custodian - Sender and recipients for emails - Subject for emails - Linked attachments - Property tags - Issue tags - Processing status - Extracted text - Original document or PDF viewer - Review controls The interface does not need advanced visual design. It must be usable on a standard desktop browser. H. Search and Filtering Milestone 1 search must include: - Keyword search over extracted text - Exact phrase search where practical - Sender - Recipient - Email subject - Custodian - Date range - Original filename - Document type - Property - Issue tag - Processing status - Hash or duplicate status Semantic or vector search is not required for Milestone 1. I. Duplicate Identification The system must flag exact binary duplicates using SHA-256 hashes. The system should not automatically delete or collapse duplicate occurrences. J. Milestone 1 Documentation Provide: - Deployment instructions - Administrator login procedure - User login procedure - File-ingestion instructions - Supported-file list - Backup description - Known limitations - Source-code repository access - Environment-variable template - Architecture diagram, even if simple Milestone 1 Acceptance Test Milestone 1 is accepted only after the following test succeeds: 1. Client logs in using the client account. 2. Counsel logs in using a separate counsel account. 3. A sample EML or MBOX file is imported. 4. Its attachment is separately indexed and linked. 5. A text-native PDF is imported and searchable. 6. A scanned paper PDF is imported, OCR-processed, and searchable. 7. Each imported item displays a UUID and SHA-256 hash. 8. The exact original remains available. 9. Search returns the expected sample records. 10. The database and storage are not publicly accessible. 11. Developer provides the source code and administrative documentation. --- Milestone 2 — Privilege Screening, Human Review, Local AI Assistance, Production Export and Handoff Fixed Price --$2,500-- Deadline Complete operational delivery by the end of the 72-hour project period. Milestone 2 Deliverables A. Deterministic Privilege-Candidate Screening Create configurable rules based on: - Known attorney email addresses - Known law-firm domains - Known attorney names - Attorney present in sender, recipient, or CC fields - Subject terms such as: - Privileged - Attorney-client - Legal advice - Counsel - Settlement - Mediation - Litigation - Draft complaint - Draft response - Work product - Attachment filename terms - Forwarded or quoted attorney email addresses - Email thread inclusion of counsel These rules must mark a document as a --Privilege Candidate--, not finally privileged. The rules must be editable through a basic administrator screen or a clearly documented configuration file. B. Review Classifications Provide the following responsiveness values: - Unreviewed - Responsive - Not responsive - Needs further review - Mixed or partially responsive Provide the following privilege values: - Unreviewed - No privilege apparent - Privilege candidate - Privileged or work product - Mixed communication or redaction required - Counsel review required Provide the following production values: - Not considered - Proposed for production - Approved by counsel - Rejected by counsel - Exported C. Counsel-Only Notes Counsel must be able to create notes not visible to the ordinary client-reviewer role. The client-reviewer may see the document’s general review status but must not automatically see counsel-only analysis. D. Review Queues Provide filters or queues for: - All unreviewed documents - Privilege candidates - Counsel review required - Responsive and privilege-cleared - Mixed documents - Proposed for production - Counsel-approved - Processing failures - Documents missing dates or custodians E. Configurable Tags Users must be able to assign: - One or more properties - One or more owners or parties - One or more issue tags - Optional importance level - Optional chronology flag Bulk tagging of selected records is strongly preferred but not mandatory if it jeopardizes the 72-hour deadline. F. Local AI-Assisted Classification The system should integrate one lightweight model running inside the Confidential VM through Ollama, llama.cpp, or an equivalent local runtime. No document content may be sent to OpenAI, Anthropic, Google Gemini, or any other external generative-AI API. For each selected document, the local model should be capable of returning structured results containing: - Short factual summary - Identified properties - Identified people or entities - Suggested issue tags - Suggested document date - Suggested privilege-candidate status - Short explanation for privilege-candidate recommendation - Confidence score, if supported The model output must: - Be stored separately from original evidence - Be clearly labeled as automated - Never overwrite human review decisions - Link to the specific document analyzed - Be capable of being rerun - Fail safely if the model is unavailable A lightweight CPU-compatible model is acceptable. Processing speed may be slower than a GPU deployment. Accuracy and privacy take priority over speed. If reliable local-model integration cannot be completed within the deadline, deterministic privilege screening, human review, and export remain mandatory. The developer must not substitute an external AI API. G. Production Selection Counsel must be able to: 1. Select responsive, privilege-cleared records. 2. Add them to a named production batch. 3. Review the batch before export. 4. Remove documents before finalization. 5. Approve the batch. 6. Generate a production package. Only the counsel role may finalize a production. H. Production Export Generate a ZIP package containing: - Exported records - Searchable PDF versions where appropriate - Native-format originals where selected - CSV document index - CSV hash manifest - Production summary - Privilege-candidate report - Error or exception report Suggested structure: `PRODUCTION_001/` - `DOCUMENTS/` - `NATIVES/` - `INDEX.csv` - `HASH_MANIFEST.csv` - `PRODUCTION_SUMMARY.txt` - `EXCEPTIONS.csv` The index should include, where available: - Production sequence number - Internal UUID - Original filename - Document type - Document date - Sender - Recipients - Subject - Custodian - Property tags - Issue tags - Page count - SHA-256 hash - Exported filename Sequential Bates stamping is preferred if it can be reliably implemented and quality-tested within the deadline. It is not more important than producing complete, correctly linked, searchable records. The developer must not assign sequential repository IDs to unproduced internal records. I. Privilege-Log Draft Export Generate a counsel-reviewable CSV containing documents classified as privileged, privilege candidates, or mixed. Suggested fields: - Internal opaque ID - Date - Author or sender - Recipients - Document type - General subject description - Privilege category - Counsel notes or reason code - Final review status This is a draft administrative aid only. The application must not represent the report as a legally sufficient privilege log. J. Complete Matter Export Provide a one-click or documented administrative export of: - Original files - Working derivatives - Extracted text - Email metadata - Document metadata - Review decisions - User-created notes - Automated classifications - Audit history - Properties - Custodians - Tags - Production manifests - Hashes Metadata must be exported in nonproprietary CSV and/or JSON form. The client must not be dependent on the application to retrieve or understand its records. K. Backup and Recovery Implement and document: - Database backup - Cloud Storage recovery or versioning configuration - Restore procedure - Application configuration backup - Secret-handling procedure - What must be retained if the VM is deleted A successful sample database backup and restore should be demonstrated. L. Final Security Review Before handoff, the developer must verify: - No public storage access - No publicly exposed database - No publicly exposed SSH or RDP - IAP or equivalent identity restriction active - Separate client and counsel identities functioning - Service accounts use least-privilege roles - Application secrets are not committed to source control - External AI calls are absent - Test users and temporary developer credentials are removed or disabled - Developer access can be revoked without impairing application operation - Logs are enabled - Backups are operational M. Final Handoff Provide: - Source code in a client-controlled private repository - Docker and deployment files - Database schema and migrations - Environment-variable template - Infrastructure setup notes - Administrator handbook - User quick-start guide - Backup and restore guide - Known limitations - Dependency and license list - 60- to 90-minute recorded or live handoff session - Removal or revocation of developer credentials after acceptance Milestone 2 Acceptance Test Milestone 2 is accepted after the following workflow succeeds: 1. Import a sample mailbox containing ordinary and attorney-related communications. 2. Import a scanned PDF. 3. Confirm exact originals are preserved. 4. Confirm attorney-related messages are routed to the privilege-candidate queue. 5. Confirm an ordinary email is not automatically marked privileged. 6. Log in as the client and add factual tags and notes. 7. Log in as counsel and make a final privilege classification. 8. Confirm counsel-only notes are not visible to the client role. 9. Mark selected documents responsive and privilege-cleared. 10. Add them to a production batch. 11. Finalize the batch as counsel. 12. Generate and download the ZIP package. 13. Confirm the package contains documents, index, hashes, and reports. 14. Export the complete matter. 15. Demonstrate database backup and restore. 16. Confirm source code and documentation are in the client-controlled repository. 17. Remove developer access. --- Security and Confidentiality Requirements The evidence may include attorney-client privileged and confidential business information. The developer must agree that: 1. All data and work product remain the property of the client. 2. No files may be copied to the developer’s personal computer unless specifically authorized. 3. No data may be uploaded to personal cloud storage. 4. No document content may be submitted to third-party AI services. 5. No sample data may be retained after project completion. 6. No screenshots, code samples containing data, or project details may be used in a portfolio. 7. All temporary access credentials must be deleted after handoff. 8. Any suspected security incident must be reported immediately. 9. The developer will sign a confidentiality agreement before receiving access. 10. Development should initially use synthetic test data wherever possible. Production evidence should be uploaded only after the basic security configuration is complete and verified. --- Explicitly Excluded From This 72-Hour MVP The following are not required: - Multi-tenant SaaS architecture - Billing or subscription features - Mobile application - Full predictive coding - Technology-assisted review certification - Fine-tuning a model on the case - External generative-AI integration - Autonomous privilege decisions - Autonomous legal conclusions - Knowledge graph - Blockchain - Digital court filing - Direct access for opposing counsel - Automated subpoena issuance - Automated legal drafting - Full image or handwritten-document analysis - Advanced email threading comparable to enterprise e-discovery products - Full native redaction of every Office format - Enterprise disaster-recovery architecture - SOC 2 certification - Formal legal chain-of-custody certification - Custom GPU deployment - Commercial product branding The developer should not spend project time implementing excluded features. --- Developer Qualifications Required: - Strong Python experience - FastAPI or comparable backend experience - PostgreSQL experience - Docker and Linux administration - Google Compute Engine experience - Google Cloud Storage and IAM experience - Secure web-application deployment - Email parsing or document-processing experience - OCR pipeline experience - Ability to work independently under a hard deadline - Clear written English - Ability to document work for a nontechnical owner Strongly preferred: - Prior Confidential VM deployment - Google IAP experience - Legal-tech, e-discovery, compliance, or records-management experience - PST, MBOX, EML, or MSG parsing experience - OCRmyPDF or Apache Tika experience - Local LLM deployment using Ollama or llama.cpp - Role-based access and audit-log implementation - Production/export workflow experience This project is not suitable for a junior developer learning Google Cloud during the engagement. --- Proposal Instructions Begin the proposal with the words: --CONFIDENTIAL EVIDENCE MVP-- Then answer the following: 1. Can you begin immediately and deliver within 72 consecutive hours? 2. How many hours can you personally commit during that period? 3. Will you perform the work yourself? 4. What application stack would you use? 5. Have you deployed a Google Confidential VM before? 6. Have you configured Google IAP? 7. What email formats have you previously parsed? 8. How would you handle PST ingestion? 9. How would you preserve exact originals while producing OCR derivatives? 10. How would you ensure no document content reaches an external AI API? 11. What lightweight local model would you recommend for a CPU-based Confidential VM? 12. How would you separate client-visible and counsel-only notes? 13. How would you implement immutable or append-oriented audit events? 14. How would you produce a complete nonproprietary matter export? 15. Identify the three greatest delivery risks. 16. State clearly which requested items you believe cannot be reliably completed within 72 hours. 17. Provide links or descriptions of two relevant projects. 18. Confirm that all source code and infrastructure will be placed in client-controlled accounts. 19. Confirm acceptance of the two fixed-price milestones. 20. Confirm willingness to sign a confidentiality agreement. Generic proposals that do not answer these questions will not be considered. Interview Questions Shortlisted applicants should be prepared to explain: 1. The difference between an original evidence file and a working derivative. 2. Why the application should hash the original before OCR or conversion. 3. How an email attachment should remain linked to its originating message. 4. Why duplicate attachments should not automatically be deleted. 5. How IAP differs from merely placing a password on a web page. 6. How the application will operate if the local LLM fails. 7. What data remains if the VM is destroyed. 8. How developer access will be revoked at the end of the engagement. 9. How counsel-only notes will be protected from the client-reviewer role. 10. How a complete matter export would be restored outside the application. --- Payment and Acceptance This is a fixed-price contract. Milestone 1 — $2,000 Released only after: - Secure infrastructure is operational - Named users can log in - Files and emails can be ingested - Originals are preserved and hashed - OCR and text extraction work - Basic viewer and search work - Source code and Milestone 1 documentation are delivered Milestone 2 — $2,000 Released only after: - Privilege-candidate rules work - Client and counsel review roles work - Counsel-only notes work - Production batches and exports work - Complete matter export works - Backup and restore are demonstrated - Security review is completed - Documentation and handoff are completed - Developer access is removed Incomplete source code, deployment only in a developer-owned account, use of external AI APIs, or inability to export the complete matter will constitute failure of the applicable milestone.