I build software where AI, data and financial systems meet.
I’m a software engineer with 10+ years in enterprise systems, backend development and technical leadership. Today I build AI and data tools for financial and regulatory work, drawing on that experience to make complex systems usable.
My earlier work spans mobile and education products, enterprise platforms and development-team leadership. Graduate study in France and Italy brought me further into data science and FinTech; my current projects build on that engineering background.
A reader and search tool for European financial regulation.
DORA Article 28, with a linked provision open. View full size
From source files to a shared runtime
Official material is downloaded and parsed before serving. Structured canonical documents are compiled into a read-only SQLite runtime, so the Reader, search and downstream tools use the same source representation. Publisher notes and editorial annotations stay separate from legal text.
I built the Reader around articles, recitals and references, keeping the official source close to the text. The same canonical data serves the website, REST API, MCP tools and RAG exports.
Reading and search work without a model. You can open a law by article, search definitions, follow explicit references and inspect related measures. Reviewed legal relationships are distinguished from metadata and similarity links.
Multi-turn context and memory
The Reader Copilot keeps a separate conversation for each document. Recent turns travel with the current provision and selected text; threads persist locally in IndexedDB. Switching documents restores the right thread, with cancelled loads prevented from overwriting the new context.
Memory is bounded: up to 20 document threads and 40 messages per thread, with the latest eight turns sent as context. Stored responses are schema-checked before reuse; the conversation stays usable in memory when browser storage is unavailable.
Citation consistency
Evidence follows the Reader’s canonical content order, including nested clauses. That avoids a subtle error: joining a parent paragraph and its children in an order the source never used.
A regulatory question can contain several obligations, exceptions and conditions. My retrieval pipeline separates those claims, finds supporting provisions and checks coverage before composing an answer.
I don’t want the model to sound confident. I want it to show its work.
The planner produces a structured retrieval plan; the engine executes it without model calls. Each claim gets its own allowed evidence IDs. Citation validation and a deterministic coverage guard keep unsupported statements out of the final summary, while leaving partial answers visibly incomplete.
Retrieval and evidence coverage
Keyword and dense retrieval generate candidates. Claim-aware reranking then looks for provisions that can answer the question, while structural expansion recovers parent clauses, list items and relevant cross-references. An isolated sentence can otherwise miss the condition that changes its meaning.
DORA Article 6(5), retrieved in offline extractive mode using the legacy corpus.
Corpus and index integrity
Release manifests record source fingerprints and lock the corpus to its index. The activation pointer is written only after build checks pass; an invalid active release fails closed instead of silently switching to different material.
Evaluation tracks retrieval evidence by claim, separately from the generated answer. That makes a missed provision distinguishable from a generation or citation error.
The standalone engine handles each question independently and is available through Python, CLI and HTTP interfaces. Conversation memory belongs to the Reader Copilot above; business workflow state belongs to the calling application.
Second Line Risk Copilot
A working prototype for DORA access-management reviews. It connects regulatory evidence to obligations, risks and monitoring metrics, then lets a reviewer accept, edit or reject the results.
I keep generated candidates and reviewer changes separate. Each edit belongs to a run and a candidate; the reviewed view combines them without overwriting the original evidence or output.
Orchestration and shared state
A LangGraph workflow coordinates source discovery, retrieval and generation through typed interfaces. Shared schemas carry evidence references across stages, and a final quality gate checks the links between obligations, risks, objectives and metrics.
From generated output to reviewed work
Accept, edit and reject decisions remain attached to the original candidates. Review completion includes warning acknowledgement, and the spreadsheet export carries the human decisions with the results. The interface also identifies live generation, deterministic generation and fixture fallbacks.
The prototype uses a lock-protected in-memory store. Multi-agent coordination and durable case memory are the next development steps; monitoring and follow-up preparation currently run as separate deterministic capabilities.
Enterprise platform engineering across CRM, ERP, supply chain, warehousing and logistics. My work covered architecture, technology selection, engineering practice and delivery coordination.
The platform combined Java microservices, service discovery, caching and messaging with containerised delivery, CI/CD, centralised logs and tracing. My role connected those engineering choices with the development team’s day-to-day delivery.
