DATA INFINANCE.

A personal build to answer the question I kept running into: how much of my return is actually being paid for by risk, and where is that risk coming from?

Two teams, shared checkpoints. The cockpit now connects to a separate agentic framework with two very different AI teams. They review each other’s work at defined checkpoints through the process, and help take the cockpit platform itself further. The quantitative toolkit remains the foundation; the agentic framework adds another way to work with and improve it.

Risk decomposition. Portfolio volatility broken down per position via Euler risk contribution, alongside beta, 1-day VaR/CVaR in euros, the correlation matrix, a diversification ratio, concentration and currency exposure. Positions held through funds are looked through to their underlying sector weights, so exposure is measured on what you actually own rather than on the wrapper.

Scenario and sensitivity modelling. Hypothetical market, rate, currency and sector shocks applied to current weights — market moves through each position’s own estimated beta, rate sensitivity fitted empirically against the US 10-year (FRED), sector shocks ceteris paribus via each holding’s beta to its sector ETF. Plus historical stress tests replaying 2008, COVID and 2022.

Factor screening and ranking. Quant factor and fundamental models rank a universe of ~13,600 listed equities and ETFs, with hierarchical risk parity (HRP) available for allocation. Candidates carry through to deeper single-name analysis and a like-for-like comparison against sector and regional peers.

Performance measurement. A FIFO transaction ledger is the source of truth, from which true time-weighted return is computed and benchmarked against the S&P 500 in EUR — separating what the portfolio earned from what contributions merely added. Sharpe and Sortino are shown against a live risk-free rate.

ESG (Sustainalytics ratings, SFDR article 6/8/9) is carried as a deliberately informative-only layer: visible on every report, never folded into a score.

Stack: Python for the analytics; FRED and market-data feeds; a local web app for the workflow.

Elsewhere brings our holiday plans together in one place: a day-by-day itinerary, a map, bookings, preparation checklists and the decisions still to make.

A plan with room to wander. Expand a day for its activities, see the stops on the map and adjust the itinerary as the trip takes shape. Download the next few days to keep the plan close when connectivity is limited.

AI-assisted planning, with a human decision. Planning skills in the private repository guide the AI through our preferences and existing commitments. Proposed changes are reviewed and approved before they update the shared plan.

Bring people along. Invited friends can sign in to follow the complete itinerary in a read-only view. A separate journal shares the stories we choose to publish, while booking details and private planning notes stay private.

House hunting around Antwerp taught me that it is easy to see what is on the market today, and almost impossible to see what any particular house has done over time. So this keeps a running record and does the analysis on top of it.

Same-property matching. The same house reappears over the years under different descriptions, agencies and asking prices. Records are normalised and matched so that one house is one row — which is what makes a history meaningful rather than double-counted.

The history a snapshot can’t show. Because nothing is discarded, it can answer questions a single moment in time can’t: how many separate times a property has been on the market, what it asked on each attempt, and how long it has been sitting — both now and in total. A house on its fourth attempt at a falling price is a very different proposition from a fresh one.

Cost of ownership, not asking price. Each entry carries the real cost of buying — registration duty, notary fees, VAT, disbursements — plus the cost of keeping it: annual heating in kWh and euros derived from the EPC label, rolled into a ten-year figure. Two houses at the same asking price are rarely the same purchase.

Valuation and screening. A comparables-based estimate and an indicative renovation cost sit alongside €/m², EPC label and build year. Saved preference profiles are matched against anything new, with a message the moment something fits — and a dashboard with list and map views for exploring the whole dataset.

Stack: TypeScript across a Node service and web front end, with a local store for the time series.

The project where my day job (data & AI) meets my sport (triathlon). It syncs data from Garmin Connect, Apple Health and Strava, tracks recovery (HRV, resting HR, sleep), and every morning regenerates a training plan that adapts to how you actually slept, recovered, trained and lived — while always steering toward the races you’ve put on the calendar.

The one-paragraph pitch: TrainingPeaks tells you what your coach planned weeks ago; intervals.icu has brilliant analytics but doesn’t plan for you; Garmin’s suggestions adapt but ignore your race calendar and life constraints. This app closes the loop — plan ↔ execution ↔ recovery ↔ replan, every morning, on your own machine, with your own data, for triathlon specifically (swim + bike + run + strength as one interacting system).

It also handles structured workouts and fuelling, FIT export, a compliance tracker, health/sport dashboards from Garmin effort curves, an injury/niggle log with a staged return-to-training, and pre-race briefings with carbohydrate guidance. Stack: local FastAPI + SQLite, Python analytics, JS/HTML front end.

A hot day, no bottle, and no easy way to tell whether the nearest option is a free tap, a vending machine, or a shop that closes at noon on a Sunday. So this combines four things no single map puts together: free drinking water, drink vending machines, shops, and the fuel stations that actually have one — pulled from OpenStreetMap and kept current automatically.

Open now, not just nearby. Every shop and machine is evaluated against its real opening hours — including Sundays and Belgian public holidays — so the map answers “is this actually open right now,” not just “is there a dot here.”

A heuristic worth being proud of. Only about 1% of fuel stations in OpenStreetMap are tagged with whether they have a shop. Rather than showing thousands of unreliable pins, a station only appears if it has an explicit shop tag, or has posted opening hours and isn’t flagged as unmanned or a self-service sub-brand — cutting ~3,000 raw fuel points down to the ~320 that plausibly sell a drink, with a report button for anything wrong.

Community input that upgrades the real map. Anyone can suggest a new spot or report a problem; submissions stay an unverified pin until reviewed. Approving one is one click to open OpenStreetMap’s own editor at that exact location — so a verified addition goes upstream into OpenStreetMap itself, where every map built on that data benefits, not just this one.

Built to stay current with no server to babysit. The whole map is one self-contained static page with ~9,500 points embedded and clustered for performance; a small Python script refreshes it from OpenStreetMap’s Overpass API every day via GitHub Actions, no manual maintenance required.

Stack: Leaflet for the map, Cloudflare Pages Functions and D1 for community suggestions, Python for the daily data refresh.

Projects are easy to start and harder to keep track of. Project Radar gives repositories, local services and deployed websites a shared overview, with the last commit and the latest check beside each project.

Checks with context. Scheduled availability and content checks retry before recording a failure. Incident and recovery history help distinguish an outage from an old result. Local service checks run on the Mac, while public websites can be checked from the hosted dashboard.

A record of reviews. Manual AI reviews carry a date, notes and the commit that was reviewed, so later code changes are visible without suggesting that a successful HTTP response means the whole application has been tested.

A private overview. The local dashboard keeps repository details together; the hosted version receives a scoped metadata sync. The public portfolio shows the project, while its inventory remains private.