Every serious project starts with a language decision, and most teams make it by defaulting to whatever they already know. I am making this one deliberately because the choice has downstream consequences that compound.
What Tessera Needs
Tessera’s core function is extracting decisions from unstructured text, building a graph of relationships between those decisions, and retrieving relevant precedent when new situations arise. That means NLP, graph construction, embedding generation, and eventually local LLM integration for synthesis.
Python wins this decisively. The ecosystem for NLP (spaCy, Hugging Face), graph analysis (NetworkX, PyTorch Geometric), embedding models, and LLM integration (llama-cpp-python, transformers) is unmatched. Every alternative would require building bridges to Python libraries anyway.
The Deeper Reason
Python’s readability matters for a project where I need to audit every processing step. Tessera is handling my most sensitive data, twenty-three years of personal and professional decision-making. Every transformation, every extraction, every inference must be inspectable. Python’s clarity makes the codebase auditable in a way that more performant but more opaque languages do not.
This aligns with the EIAF transparency principles I have been developing. If I am building a governance framework that demands transparency, the tools I build should embody it.
Mitigating the Tradeoffs
Python’s performance limitations are real but manageable for this application. The heavy computation, embedding generation and LLM inference, happens in compiled extensions (llama.cpp, ONNX Runtime). The Python layer orchestrates, validates, and logs. FastAPI provides async capability for the service layer. The bottleneck will never be Python. It will be the model inference, and that runs in C++ regardless of the orchestration language.