Why Would Documentation Drive the Implementation? What Our DAIS Booth Taught Us

The Question That Stopped Me

Most people who came by our booth at Data & AI Stockholm asked one of two things. What is Daana CLI? And how does it work? Good questions, and the right ones to start with.

One visitor asked something else. It went roughly like this: why would you want the documentation to drive the implementation?

That one stopped me, because it skips the what and the how and goes straight at the premise. Most of us were taught that documentation comes after the build, if it comes at all. Our booth wall asked "Your AI knows SQL. Does it know your business?", and here was someone asking why we'd turn the usual order around. It's a fair question. The best answer I have is what happened at the booth that day.

The Partner Who Ran to Get Three Colleagues

The same day I was talking to two people from a data consultancy, one of them its founder. I gave them the two-minute version: you decide what things mean, you declare them, and Daana generates the business layer from that.

I didn't get to finish the sentence. The founder asked me to wait a moment and ran off. Shortly after, the two had become five, with three more people from the same company, and I started again from the top.

They got it quickly, and they were excited about it in a way you don't often see at a booth. One of them reached for a comparison. It was something like: this is Lovable for a data platform.

If you haven't tried Lovable, you describe an app in plain words and it builds it for you. As compliments go, it's a generous one, and I won't pretend I didn't enjoy hearing it. Whether it's right is another matter.

A Front-End Name for a Back-End

On the other side of the booth, Patrik was having a very different conversation. A visitor whose own product is built on context graphs said, kindly, that we'd never be sexy doing the back-end. No criticism meant. It's just how it is: the front-end always gets the credit.

Put the two conversations next to each other and they make a nice pair. Same day, same booth. One visitor tells us nobody gets excited about back-end work. Another gets excited enough about back-end work to go and fetch three colleagues, and the best word one of them can find for it is the name of a front-end builder.

I don't think either of them is wrong. The back-end doesn't get the credit. And when it finally gets some, it seems to arrive in the front-end's vocabulary. I'll take it.

What "Lovable for a Data Platform" Gets Wrong

The scepticism I heard most that day went the other way. People wanted to know how a whole business layer could possibly be generated automatically. Fair enough. My answer was that yes, it's generated, but a person makes the decisions at every step.

Someone has to decide what a customer is, when an order counts as delivered, and what the business means by churn. Those are judgements about your business, and no tool makes them for you. Once they're declared, Daana generates the business layer from them: the part of your data platform that describes the business in its own terms, roughly where silver sits if you think in bronze, silver and gold. We call it DAB, Data According to Business. The thinking stays with your people. What Daana takes off their hands is turning those decisions into tables and code.

So the comparison flatters us in one place it shouldn't. I'd push back on the idea that anybody can now build a data platform. You still need people who know the business and engineers who know data. What changes is where their time goes: into the conversations about what things mean, instead of building the business layer by hand.

What Made People Lean In

What made people lean in was one point: adding context on top of a data platform won't fix the problems AI is now exposing.

The way one of the speakers put it, AI doesn't create the faults in your data foundation. It makes them visible. I think that's spot on. The definitions nobody wrote down, the two teams counting the same thing differently: those were always there. A dashboard could hide them for years. An agent answering questions in plain language can't, because it repeats whatever the data says with total confidence.

Their conclusion was that you have to start by defining what things actually mean. Layering more context over a foundation that hasn't done that gives the agent more to read, and the same faults underneath.

Lead With the Outcome, Not the Mechanism

We also learned something about how to explain Daana. When we got into how it works underneath, we lost people. Patrik found the same thing. The broad picture of agents working from metadata that generates the business layer landed well. The details below that did not.

When we led with the outcome, a business layer generated from its own documentation, people leaned in. And that is my answer to the question that stopped me. You want the documentation to drive the implementation because then they can't drift apart. Change what a term means, and the business layer is generated again from the new definition. The document stops being a description of the platform you hope is still true.

We also heard, from at least one visitor, that they had built the same thing. I'd like to compare notes.

The Candy Verdict, and an Invitation

And then there was the candy. The boxes said "Data without meaning is dead", and the candy inside was shaped like skulls, which we thought was a decent Halloween joke. I came away thinking it wasn't that popular. Siavoush says everyone he talked to loved it.

So the three of us who ran the booth still can't agree on the candy. We do agree on what people asked us, and on which question was the best one.

If we talked at the booth, or you wish we had, I'd be happy to pick up the conversation. Get in touch at daana.dev.