Data Engineer

About The Project (description, Duration, Stage) Join Neurons Lab as a Data Engineer (part-time) on a flagship engagement with a European private investment group — a holding company with a C-level executive team, an investment/portfolio function and an affiliated family office. The programme builds one private, access-scoped context layer over the group's data, then AI skills and agents on top of it. You build the plumbing underneath: Phase 1 (Capture) — turn on ingestion across calls, email, Slack and messengers, board protocols, decks and portfolio updates, live and historical; Phase 2 (Connect) — land it all in the context layer with identity resolved, access scope attached and lineage intact. This is deliberately an unstructured-first data-engineering role . There is no clean warehouse to model: the raw material is transcripts, threads, attachments and years of archive, and the hard problems are entity resolution across people and entities, deduplication, incremental sync, PII handling, and keeping cost sane at volume. Roughly eight to ten two-week sprints overall, with your load front-weighted to the first four or five — allocation may flex above 0.5 FTE during Capture and Connect and settle back afterwards. Stage: pre-contract / design-partner negotiation. Reporting: the AI Architect on the engagement, working alongside an AI Analyst; the client's Head of Security is in the working group from day one. Part-time, 20-hour-a-week engagement. What You'll Actually Do (example Tasks) Stand up capture by default: notetaker on every call with speaker attribution, plus ingestion from mail, Slack and messengers — designed as opt-out, not opt-in, and reversible if the client changes their mind. Backfill the archive: years of historical email, Slack, board protocols, decks and portfolio updates — parsed, deduplicated and dated correctly. Build document parsing for the awkward long tail: PDFs, scanned board packs, spreadsheets, slide decks, forwarded attachments. Implement identity / entity resolution: the same person across Slack handle, mail alias and calendar invite; the same portfolio company across a deck, a mail thread and a CRM record. Build chunking and embedding pipelines and load the vector + graph stores behind the ontology the architect defines. Implement incremental sync through the connector layer (MCP / Composio-class) — no full re-crawls, no silent drift, clear handling of edits and deletions. Attach access scope and provenance to every record at ingestion, so permission-aware retrieval and audit are possible downstream rather than bolted on. Run PII detection, redaction and retention logic; evidence to the client's security function what is stored, where, and for how long. Orchestrate with Airflow / Step Functions; build repeatable, monitored pipelines rather than scripts, with alerting when a source stops flowing. Keep cost and latency under control at volume — batching, incremental embedding, storage tiering — and report the unit economics. Write runbooks so the client's own team can operate this after handover. Skills Strong Python and solid SQL Unstructured-data pipelines: transcripts, mail, chat, documents — parsing, normalisation, deduplication Embedding / retrieval infrastructure: chunking strategies, vector stores (pgvector, OpenSearch, Pinecone-class), plus loading a graph store API and connector integration at scale: Google Workspace / M365, Slack, CRM; rate limits, pagination, incremental cursors, webhooks Entity resolution / record linkage (deterministic + fuzzy) without a clean shared key Orchestration: Airflow, Step Functions or equivalent; idempotent, restartable jobs AWS and/or GCP data stack; comfortable in a private / VPC deployment PII detection, redaction, encryption and retention in practice Clear written English; documents for handover and works well async in a small distributed pod Knowledge GDPR applied to employee-generated data (mail, chat, meeting recordings) and EU data residency across multiple jurisdictions Data lineage, provenance and audit patterns — and why an AI system needs them more, not less How retrieval quality depends on ingestion quality — enough understanding of RAG to make the right upstream choices Well-Architected security and cost practice; awareness of financial-services expectations — a plus Experience 4+ years in data engineering, with real unstructured / semi-structured work (not only warehouse modelling) Demonstrated experience integrating many third-party APIs into one coherent store, including historical backfill Experience building pipelines feeding an LLM / retrieval system — strong plus Experience handling sensitive personal data in a regulated or security-sensitive environment Comfortable being the only data engineer on a small (2.5-FTE) pod, at part-time allocation, without hand-holding #J-18808-Ljbffr