Proof of Work: AI Value Creation
00:16:38 · Joe Zein
[00:16:38] S2: Yeah. Again, right, it it's the more depth, the more, the more deep you go into a company, right, the more you're able to understand what constitutes a certain aggregate metric, which is or or down-the-line metric, which is EBITA, something like EBITA, right? In the credit space, I mean, it's kind of like a an interesting space because lenders put up covenants when they they write, they underwrite a loan. And so those covenants, which are essentially rules to make sure that, you know, you know, are are tied to those aggregate metrics. But then we've been seeing more and more rules that are more granular than just saying debt to Ibita should never go above that specific threshold, right? Because there's a lot of things that constitute debt, and there's a lot of things that constitute Ibita. And it's really about decomposing that metric, that metric that is either the sum run uh long sum of a lot of subline items. And and I don't want to say like there's been like specific signals, everyone is tracking covenants, but then everyone is tracking what's making up those covenants. It depends a lot about like how deep you want to go in a company, right? A big deployer like Blackstone will not, you know, and this is you know, every everything that's being talked about about in the credit world that, you know, the credit boom, people have been funds have been, you know, under have a lot of drag powder that needs to be deployed. Uh, and private credit is a very interesting and an appealing asset class. So prices have gone up, the covenants have become looser, and what this ends up happening is like people are are running away, are are having less signals than they had because the pressure is to deploy, right? But then if you if you go in and and and dig deep onto every company, then this is usually what the smaller funds do. It's like I go in, I dig very deep, I set up very narrow uh covenants to make sure that you know uh this company's not gonna go under.
00:18:25 · Stuart Willson
[00:18:25] S0: Again, it's it's it's it's a very company by company based uh one thing that I'm seeing, you see it on LinkedIn, you see it on X, is that someone on the deal team or the operating team builds a monitoring tool? Maybe they do it in Claude Code or Claude Cowork or OpenClaw or whatever is hot that weekend and it works and then it doesn't. What goes wrong when um individuals build monitoring tools like that? Maybe Joe, you can start.
00:19:01 · Joe Zein
[00:19:01] S2: Yeah, I'm gonna start very simply. Uh and I wanna let Yann hear what Yann has to say about this. One of the hardest pieces of technologies to build is portfolio monitoring. Because of how high impact it is, this is something that is touching that you're sending to LPs. This is these are numbers that are getting reported to the SEC and to other governing bodies. So this is not the kind of thing you want to botch. And anecdotally, a lot of things that we've been hearing is from associates, as you said, it's amazing that we have all this that you know this level of curiosity, and people are trying, and people are trying to do new things, but people don't understand what they're building. The answer is always like DAI did it for me. I have no idea how this is working. We haven't been hearing a lot of, we've been hearing people oversimplifying it and saying, yeah, at the end of the day, this is only serving us as a database. But then you dig a little bit deeper and you realize that there's actually a lot more than just storing data points. There's a lot of calculations, there's a lot like on the 73 string side, there's valuation. And most people are, I want to say, smart enough to know that this is like territory that we shouldn't go into. But the apps that we've been seeing being vibe coded over the weekend are generally not portfolio. We've heard people say portfolio monitoring, you know, we're not using using it to its full extent. So maybe we want to hard code, we want to vibe code something that is, you know, a lighter version, which I hear. But if you are using a portfolio monitoring tool as you should be using it to its full extent, this is not something that that you can vibe code. Um I think the 73 string has been doing it for half a decade. The high-level guys have been doing it for decades. Like a lot of people, like and and there's a lot of complexity that goes into that, right? Like IRR calculation is not a simple summation. Um, anyways, Yann, I think.
00:20:53 · Yann Magnan
[00:20:53] S1: Yeah, no, uh, and to to uh to maybe um stress what you just said, uh Joe, at the end of the day, this uh the private capital industry is an industry that uh needs to get to 100% accuracy. There's just no no other way. You can't get to 99.5. If you run an algo for to do whatever once, uh and you and then you run it again one hour later, you have to get to the exact same conclusion, not a slight difference. And and the reality is that at this point in time, LLMs can do a pretty good job, 100%. They can do a pretty good job in surfacing insights and intelligence. But if you if you don't get the basics, the basics right in the in the first place, which is a very sound, robust, governable, auditable, as Joe was saying, data model. If you're not developing something that will you know make sure that your regulators, LPs, you know, trust what you what you provide, at the end of the day, it's garbage in, garbage out. As simple as that. Well, if you do that, if you have that first layer where you have a very robust data model where you can overlay that with Some solutions that are common. If you can create that data model when it makes sense so that it's consistent consistent across across a portfolio, then that's when you can create massive um uh intelligence insights and value. And and and and people like a Soal Labs can basically do that work to overlay uh this type of intelligence on top, on, on top of that new structured data model. But like I said, the starting point is you have to get the data right in the first place. If you don't, if you're not getting that right, I mean garbage in, garbage out, and recipe for a disaster at some point in time.
00:22:37 · Stuart Willson
[00:22:37] S0: Yeah. Uh you spoke to reliability and you spoke to a robust data model that is critical to ensure reliability. What does a robust data model look like for a fund that is exploring portfolio monitoring for the first time? What does that look like? Is it a folder with a bunch of files in it? I know it's not. But uh what is it what does that data model look like? And what are the steps that one needs to take to go from Excel sheets to something more robust? Jeff? Jordan, do you want to get started?
00:23:14 · Joe Zein
[00:23:14] S2: Yeah. Uh I can get started with this one. Uh a robust data model is definitely not an Excel sheet. The thing is you need auditability, you need, you know, uh version version, you know, you need to be able to see the versions. You need to be able to know who edited what, who did what, you need to have rules on top of it, and Excel obviously does not allow you to do any of that, right? Excel is amazing because it's a canvas, it's a free canvas, right? Open canvas, or you can do anything you want, right? But there's no way of checking rules. There is no way of limiting someone to add to add a row. You see an Excel sheet, if you have added access, you can do whatever you want with it. And when we say a governed and proper and a good data model, I think one, there is those key criteria that we have to have, which is auditability, traceability, version history, all those different things. The second thing is this is on the call metadata layer or on the envelope layer. The other thing is, well, what do you use a data model for, right? You use a data model for to query it and to write to it. So there is years of computer science experience of like people who have played around and toyed around and tested different different data structures to see what is optimal for retrieval and what is optimal for writing data. And what is optimal today, and why this is becoming more of a topic of interest today, is because you also want to feed something to DLLM that is structured enough, right? There's this analogy that I like like to give. You go into a library and you see the books all over the place, and someone is asking you to give them a summary about a specific topic. Today, the way DLLM is gonna work is if you just give them a file system, right, of a bunch of Excel files and PDFs, is gonna go and try to read all the books based on text work on text similarity and try to come up with a summary. And you see why this could be problematic. On the opposite side, if you have everything in clean tables that are kind of self-documented and that are organized in a way and that have constraints, both at the database level but also at the metadata level, that that help you understand that you know each row is an individual transaction.