Watch now | Recording of AURA - Anna Bergevin & Shane Gibson 21st August 2026

Hey, Anna, welcome to, uh, I think this is our second Aura session. Um, what's it been, a month? Bloody hell, doesn't that fly fast?

Yeah, it's been a busy month too, at least on my end.

Yeah, what's been top of mind for you over the last month?

You know, we just had, um, at the hospital our first, like, uh, new, a new style of quarterly planning. Which hit the technical teams especially hard, I would say, because the hospital views the internal technical teams, like the data team, as shared services, right, of like limited capacity to allocate. And so, it was really interesting to, you know, coming from a tech background to a hospital that's like going through tech transformation and trying to be agile and do things this way, but also everybody wants to know what they can count on. And everybody— both wants more data than they can have and also doesn't know about all their opportunities with data, right? And so, it's like this weird give and take. And so, anyway, we're coming out of that. So, for better or for worse, we made it through. And I think it was a very useful exercise. I'm excited for next quarter. But it was like, all right, teaching my team and the rest of the team, all right, what do these commitments mean now? And What are we continuing? What are we starting? What are we stopping? Um, so just, it was just a really interesting month, very, very busy. Um, and I'm just learning a lot about hospitals. It's my first time working in a hospital, been here almost a year, and I'm still just like such a newbie with, uh, hospital data. It's so different.

Have you, uh, defined what a bed is yet?

Uh, no, I, I, um, no. Uh, we have been working very hard on defining the difference between visits and encounters. Which sounds like the same thing, but imagine the difference between you show up at the emergency department and they choose to admit you. So you have your emergency department engagement and then you have your inpatient admission. Those happen on the same day. Which one of those is a visit? Which one of those is an encounter? And then what if you have a chronic ongoing condition? And so there's a series of visits and encounters that are interrelated even though they're on different days.

And somehow relate to an admission or not an admission.

Yes. So anyway, um, that's been a— the hospital just switched electronic health record systems, which is extremely disruptive. And so the way the old health system drew this line or connection in the data and the way the new one does are slightly different. And so it's been a very like— everyone's like, wait, are visit numbers up? Are they down? Are encounters up? Are they down? And we're like, um, let's first talk about what we mean. So that it's been a lot of stuff that I know you've been talking a lot about too, which is conceptual modeling and meaning and governance, and then how are we gonna connect that to the data stack? And how are we gonna do this at scale? Not just for 2 of the most important terms, but ongoing.

Yeah, yeah, because Juha and I are writing a book. So, actually spent quite a bit of time on it this week, or a bit of time on it anyway, which is good. And he's doing a lot more work and research around conceptual models or concept models and ontologies, taxonomies, those like, And so, we're gonna talk about that actually at Helsinki Data Week. Whereas I've kind of been focusing more on the scaling bits, 'cause that's kind of what excites me. So, yeah, this idea of words, right? They're really important. So, I could think about, I had a visit with an admission, and with is the wrong word, right? Again, I should have listened more in English when I was at school. So, my verbs and my nouns still aren't... well-formed. And I could think about I had an engagement with an admission, or I could think about I had a visit admission, or a visit engagement, or an engagement visit, or an admission visit. Like, how do you set the frame— not the framework, but the pattern of the language really, really early about nouns and verbs and— Do they, you know, I talk about customer, active customer, marketing, not active marketing customer, right? So I kind of, I set the pattern of the language that I want to use so that I can always look and go, where does it live? But this week I've been working on one which was payment arrangement, payment arrangement installments. And then I found I did decline payment, banked payment. And I'm like, oh, hold on, I've just moved the words. to the left and the right, and I've broken my pattern. It sounded better, but I think I'm gonna have a problem. So how about you? Do you like— because you're at the beginning of that, like—

Oh, I think that, um, I don't know, we're still figuring this out. What I'm more worried about is, yeah, teaching my PMs how to do that, my product managers. And, um, they are new My product managers, they come from different backgrounds. One is a former data scientist, very strong in measurement. One is a former software PM coming into data PM, and one is more of an analyst converted into a PM. So, they have very different strengths and gaps. And so, it's like, how do I teach them what conceptual modeling is, what taxonomy and ontology are? How do I teach them why meaning is important and why the investment in meaning is different today than it was 3 years ago, right? We've been talking about this for a very long time about semantic layers and keeping metrics aligned. And that was like, you know, a third of what now is the problem. That's still a really important problem because we waste a lot of hours in organizations arguing about things that we end up going, oh, we actually meant 2 different things, or, oh, we were actually talking about the same thing. And so, So that's why the numbers were different or did match. And now it's like, well, what does it mean to govern meaning as an organization? And what does it mean to govern knowledge as an organization? I think knowledge management and master data management was always this, like, side office governance nerdy thing that it's, like, hard to get traction on, sat over here. But when I come and talk to people about it, saying, If we want agents to help us, we have to give them governed knowledge to tap into that's like, this is authoritative, and you can trust this, and then the agents can act for us. That feels much more modern and exciting, and much less this dry governancy thing. So, I'm trying to get my product managers to have this aha moment and to see how all this is connected. Because essentially, they need to go sell the rest of the organization on it. Because sometimes, when you're trying to get them— stakeholders to engage or care about these things, They don't really— they're like, I'm busy, why are we talking about this? Or can we just jump to the calculation? You're like, no, we can't jump to the calculation, we need to talk about the concept for a minute. And but when you explain it, people are like, oh, I get it. And then when I tell them— the other thing I have to teach them is like, we're building a system that will hold this knowledge in context and bring it back to us. Meaning I'm not going to come back to you in a year and be like, let's talk again about what we mean by visits and what we mean by encounters. Like, once that's decided and we spent Many, many hours with a lot of very expensive people in the hospital who all care a lot about how these things are defined because it affects finance, it affects operations, it affects clinicians. So once we define that, I'm helping them have confidence in me as a platform person. Like, I'm creating a system to contain this, to retrieve it, to remind us about it across all contexts. I'm not going to make you do this again. And once it feels like that foundational investment is like gonna pay off, people are really bought in. And so, I can sell that, but I'm not in every meeting. So, I need all of my PMs to become really good at selling the journey and the mission and why are we doing this. And at ResMed, when we did this, I don't even like calling it a data catalog, because that's where we're storing this meaning for now. That's where definition lives. I call the catalog, like, the source system of meaning or the source system of definition. In the maturity of the organizations I work in are at. It'd be nice if I worked at Amazon, we had a whole taxonomy ontology team, but that is not really in budget. And so, it's like, we're going to create this one place where knowledge and meaning can be governed. And someday, I hope we mature, and we're able to hire that ontologist to come help us take our quite structured, but not formally structured knowledge, and help us clean it up. So, anyway, that's what I'm focused on right now is selling the story, selling the systems, trying to create the structure so that we can execute along those rails, if that makes sense.

Yeah. Hey, so much to unpack there. Let me pull a couple of threads. As you're talking, I kind of went back on my thoughts, right? So, we went, oh, the structure of the language, you've got 3 PMs. Thank you for saying product managers, because again, could have been project managers. And hey, Joe, good to see you, man. And hello, System Decoder. whoever you are. And so, like, my natural reaction is I want this pattern of language, right? So I want payment arrangement installment, which means therefore I want payment banked, payment declined, right? Because I'm gonna, as a human, I'm gonna look at it and I've got this structure that I'm looking for. And the least words I have, the more dangerous I know that word is, right? So when I have payment and I know that there's other states, I know that actually payment is a really difficult word. When you say to me, how many payments were there? We're like, Was that payment attempts? Was that payment collected? But what I haven't tested is if I put the variations into an LLM without following my— once by following my structured path, and then a second time by giving it the one where it goes bank payment, collected payment, payment attempt. Does it care, right? Like, does it care as much as I do? Or does it just go, oh, it knows how to work that shit out because it's a language model and I'm not. I'm an I'm gonna go try that.

I think it's interesting. I was listening to an amazing podcast that I cannot stop telling everyone about that I listened to recently, which lots of podcasts you listen and you forget. This podcast, I cannot stop thinking about, which was on Lenny Rachitsky's podcast, the top product podcaster, top newsletter on Substack. And Lenny interviewed Simon, I cannot remember his last name, this developer about AI and AI agentic development. He was talking about how he provides context and how a lot of people do these, like, extremely involved harnesses and context structures and Cloud Markdown files. And he talked about how little he needs to give it to write code the way he wants to. He's like, I give it this very brief context. I can't remember if he said it was a file or a pre-prompt, however he provides it. And it's things like, here's a test. That's how I like my tests written. Over and out. And so I kind of wonder how much language structure we have to give an LLM to be like, you have all your language training, but here our language means this, or I think about language in this format. And if you had enough of— if you're talking about becoming thoughtful about patterns in language and the specific patterns you're building, I wonder what the critical mass is of that pattern before the LLM picks up on the pattern you're creating.

Oh, and what happens when you give it a separate pattern? So, one of the things, so we kind of talked online a little bit about this idea and this thing that I've had, which is what kind of personality style you are and when you work with your GenAI LLMs. And you talked about your husband being very engineering-focused, right? So, very spec-driven. And then I think you mentioned that you are product PRD, product requirements document-driven, right? Which is a form of a spec, but different language in my head. And I'm not, right? I'm like the worst vibe coder everywhere. I'll just give it, I'll give it a sentence of intent with bad spelling. I used to type it, stop and spell it, go back and edit it. I don't even bother doing that now. And then, but then the downside is I often get something that I didn't want, right? And so I pay for it at the end and I'm okay with that, like, because I'm looking at it an intent point of view, and then I'm going back and saying, change it, change it. And I'm willing to do those reps at the end rather than the beginning. But we were doing some work with a customer, and what I found, so, with our information product builders, so, building the last mile part on top of the data. And what I found in the past is I'd kind of have a conversation, do the canvas, because I use the information product canvas to start every build cycle. But then we get into the next level of detail. And so, I'd talk to them, would show them some prototypes, they'd play with it, they'd talk me through, I'd have a Granola recording going from a transcript, and then I'd kind of get it to summarize it, and then I'd go back into the GenAI tooling, and then I'd kind of create an abstraction of what we talked about.

Yeah, yeah.

And I found that was a problem, right? Where I found better success is to take the transcript of that person's words, or another customer we're working with, they tend to email me their thoughts, and I now just cut and paste that, and I put that into the GenAI tooling, and I've got a harness behind it to make sure it kind of is building what I want, and I just let it go. And I found that me not extracting between their language to my language to that has given me a much better outcome. I'm getting stuff, better stuff built by the tooling than if I'm in the middle kind of going French to German to English, right? And my German being incredibly bad.

That's such a good point. You know, we did something interesting, a test I ran this, I don't know, about 3 to 6 months ago with one of my product managers. She's more junior, new to conceptual modeling, new to product discovery. And so, I'm coaching and mentoring her. And we're meeting with our philanthropy group who needs to raise, you know, like a billion dollars for a new tower building at the children's hospital. Great worthy mission. We need to give them data so they understand how their campaigns are going, how their donations are going, who to reach out to, who not to reach out to, things like that. And there is so much deep context we have to understand about the difference between a donor and a constituent and the funnels and the journeys and what they mean. And so it was really fun because what we did is we sat down, we had the first We kind of figured out enough to know, okay, we're gonna have 6 workshops and each is gonna be about this different part of the conceptual model, if you will. And we just interviewed them, let Copilot run with the transcript and recording. And so we kind of took notes that would be like, hold up, so we could go, what's the definition on this one? Or what did you mean? Or tell me more about that. Okay, so actually there's 2 subcomponents. So we're doing the discovery and guiding them through it. And then, we take that scrappy, messy note because you're talking at the same time you're taking notes and the transcript and say to Copilot, like, clean this up. And so, Copilot would do kind of, you know, a wiki or a write-up about that topic and tables and definitions. Then, we send that write-up to the stakeholders before the next workshop and say, tell us where we are wrong. And that reflecting back to the person, you told me this, this is what I heard, did I hear right? Not only can they catch errors, but then they go, Oh, yeah, but also, I forgot to tell you about this edge case, or there's also this. And so, we did this through, like, you know, I think it was, like, 6 workshops, and we covered all this ground. And now we have this rich context we're able to hand to our data modelers and be like, here's their CRM, there's going to be other source systems, have at it. And then it's like, okay, but now we don't want to lose those, those 6 artifacts that are wiki articles, they're rich context. Where do those live? For a year from now, me, two years from now, me. It's like the context behind the model that ends up getting built, and then so and then we need to pull out of it, you know, into the graph and into the structure the actual terms and definitions. So it's like we have the article, then we need to extract the structured part that can come out of the article. Then the data model will come back, and then how are we going to link those things together? So you can see the lineage of how the discovery led to the definition, which led to the model, which led to the output, the visualizations you're looking at, and that lineage of meaning. How are we gonna create that? So the workshop went well. The LLM helped us with that part. And now we have these artifacts and it's like, okay, how are we gonna extract from there to structure?

It's easy. You just have a second brain, right? That's what it already says. You put it into Obsidian. There's all these throwaway lines on LinkedIn and everywhere else with like second brain, Obsidian, and no detail, right? It's like—

I'm like, tell me about your second brain. Tell me about your architecture. Give me a diagram.

Yeah, yeah, yeah. And then tell me how you actually get it to link and then you test it.

Exactly.

So, what's interesting is, as we're working on the book, me and Juha, we kind of worked out that we do the same things, but we do them completely differently. We kind of follow the same steps, but we follow them in different ways and sometimes in different orders. And what we worked out is what neither of us do is actually record the transcript, right? We were always listening, Back in the days before LLMs, at least, we were listening and we were distilling and then we were modeling and documenting, right? So we, again, we were being the French to German to English on the fly and we never had the French. And then I found that even with things like Granola and those recording tools, I was still doing exactly what you just were doing is I take the transcript and then I'd summarize it and the summary became the record of of the system of record, right? But then what I found, like, when we're doing this workshop the other day around payment arrangements, we went all over the place, right? So, we went and talked about payment arrangements, and I got the transcript where they're describing the flow and the state change and all the definitions, because that's what I needed. But we started talking about a whole lot of other stuff, because they went off on tangents, because they did the happy path, and then they went down all the edge cases, right? The ones that make People, the subject matter experts laugh. Hahaha, you thought that was easy? Well, let me tell you about.

Exactly.

And what I found is that when I summarized it, I summarized it with the context of payment arrangement, the payment flow. But actually what I've got now is this rich vein of context that I can go back and say, oh, what do we say about delinquency? Because there were a whole lot of delinquency statuses that I didn't wanna drill down into in that conversation because my scope was payment, right? That's what I had to get through. But now I've got this rich vein. And so, yeah, I wonder if you stored the transcripts, right? If they're the raw ingredients now for context that we can mine time and time again, depending on the scope or the conversation around the context we want to have. That's kind of where my brain's at at the moment.

It's very interesting. There was, let's see, recently an amazing, amazing article by Irina was at Salesforce, left recently, data product person. I'll look up her last name, can't remember right now. But anyway, she was talking about context is like a search retrieval problem. It's not like a— how can you— you can't load all the context all the time. So like, how are you going to find the relevant context? So let's say you even store the transcripts. How are you going to— how are you going to— you don't want to have to scan, you know, 5 years of transcripts and be like, oh, all of these have a keyword that's relevant. Like, that feels like very slow and heavy. Like, so are you going to extract some metadata and attach the metadata to the transcript so it's easy to find transcripts that discussed delinquency? Or are you going to have to process the raw transcripts at every time? And then we have a problem like, at the hospital, we're using Copilot. And I was so mad when I discovered this the other day. You record the meeting, and then you do things with that context in short order, let's just say in the first week after you have that meeting. And then eventually, it might come up, didn't we have a meeting 2 weeks ago about this? And so it goes and looks up the transcript. Well, Well, the organizational retention policies are 60 days.

Oh.

And so I was like, oh, well, maybe they just delete the video because the video is super expensive. And I go and do this research spike and find out, no, Microsoft treats the video and the transcript as one entity and treats them both together. And there's no way to toggle it at the admin level to be like, keep that cheap transcript, delete the video, but keep the transcript. I'm like, what the world, Microsoft? Like, just let us keep the transcript. You took the time to transcribe it. The compute's already gone in. It's a lightweight text file. And so it's basically like, well, you can do a workaround where you basically copy the transcript somewhere else for storage. And I haven't talked to IT about this yet because we're just teaching people what LLMs are and how to use Copilot. We're like not ready to build like a system of retention yet. But I'm like, I'm feeling the same thing of like, I don't want to lose those transcripts. But also, how am I going to retrieve them? How am I going to make it easy to find them? They're only going to be timestamped with like a date and the name of the meeting. Like, that's not a lot of metadata.

So, I wanna talk about that cost thing, right? So, the interesting thing is you talked about how expensive it was to run the workshops, to gather the context, the subject matter expertise out of people's heads, because you've got highly paid practitioners that are surgeons, I'm guessing, right? Like, people doing really, really expensive work. And so, we kind of look at the cost to store something from an IT point of view, you go, oh, you know, that's really expensive. But actually, compared to the cost of gathering it, right, the cost of people in the room, It's like, and we're not going to get them in the room again, right? We can't go back and say, oh, we didn't quite really define what a visit was versus an engagement. Would you mind spending another 4 hours with us to do that? They're like, hell no, right?

Yes.

There's lots of techniques around RAG and indexing because, you know, effectively it's the same problem Google had when they're indexing the world and books for the LLMs. But the other thing is that in the beginning, we had a really small context window in all the gen AI LLM tools. And we used to really do have to do a whole lot of bending over backwards to try and get what we needed into that context window. And then we got, you know, a million to 2 million character context windows, knowing that we now know that actually only 30 to 40% of that is actually actively used. And then it's summarizing it anyway. So I think— I think it might get solved in the future, and I think we have some tools to do it, but I come back to the raw ingredients, right? The thing that is the highest level of scarcity, therefore the highest level of value, is those transcripts. I mean, the videos would be good because you can see where people are frowning. Like, oh, they said that that's what engagement is, but 9 people in the meeting started frowning and they had the worry lines. I'm not sure it is. That's a high-risk. Concept. But yeah, I don't know. And see, again, I don't work in the constraints of a large corporate, right? I don't, and IT infrastructure. So I go, I can store that because it's really valuable for me. So I'm going to, whereas I suppose you have these enterprise constraints, which are, you have to justify why to store it.

Yeah. Well, and then, you know, your lawyers get nervous.

Yeah.

Keeping actual transcripts for too long and cybersecurity gets nervous. Everybody gets nervous in a big corporate. And those are problems to solve. I'm less worried. I'm more worried about changing the mindset in the organization around, like, how do we work in ways that creates observable artifacts? Like, we're recording this meeting, like, creating that as a norm of, like, I'm creating this, I'm recording this for note-taking. Not everyone even has Copilot at the hospital. You know, it started with a rollout of, I don't know, 1,000 licenses. Obviously, like, our nurses don't need Copilot. They are, uh, they're not even at a computer. They're at bedside. They're— and they're using LLM tools that are built into the EHR that are really grounded in the EHR. And the EHR has its own semantic models and things going on. So it's really just the office workers. So I'll bring them along, but it's— they are not even aware of all this, Shane. It's the other thing of like, I have to like teach everyone about like, you know, Copilot can help with this. Or I'll tell people how I do a lot of being like, people are like, wow, you got that done really fast. I'm like, yeah, Copilot and I got that done. Like, I'm very like, I'm doing that not like I feel like I need to be transparent about when I use AI because it's my, it's my work product. I stand behind it whether an LLM was involved or not. I don't send work product. I don't just run it through Copilot and send it out without reading it. Like, that's so rude. People should not do that. That's a soapbox of mine. But it's more I want people to understand, like, the ways Copilot can be helpful. Even though Copilot is not the coolest tool, you're not hearing about it in the news. They're all hearing about Claude. Like, we don't have Claude. I'm like, yeah, but we have Copilot, which is like, it's like a 70% Claude. It's good enough, you guys. It can do— we're getting picky at this point. It's like splitting hairs at this point. We didn't have any of this 3 years ago.

So— We gotta remember that Microsoft invented Clippy, right? Which was actually the right idea at the wrong time with the wrong technology, right? And actually, A lot of people are jumping to ChatGPT in Seoul now because the last couple of weeks Claude's lost its shit. Yeah, I keep hearing that. They've done something and it ain't the Claude we had a couple of weeks ago. I mean, hopefully it'll come back, but I've even, you know, I've downgraded from Opus 5 to Opus 4.8 at the moment because it's the only way I can get the consistency that I had a week or two ago. And I have no control over that. Like, yeah, you look at it and you go, is it my prompts? Is it my harness? Is it my context? And I'm going, I'm not sure I changed any of those markedly. So how do I know if it's me or if it's it? That's, that's a bit annoying.

We have this testing we have to do because we kind of have this unpredictability in the systems we're building now. And so it's like an upgrade might not actually be an upgrade for your specific process. And how long are they going to support the model you're on? At some point, they're going to deprecate that model. You have to upgrade. That's a really interesting new problem. You're like, I built this cool thing that works, but, like, don't auto-upgrade it because there's a whole set of testing and it's not normal integration testing. It's a whole different wildcard where everything can break in really weird ways. I built a gardening app that is, you know, I live in Salt Lake and we're in a drought. And I flipped, got rid of all of my grass, which takes, you know, a lot of water in the desert. And it's like 90% less water, but it looks like an English cottage garden. It does not look like cactus. And I want people— I'm very passionate about being like, your yard does not have to be rocks and cactus to be water-wise. Like, this is like a side thing outside of data. Of course, I built a data-powered app to help people do this without needing to be expert gardeners. And the image generation part is really important in this app because it has to generate— because the whole point of my app is not to build a design like you're a landscaper. The whole point is to help people find what plants they like. and see an inspiration photo of their own house with those plants and be like, oh my gosh, my house could look like that, right? Have that moment that motivates them to power through the planning later. And all of a sudden, Gemini upgraded its image generation models. And the images kept coming out more like cartoonish looking and plasticky and not as real. And I was like, Gemini, can't I go back to your last model? I don't like this model. And of course, I couldn't through the chat interface where most of my users are going to be. I could only do that if I was actually hitting APIs. And of course, I didn't do that because I didn't want to pay for it. Frankly, I wanted the people to be able to go generate their image for free because if I have to pay for it, then I have to charge people. And if I have to charge people, I have to build payment infrastructure and I don't want to do any of that. So it's interesting how that model— I was so upset when I figured that out one day. I'm like, oh, the new model sucks. How do I go back to the old model? And that didn't have any enterprise dependencies. That was just annoying to me. So I do worry about that.

Yeah, the UK is funny because it's meant to be gray and wet, right? It's not at the moment because we're in our first heat wave. But, you know, having moved here, it's gray and wet. And yet the whole country gravels out their front yards. Like, I come from New Zealand where we have grass and plants in our front yards, right? In this country, they just gravel it and park their cars there. It's culturally very, very strange for a typically wet country not to have flowers and gardens.

My guess is it's like when it's that wet, weeds thrive. And people have this weird— anyway, I'm not gonna go off on a tangent about gardening. Anyway, that's a different podcast.

It is. It is. Okay, so let's go back to ontology. So the interesting thing is there's a whole lot of stuff out there at the moment about buyer ontology. Yeah, just off the shelf, or, we have a tool that can look at your technical metadata and your tables, and we can ontologize— I know that's not a word, so sorry, Jessica— ontologize your organization for you. And I always have to, when I do bad things to ontology words, I have to apologize to Jessica.

She's very about the precision in language. Surprise, surprise.

Yes, I know. And that's why I work in data. And what's interesting is you think, as a hospital, there must be an out-of-the-box ontology that's well-formed, and why don't you just implement that? Whereas you're talking about discovering how your organization works, getting it into a rough state, and then bringing in the craft, the expertise, to turn it into the, you know, a proper ontology that's defensible. Like, why? Why don't you just go buy one?

You don't have to buy them. I mean, they're public collaborations. There's one called OMOP that's used in research. So, when you're sharing research datasets from healthcare datasets, you know, it defines things like, you know, a patient, a diagnostic code, and things like this. So, there's ontologies, there's taxonomies, there's governed, you know, diagnostic codes, prescription codes, there's things like this. So, Um, the point is we will and do use all those things. Some of those are already embedded in the EHR, right? When we, when we, um, we have to use the CPT codes, which is the insurance billing code, um, for a procedure in the United States. Um, so some of that's baked in. We're getting it at operation time because they have to code it to bill it. And so we're getting some of it structured and it's happening in the EHR. Of course, a lot of the rich contextual information to make healthcare personalized and algorithmic is in the notes, right? The clinical notes. And so that there's a lot of opportunity there, and there's a lot of opportunity even in the other data. So EHRs are aligned to FHIR, which is a standard. So there are a lot of overlapping standards, but they all kind of have different purposes and different meanings. So I view it as Those are all really important inputs to our ontology. But our ontology is going to have— for one thing, I work at a pediatric hospital. Pediatric patients are not just smaller adults. Pediatric healthcare is actually different. Like, a pediatric brain is different than an adult brain. Best practices are different in pediatrics, which is why, if you've ever had a kid, even like my daughter sprained her ankle, her whole ankle was like black and blue. We're very worried it was broken. And we had to go to the emergency room. And they're like, Go to the children's hospital. I'm like, it's a sprain. Like, I'm pretty sure you guys can see it here. They're like, we do not mess with kids. You send them to the pediatric hospital. And I was like, I find that really interesting. So that's an interesting thing is pediatric healthcare. We have like nuances and specifics that are so often when we find resources, we'll be like, is it pediatric? Have you figured out the context for pediatrics? So a lot of the EHR AI things were like, well, how will they work overall? But how well do they work? On pediatrics? Because if they've been trained on most hospitals or adult hospitals, is it biasing? And is it working correctly? So we have a lot of evals to do. Anyway, I view it as we're going to use— we will need to translate our data into these different public ontologies, taxonomies, vocabularies, resources, depending on the use case. Like my research institute, they want everything in OMOP. We may not want to be restricted to OMOP for everything we do, so we almost have to create. There's a really cool. We actually just talked to them at UPMC, which is a hospital in Pennsylvania. They have a project called Project Neptune that's like 15 years in. That's all about interoperability between their large hospital system and had like nine EHRs, and they had to rationalize between them, which ends up being you cannot blend data from multiple EHRs until you find the conceptual or semantic model. That that creates the translation layer. So I view it as we need to create these translation layers, and those taxonomies and ontologies will probably shortcut us being like, "Well, we like OMOP's patient definitions. We're going to use that." That's great. Or be like, "Oh, these guys do it slightly differently. We're going to go with this one over this one." So we'll kind of pick our canonical and then have our translation rules. So it will inform us, but we can't just adopt it wholesale. Because it won't always apply in our use case. It won't always apply in how we as a hospital have chosen to operate. You know, not everything in the real world with human bodies and medical healthcare always fits cleanly into clean structures. So, it's like, we'll apply it when we can, and then we'll come up across all these use cases where we're like, yeah, well, we do that a little differently here. So, that doesn't apply. That's not how we actually admit people. So, a lot of hospitals are best practice and are standardized. And so lots of it will apply. Anyway, that's my way of saying it's a huge nightmare that I get to deal with.

Again, it just reminds me of back in the days we had enterprise data models, you know, so a bank, you know, a financial services company or a bank would go and pay IBM or Teradata, IBM normally, you know, millions and millions of dollars for frequently a diagram. And, yeah, it was always part entity thing is a thing is a thing because it had to cover every use case. And I have a particular, thing against those, I call, you know, those anti-patterns, in my view, but that's just my view. But they were never implemented, right? So, parts of them might have been, but I've never saw one fully implemented. And so, I think out-of-the-box ontologies feel, even though most of them are open source now, nicely, they still kind of feel like they're helpful, but they're not the answer, right? And so, I was kind of intrigued, yeah, how that worked. your domain? Because as you said, your domain actually, I don't know, does it have the most number of ontologies that are available of any industrial domain in the world?

I mean, we get this nice benefit, at least in the United States, where the US government has done a lot of work. I don't know the actual timelines of when this happened, right, to incentivize the industry to get onto electronic health records when they were on paper records, and to create interoperable standards. You can send records between hospitals. And because The US, we're not a single-payer system in the US, right? We have private and public, but obviously being paid by the federal government under their, the many patients they cover for Medicaid and Medicare incentivizes you to meet their interoperability standards for payment and reimbursement. So there's a lot of public funding and public incentives that have helped create some normalization in healthcare, which is really, really nice. But like you said, We'd be crazy to start from scratch and act like this meaning and all this work hadn't already happened. These huge committees that built the FHIR standard and the OMOP, like, we would be insane to act like those don't exist, which is something that, um, you know, Jessica Talisman, who you mentioned before, is always saying. They're experts, you know, they're experts who specialize in this. And so it's like, why would you reinvent the wheel with how knowledge is governed, or what, what's a taxonomy, what's a These things are separate objects, and they're built in a separate pipeline, and these ways of working. And similarly, in the niche of healthcare, you'd be crazy to not leverage the benefit of the fact that OMOP had a taxonomist in that room going, no, we're not going to do it that way. Like, so much of the hard problems have already been thought through and solved. Why not go to the 80% and then be like, okay, and where might this wiggle room exist? That's how I view it.

Yeah, so we're doing something where we're building out a product for media effectively for a customer, and we've worked with them for a while. And so we're effectively grabbing data from a large number of publishers. So, you know, video on demand views, linear TV, box office, those kinds of things. And going into that domain a couple of years ago, I was like, it's media, right? There's massive media companies around the world. Every country has its own public broadcasting, typically station. So this is a solved problem, right? The definition of a content title and the definition of a platform, right? Like, yeah, I don't have to reinvent this wheel. And oh, shit me, did I? What? I mean, BBC have published a glossary in a form of ontology, but it looks incredibly light. And then there's nothing that I can find. And again, I look at this domain and I go, well, why isn't there? shared language across that entire domain. And I think you're right, it comes back to, there's no incentive. Like, why would they spend time and money doing that? So, it would've been really helpful for me. But yeah, that kind of flabbergasts me that it doesn't exist. But coming back to your point about expertise, right? Because this is, again, one of the areas I'm struggling with right now. So, when we saw the last wave of modern data stacks and dbt and the democratization of transformation, right? So, moving away from when we democratized BI last-mile tools with Tableau and Qlik and all those draggy-droppy things into allowing analysts effectively to do what data engineers did. We lost the art, the craft of modeling physical data structures and conceptual modeling, right? And if I look back at it, I can see the behavior that I think was the cause, right? It was experts at data modeling said, There are a large number of experts out there, hire us, let us do the work. And the only education we really had was Kimball and his books, and he kind of retired by that stage. And his books are still really, really popular. And I think that's why we see dimensional modeling being kind of now the linchpin physical modeling structure. But as a domain, data modeling and the expertise kind of lost, right? Lost the war.

Mm-hmm.

I see the same thing happening with what I see as library sciences and ontologies, right? That same, we're experts, and they are experts, right? And they have trained well, and it is a skill, and it is a craft. And I can't look at the way I do a glossary and say that's anywhere close to an ontology or taxonomy, right? Because I know it's not.

Right.

But I know it's not, whereas I'm seeing a lot of ontology washing, right? But what's your view, right? Like, how And elitist is not the right word, but it's the word I'm going to use, right? How elitist is that library sciences ontology space at the moment that you're seeing? And how is that going to impact, in your view, the adoption and democratization of it into our ways of working, which is what we need right now? Oh, it's a spicy one. You can opt out of this one.

We can move on. It's so spicy. I'll put it— here's what I'll say. An interesting, um, challenge is I see that people who are in that, that domain— I, um, Jessica and others, I, I follow as many of them as I can find. I follow them because I want to learn from them because there's, there's so much expertise there. But they're very precise in their language, is something I noticed. And so sometimes, like you said, the ontology washing is truly people acting like there's no difference between these things. Mm-hmm. And you're like, these are not the same things. There's a difference between that and me being less precise in my language because the audience I'm speaking to won't understand it. But I am holding the space for that complexity. Do you know what I mean? Like, I'm not expecting my, um, even my chief data officer to know. I mean, he does know about these things, but not to, um, to care about the difference between we're going to start with the glossary and then we're going to— it's going to be a controlled vocabulary and then it's going to be a taxonomy and then it's going to be ontology. He's not in those weeds. But, like, how are you gonna sell your data engineers if you lose them in the jargon? And so, I feel like there's this translation role as a product manager I'm trying to play of, like, these advanced structures and this, like, progressive formalization of language and meaning has immense value. But if we get too jargony about it, the learning curve feels too steep, and then we lose people. And they're like, I don't have time for all this. Like, I gotta go ship this data model, like, right now. Um, and so it's like, how do we create— um, so the way I'm focused at the hospital is like, we're so far from ontology, I'm not even worried about that right now. I'm worried about a freaking controlled vocabulary. Like, let's just— visits mean this, encounters mean this— and teaching people that there's a difference between the semantic definition of a thing and the calculation against that thing. Those are separate stages of approvals and governance. Cool.

Talk me through that one. Take me on that journey.

Yeah. Okay. So, I might say, let's think about a not-fraught thing, a prescription. Okay. A prescription at a hospital. So, the word prescription, I'm going to say, a prescription is a doctor writes a script, and I go to a pharmacy to fulfill it. You know, it's the actual piece of paper that gives me the authority to go obtain So, it's okay. So, there's the script, prescription script, and then there's the prescription physical, like the actual medication is in my hands now. Okay, what are we going to call those things? So, there's that work to define words and definitions of things and their meaning. And maybe, uh, you have to have a prescription. Okay, in a hospital they call them orders because an order for a lab is different than an order for a medication.

Hmm.

So, the order is the thing that goes with the authority. Only certain people, certain credentials, can create certain types of orders. Like, a registered nurse cannot order a prescription, but the nurse can administer the prescription once the doctor's placed the order. So authority goes with the— anyway, so all these words have meaning. So if I want a count of— you need, um, and some things don't require a prescription. You can get a flu shot in the U.S. without a prescription. You show up at a pharmacy and be like, I want a flu shot, and they give it to you. That doesn't mean it's not a controlled substance. It just means that one doesn't require require a clinician order. So it gets very messy. So what am I trying to count when I say I want to know how many lab orders were placed in this day? I need to be that precise— lab orders. So then the calculation of the thing— the orders exist, they are out there, but the calculation of the thing is it's a count, it's an average, it's an aggregation, it's a time-bound thing, it has inclusion and exclusion criteria. So the semantic meaning is What is the thing? What is the concept? What is the word I mean? How would a dictionary definition describe it to you? And then, what do I want to— what metric or calculation— what metric do I want of that thing? And the metric has its own semantic definition. And then, the calculation of the thing is the actual— this is observable in this dataset. I'm going to sum this column, filter on this column. Those all get muddied in the same way that ontology gets muddied. And so, Helping my team mature to the point of being like, okay, stop trying to just jump straight to getting approval on your calculation because that's what analysts often do. I'm going to calculate it this way. Does that make sense to you? And the stakeholder's like, I'm just going to trust you because it seems reasonable what you're saying. Or if you walk them through saying, when you say lab order, do you mean this? Do you mean inpatient lab orders? Do you mean all lab orders? Oh, I meant only inpatient. Okay, got it. Inpatient at all campuses or just the main hall? Oh, good point. Okay, just the main hall, right? And so, if you don't actually take the time to do each step, you end up later with people thinking this thing you calculated means one thing and it means another. And also, there's no record of all those decisions that happen. It's all just like when analysts don't use data models, and they write an 800-line query on ingest into Tableau, and they transform it, and then they do calculated fields. And you're like, what does this thing mean? And you're like, good luck tracing that. It's the same thing. It's like the— we have to create a process that creates a lineage of meaning. And if we don't actually follow the process, every meaning is an investigation into, I actually don't remember what we decided. And I actually don't know if the stakeholder understood what we were doing when we did it. So, how do I help create the maturity that these are all separate decisions?

Oh, we just put into an LLM, right? Just upload it with CSV and then ask it the question and it will infer all those decisions that you just—

I mean, you're okay with a robot just making calls. It's similar to delegating to like an intern. That's how I feel with LLMs. I'm like, all right, cool. Like, yeah, I'm sure if you have a smart intern, they can come up with a measure for you, whether that's the measure you actually wanted. Who knows?

I liken it to giving an intern my credit card and me saying, I'm thirsty.

Yes, I love that.

I'm not doing that. Okay, let's go back to language and let's go back to the team. So, one thing is, it's interesting you use the word that you're a product manager, whereas all the things you talk about, I see as a product leader. And what I mean by that is you're not just focused on what a product looks like and the value of that product and managing that product to market, You're focused on how the team behaves, how their ways of working are, how we upskill them, how we integrate them, how we find patterns that are reusable, how we put in place principles and policies that mean certain things can't happen. So that for me is a form of leadership. Do you agree with that? Like, is that all the things you're doing as what you call a product manager for you?

This is a good question. So I was a product manager for several years before I became a leader of product managers. And so, when it was just me, a senior PM, and I wanted to do things like this, like sit down with the stakeholder and be like, when you say activation, I think you mean sign up. And those are not the same thing, right? I could develop my own templates, my own process. And I'd be like, this is how I just keep my own. It's akin to like, I'm going to tidy my own space. But it's the difference between living in a dorm and I tidy my space and being the resident assistant for the dorm floor and being like, we are all going to tidy our spaces in this way. Or no one is allowed to keep pets on this floor. That's disgusting. Or whatever, right? So, when I became a product leader, I had finally authority to say to people. Now, I'm also not a micromanager or a dictatorial leader. But I am a big believer, and I hire people who are big believers in good process. Meaning, I don't want bureaucratic process that does not help us. But pre-baked decisions where I don't have to remake a decision over and over. It's like when we define a thing, this is where the thing lives. That's great process because then everything has a home. Everything has a place. So I try to create that collaboratively with my team. But also, I have more experience than most of my team, and so I try to come in and be like. In my experience, we need a place where this lives. I was thinking maybe here. What do you guys think? Right? So I am now as a people leader. So I went from thinking just about how to do this well myself to how do I get my product team to do this to all right the product team is just the tip of the spear and then we have analysts, engineers, data scientists who are also executing. Okay, then we have the people inside the data team. But if you're a distributed team, what about the analysts not in my team? Who I have no authority over and I need to influence to behave a certain way? What about the stakeholders? So, I began to think more about how there's a limit to how much process and my personal influence can create coherence, to thinking about how does a system create coherence over time. Meaning, why would I reinvent the wheel if there's a well-documented thing here? It's the same thing with data modeling. Like, why would I build a script from ODS? Well, I don't know the data model exists, or I do know it exists, but I don't know if it's what I actually need. I don't know if I can trust it. All those things. So, it's the same thing with, like, anything I build. I'm thinking, what would get in the way of people adopting this? What would make people act chaotically when they could act coherently? And making sure that the product creates the incentives and the utility. That's where product design comes in. I want it to be like, People want to use the things we build because they'd be crazy not to because they have a busy day. So I view anytime someone's not adopting the process, the thing, the thing, the thing I'm creating, they always have a good reason. And instead of treating it— some people can get very like, stop going rogue, just use what we've built. And I think that's such bad product practice. And instead, I should be going in and going, tell me why you're not using this. I didn't even know it existed. Oh, okay, I need to do a better job. Advertising with discovery, distribution, whatever. Okay. Okay. Now I know it exists. I don't know if I trust it. Well, how do I make sure you trust it? What does trust mean for you here? So anyway, as a product leader, I am thinking now more about not just how I can do good work or how I can make sure my little squad—I'm a product manager with two engineers or whatever—can do good work. I'm thinking about how the entire data team and the hospital can do good work at scale. So the It's much more— that's why I love when people say data is techno—

Techno-social. Yeah. No, socio-technical. Yeah.

Yeah. Socio-technical. That's why I was struggling with it. Socio-technical because it is. It's about the behavior around how we create data and how we evolve data and how we serve data is both behavioral and system-driven. And if we don't plan for that, and now we're adding new agents who You shouldn't personify agents. They're not people. But you also have to think, if a robot's not told any differently, what are they going to choose to do? Because that's how you find them.

Yeah, I think we should personify them as people, not because they are, but because it gives us a mental framework. If you bring somebody into your organization, you have to tell them how the organization works, right? You sit down with a coffee and you go, hey, this is— I mean, one of the things I always say now, and I got it from Dylan Anderson, is when I work with a new data team, First thing I ask them is, how does the company make money? If they can't answer that, I know I've got a bigger problem than, are they using Databricks or Snowflake, right? Who gives a shit?

Oh, yeah.

Yeah, they're not gonna be there for long because they're not adding value because they don't know where value lives. And then, you know, you've talked a lot about what I call systems thinking, right? But I love your comment about nobody using it. I liken it to when data teams, and, you know, they go, well, really what you've done is you put a box of cereal on a shelf in a supermarket and everybody's using the other boxes of cereal. Yeah, it's probably not them, it's probably you. So are you going to change your cereal and make it a little bit more interesting?

Is your cereal $8 a box? That might be why no one's buying it.

You're like, it's got no sugar.

You put raisins in it and they all hate raisins. You know, like, uh, I think if you blame the user, it's just a slippery slope. There are certain things that we have to be like, I'm sorry, GDPR says you cannot access the The identifiable data, like that is the law. There are very firm things, but almost everything else is like. It actually gets back to one of my favorite things that I talk about now, which is data modeling has such value. So why do analysts go rogue? Why do analysts build from scratch? And I think there was a long time where I was like, guys, work with us, help us build this data model. I'm like, why won't these guys work with us? Why don't why? Don't they want to, like, I felt, I'm like, is it territorial? Why don't they want to divide and conquer? We'll build the model, then you just build the viz. And then I realized it was a timing thing. Analysts are under the gun to get insights yesterday.

Mm-hmm.

And we cannot build a model in a day. And that's just not good engineering. And so, if you get frustrated by that tension and you try to just constantly force resolution, adoption is going to be limited. So, now, I'm much more passionate about how do we create sandboxes for analysts? How do we observe what they're doing? And then say, hey, this thing, you're using it a lot. But if Todd goes on vacation and this breaks, there is no one who owns maintaining it. So, what if the analytics engineers shift this left, you refactor your last mile, and now that's a data product? And they're like— when I explain that to analysts, like, we're not going to shame you for for going ahead. I talk about them as being the scouts who are going out and finding the problems. They're closest to the problems. But that doesn't mean modeling doesn't have value. We can't just always be scouts and always building from scratch. It's cost inefficient. It creates a lot of risk. And so, we have to plan a system for flexibility. And so, that's what, as a product leader, why I love product and data is you're thinking about how do people behave? Why do they behave? Where people are like, why do I need a product manager? And I'm like, do your engineers have the time to think about these things? Because in my experience, they don't. They're so busy just shipping and modeling and building and fixing breaks. So, that separation of responsibility, it's not that I can't write code or my engineers can't think about discovery. It's that having the time to own different spheres creates something better than when everybody tries to be full-stack, if you will.

Yeah. I mean, the question is, why do you need a product manager? Well, go have a look at your Jira backlog and how many tickets have been requested that have been sitting there for 6 months, and somebody's got and built it outside of your team because they haven't waited. And the mental model I use is exactly the same as yours. I talk about pioneering town builders. We want people to go out and pioneer, right? They're out in tents, they're out on horses, they're in places that they have to get to quickly, and we're not going to do that. But we then need to follow them up. And when that pioneering village gets bigger, we should take it over and build a town and let them go off and be pioneers again. Because all the analysts that are doing the great work, they don't want to be building and maintaining things that run on a regular basis with all that engineering stuff normally, right? They want to, well, they're not even allowed to, they get, they've got to answer the next question.

Or if they do, I say to them, have you heard of analytics engineering? I think this might be a better job for you. Like, do you like owning the system or do you like being a pioneer? And if you like being a town builder, but your title is analyst, you might be in the wrong job. And so that's also sometimes it, or I go, hey, what if I took this off your plate so you could go pioneer some more? And the ones who are true analysts are like, Heck yes.

Yeah, yeah, yeah. I've done the fun stuff. I've solved the problem. Now you run it and I'll carry on. We've got a question in the chat, and I've got to keep remembering that, keep going back to that. So I'm going to butcher the name, so sorry, Jürgen, but separating analytics from metrics is a good step. So I'll let you answer that one for me, but before I do, so we've just been experimenting with a thing called BigQuery Graph, right? And the reason is it's come out and it enables us to create what they call a metrics layer. And I've always defined, when I was teaching people, 3 terms. I talk about facts, which are an immutable number I can see in the data, right? So, you know, 12, 35, that for me is a fact. I say a measure is something that is an average, a sum, those kinds of small calculations. And for me, a metric is where I've got a complex formula, you know, this over that, window on that, this divided by that, over that, that kind of thing. So that's the language that I use, right? And so when I go, oh, cool, we're getting BigQuery Graph, it's got a metrics capability. We've been waiting for ages, we didn't have to build our own one. Yahoo. And then I go into it, and it allows me to do sums and averages, but I can't do this minus that, or this over that, right?

Oh, interesting.

It's coming out this week that we can. But again, it's that language, right? I go, that is what a metric is. And then all of a sudden, I've got a thing that does measures. So, how would you separate, like, yes, I understand that, you know, the comment is separating semantics from the metrics, and I think it comes back to your definition of concepts and terms versus the calculations for counting them. Is that how you think about it? Or do you think of semantics, now that's such a loaded word, as being different?

I think of semantics as a very, I think you have to plan infrastructure for semantics just like you do for data, meaning what's the pipeline? What's the process? How does this get built? So, at the hospital, the parts that I've been doing a lot of work on this year, I haven't had time to write up anything about it.

I noticed. I'm waiting.

Hopefully this fall. You wouldn't believe how many drafts. It's been a busy summer. Um, uh, and I don't regret that. But, um, what's coming in, in our stack, the way I call it, um, the semantic— we call it the semantic stack. For a while we talked about build versus buy. We called it the Scrappy Semantic Stack, was the version we didn't buy anything, we just built everything. Trademark pending, Scrappy Semantic Stack. And then formally, so what we're doing for now is first there's the discovery phase of semantics, and that's what we've just been talking about— the meetings, the transcripts, It's very fluffy. There are not amazing tools for that stage. The closest I've seen is LEAI, where you can build a semantic map. Obviously, you can do things in whiteboards, but then it doesn't— there's no structure or connectivity behind it. Tools like Lucid, things like that. And we're okay. That part, I'm like, that is a problem for future me. For now, everyone do things in your scrappy way. And but then, when definition happens, that's where we need to get structure. And so, we just were moving our data catalog from Elation to data.world. Part of that was because data.world's inherent knowledge graph structure and semantic triples and the ability to do SPARQL and to export as Turtle files and RDF and all these things, right? It's like baked in. So, it allows us to start. We have a user interface where I can put a glossary term and a definition. And so, my product managers are now being asked, So when we do a PRD, we've done all this discovery, we're like, okay, these terms matter. Like, don't define those terms in the PRD, define them in the catalog and link from the PRD. So that's the first time something exists as like a true long-term artifact with a UUID is in the catalog. And then when the data modelers come in, they're gonna model it in Erwin or whatever software they're using for data modeling. And then, Then they're going to actually execute the model. We're on Databricks, we're looking at Databricks semantic metric views, or looking at analytics engineering is newer here. Are we going to use dbt? How are we going to actually build our models? And what I am talking to engineering right now about is, okay, when you codify meaning in a model that exists, so I might have glossary terms with definitions, metrics with definitions, those are like semantic assets. And then they're going to build them in code. And so, we're talking about, okay, when you create it in YAML, can we reference and create a tag in Databricks that has the UUID from the catalog? So, when the collector picks up the metadata from Databricks, the UUID is there for both, and then we can run a job that creates the relationship between them automatically. So, that's what we're thinking about now is, we have discovery, we have definition, we have codification, and then we have the serving layer. And so, we're definitely opinionated that semantics exists upstream of the serving layer. The BI people all want us to build our semantics in there. And I'm like, no, you can read my semantics. I will feed you my semantics, but I will not build them there. And, you know, and then because the semantics live upstream, we can serve them. So we have to think about how does it get carried along?

Okay.

Does this exist here? And then does it become a tag in Databricks? And then how does it get fed into Tableau or Power BI or Omni or whatever we're going to use? And so, part of the problem I've been facing is a lot of BI tools that are like doing really cool things assume that the person creating the meaning is the person doing the viz.

Yeah.

So, like, build it in our semantic layer. I'm like, no, the meaning happens earlier and by a separate person. And I'm so frustrated because I'm like, you assume they have enough context to create the meaning at this time. I need to create it way earlier and differently, and I just need them to codify the meaning. So, I'm very frustrated that a lot of current tools I get into it and it won't work with our process. And so it breaks. And maybe we'll just build Claude on top of it for the BI. Maybe we'll just give up.

Yeah. Because, and the reason is because it's siloed. We're still back at Lego blocks. And then the second reason is they want to own the semantic context, right? Because they know if they own that, then they become immutable and you can't remove them as easily as you can if they're just executing off it. And I'm with you. I'm like, define it once, reuse it often. I think, in my head, the model we should be going to is you define it once, and then, and that's the PET, right? That's where we protect it, and we really care about where those initial definitions, like all that context and semantics, is created and stored. And then it should hydrate as cattle, right? So, your engineers should be able to point at that contextual meaning and have it start their engineering patterns. But that's not how it works, right? They have to read it, write the engineering patterns, and then link it back to that big, you know, that brain. And I'm like, but hold on, a lot of what they need is already over there. Why doesn't that start the journey? But the problem then is we've got so many different tools that don't talk that way, and we don't have standards across them. So, you know, you have, like we talked about right at the beginning, you have standards for ontologies across medical environments to a degree. We're trying to get the, what's it called now, Apache Aussie as a standard for semantic metrics, but actually, it's been driven by BI semantic layers. It's been driven by the definition of metrics, not the definition of the organization, not a conceptual definition, not an ontology, not a taxonomy, not all the anything around definitions, right? It's been built around this idea that I have a, as you said, a bunch of code that wants to calculate a thing. And that's too late, right? That is at the end. We should leverage everything else we've got. So, I'm with you, but we'll see if the market moves, right? Hopefully, they will this time.

But who knows? I know. So, I'm like, all we're— so, right now, I'm very focused on that definition space, creating process. We're going to adopt data.world. I'm going to teach the organization and changing the mental model of my team to be like, meaning is a shared thing we create. Meaning is not, I've been here for 15 years and I'm the only one who knows how to do lab order analytics. That's great. But I hope someday you get promoted and someone else will do that work. So, I need you to like, You're not valuable because you're the only one who knows that. You're valuable because you are the top contributor to our shared repo of meaning, if you will. And that's a mental shift for people. And it feels scary because everyone's worried about, am I going to have a job in the age of AI? So, we're doing all of this change and transformation, Shane, in a time when people are very scared.

Yeah.

And so, there's a lot of work, I think, for me to go, I think your job's getting more exciting. I think you're more valuable in this context. It's okay to let go of this piece you used to do because here's this new piece where you can contribute. But that story takes time to tell that and bring people along. So that's what I'm focused on.

And that's the social technical one, right? Just because, you know, after this podcast, right, this Substack Live, your DMs and your emails are going to be flooded by every vendor in the world because you're kind of at the greenfields beginning of the journey, right? So—

The vendors love to message me. I'm like, speaking of Joe Reese on here, I'm like, oh my gosh, can you imagine how many vendor messages Joe gets? I'm like, I'm like small potatoes and I get so many.

Oh, look, I actually, I think I found a great pattern. You just, you've just come up with a great pattern because Joe is on here. So what I think you should do is you should say, um, oh, if you want to pitch me something, Joe's my advisor, go pitch it to him. And then Joe has a certain way of dealing with those people. Then you won't have to worry anymore. You might have to buy him a coffee.

I just put something on my profile that says I have no budget authority. I have no ability to help you.

They don't care. They know you can influence You're a leader. No, I think that's the answer is, yeah, Joe's my frontman and go talk to him and then he'll do his usual—

I don't wanna make an enemy of Joe Reese, Shane.

I think he enjoys it. I think he enjoys that stuff, but no doubt, we'll find out. Yeah. Sorry, Joe. All right. Hey, look, that's been great as always. Yeah. We were gonna talk about context engineering, but next month's, right? It's always funny, which comes up as exciting and interesting over the month that We've been working and figuring out where we triangulate.

Yeah. So today we talked, you know, more concept modeling, ontology, semantics. So next month we can be like, what, what about context when it goes beyond that to the rest of the context? And how are we going to engineer that? Maybe I'll have done enough thinking in the next month that I'll have more thoughts.

Well, that's the other thing is think about it. Then we get the transcript and then you can use that as an input into writing about it. There you go. Oh, yes. We'll get that article I'm looking for.

Oh my gosh. I'm trying. Uh, the bad weather is coming and that's when I do more writing is when I, I'm in, I'm an introvert and I hate the cold. So in Utah, when the weather gets bad, I'm like, I can't garden. I can't do anything. May as well just write a bunch.

So writing will be cyclical. I was talking to Juha the other day as well. And he's saying that, um, his writing on his Substack, right? He hasn't done it for a little while for a whole bunch of reasons. Um, And he's kind of realized, you know, how hard it is to get back into it. And I think people who don't create high quality content really don't understand how much time and effort it takes to get the idea and craft the story and do the arc and then go back and hate it and then change it and get it to a level that you go, it's articulating the story and the message I want to articulate and at the level of quality I want to articulate it. And everybody thinks it's just half an hour and it's out there, right? And it's, it's not like that.

Oh, it's... And the better, the more thinking. Yeah, that's why the fastest content I write is something I've been thinking about this for 6 months, and I've done a lot of writing internally at work about it. And I'm like, okay, and then I'm just generalizing it for public consumption. That's the easiest stuff. But the more frameworky I want to make it, the more I want to make it useful to people who are new to it, all of that takes more time. And just can't get beyond— it's like my kids just went back to school. That's the other thing. Kids went out. hiking, doing other things, you know, like, I'm like, sorry, I'm not, uh, the writing will return when it returns. Um, and I'm not trying to become a content creator. So being consistent all the time isn't important. But, um, I guess I'm a content creator today.

So, um, yeah, write when you want to and write when you have something to say, right? That's, uh, that's, that's the goal. That's the love of it. Yeah. Excellent. All right. Well, we'll see you in another month and see what's, uh, top of mind then.

All right. Thanks everyone.

Catch you later.

Bye.