I work on enterprise AI adoption and governance: moving AI from pilots to governed, measurable services in large organisations. These repositories show how I approach it in practice: a framework that makes AI services consistent, and the working systems it is built from. Small, tested, auditable, explicit about what they measure and what they cost, and able to run entirely on open-weight models on an organisation's own infrastructure.
- See a governed agent run end to end. The platform's screenshots: an agent's email waiting for a person, the audit trail with every policy decision and its cost, and one OpenTelemetry trace across the agents, the LLM gateway and the MCP server.
- Check that it is tested, not described. Every repository's CI badge is green; the platform's CI starts the whole stack and walks a run through a human approval, and a Kubernetes workflow deploys it to a cluster and checks that the network policies block what they should.
- See the numbers. Measured results with a local open-weight model next to Claude, recorded and replayed in CI.
- See how a new project starts. The framework's use-case intake and service template: a proposal scored on sensitivity, cost and risk, then a service generated local-first with its evaluation already wired in.
- See a negative result. The gateway's judged router lost to plain rules, and the README says so, with the recording CI replays.
ai-engineering-framework: how an
organisation identifies, builds, industrialises and operates AI solutions the same way every
time. A reference architecture with on-premises, hybrid and cloud topologies; seven solution
patterns, each with a working reference implementation below; engineering standards that run as
checks in CI (aief check); a use-case intake that scores proposals on feasibility, information
sensitivity, security, cost, scalability, interoperability and sustainability and recommends a
pattern and topology (aief intake); lifecycle gates and a handover pack; and a service
template that starts every new project local-first, evaluated and production-ready.
| Stage | Repository | What it shows |
|---|---|---|
| Identify | governed-agents (use-case triage desk) | Agents that register a proposed AI use case, assess risk and cost, choose a pattern and submit a decision record for sign-off |
| Build | policy-evidence-mcp | An MCP server giving assistants cited access to official statistics (SDMX) and policy documents: hybrid RAG with a sensitivity ceiling, per-caller access from bearer tokens or Entra ID app roles, SharePoint libraries synced through Microsoft Graph with Purview labels as the classification, served to Microsoft 365 Copilot through Copilot Studio within each user's roles, retrieval evaluation as a CI gate |
| reference-resolver-agent | Deterministic scoring first; the model chooses only among records actually retrieved; a bounded search agent; uncertain cases to a human review queue; measured on a gold set | |
| oecd-data-pipeline | Python computes every figure, a model (Microsoft 365 Copilot or a local open-weight model) writes only the wording, and a validator rejects any note with a number not in the data | |
| copilot-team-knowledge | A verified knowledge layer that Microsoft 365 Copilot answers from: only active cards at or below a classification ceiling are published, to SharePoint through Microsoft Graph; also answerable by a local model | |
| Industrialise | governed-llm-gateway | One door to every model: routes each request to the cheapest adequate model (Claude, Azure OpenAI with Entra ID, or local), masks personal data, enforces budgets, chargeback without storing content, OpenTelemetry traces |
| governed-agents | Multi-agent runtime where a policy engine decides every tool call: least privilege, autonomy levels, four-eyes approval for external actions, audit trail, kill switch, trajectory evaluation with a planted prompt injection, one OpenTelemetry trace per run | |
| Operate | governed-ai-platform | The components as one operable service, on Docker Compose, Kubernetes (restricted pod security, default-deny network policies) or Azure Container Apps in Bicep (Key Vault, managed identity, Azure OpenAI with no key): Prometheus alerts, one trace per agent run across the services, pinned versions, runbook, an end-to-end test in CI, and a sovereign mode in which no external model exists |
Every system runs without a commercial API: Ollama on a laptop, or any OpenAI-compatible server (vLLM on a GPU server, for example), with commercial models as a governed choice through the gateway. Measured with two open-weight models, Llama 3.1 8B and Qwen 2.5 7B, on a laptop CPU, answers recorded and replayed in CI: both matched Claude on the resolver (precision and recall 1.00) at zero cost; both passed 10 of 10 cases on a service generated from the framework, including one where the model followed a planted instruction and the validator withheld the answer; with each reply constrained to their own tools, both completed all five multi-agent cases through human approvals with every safety check held. Neither was better everywhere, which is why each service is measured on its own cases. Each model also exposed something scripted tests had not (integration bugs, a flaw in a safety metric, a false link, an agent reporting work it had not done), now fixed and tested (details).
Where software needs a decision rather than a paragraph (pick a candidate, grade a passage, route a request), the model answers from a closed set, anything else counts as no decision, and code corroborates the answer before it acts. Measured on open-weight models on a laptop CPU:
| Where | Result | What decided it |
|---|---|---|
| Reference resolver: choose among retrieved records | Precision 1.00 with Claude, Llama 3.1 8B and Qwen 2.5 7B | Qwen's wrong choices came with confidence 0.95 and 0.80; code-side checks sent both to a person |
| Evidence server: rerank passages | hit@3 0.90 to 0.95 on 40 paraphrased questions, no leak | Most replies for 20 passages were incomplete and became "no decision"; on the first 13 questions the gain had looked twice as large |
| Gateway: judge request difficulty | 14/24 against the rules' 22/24; stays off | The judge called almost everything simple, with confidence 0.9 to 1.0 |
The common lesson, written into the framework's pattern P7: a model's stated confidence carried no information; the closed answer set and checks in code did the work.
Four MVPs built the way I would run a product with a team: discovery with falsifiable hypotheses, a PRD with non-goals, explicit prioritisation (RICE or WSJF) with the cut line, a pilot whose decision rules are fixed before launch, and a team pack (brief, RACI, backlog, iteration plan, working agreement) in which CI fails if a story marked Done has no test proving it. Each README opens with a ten-minute reading path through the product case.
| Repository | The product | Worth a look |
|---|---|---|
| ai-adoption-tracker | Evidence for an AI review committee: which pilots to scale, iterate or stop, with every check's value and threshold; the tool recommends, the committee decides | The PRD, the decision log, how overrides are flagged |
| obligations-register | A draft obligations register from contracts and policies: every line the exact sentence with its location; a model may only add whole sentences that exist in the source | The held-out result (deadline accuracy 0.64) and why it was not patched |
| feedback-to-roadmap | Continuous discovery for an internal AI assistant: feedback from four channels counted in people, not rows, with verbatim quotes, silent segments and spikes; RICE changes proposed with their rules; the product owner accepts, rejects or pins, each with a note | The worked example where evidence overturns the sponsor's priority, the decision log, the held-out result (precision 0.69, recall 0.24) and what it changed |
| agentic-procurement-intake | A corporate process redesigned AI-first: an agent turns a staff purchase request into a package procurement can approve on first review (method with its rule, framework reuse, split-purchase check, draft TOR); people confirm, approve and sign off, enforced in code | The service blueprint with autonomy levels per step, the build, buy, reuse or stop case, the WSJF roadmap |
The four are linked: the tracker decides which assistants scale, iterate or stop; feedback-to-roadmap plans the iterate cycle for one of them, from the same users; and the register, the intake desk and the feedback tool log their own usage in the tracker's event format, so their scale-or-stop reviews rest on evidence.
- Deterministic where possible, models where they add value, people where it matters
- Guardrails enforced in code, not only in prompts
- Every system ships with an evaluation, a cost figure and a way to run it locally
- Standards that run: each repository is checked against the framework's standards in CI
- Losses are published like wins: a model step that does not beat the baseline stays off
- Ready for coding agents: every repository has an
AGENTS.mdwith its commands and the invariants nobody may weaken, and the tool servers ship skills for assistants
The design decisions behind each project are documented in its docs/ folder.
Python · MCP · RAG · AI agents · FastAPI · pandas · SDMX · Claude API · Azure OpenAI · Microsoft 365 Copilot · SharePoint · Ollama · open-weight models · Microsoft Graph · Entra ID · Copilot Studio · Azure Container Apps · Bicep · Docker Compose · Kubernetes · Prometheus · OpenTelemetry · GitHub Actions · Copier
Paris · English, Italian, Spanish, French (working knowledge)