A conservation-technology NGO monitors wildlife across Rwanda's protected areas, and none of its systems talk to each other. Jean-Pierre Habimana sends one careful email asking for a comprehensive ML approach and an honest assessment before he commits scarce resources. The deliverable is one integrated wildlife-monitoring system -- not four scripts that happen to share a folder.
The discipline skills, all at once: scoping a maximally ambiguous problem into a buildable component architecture; identifying species from camera-trap images where the vast majority of frames are false triggers, so accuracy is meaningless; detecting poaching patterns and assessing habitat health with matched offline and online feature paths; building retrieval over a ten-year document archive; composing the components and verifying every boundary; running a shared monitoring layer that also watches whether the monitoring itself is still alive; designing the AI development infrastructure as a deliverable; and writing the documentation an annually-funded NGO has to put in front of donors.
The loop lesson: nothing about AI improved. It behaves exactly as it did on your first project. What changed is that the architecture, the decomposition, the context strategy, and the verification design are now yours to supply -- the platform used to provide them. From one email, AI's plausible-but-wrong defaults are the trap at full strength: isolated scripts instead of a system, a species model optimized for an accuracy number that means nothing under heavy imbalance, the document archive and the live alerts treated as the same problem, ingestion that silently loses a week of field data, monitoring with nothing watching the monitoring, and "done" declared the moment the components run. Every default is reasonable. Every one is wrong for this NGO. You supply the architecture; AI supplies the labor.
Your Role
ML systems architect. You scope the problem, make the architecture decisions, decompose the system into pieces AI can build, build them, compose them, deploy them, monitor them, document them, and hand them over.
Last time you adapted an existing system -- a brief, a codebase, a defined task. This time there is no brief, no spec, no design pack, and no codebase. There is a problem statement and nothing else. The system does not exist yet. You work with AI in an architecture-and-orchestration register: AI builds the components, but you own every composition boundary and every invariant that has to hold across the whole system, because AI holds none of them.
What's New
Last time you adapted a working recommendation system for Maria at Balita Digital, under a forced embedding-API deprecation with a 90-day clock -- the scope was given, the system existed, the job was to make the change durable.
Here there is nothing to inherit and nothing to adapt. The scope is undefined and large -- and you define all of it from one email. The full directing-and-verification repertoire carries forward; what is new is that it now turns on a complete system you architect from scratch.
The hard part is that the ambiguity is the work. Before you build anything, you have to make Jean-Pierre's vision tractable -- decide what is one system versus several, what gets built first, what the data is actually like before any of it is modeled. The discovery conversation is where the real architecture decisions surface, and they will not be handed to you.
Tools
- Claude Code -- directing the architecture, decomposition, build, verification, and infrastructure design
- Python -- the substance: the species, poaching, and habitat models, the ingestion and batch pipelines, the serving layers (pandas, numpy, scikit-learn, PyTorch-style code)
- A retrieval stack -- embeddings, chunking, and vector retrieval for the ten-year archive query system, plus its LLM serving layer
- Git/GitHub -- the project repository; you commit the system, the infrastructure, the architecture decision records, the model-strategy document, the monitoring, and the handover
- Jupyter -- the evaluation notebooks: imbalance-aware species evaluation, retrieval-quality evaluation, composition checks
No new tool category is introduced. The capstone is the integrated application of everything you've built across the track. Any setup specific to this project is introduced where it's first needed.
Materials
You receive:
first-contact-email.md-- Jean-Pierre's email: the whole vision, none of the scope, priorities, or constraints specified- Representative real data across every source, as working inputs you profile and build against -- a camera-trap image sample, ranger patrol GPS logs, environmental and satellite sensor data, GPS collar tracks, acoustic recordings, and a slice of the ten-year survey-report archive for the retrieval system. Not pre-processed, not pre-modeled.
CLAUDE.md-- a thin starting context file you take ownership of and grow into the system's working memory
Two senior colleagues are reachable on demand: Dr. Sarah Chen on evaluation architecture and Marcus Webb on production architecture. Neither is assigned any work and neither appears unless you decide a question warrants a specialist -- deciding whether and when to consult them is part of the job.
Everything else -- the scope decision, the architecture decisions and their records, the evaluation design, the components, the retrieval system, the ingestion failure paths, the shared monitoring layer, the AI development infrastructure, the model-strategy document, and the donor-grade handover -- is yours to produce.