About this talk
This talk explores the concept of using domain-specific languages (DSLs) in conjunction with artificial intelligence (AI) to enhance software development processes, particularly through a spec-driven approach. The speakers, from TypeFox and Cognizant, discuss how traditional specifications can evolve into AI-supported code generation, emphasizing the importance of clarity and structure in specifications. They introduce various models of spec-driven development, including 'spec first,' 'spec anchored,' and 'spec as source.' By employing DSLs, they argue that developers can reduce ambiguity while maintaining a balance between formal and informal language elements to aid both human users and AI agents. The presentation also highlights the Cognite Design Language, a specific DSL developed for streamlining app development in industrial applications, showcasing its advantages in creating consistent user interfaces and reducing redundant code.
Full transcript
[music] >> Yes, so welcome everyone to our session on AI with DSLs in a spec driven way. Uh this is uh really exciting for us because it's uh we are from two different companies, TypeFox and Cognizant. And this is the result of an informal discussion that we've had and which led to the insight that we have a lot of very common ideas and yeah, that's what we're
going to show today. Um So, Andy. Yes, thanks Miro. I thought we'd introduce ourselves. I'm Andy. I I I work at Cognizant for a few years uh giving giving science advice to how we build DSLs, but I've got quite a long career in programming languages. I was at Microsoft for a long time and before that at Cambridge. I've got a I'm a I'm a In terms of
open source, I think my my my sort of key claim to fame, which is very modest, but I'm a Wikipedian and I I created the the wiki page for vibe coding last year, which was quite a hit. Um over to you Yeah, thanks. Um yeah, I've had the pleasure of doing a lot of stuff at Eclipse besides working at TypeFox first as software engineer and co-CEO and
I had a small list here, but then this morning I had the honor of shorting this to just saying lifetime achievement award 2026, which is really great and it's also an honor for me to to do this talk with you Andy. It's a really nice thing. And so let's jump into it. We had the the term spec driven in our title and that's nothing new. There's a
traditional sense of doing spec driven development where we define a specification and that guides our software development. then in that case the software that results from that, the code is what we then test and deploy and further evolve. And so in a sense we can say that code is the source of truth in this case. And what changes with a new term of spec driven is that
specification can generate code using AI. And ideally in that case, then the specification becomes the source of truth. And I say ideally because there are multiple ways how you can understand the term spec driven in this AI context. It's not a standard or so, there's no standard definition. Here's an attempt to classify it. So, one is spec first where a structured spec is written prior to an
AI assisted coding task. This is somewhat related to planning mode, which means so there is a planning phase where you write a specification for a specific task and in most cases then you throw that away when it's done. Then second is spec anchored where the spec is maintained alongside the code for ongoing evolution. That's again related to agents MD, Claude MD, custom instructions so that or in
general documentation that you maintain along a code base to help agents perform better on that code base, find more quickly what is the relevant information and so on. And you maintain that those markdown files along with the code. And the third is spec as source where humans only edit the spec. The AI changes handles all code generation and changes. That's what we're going to talk about here.
It's somewhat related to harness engineering although that is more generic general. It includes specs, documentation of the project to help guide AI, but also much more like formal tooling to verify that results really do what they what they're intended to do and so on. But here we're focusing on the spec aspect of it. I mentioned markdown. That's the standard for writing specs in with AI currently. yeah,
normally you do that in English. You could also use other languages, but English has the best training corpus in the AI models, so it's often has also the best performance in that regard. But it has inherent limitations or risks. It natural language can always be ambiguous, vague, incomplete, verbose. And there are ways approaches to mitigate that and with different techniques and you do a lot of context
engineering. You Basically the talk from Philip Langer before lunch also was about techniques to make this better using language, but what we want to propose today is to address this right at the language level by using domain specific languages, which again are not a new concept at all. It's it's a long time thing to write languages specifically for a set a class of tasks or specifically for
a domain for a specific industry for a specific set of users. And we don't have the time to go deep in how that works, how these languages are built, so just a quick overview. For a DSL you need to define some syntax. For example, a grammar definition, parser, and AST. You need to define the corresponding semantics and that can include validation checks, linting, static analysis, type system,
interpreting, code generator, all these aspects of a language determine different parts of the semantics of the meaning of that text. And you also need integration. Good text editor integration nowadays using language server protocol. You want to integrate with workflows of the target users and execute it in some way. So, let's have a look at an an example. First, a natural language spec or prompt. It's about banking
domain, some sort of loan application rules and this is we don't have to go into details here, but this is written intentionally in a way that it's a bit vague and also incomplete. And quite typically when you want to address vagueness and incompleteness on the this English language level there is the risk of that becoming a lot more verbose because you have to specify a lot more
to clarify all the things. And so let's compare this with a possible DSL that we could define for the same domain. And it could look like this. Here we have a rule definition with multiple cases and in each case we have conditions that have to be met to enter that case and a corresponding action. So it's quite easy to overlook This reminds you of probably of programming
language, but it's actually a custom-made custom-tailored language specifically for this use case. And of course we want to make it intentionally make it look similar to to other languages, so we don't want to reinvent everything. Second example, we compare JSON, standard serialization format, which is also used a lot in in the context of AI. And this one this JSON object describes a wait until statement and has
a condition. Yeah, it's hard to see. It has a lot a details in what this condition actually is. And a possible corresponding equivalent representation in a domain specific language could be like this. Wait until warehouse stock level times demand forecast is less than reorder threshold. Now it's it condenses down to a mathematical expression written in a way similar to how you do it in a programming language.
This is much easier to read as a human and the nice side effect is that it's also easier for for DSLs for large language models because the token usage is much lower. you express this exactly the same information with much fewer tokens. And so there's also the term token density to refer to this. So, how many tokens do you need to express a certain thing, a certain
semantic property. with DSLs we can potentially reduce cognitive load by focusing attention on domain concepts, on the thing that matter. We can enforce semantic constraints at the language level, which means we can have automatic checks that give feedback to the users who wrote the DSL text or also to agents who generated the DSL text. So, which means the tooling around that is consumable both by humans and
AI agents. So, and AI agents use these semantic constraints to iterate on the result and refine, improve the result until for example all validation errors are eliminated. Exactly the same as AI agents do with programming languages. what I already mentioned, we have similar advantages for humans and large language models. So, for humans it's more about readability and for AI it's more about token density. So, which is
maybe related to each other. Now let's take it one step further. Semi-formal languages is a we we'd like to introduce here. And we define it as notation that conforms to a formal grammar. So, it's similar to a DSL or like a DSL, but with embedded pieces of natural And if we think about it, there every computer language has informal parts. Comments are natural language sprinkled into your
code. Identifiers are names that you assign to a function, a class, or whatever you define. With normally you you compose that of one or more English words or whatever language you write your code in. And so, that also has some informal meaning. And strings that can be strings inside in your code that can be anything inside, but the then of course it depends on how they're used,
but that can also have some natural language inside. And this is essential semantic information. Really important to understand the code and to grasp what it's about, but it's mostly ignored by compilers. So, I comments are usually just thrown away when you run a compiler on it. Identifiers of course important to match a function name definition to to the usage, but other than that a compiler doesn't care
at all how you name your function. That's why code obfuscation works, right? So, you can just rename it and it's still the same the same execution behavior. So, the new thing we propose here is deliberately add informal aspects. Because informal aspects can give more semantic context to the code, either a programming language or a domain-specific language. An An example about that. This is a snippet of a
potential domain-specific language. It starts with a comment to be executed in the user interaction to be describes an action load recent posts within HTTP route and method. And then there is a returns property that just says the 10 most recent posts. And so, it's really impossible for a formal compiler, so a traditional compiler to generate database code from this. It's just a string with some English in
it, right? But a large language model can perfectly understand what returns the 10 most recent posts means and easily generate corresponding SQL code assuming that it has access to the underlying database schema. So, you just give it the right context and and this code snippet and will SQL code. What we get from this is some parts are formal and which gives us immediate feedback when we write
the snippet. We can check if if the syntax is correct, if the route uh corresponds to some rules that we have defined in our project, if the HTTP method is uh is correct. But the actual generating code can still be left to the to the agent. And with this we have a very compact and simple form to express what we actually want without overcomplicating. And so, this
uh graph or this graphics summarizes everything, so we can apply both formal tooling and AI agents to the same domain-specific language. From the formal tooling we get yeah, so immediate feedback with validation errors and warnings to the user and to AI. And we can apply code generators or interpreters to simulate something to run it immediately. While on the other side AI agents can understand the whole picture.
They see the formal and the informal aspects and that gives us more flexibility when designing the DSL also, but also any as a user. When when I want to write something, maybe I can even choose whether to specify the actual action content in a formal way like within a formal mathematical expression or just with a kind of string with English language in it, because that's good enough.
It's It's clear enough what it means and it can write it more much simpler and with fewer tokens or fewer yeah, with in a shorter form. So, and with that we get the best of both worlds. And yeah, next up Andy will show us how this looks like in practice in real industry applications. Great. Thanks, Miro. Um yes, I'm I'm from Cognite and I'm going to tell
you about our DSL, the Cognite Design Language, which is built on top of the Langium framework that Miro and the good folks TypeFox have developed over over many years. Let me start by saying a bit about Cognite. Um we're about 3 years old. We were our our our mission is to improve productivity by initially working with companies that are in the physical world. They've got pipes in
the ground, say, and we build custom apps by automating some of their expensive business processes. And this is a shot from our website. We We work with companies like Cadent that has pipe gas pipes in the ground, Network Plus they've got I think electric pipes, there's water pipes. And then we also work with Tropicana and they have orange juice in their pipes. So, we we we reckon
we're somehow the pipes company. Okay, so what do we do? Well, we we start and we have an interview with our customer and figure out their problem. So, that's this problem space. So, we we talk with the customer, find out what they currently do, which usually involves sending spreadsheets around and having a sort of informal process that's usually error-prone and slow and they'd like to automate that.
And then we use AI to capture that information and to structure it and then basically to turn it into the kind of spec that that Miro has been talking about, which is here, the solution space. And we actually use several DSLs that are implemented using Langium, but the one I'm going to talk about is is our Cognite Design Language, which sits here. And from there we can
turn that into actual implementation code and then we deploy the code in our website and the customer will go to our website to use it and they pay us a subscription once we've deployed it of course and then we will keep it running, we will maintain it, we will make sure it doesn't doesn't go down. So, that's the basic business model of Cognite. Now, I've deliberately made
this strip of what we do quite narrow. Right? In principle, we'd like to be able to synthesize any app this way, but in practice for practicality, we want to start with, you know, a simple uh fairly narrow strip. So, we're we're only building web apps and as I say that we're automating fairly simple business processes. But in general, we hope this message can broad out so broaden
out so over time we hope that this will become a much broader space of of apps that we can we can build. Um so, by about a year in in mid-2024, we were hitting some problems with the apps that we were generating using AI. One of the problems was inconsistent UIs. So, you might have found this yourself. If you get AI independently to generate user interfaces for
different apps, you'll find that it makes different choices each time. And what we were finding is we were getting this fleet of apps and they all had rather a kind of different sort of look and feel, which which just wasn't good and was would confuse customers, certainly was was confusing us. So, that was one problem. Another one was pattern duplication that we found there were some typical
patterns we'd implement again and again for different customers and this was this is inefficient and also it was kind of wasteful. Well, same thing, but it was we we implement them in different ways, so it was just a bit of a mess. So, we wanted to get some eliminate some of those those redundancies. And thirdly, we didn't really capture what the sort of user story, the user
flow that a user would take when using our apps. And so, sometimes that meant the apps just weren't really fit for purpose. They they they they it was and it was difficult for when designers reviewed them to really understand how the AI as it were thought that the user was actually going to navigate through the app. So, that was a bit of a mess. So, our designer
thought about this and took a leaf a leaf from Apple's playbook. So, big companies like Apple also have these problems and what they do is constrain themselves and have the concept of a design language. Um and And this is a a screenshot or this is a short showing the design language of Apple's Vision Pro. Um and it shows like different or sort of uniform ways of performing
different tasks if you're inside Vision Pro rather than allowing it to be arbitrary. So, the the design language constrains how you can do things like, you know, selecting objects or you know, showing showing, you know, maps and so forth or or picking things from libraries. It has a bunch of sort of standard ways of doing things. And this is great in a big organization cuz it means
the designers in Apple have got a sort of a sort of fixed constrained menu of you know, from which they they pick from. And it doesn't it doesn't nail down all the decisions. So there's still room for creativity. It's also great for the user because there's a sort of standard way to sort of select and so forth. So we thought this is a great idea and let's
see if we can come up with a design language for Cogna that would help us. And we had a couple of hypotheses when we were doing this. The first one was that it was possible to do this, that we could encode app intent within a constrained language. Um and to our second hypothesis that went a bit beyond that was that we could actually take that language and
deterministically turn it into UI and and the rest of of the code. So let me kind of um set out the different components within um CDL. Um so there's really three parts I'll talk about. There's data, the data model you're dealing with where you've got fields and you've got relationships. There's data displays, the actual screens or or or parts of screens or tabs within screens where people
can interact with the data and they have filters, you can search, you can sort. And then obviously the user wants to be able to perform actions. So there's always actions that can be performed and that will often involve the user selecting things and maybe inputting additional information. Um and there'll be maybe multiple processing steps. Um and so this loop shows basically what what it's like. It's our
model of interaction with um uh with the with the app. That you always start with data entities then you display them and then perform actions and then loop around. That's a bit abstract. Let me go for a very simple um of of customers with orders. So this is the classic I don't know uh uh business business data processing example. You've got customers with orders, right? It applies
everywhere. Um so we we've got a we'll have a table of of customers as a particular kind of entities and one customer will have you know, many orders. And an order may have a status, a date created and have may some may have some notes. So that's the data that my example is going to be dealing with. Um and this is showing a flow of how the
user would interact with data in the app. So this isn't the the app itself, but this is like a diagram that can be extracted from CDL that sort of shows the user story that's this possible. So the flow we start off that you you want to see what orders So orders have two statuses. They've been Well, they they've been either they're simply received or they're in progress.
In fact, they can ultimately be fulfilled and then they vanish from the system. So they're kind of they've got a simple sort of state uh di- uh state machine that they they pass through. Um and so we're going to have a I'm going to show you shortly um a tab that is a display of received orders and then there's different actions that you can perform. You can
accept an order that takes you further down this path or you can reject or add another one. And once you get to this path, you're looking at the in progress orders list and at that point you can add notes or you can mark one of them as fulfilled. So that's the kind of flows that we want to allow inside this this app. Um so this is Remember
our hypothesis was we could deterministically render and so this slide shows you that where at the top we've got the received orders page and each of these rows is a particular order and in the bottom we've got the in progress orders the in in progress orders uh page. And on the right we've got mobile versions of the same thing. So the same CDL can be rendered in
different ways depending on the the endpoint. Cool. So here is a video showing showing me interacting with the with the app. That that was initially the um the received orders um and then this is the user here I've accept I've I've selected and then accepted one order and then I moved over to the in progress orders page selected a few and I'm going to fulfill mark them
all as fulfilled and so they're going to vanish from the system. So that's showing the flow and it's now looping around. We're back on the um and it's going to select one and and then browse it and then accept it. So all this is deterministically rendered from our our DSL. Um so let me go to that. Before I go there, I want to remind you of an
idea, an important idea that Miro told us about, this idea of a semi-formal language. And I think this is this is a I I think a key idea that really exploits the existence now of generative AI. That CDL represents an intermediate point. It's not the start. The start we just have like conversations with our customer and then we use the AI to to start from that conversation,
understand what the problem is and then suggest a particular app that would meet the need. And we use CDL as a as a uh notation for describing much of the details of the app. So much of it is deterministic. I mean at this point we're going to decide about different screens, but there's a lot that's not yet known. Like we don't even know the the concrete data
format yet. So we need to leave some of it unspecified and that's where we exploit a semi-formal notation cuz you're going to see some natural language instructions that are held within the the DSL. Um so I know this is getting a bit detailed, but uh this is I'm going to have to step down here. But it's okay. I'm sort of amongst you Uh so over here we
got the order fulfillment page that I showed you, right? This is received orders and you've got a bunch of orders there and this has been rendered from this This is Uh and this is a data display which is one of the key components that we were working with. And the Let's just think about the parts in red. So part of this is just deterministic. So this display
name field with received orders determines this heading here on the page and then this actions array here that's got accept order, reject order and add order. That determines buttons that are going to show up on the page and you see them over here. We've got accept order which is the primary one so it's in purple and reject is a secondary one and then add order doesn't apply
to the table but is sort of you adding uh or rather it doesn't apply to a particular or it applies at the whole table level so it's shown up up here. Okay, so this is just deterministically laying out the page. And note by the way there's there's no information about layout or colors or anything within this this CDL which was really great in sort of taking that
off the table in terms of like avoiding arguments about that sort of stuff. It's really just describing what the kind of the logic of the the app is. And then the semi-formal part is is here, instructions. Um this is what's going to happen uh you know, later that the data loader must filter by or rather it's describing what actually appears here and we just say data loader
must filter by status equals received, a bit like the example that Miro gave. And then the second slide when you actually perform an action to accept an order, uh we get to this point in the uh this frame from the video I showed you. Um and again this in the in the DSL here, there's some deterministic stuff like the name of the page and then this message
here which you're seeing there, are you sure you want to accept this order and move it to in progress? So those things are fixed deterministically, but at this point the AI doesn't completely know what the back end is how the back end is going to operate, but it can put in in natural language the instructions that that what the action does. This is like the semantics of
the action that it sets the order status to in progress and the order will move from the received orders page to the in progress orders page. So that's another example of a sort of uh well, example of how this is a semi-formal language where we can um defer some detailed implementation decisions and at this point just say in natural language what the button does. And we can
we can implement this already and we can even have an an LLM sort of interpret these actions on the fly which is really great for our business model because what we do is we talk with the customers as I say and then we want to very rapidly show them the app running or what the app is going to look like so we can get their feedback on
it. And so this is great for this. So we can get this preview of the eventual app really rapidly by exploiting the the DSL. Um so it's really helpful that we can just have this informal material amongst a lot of deterministic uh information. Okay. So some reflections um uh CDL. Uh this it took a while. I remember being part of the conversations and it sort of a
bit of a drama inside our little company about whether we were going to move away from our existing way of generating apps to this way of doing it with um this intermediate language, but it worked out and uh all of all of our new apps since January of last year have been implemented using CDL. Um I think the key you know, gain we got was that the
the system and the people start speaking the same language. So the our our team our sort of forward deployed technologists who talk to the customers, they're not engineers, but they're they're very I mean they're they're technical people, but they wouldn't think about themselves as engineers. They're kind of people people who uh you know have some technical you know background, but they're not so deep in the code.
So, they used to have some difficulty in talking with the engineers about the state of the the code base. But this this really helps because it kind of fixes a particular notation for how at a high level you describe the the app. And so, the engineering team, these these solution strategists I've described, these forward deployed folks, and our design team all could speak the same language and
that was just incredibly helpful. And apps have now become compositions of shared building blocks, which addresses one of the problems that I've I've said earlier. We're sort of there's much less reinventing the wheel. By defining this DSL, we can once and for all define a bunch of different pages that are like uniform across Cognite apps. Uh And finally, you know, it's this isn't the end of the
story. Uh we're starting to bump up against some limitations in CDL, I must admit. So, we're actually evolving it. Um but it's been a great um asset for us this far on our our journey. Um and we we built all this with Langium and I'd like to just pass back to Miro for some final reflections about Langium. Um just a few hints if [clears throat] you uh
are start thinking about uh creating your own language to work with AI, uh what could be things to watch out for? And one is using syntax that is familiar. Uh of of course, yeah, you are inventing a formal language, but in a way it should be close. So, I mean reading it as a human already should be fairly intuitive. That's important. And if it's if it's intuitive
to humans, it's probably also intuitive to AI because it's there's a connection between how you read uh formal text like programming text well, programming languages it's it can be quite special sometimes. But uh for this else, you can make it relatively close to natural language if you want. Or you can make [clears throat] it close to structural stuff like JSON. Right? And what the examples we saw
here, including the CDL, are somewhat JSON-like, but the the key thing is you it doesn't have to be and you can also put in some expressions which can compact things a lot more in a um while describing still describing something formally. Um So, familiar syntax helps to make it intuitive for us and also helps um teaching it to the AI, which I will come back to in
a minute. Then, semantically meaningful keywords and delimiters. Yeah, semantically meaningful then also means in the context of your domain and in the context of the user group you're targeting, it has to really make sense and keywords are yeah, the the main things that define what something is. Like in a programming language, you start a line with function, for example, and then what follows is a function, right?
So, that really makes sense, makes things easy. Then uh you uh want to implement a language server. A language server is a a process that runs in the background and that can receive input from a client. Uh typically, so the origin of that was VS Code, which introduced this concept of the language server protocol. So, that VS Code as a client can ask the language server, for
example, for validations, uh so diagnostics about a document or completion and so on. And so, this is therefore uh really useful to the users working with a DSL, but it's also useful, as I mentioned before, to the AI agent because it can run in a loop uh and uh generate some DSL text, validated against the language server, and uh then fix errors if the language server reported
it. And and so, the language server is a formal implementation. You can do that with Langium. So, Langium helps you to build the language implementation, including these semantic checks. And that is then reported back and it's deterministic, it's formal, it's it's always the same. And the AI agent takes that as input and so, this helps to really improve the quality. Then, keep it simple. This goes back
yeah, similar to the familiar syntax point. We you have to always remember you need to explain this to the large language model, to the AI. And that can be done with custom training like fine-tuning a model or so. Nowadays, in most cases, you would rather just yeah, have a system prompt that that defines and describes to the agent what your DSL is about, how it works, maybe
a short EBNF syntax. And in order to you want that description to be as short as possible so that it doesn't use up too much context window. And so, in order to to ensure a good performance, keep it simple so that you don't need many words to describe it. And by the way, that topic is something Ben over here is going to talk about tomorrow. Langium AI
is a tool that helps with exactly that. And finally, find the sweet spot between formal and informal. Yeah, use the formal parts for those things where you think uh tooling formal tooling like validations, interpreters, code generators would be useful. And where you want to be precise, but stay informal with natural language where it's those aspects are not that important and you just want to keep it flexible.
Good. That was it from our side and we are of course open for questions. >> [applause] >> Yeah. Go ahead. So, you say kind of this kind of semi-formal why not fully formal? Uh if you have a fully formal language, then what you can do is you can reason about properties expressed in it because a lot of time it's not enough to just give a specification, but
you also want to prove that your specification has certain properties. Maybe not for web apps, but if you want to specify a protocol or some more complex algorithm. And as far as the usability goes, I don't see a formal language being harder to understand or to use either by people or by uh or by the agents. Yeah, I think there's a lot to say about that. It's
excellent question, I think. Um Can I take back to our >> Yeah, maybe to the small example in the middle. Um It's Oh, your example. Okay. Yeah, or you can also add to it. Uh Okay. Um >> You go first, Miro. Thanks. Uh So, in the end, what I said is find the sweet spot. And if your sweet spot is to be more formal, then it's good
to do that. And then because then you can apply more of the formal reasoning. And and then if it helps you in your particular use case, then it's good. And you mean you can have a language that is also as formal as possible if you want. The point here is that you don't have to because AI understands also the informal parts. And one possible way to motivate
that is the small example here that I showed where uh this simple statement returns the 10 most recent posts is enough for AI to understand what it what it's meant to to do. And so, writing this more formally would mean that we have to include something like a subset of SQL in our DSL. Like a query language, which is possible, but it's a lot of work to
do that. Yeah, you have to to capture all the different things that are possible in the in this database domain. And here, we just you might just choose to not go that route and keep it simpler if you want. I I have a slight >> Can I just Can I just comment a bit to this because what you're saying that, but the agent will interpret that these
are the 10 most recent posts in whatever way. You don't have control about an agent. An agent can interpret it in a completely crazy way. And if you want to check it against your informal specification, there's no way to check that what the agent has done is correct. >> Okay. Yes, but remember that the starting point we came from is markdown. Yeah, so so the standard way
nowadays to do specifications with AI agents is just English language markdown. Right? And this what we are telling today is you can enhance markdown with more formality. Yeah. Yeah. I mean, in in our use case, um I mean, it's more complicated than this, but but the same principle applies. We actually don't know the schema at the point that we're writing this. Or actually, this is a better
one. Um This information here, at this point we're we're wanting to talk to the customer and what you find is that the the people you talk to in a company, maybe they're not the IT team. So, they don't literally have access to the schema of the SQL database. And so, they don't know. They can maybe give you some you know, Excel file that shows you example data,
but it means that and it it there's a sort of there's an uncertainty about what the actual schema is. So, at this point you can't really be fully formal in our setting. So, by remaining semi-formal about this, uh we can sort of execute it and uh get feedback from the customer, but even at a point where we can't actually generate code or generate a formal spec. Uh
a question to you, Andy. Um on the previous slide, um you mentioned that, for example the actions are placed deterministically you said, right? Uh, yes. Right, so how does it work because for example accept order and reject order is an action on the respective uh, row whereas add order is a is a general action let's say. How does it do that deterministically? How does it know? Uh,
okay. That's a good I was wondering about that. I don't know. Okay. Okay. That's good. I I I I I I won't I won't BS you. I I don't know exactly. I I I I think somewhere else in the file it it will there'll be some sort of type information that Okay, I'm that's my guess is it can figure out the type elsewhere there's definitions of accept
order and reject order and add order and some of these act sort of on individual items and some of them are global and because that one is global it goes up there. >> Okay, that makes sense. Thank you. It's a good question though. Good. Thanks a lot for being here. Uh, enjoy the conference. >> Thank you. >> [music]
