I work at the intersection of software security, engineering practice, and organisational knowledge.

My background is in application security and software delivery, but over time my focus has shifted from tools and controls to a harder question:

Who actually understands a system? What risk does that create when they leave, change roles, or stop maintaining it?

Most of my work today sits around Git-based evidence: using real contribution data to understand code health, maintenance risk, developer knowledge, and how organisations actually build and sustain software.

Kospex is a research-driven platform for analysing Git repositories to surface signals about:

• Developer contribution, tenure, and knowledge distribution
• Code maintenance and hotspots
• Key person risk and ownership gaps
• Open source dependency freshness and supply-chain risk

It’s not a dashboard of vanity metrics.
It’s a mechanism to turn version control history into something organisations can reason about,especially in regulated or long-lived environments.

Kospex grew out of consulting work where traditional metrics (DORA, coverage, SBOMs, etc.) were useful but incomplete. The missing layer was always people, knowledge, and time.

Sabbaticas is how I do advisory and consulting work.

It’s deliberately small and focused. I use it for:

• Software security and supply-chain risk analysis
• Git and engineering capability reviews
• Helping teams reason about knowledge loss, maintenance debt, and organisational blind spots
• Translating technical evidence into something execs, legal teams, and engineers can all understand

If Kospex is where ideas get formalised into software, Sabbaticas is where they get tested against real organisations and real constraints.

I usually work with people and organisations when:

• They want a data drive approach to software security and maintenance
• They have lots of Git data, but no shared understanding of what it means
• A system “works”, but no one is confident it’s maintainable
• They have a gut feeling that something is wrong, but can’t put their finger on it
• Key engineers have left (or might), and knowledge risk is invisible
• Security conversations are stuck between theory and checklists
• They want evidence-based insight, not another maturity model

I’m most useful when there’s ambiguity and limited visibility — technical, organisational, or both.

• Evidence over opinion
• Long-term maintainability over short-term optimisation
• Making tacit knowledge visible without oversimplifying it
• Treating software as a socio-technical system, not just code

If you’re trying to understand your software and capabilities, not just measure it, I can help.