About this talk
This talk introduces Sphinx Needs, an open-source documentation framework created by the Python Foundation, and explores how it can leverage AI for improved traceability and automation in documentation. The speaker discusses the Docs-as-Code approach supported by Sphinx, which allows developers to write documentation in Markdown or reStructuredText alongside their source code. Daniel elaborates on Sphinx Needs as an extension that integrates requirement engineering into the documentation process, enabling traceability across multiple project components. He also presents Pharaoh, an AI framework that assists in managing requirements and highlights additional tools and extensions like UbiCode and UbiTrace. The session concludes with discussions on the future of AI in documentation practices and the need for responsible management of automated agents in software development.
Full transcript
[music] >> So, yeah, welcome everybody. Thanks for having me here and I'm I'm glad that you are interested in in Sphinx needs and how maybe AI can help um to get traceability and automation out of it. Um I'm Daniel. If you have any question during the meeting or after it, just ask. It's more discussion here and I'm a little bit old old-style guy. I love to have
a um TOC at the beginning. So, what I want to talk today is about um at first the Sphinx needs introduction, what it is. So, may may I ask a first question to you, who of you knows Sphinx already, the documentation framework? Okay, good. And not so much. So, I thought. And Sphinx needs? How many of them? Okay, good. Good to see. Then you are right here
for also all the others because then you get some introduction of what it is all about. Um so, what we have achieved in the last years and what we have built there. Then I talk a little bit how we can already use AI today with Sphinx needs docs-as-code approach and everything like this. And I will also present you to an AI framework um called Pharaoh um which
can be used together with Sphinx needs to get some nice um feature and um other stuff out of your um traceability documentation. At at the end, I want to ask some question or raise some question and propose some solutions for the discussion how AI can be somehow documented in a safe way and if this is even needed. So, that goes into the direction of um into the
future where we want to end at the end. Um but let's start. Okay, good. So, Sphinx itself is an open source framework created once by the Python Foundation um to document everything. And as you can see the Eclipse core project is using it to create the complete documentation website and everything like this. So the website here you see is the outcome what is capable to do. That's
not so interesting I would say a lot of software is doing the websites. The nice thing is you see on the right side that is following a docs as code approach which means that you write your in a markdown or restructured text file, store it together with your source code, with your test inside your repository, and out of this then you generate your website, your PDF, whatever.
The good thing is that this format you focus really on the content as a developer who's writing this. You are not caring about colors, if something shall be bigger written or smaller and and everything like this that's done automatically by some theming. And that's great because it allows the developer to follow also the developer workflows for documentation. So this means when you store your documentation artifacts, whatever
they are, requirements, test case results, project handbooks, you can build them together with maybe your change request which you have created in GitHub. And then when you have introduced a new feature you can say okay the code is there for the new feature, the test cases are there, everything is green, but wait there is no documentation. And this means okay you can also stop then the pull
request and say okay please make an update. And that's much better if having the documentation of a feature maybe in a wiki system which is not in sync with your code. Sphinx needs is an extension for Sphinx and it brings yeah some kind of requirement engineering ALM however you want to call it into Sphinx itself. You see here also an example from from the score project. Above
you see the source code how it is and this is a stakeholder requirement here which is written then you can set different metadata. You can have here a content which can be everything which is supported in Sphinx and Sphinx can really support a lot. You can add images, PDFs, tables. So you can have one line or you can have pages of information inside your your requirement for
instance which describes this and at the end you get then here some output. So this box is then in this case a stakeholder requirement in your documentation containing already links which are coming in here. So they are not defined here because this is a feature in score which is linking against a stakeholder requirement and this is a mentioned here and then you get all the information in
your documentation. And from this object tens, dozens, you can have hundreds and the biggest project we have with a customer together is that they are maintaining 100,000 elements inside a documentation for ECU project inside it and build it. So it can become quite huge. So as a recap, Sphinx needs is a Sphinx based extension for requirements. Sphinx is a documentation builder. Really a great software already a
lot of time on the on the market and well tested with a lot of projects, extensions, everything like this and it's everything stored in Git so that it can also be tested against certain rules. What I also want to show you is another extension also for Sphinx. It's just called code links which allows you to have some markers inside your code. This is here. Um where you
can really say, "Okay, this marker, please get me this out of my via a statement in your documentation where you say, "Please trace me just the project which I have mentioned here." And then you also get again Swings Needs Objects. Um the good thing is you can link Swings Needs Objects. So, when you have this implementation here, you can link a requirement, a specification, architecture element, test
cases against it to get the complete traceability in So, this means that you can really not only have parts in your documentation, but information also directly in your source code, which allows you for instance to maintain your test case description in your test files and not in a separated file or something like this, which makes it then also easier for developers to develop this test case because
the description is just above the code. what Swings Needs really do at the end is it creates a traceability graph, where it gets a lot of information inside it. What we just have seen is that we put something from AST files here from Swings, which goes inside it. We have seen code links here from source code, which is also Well, what is also there is Swings Needs
Test Reports, another open source extension, which which grabs um test case results from your test framework like Google Test or something like this, the JUnit XML format, and then it can link this result against your test case to really say, "Okay, these test cases which you have defined here for this specific release are all green or some are red." And then for sure you can also do
some more um automation, where you can say, "Okay, if all my test cases are green, then the linked specifications are also somehow closed. And if all my specifications are closed closed for specific requirements, then please automatically close me the requirement." That's that's doable, or you can even test it and say, "Okay, I have a requirement inside my release, but I have red test cases, so please um
report this somehow." what you can also do is you can integrate um external information. We have an ex um export-import format called Needs JSON, which we um can create, but also import from different sources. And different sources can also be another Sphinx project. So, what we often see is in a new system project that you have component projects and component documentation, which are very team related, so
that they have a really specific scope and are quite small and can be built and therefore quite fast and developed quite fast. And then you integrate all of these component documentation in some kind of a system documentation, which summarize everything, then you get a complete uh documentation and traceability of your system and everything is is then there available. And on the right side, you also see here
um what you can do with this traceability graph. It's not just as you get the square boxes with this information of each requirement, but you can then get tables out of it. You can have here the need flow. It's it's really small, but um pie charts, bar charts, so there are a lot of options what you can define in your documentation, how you want to have your
information then presented. Um and if you want to go into more details, you see there's a link and the QR code for the our Sphinx needs um test demo project, which also have some A-Spice related information, so you can go into it. Um what I need also is to highlight um because yeah, it's it's a topic also always on the Eclipse conferences, how to make money a
little bit with uh Sphinx needs and have a revenue stream. Um above this open source values which Sphinx Sphinx Sphinx brings us, we have created some extensions which are also relevant um for AI in this topic of this speech here. Um so, for instance, we have created UbiCode, which is a VS Code extension, um which helps developers to get information about their traceability as fast as possible.
So, UbiCode is scanning or creating the same traceability uh graph, but it's not based on Sphinx, which is written in Python, it's based on Rust. So, we have done the task which Sphinx normally is doing maybe in 20 minutes for a really huge project, we have done in 3 or 4 seconds. So, that when you type, you get directly information about what is wrong, are you allowed
to set a certain status, is the link correct, and everything like this. So, everything regarding shift left to get information when you really write stuff. Um and because we have this traceability graph, we can also have here features which are really relevant for um AI. And that's is the MC key um protocol for agents and also to provide a command line tool, which also can um agents
then invoke directly. Um just to make it complete, we have UbiConnect also, which provides you some connectors to other tools like doors, Jama, Web City, and and so on. And we have UbiTrace, which is um I I would call it summer or management app, um because this is um because managers don't like to often Yeah. Make changes available in code and and follow a pull request. So,
what they want to see is is a website, and UbiTrace is collecting all your traceability graphs from all your versions and make them available into one tool, so that you can really have access um on history data. So, you can say, "Hey, I don't know, 3 months ago we have uh two um 200 open requirements, now it's 150 requirements." So, that you can make comparison against history
data. And also authentication is an important point. So, when you have for instance um supplier um relationship and want to say, "Hey, certain information shall be kept inside our company, but we need to share other information with a supplier or OEM or customer." Then you can con- configure it on a role-based access management. And we are also planning for the future, we are working already on it,
to make certain things at least editable with a not boxes code approach um but therefore more later. Um Let's come now what we are currently doing with Sphinx needs related to AI and the question is it good or is it not good? It's great, to be honest. So, um AI loves Sphinx needs or in general every boxes code approach. Um first of all because it's all text
and text is really something AI really understands quite well. The next thing is that Sphinx and Sphinx needs are based on restructured text, which is a format and standardized and documented. um it's quite easy for AI to read the documentation to understand it. But the good thing is that as Sphinx is already, I don't know, 15, 20 years old or something like this. Um There are over
100,000 projects available in the source code. So, each model you find outside there has training data of AST data and everything like this already inside it. So, it's understands immediately all the syntax what it's needed and as Sphinx needs is 100% um client to to AST, it's also understands all the traceability and and all the mechanisms Sphinx needs provides here. So, it can scan AST files, but
if you have 100,000 of your AST files, it's not a good idea to ask an AI agent to to index everything of and read everything because then the context gets um to be quite and it will forget a lot of information. So, therefore Sphinx needs also can be filtered and by tools. So, MCP and and command line tools I just have mentioned with the help of Ubi
code, which is by the way completely free available for open source projects. So, all our tools may not be open source, but they are available always for open source projects um so that you can directly download it without any registration, test it and and yeah, use the benefits you may have there. And at the end as Sphinx needs has a traceability graph, also information which the AI
is creating can be validated then. So, when an AI is creating requirements and linking it against an architecture and then linking it against test cases, all the linkage, all the rules you may have defined can be tested so that then AI really creates process compliant output, um which makes it also great. And for sure there are a lot of Docs as Code examples out there to learn
from. So, you can easily say when you work with an AI, "Hey, I've seen an example of this what I want to establish here there. So, please take a look how they have done it and then establish here." It's working pretty well and everything you have is locally because it's in Git. So, you can also execute this with local models and no internet connection, needed so that
at the end you only need one tool, your IDE, which can has access to to AI, which has access to all the files, the RST files and Sphinx needs files to deal to regularly your project management there. Good. Um what we have created is in the last days and that's a little bit bit updated here because um yeah, AI is changing a lot. It's it's in really
in weeks. Um we have created an agentic system called Pharaoh, which is able to read RST files and do a lot of of stuff for you and it is also completely open source. It's it's under the MIT. You can um clone it. You can then ask Pharaoh directly for instance in VS Code to set up it and install it maybe in a project called score. Um you
wait some minutes when it's figured out everything and at the end then you open your project and can start asking question. So, on the left side you see we have asked um Pharaoh what it can do. So, it can help you for instance to trace information. So, to say, "Hey, I have here a specification. Is all the linkage complete complete or is something there missing?" Or you
can also ask, "Hey, I want to change something." We We later see an example of it. "What impact does it have? Is it a good change, a bad change? Is it okay if I only change this element or do I need to change so much more?" So, there are certain features, agents available which really help you to deal with your data. So, you don't need to write
maybe your things needs code and your documentation on your own. You just argument discuss it with with an agent and the agent is also asking back if you maybe miss some information which are process relevant. And also the far all stuff has access to certain tools like MCP and the command line tool and as a fallback it can also pass files directly. But that's we will later
see is not a good idea to rely only on this. So, here's an example of a life check what we have done in the score project. So, where we check okay, check me the stakeholder requirement for a platform one time determinism and this here is then the output. You can see in this line that it's really query the UB code MCP server to get the information for
this specific need and does not scan all the AST files to find this specific lines. And then it does certain tests for are all the fields set is are all the features which are linked fine and have a good valid status. But for sure mostly AI find something. So, there are also some some findings where it's saying, "Hey, every other stakeholder requirements have a field called valid
form. This one does not have it." Maybe it's a good idea to set it or not. It's It's It's up to you. Another example is a change report. There you get a lot of information out of it. I just have copy paste here the the summary and they are simply ask, "Hey, what if I change the AZD status to ASLC requirement here?" And the output is, "Yeah,
it's it's not a good idea to do this because this feature is linked to a stakeholder requirement which is ASLB, so you have to change the stakeholder requirement to ASLC, but if you do this, then there are links back to other features which are still ASLB, so you also have to update them. So, at the end you end up in at least reviewing over 20 objects to
be sure that this can be really be executed and meet." And that's already quite quite helpful to get such information, especially as a developer maybe who starts in such a project to really understands what the complexity is and and what to do and maybe not to do. AI is often the question, "Does it work or or does it not work?" And then you can have an agent
and you ask yourself, "Okay, that's a nice play around nice examples." Um we have had a Sphinx needs user group meeting last week where over 40 people came in. We have also there a workshop to build um some piece of hardware and I just show you the image what we have done. We have um created a park assistant. And we just used Pharaoh and AI and we
only defined requirements. So, what this is doing it has here a time of light sensor which is measuring the distance to my hand and as the car is going to a wall, that that's the scenario here, if it's getting closer then please change the color, make also some sounds. I have the hardware with me, you can test it later if you want to see it. And um
in this workshop we really started from scratch and just saying, "Hey, we have a display here. This is of this type. Please show me the information there. And there I was really capital to create from our requirements step by step the certain needs. Um without yeah, writing one line of code from our own. So, it's all right coded for sure. It's not based on the Eclipse core,
on a huge middleware. That's too much for such a short um workshop. But it was really amazed to see that requirements really change something in your real world. Um get information of it and and and also show something Um there was also a presentation by Erwin Roth from Audi. Um he has tested Pharaoh and other AI frameworks and approaches uh to figure out what is best for
their use case. for me also surprisingly um it was um in the moment. Um so, that he tested if every scenario with cloud code and superpowers or you also tested if I think gets done um are really finding all the elements because missing some elements is um bad for safety. For sure, if you want to make an update and you forgot about some requirements or some architecture
elements, that's not good. So, there were some tests and and Pharaoh was the only one which um triggers everything. Uh but at the end also he measured the tokens which were used. So, as you can see, Pharaoh he has used 11,000 tokens in his tests in this particular one and all the others has taken more up to nearly 70,000, so six times more. much um worse um
results at the end. So, which is also a cost factor if you really use MCP and then command line tools with your AI together. Okay. Um but there is not only Pharaoh. So, there is already a small Swings Needs and AI ecosystem, I would say. Um some similar is a sys pilot, which is also based on on on Swings needs to get some stuff and this is
created by Georg Dolfon Microsoft, the CTO of automotive there. It's a private project totally for testing stuff. So, nothing official by by Microsoft, but you can also scan it. It's open source. You can play around with it and see how good it works and there's also an AI memory protocol um available based on Swings needs um by Baratos. Um which also works well and for sure there's
our Ubi code tooling then, which really provides an That's the current status how we have used AI together with Swings needs and what Swings needs is. Um doing the workshop, doing all the discussion we has had um we ask ourselves certain questions because we have done so much um safety related discussion regarding requirements traceability um that we ended up asking ourselves do we need to treat an
agent definition the same way as we do it for software? So, in the software the holy goal is that um each line of there can be mapped to a requirement at the end. Where you have the motivation why this line is there, is it tested, was the test successful, everything like this you want to have at the end. The question is do we also need this for
um an agent definition? If you have an agent defined in 500 or 1,000 lines and this is used by 500 people in your project who can make changes to it, who writes it, why is it there? Can I change something without maybe changing um destroying the use case of another team? That's all something um we ask ourselves and we don't have a um question yet. And also
what we want to know is um the execution itself. Does it need to be somehow fulfill any rules to to become at at least a little bit more safe as it is currently? So, do um define how the tools are used in the safe way? Do I need to restrict the scope which can be accessed? And when I restrict something like this, do I also need to
monitor it at the end? And say really, okay, the tool usage which I have defined at the beginning was also respected by the AI agent and I can prove it and can document this. All open question, currently I would say not solved yet. And at the end, the question of all is who is responsible for the agent code? Currently I would say it's the engineer, I hear
mostly, because they say, "Okay, agents are just helping you, but you are responsible at the end for everything." But I also had a discussion with engineers who are became already just reviewers, getting a lot of um AI stuff and doing reviews of pull request with thousand of lines of code, pushed by the management to integrate it, because they want to see new and then suddenly the reviewer
is is the the person which is reliable for the quality, but also stopping everything, the bottleneck in the company to get new stuff inside it. And for sure this is job nobody wants to do more than maybe two or three weeks. After that you will have a burnout um so this can be the solution. So, the question is will this move maybe one day to the IT
department who's defining all AI agent or can the AI AI agent be self be um reliable for this? And at the end then also put in front of a court and go to jail, I don't know. Maybe that's the beginning of of a Skynet and the Terminator stuff if it matched to us. and the question is also, do this change over time? So, currently I would say
the engineer is responsible, but how does it look in future? Um so, what we want to do and what we are already testing and planning is that we say, "Hey, we have requirements. We have the Swings Needs Framework or possible framework um which is able to to create requirements, architecture, everything in a visible way. Why not define our agent there as well? To have options for instructions
um for an agent. You will later see an example how this looks like and then it's part of your documentation, of your Swings documentation. And maybe in your Swings documentation, you have all your requirements, architecture, test already defined like in score. Maybe you also have defined your processes, how you work. Maybe you're not using stages anymore, the famous tool for process definition, but you have defined it
also here the steps and roles. And maybe you also have done the tool qualification here to say what I'm or yeah, how I'm allowed or forced to use certain tools like a compiler and maybe don't use certain options there. And if you have all this information available in objects like by Swings Needs, we also can create a traceability between all of them. So, that at the end
we can say an agent then here, "Hey, we don't need to tell you how to do something. Just look in the process we have written for humans and act like There all the steps defined, there are all the artifacts defined how it needs to be looked at the end. And for some of them, we already have written tests. Just look into the tool qualification which tells you
how to use a tool and what not to do. And so, that you can really use all this to make a somehow good agent which feels a little bit more safe. It will never become safe for sure, but we go into the direction, hopefully. And then, as everything is stored inside Git, I forgot this. Um this information is available in certain tools, so that you can say,
"Hey, the developer is using an IDE to maybe invoke an agent, but maybe the system engineer is using a web app or something else to invoke the same agent with the same rules that can then be interchanged." So, [clears throat] what we have done is we have defined, just as a test, a model for agent where we say, "Okay, instructions, skills, and tools." This is what we
currently describe in Markdown files for an agent. So, this is also what goes into the context. But, we wanted to have the motivation out of it. So, we say, "Okay, we have also created a story which describes why we want to have a certain line or certain feature into inside an agent." We have this this linked then with a specification to exactly describe what tool maybe to
use for this and roughly how, and then this is all linked then to those certain elements which getting really important for an agent. and then, if you have done this like this, we can create agent families, we call it. So, Faro maybe one of those, maybe there will be an A space agent, trustable um framework software framework maybe be in another. It's it's independent because we have
this model and we can define whatever we want. And then, what the user is doing here in the end, saying, "Okay, I want to have maybe Faro. Here is my project repository with my source code, with my test, with my documentation containing requirements, processes, and whatever." But, then you also get here on under my AI the Faro with all the agent definition and and AST files. And
and that's important that this gets really copied completely over to the user repository because I never have seen a project using the same process and all the same workflow and everything like this. So, therefore, um you will make changes to this at the end. So, therefore, you need to have complete um access to it and be here. You have to complete control. So, how does it look
like in reality? Um that's just really a prototype. So, uh it's um just the beginning. But, I've created here an agent called it Ruby flow as working title. And then, I created here a description of a roughly one, but the most important point are here the links. So, applies is linking to certain instructions um which this agent is pulling in. So, there can be a second and
a third agent pulling in different instructions, but also reuse already existing instructions. And it employs certain um uh skills which then describes how to use certain tools and everything like And this link- linkage describes then how the agent really then interacts and what the content Thanks and the description out of it is at the end. So, that um here's an instruction which was linked for for guide
you through an um with five steps uh through some kind of of workflow. And there you can see also it implements a certain specification here. Here's the linkage for the traceability. And it is used by this agent here. Um so, now when you have a second and a third agent, you would also see this here. So, you know, maybe as a developer, I want to change maybe
this instruction a little bit, but suddenly I would organize it. Architecture agent is using it, the testing agent is using it. Maybe I should talk with the teams if this is really something I should do or maybe make a copy of this instruction and then pull this in and not the original one. And how does it look like really then in the source code? So, I've opened
here VS Code. You see here the AST code. This are our flow instructions we just have seen with all the linkage implementation, description, whatever. And on the right side, we already see the traceability tree provided here by UbiCode. Um where this is our instruction here, which is the same here on this side, but you can already see, okay, it's got pulled in by our agent above here.
it's implements here the the specification, but you also see the next level where it says, okay, this classification is linked against the story and therefore the motivation. So, we have already here the complete traceability tree for this instruction used by by the specific agent. Good. So, that's all theory. I mean, we can create it like this in Swings needs, it's not a problem. We can get the
trace the traceability tree and and all the data inside it. All doable. The question is, are our models or the co-pilots and then everything on the world able to deal with it? So, what the current status is is that we say, okay, we put everything into an agent markdown file, what PowerUse currently doing in the the current version, and then co-pilot is is interpreting it it's it's
it's calling it and everything It's it's great because it's easy to define. Just one markdown file, paste everything inside it, agent acting like Um it's not so easy to maintain if you know you are in a big project with a lot of developers and you don't know who's responsible for what and and also not to trace. And also problem is this file gets completely interpreted by the
LLM at the end. So, this means it's it's reads it, it's tries to understand the context, it's tries to create a workflow out of it, it's tries to understand what tools are allowed to to use, and then it may act like it or may not. Uh it mostly at the beginning, first time, second time, it's it's working like this, but after a time you will recognize that
instructions get lost, tools are used a different way, stuff gets added magically. Um, so that's not a good solution. So, what we tried here is um to say, "Hey, let's make it differently. Let's say in our agent MDP, because this is the interface currently for all the co-pilots, um there's only one rule. And the rule is saying, please ask the MCP server for Swing's needs to provide
you with all the instructions and links elements for for your for your agent." So, that this is one call. The MCP server is filtering for the agent with with the linking from above, and it returns all these elements back to co-pilot, and then it gets maybe 20 instructions and maybe uh five skills, and shall act like this. Um, at the beginning it was looking really good, to
be honest, or I was blinded a little bit. Um, and I was also able to say, "Hey, for each task you execute somehow, please give me the reasoning." Saying, "Hey, you are doing here um a repository um check. Um, why are you doing it?" And it's was referencing the instructions with the direct um correct a location in the source code and also the skill, where it was
saying that based on this I am doing that. Um, that would be great, but it was not always the truth. And it's also forgot a lot of stuff, to be honest. Um, because reading information from here is not the same as reading information from there. that's part of co-pilot and all the others, because they say, "Hey, the agent and the file is telling me what to do,
and all the rest is somehow content I need to interpret, I need to work with, but it should normally not contain instructions. It can do, and it's working, but it does not have the same level of priority, and therefore your instructions are have the same priority as maybe a text file it reads in or what whatever. And therefore it has really forgotten a lot of stuff. Um
it was excusing a lot that it has forgotten a lot of stuff, but it never learned and make it better. And now I come to the last slide um and this is what we are currently testing in a prototype is whenever we as tool developer has a problem, we make it more complex. But luckily um we do it for ourselves and we try to keep the user
interface still be easy. So what we are currently are implementing is um we have still our user prompt. But for instance Copilot has a mechanism called chat participant which is an extension and the chat participant allows us to call code. So Copilot is not calling an agent directly on an LLM. It's calling our code first and our code then decides what we want to do. Um this
means what we do with a deterministic code is when we get a and we know it's an agent, we say hey via our code ask um things needs again maybe via an MCP, but also via a normal API what are the needs, the instructions you want to have. And this we get as as return back and then we call the agent. But also for the agent, the
chat participant allows us to completely define the scope. Um which means we can say okay, what are the skills and instructions we want to put in? Do you have any history from from chats before or do we to completely wipe this out? So to really focus on what we give you. We can say what tools are you allowed for this specific task to have. Maybe a step
for an architecture is using different tools as as for testing Um and as we may have the link to tool qualification in the same um repository, we can also fetch this data via a deterministic way and integrate it into The same for files. We can also say, "Okay, you as with this architecture-related call are only allowed to read and change architecture file. Everything else don't do it.
Don't touch it. Don't even look at it because it may confuse you." And the last thing is um often agents are breaking down a task in in subtask. So, we can also control this. Maybe also related to processes we have defined in our documentation. And to say really what is step A, B, and C in this order and don't skip any step. order it a different way.
Just execute And so that at the end we have full about 100% of the input data which really goes to an LLM. Which does not make it safe, but again, it's hopefully brings us a little step nearer so that this is possible. And the good thing is also the output from the LLM is not directly going to the user. It's again going to our little chat participant
script with all of our code. So, as we know what tools are going in here and also instructions and all the files, we can check for instance, have you really only touched architecture files or have you done something else? Have you invoked tools which were not on the allow list? Or have you invoked them differently with flags which are not allowed? So, this we can all monitor.
We can check against an ontology if for instance requirements were created with Sphinx needs in the same way following all the rules. We can do this automatically so that at the end then we decide what really gets back as an answer to the user prompt so that we can somehow validate a little bit that the input really was respected LLM call. And that maybe the answer and
the result somehow trustable a little bit more is throwing a prompt at an L&M. And that's it. So I'm really happy to maybe discuss more ideas or problems you see with this approach. You can contact me via email or just here and spend you a coffee. Shall be great. So thanks for having me. >> Thank you. Thank you so much Daniel. Really. >> [applause] >> I will
just give you the the mic just one one minute. I love the work that you are doing and I have one question for you. Sam Shilais from Microsoft calls it too many mental calories. So you you have now thinks needs is amazing, right? For organizing requirements. You now have an AI generating 500 requirements perfectly. How does the human in the loop manage the 500 requirements of for
safety standards with so many so many speed that the AI can generate? Ever are you thinking about that? I have no answer for this. This is totally under discussion. So we also call it the dark factory for software creation where we say there's no human more involved and this maybe eventually happen one day that you just write review the plan what the AI will do and what
changes it will will do but at the end then you trust just your automatically testing and and and your ontology test and whatever but never take a look on the software again. Maybe that's not the case for all the software. Maybe safety is special or SLD only. I don't know but I know already white coding is a lot used in in tool development for where you just
want to have small scripts. Maybe a quick dashboard about company data and nobody's taking their look into the code anymore and I think this will grow. And um I think you have more trust the trust the process and your testing and not to the manual reviews anymore. >> Yeah, thank you very much for your presentation. We are also having havingly using things needs in our proprietary solution
as well as an S-Core. One thing I do not know, maybe you have some answers. We have several initiatives like Open SOVD, like S-Core, like other things. How can we combine them together? Because at the moment we are focusing, let's say, on one GitHub organization, yeah, then you have all the traceability done and so on. And then you have another initiative like Open SOVD has also the
same thing. How can we bring these things together? Is there an answer from your side? >> No, it isn't. I mean, this is a question for me is also what is the motivation to bring them together. Does it mean that they need to follow certain templates and the same process? Or is it just to learn from each other so that it's more a community event where you
invite everybody and to just talk about the tools you are using. >> Yeah, at the end of the day you have a product which is then shipped to somebody, and then at the end of the day you have to be or show evidence that everything is fine, yeah. So. >> Okay, good. So, this means that the meta model which is used in all the projects needs to
be somehow mapped together so that you can make an overall statement about the traceability and everything I don't have a because I also have made the experience that our users and then customers are always asking for a reference implementation to start with something But also already after 2 weeks they start to evolve from it, how they call it and they change it for their own needs and
suddenly they have created their own meta model which is not any more compatible to something Yeah, it's it's a discussion. If this is okay and and needed much more than a standardized maybe the trustable software framework is a solution for this is really have a strong mythology We have to see what what really if if Which means >> Any more questions? No? So, thank you again Daniel.
Amazing amazing work and amazing session. Thank >> Thanks.
