Tasman Analytics

The companies that come to us don't struggle with a lack of data — they have too much data anyway — but they struggle with conflicting numbers, unclear ownership, and decisions that stall. It shows up differently everywhere. A strategy nobody is really owning the outcome of (as its not measured). Infrastructure that's grown organically. Dashboards that are built once and then ignored because of that one number no one trusts. Agents running without clear guardrails or context. Every client's version of this looks a bit different, so does our approach. But if we were to name the pillars behind how we build data capabilities for ambitious organisations, it'd be these: 1️⃣ Data strategy and architecture — identifying and delivering the insights that actually change how decisions get made. 2️⃣ Data infrastructure and migration — building reliable architecture and one single source of truth. 3️⃣ Data analytics and reporting — turning raw data into the insights behind every good decision. 4️⃣ Advanced Analytics & AI Applications — and once the foundations hold, embedding AI into analytics workflows so the focus shifts from operations to strategy. We've done this for 70+ teams since 2017. Our success formula is to have three things work together: the right questions, the right architecture, and a team that can run it without us. We're dropping the link to our case studies in the comments so you can see what this approach looks like in practice. And Thomas in't Veld is always up for a chat if you want to talk through how Tasman could help build data capabilities at your organisation.

You cannot buy a context layer. Every vendor selling one is really selling a semantic layer, a catalogue, or a knowledge graph with an agent bolted on top; definitions that typically suit the vendor rather more than it describes reality for you and your data team. The knowledge a context layer actually needs doesn't exist in any product yet. It lives in someone's head, or a Slack thread that's already scrolled away. So — we wrote up a guide to building one :) Three things worth knowing before you start: 👉 Context isn't one thing. We split it into four kinds of knowledge — static warnings, dated events, reasoning, verified answers — and each one has a different home: dbt YAML, a warehouse table, plain markdown files, an eval set. 👉 It's a seven-step build, not a framework to admire. Ship caveats with the model, make events joinable, version your definitions, and four more — each one concrete enough to start this week. 👉 And none of it needs new tooling! Full guide including a fictional company example in the comments.

"𝑀𝑦 𝑙𝑒𝑎𝑑𝑒𝑟𝑠ℎ𝑖𝑝 𝑡𝑜𝑙𝑑 𝑚𝑒 𝑡𝑜 𝑙𝑒𝑎𝑟𝑛 𝐴𝐼 𝑜𝑟 𝑠𝑡𝑎𝑟𝑡 𝑙𝑜𝑜𝑘𝑖𝑛𝑔 𝑓𝑜𝑟 𝑎 𝑛𝑒𝑤 𝑐𝑎𝑟𝑒𝑒𝑟. 𝐵𝑢𝑡 𝑛𝑜𝑏𝑜𝑑𝑦 𝑐𝑎𝑛 𝑡𝑒𝑙𝑙 𝑚𝑒 𝑠𝑝𝑒𝑐𝑖𝑓𝑖𝑐𝑎𝑙𝑙𝑦 𝑤ℎ𝑎𝑡 𝑡ℎ𝑎𝑡 𝑚𝑒𝑎𝑛𝑠 𝑜𝑟 𝑤ℎ𝑎𝑡 𝐼 𝑠ℎ𝑜𝑢𝑙𝑑 𝑎𝑐𝑡𝑢𝑎𝑙𝑙𝑦 𝑙𝑒𝑎𝑟𝑛. 𝐼 𝑔𝑒𝑡 𝑖𝑡’𝑠 𝑖𝑚𝑝𝑜𝑟𝑎𝑡𝑛𝑡 𝑏𝑢𝑡 𝐼 𝑑𝑜𝑛’𝑡 𝑗𝑢𝑠𝑡 𝑤𝑎𝑛𝑡 𝑡𝑜 𝑚𝑎𝑘𝑒 𝑢𝑝 𝑠𝑡𝑢𝑓𝑓." Most data analysts will go through a version of this. The anxiety is real but we are noticing that the guidance usually isn't very useful. So here's a practical frame. "Learn AI" is three different asks dressed as one. Most managers can't tell you which they mean. The first is tool fluency — that means using AI in your daily work. Writing SQL faster, summarising documentation, sense-checking your own analysis. If you're not doing this yet, start here. The time saving is immediate and the learning curve is shallow. The second is evaluation. Can you look at an AI output and know whether to trust it? Can you spot when a model is producing confident nonsense? This is harder, and it's the skill that separates people who use AI from people who are used by it (to borrow a phrase). Blanket distrust is bad, but so is overconfidence in the output. The most effective users will have frameworks that allow them to build self-testing frameworks. The third is building. Data engineering skills combined with knowing how to build pipelines that agents can actually consume. That’s really building for the AI age; and it makes you more of an engineer than an analyst! Pick the one that fits your role. Do that first. The fear that AI will replace data analysts is mostly misdirected — the analysts who'll struggle are the ones waiting for a clear plan before starting. That plan isn't coming.

Over the past couple of years, we've been closely following how SQLMesh develops. We've deployed it across multiple projects, run it through internal hackathons, and accumulated a mountain of Slack threads (more than we're comfortable publicly sharing) — debating where it fits and where it doesn't. Our most recent implementation gave us a particularly instructive set of learnings. It was a project where tight cost control was non-negotiable: our client came to us with what they called a serious case of 'Snowflake bill trauma.' If you know, you know. SQLMesh's virtual environment model made it the right tool for that brief — build the table once in dev, repoint views through CI and prod rather than rebuilding three times. It performed better than we expected in some places, and showed us some edges we hadn't hit before in others. Here's what that looked like in practice: 1️⃣ The CI/CD bot is the best out-of-the-box CI experience we've had in transformation tooling. In dbt, clean CI environments take custom commands, slim CI techniques, some duct tape. SQLMesh gives you this by default. Copy a GitHub Action, run it, done. The diff lands as a PR comment. A virtual environment is waiting for QA. No custom commands. No arguing about which schema is current. 2️⃣ The state database is more powerful than it looks, and more fragile than you'd hope. SQLMesh reads state rather than Git — it knows exactly what's deployed and runs only what needs running. That's elegant. It's also a single point of failure that needs treating like infrastructure. 3️⃣ The AI tooling gap is real and annoying. LLMs have trained heavily on dbt content. SQLMesh's community surface is smaller, which means more hallucinated commands, more deprecated flags. Working with an LLM on SQLMesh problems is a noticeably different experience from working with one on dbt. 4️⃣ One we didn't see coming: virtual environments blur the dev/prod boundary in ways that need careful role management. When your dev table is the physical object production points at, a developer could theoretically break production without touching the production schema. Some say this is only solvable with multiple gateways, but then potential savings in repointing are gone. A strong role-based access hierarchy is key to mitigate this risk. We're excited to keep building our SQLMesh muscle — each implementation sharpens how we think about where it fits and where it doesn't. With the tool's move to the Linux Foundation, the commercial strings are gone, which matters. As good engineering practice, we'll continue to monitor project health closely — active contributions, maintainer activity, community adoption — and factor that into how we recommend it going forward. Where this lands in the transformation landscape will be worth watching. Insights pulled together by Miguel Duarte and Ho Yin Wong from our engineering team. Anyone else running it in production? Curious what you're seeing.

Your AI agent saw the right answer 80% of the time. It still got it wrong. June was the month we worked backwards from the top of the stack. Anthropic ran an experiment on their own analytics team — same model, same data, same questions. Without structured context: 21% accuracy. With it: 95%. We wrote about what that means and how to build it. But before you get there, you need solid foundations. We cover how to get them funded. And whether you or your team are still figuring out which direction to take in AI learning, we mapped out three options forward. One email a month. Business value first. Want in? Subscribe ✅

Most orgs separate the data stack ownership from the product. For really good historical reasons - trust us :) But at this point in time, with most orgs wanting to see rapid AI progress, and with AI sitting on top of both engineering and product, the question is whether this split ownership still makes sense. Who owns the AI stack? What does our data actually need to look like before AI can do anything useful here? Roadmaps get written, tools get bought, and the foundations that would make any of it work stay unbuilt — because nobody is really accountable for them. The fix isn't hiring an expensive CDO. It's designating one person and giving them a real remit — not advisory, not "point person," but actual decision rights. The authority to pause projects that would compromise data quality, and to push back on timelines that skip the foundation work. The part most teams do backwards: they audit the data first, then try to match it to AI use cases. Start with the business question instead. What decision do we want AI to help make? What task do we want it to handle? Then work back to what the data needs to look like. That sequence changes what you actually prioritise. An AI readiness audit isn't an inventory of what you have. It's a gap analysis — specific, use-case by use-case — of what's missing. Most teams are surprised by how achievable the gaps are once they're written down. Who owns AI strategy at your company?

IT'S LONDON CLIMATE ACTION WEEK! For more than two years now we have been supporting The Earthshot Prize with their awards Search & Selection processes. This type of work is super impactful and makes you remember why data analytics matters. Today, they're announcing the collective impact of their finalists at London Climate Action Week — five years of breakthroughs in renewable energy, nature restoration, and waste reduction, live alongside Bloomberg Philanthropies. That's an amazing milestone. Halfway to their super ambitious Earthshot Targets. We're biased (of course). We've been working alongside their team to build the data foundations that power how they find, evaluate, and track climate solutions from around the world. As data experts, we build the dashboards but we don't always get to see the impact they bring. Today's a good reminder. Major kudos to every finalist who made it this far - the impact you made is extraordinary.

If you've ever migrated a data warehouse, you know the drill. There's a reason why migrations take years and leave everyone on the brink of burnout. It's rarely the tooling, and it's rarely the methodology choice. Even before you start, you're already set up for failure. The existing system is full of decisions nobody remembers making — code nobody currently employed wrote, logic nobody has written down. And that's what you're actually migrating. At the last dbt Meetup in Amsterdam, Ricardo Angel Granados López from Xebia walked through how his team moved 2,400 undocumented stored procedures from Data Vault to Kimball in weeks, using AI. The point of the talk wasn't that AI made it fast, though it did. It was the order of operations that made it work. Before any schema, before any model choice, before the first line of new code — they built the conceptual map. This is where we start every engagement at Tasman. Work out what the entities are, how they relate, and what the business actually means by each one. Ricardo's method was to ask the model for a map of reality and its gaps before you ask it for a schema, and make that map reach into where the business is heading, not only the system it is leaving. The conceptual layer isn't a documentation exercise you do once and park somewhere. It's what makes AI output trustworthy rather than just quick. We wrote up the full argument from the meetup — link in the first comment. And if you want to go deeper on how the conceptual layer actually gets built, our domain modelling post is a good place to start — that link's in there too.

And just like that, the Tasman Summer Summit 2026 is a wrap. Four days in Krakow. Work sessions, a town hall, a salt mine, a treasure hunt, and gourmet food with proper Polish beer. The city delivered and so did the team. To be fully honest, four days in, the energy is running on fumes — brains thoroughly overworked and stomachs still recovering from the best roasted duck of our lives. 🍗 This summit was a special one. For the first time, we were joined by three new faces making their Tasman summit debut: Leigh Smit — Data Analyst Lauren Wilson — Delivery Manager Eliza Kozhevnikova — Data Analyst We hope Krakow gave you the full Tasman experience without making you want to hand in your notice!

Hard work and good fun aren't mutually exclusive. At Tasman, especially during summit time, we make a point of both! Thursday kicked off with morning breakout sessions where we got to work in small groups shaping real projects that will be the ignition sparks for the next point of growth for Tasman this year. Then we swapped the laptops for a map and headed into the Old Town. A good old treasure hunt has become something of a Tasman summit tradition at this point. Every city we visit, the treasure hunt comes with it. In Krakow, that meant racing through medieval streets, map in hand, with far too much conviction about clues we'd for sure misread. Treasure hunts definitely bring out a side of the team that the work sessions don't. Turns out everyone at Tasman is deeply, unapologetically competitive. The same people who spent the morning solving real business problems spent the afternoon proving who's better at solving clues. And we wouldn't have it any other way.