# Building trust in AI generated artifacts: GNAT Foundry - Intersection
**URL:** https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742
**Category:** General
**Tags:** spark, ai
**Created:** [September 14, 2026, 3:46pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742 "2026-09-14T15:46:37Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@markhermeling](https://forum.ada-lang.io/u/markhermeling)
#### Post date: [September 14, 2026, 3:46pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/1 "2026-09-14T15:46:37Z")
We spoke about this on the Ada SPARK Office Hours last Friday (recording to follow). The team at AdaCore has built a demonstration project to highlight how deterministic tools with Ada SPARK can be used to build trust in AI generated artifacts.
[There is a blog post with details.](https://www.adacore.com/blog/gnat-foundry-intersection-demonstrating-trustworthy-ai-development?utm_source=forum&utm_medium=forum+post&utm_campaign=gnat+foundry+blog+forum&utm_id=gnat+foundry+blog+forum)
The repository is here:
> **[GitHub - AdaCore/gnat-foundry-intersection](https://github.com/AdaCore/gnat-foundry-intersection)**
>
> Contribute to AdaCore/gnat-foundry-intersection development by creating an account on GitHub.
I am biased of course, but I think the content is very interesting. It is a full implementation of a traffic light control system. Not full as in, use in a real intersection, but full as in starting from requirements in a concept of operation, to high-level requirements, to low-level requirements, to code, tests, code coverage and all cross-linked with full traceability.
The repository has full automated test and is AI enabled (see .claude and .codex directories). There is a demo-prompt that you can execute to add new requirements to the implementation and the guardrails will make sure that the resulting code is trustworthy.
Have a look at it and dig into the details. The community tools are fully supported of course. You will need to bring your own AI subscription. The open models are not supported yet, will be experimenting with that myself as well.
We are very interested in feedback and to learn how you could use this to build your own control systems with high-integrity.
Like-and-subscribe!
Regards,
Mark
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [September 15, 2026, 5:00pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/2 "2026-09-15T17:00:59Z")
There’s a couple of threads that dovetail directly into this topic:
1. [Best LLMs for ADA (SPARK) - Hobbyist](https://forum.ada-lang.io/t/best-llms-for-ada-spark-hobbyist/4632)
1. Where I suggest factoring out unification (used in DB query and SMT-prover) [here](https://forum.ada-lang.io/t/best-llms-for-ada-spark-hobbyist/4632/22).
2. [[ANN]: adacovex 1.48.0: Performance improvements, more flags](https://forum.ada-lang.io/t/ann-adacovex-1-48-0-performance-improvements-more-flags/4741)
(an Ada/SPARK formal verification and compliance toolchain)
3. Github-repo: [DIANA-2022](https://github.com/charlie5/Diana-2022)
(the AI assisted proposed update for DIANA, @charlie5 & I did)
4. There was a third local thread touching AI, but I can’t find it again…
But, along with some other items, we are afforded some interesting possibilities:
- If we develop a `Indefinite_Graph`/`Formal_Indefinite_Graph` as if part of `Ada.Containers`;
- Tie this with the Verified Unification Engine proposed above, and you have the core of a DB.
- (A possible starting-point would be [MNESON](https://github.com/marius-linguist/Mneson); directing it to update from the Charles containers to the `Ada.Containers`, then working from there… which may or may not be what the `MNESON-2022` subdirectory _is_.)
- Dogfood ourselves: Use the above VUE to implement an SMT-solver, usable in SPARK.
Also it needs to be:
- hierarchical, so that multiple-provers / multiple-instances can work on proofs.
- DSA-able (distributable), so that you can have a “compute-node” able to churn through the hairy/complex stuff if needed w/o having to change the problem.
- Parameterizable, so that you could e.g. prove the body of a `generic`, and like instantiation, check that the supplied parameters ‘pass’.
(IIUC, this is actually beyond current SPARK’s capabilities; it’s been a few years, but the last time I looked into it, SPARK ran over the instances of instantiation rather than the generic proper — probably due to GNAT’s macro-expansion handling of `generic`s.)
- Able to use other provers.
- Able to be used externally (e.g. by GNATProve)
- Combining the above with an updated DIANA, we get a DB-amiable Ada-IR, running on a formally proven DB-engine…
- Add in [this 1987 paper](https://users.ece.utexas.edu/~perry/work/papers/icsm87.pdf) and we get a VCS which _never_ has the _“Oh, be sure you pull last week’s version, Dave broke the build”_ problem **and** applying hooks to gate the final root-ward merge solves CI.
- Combining the above _again_, say with a formally-verified bittorrent, and we have a distributed DB for distributing DIANA…
- This means we could eg query projects on compatible licenses, or (assuming an “interface-checker”) query if updating library X impacts my client’s usage.
- Imagine these capabilities with Alire and/or [AURA](https://github.com/annexi-strayline/AURA) (see [the premise in its documentation](https://aura-docs.readthedocs.io/en/latest/)).
- Remember, DIANA is source-recoverable; this means that given a DIANA-reader it will be easy to spit out text-files for systems that use text-files.
- Given DIANA’s heavy use in the above designs, it may be prudent to consider implementing IDL; though not required, it could be of some use:
- As DIANA is an instance of IDL, we could define analogs for:
- SQL — This would make the above VUE-using DB-engine much more familiar, as all your SQL knowledge could be ‘ported over’, the whole of the syntax, DDL, DML, etc. (The SQL spec is a lot, but I got them on sale.)
- Queries — This would be specifically analogous/applicable to the VUE; being to the mentioned AQRL of [Database Research needs an Abstract Relational Query Language](https://www.vldb.org/cidrdb/papers/2026/p27-gatterbauer.pdf) what DIANA is to Ada.
- Other languages, such as VHDL (which did have one, IVAN), or Erlang (I think it would be interesting to see how tasks could be interfaced to Erlang’s entity-model), or as database-schema updators (the input-form would be one set of structures and the output form would be another set; the IDL `process` would allow setting up the input/output; could possibly automatically output one of the normal-forms).
- I have the Snodgrass book (hardcopy & PDF), the DIANA manual (hardcopy & PDF), and pdfs of the [earlier] definition and tutorial; using IDL on IDL (that is, something to IDL that is as DIANA is to Ada) and we get the nice feature of being able to compose IDL… add in something like ASIS (let’s call it ISIS, IDL Semantic Interface System), hooking into the DB we would essentially get a metalanguage for IDL and be able to manipulate instances thereof… meaning that we could implement “ASIS-2022” as calls to ISIS.
- Apply GNOGA to all the above, and you have a distributed, DB-based, Ada IDE… sans object-code generation, which, as is tradition, is left as an exercise for the reader. 😉
Anyway, those are my thoughts.
---
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [September 15, 2026, 6:14pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/3 "2026-09-15T18:14:31Z")
Presently I am looking to define an abstract Ada library interface and, maybe, provide an implementation of based on Direct\_IO persistency layer. The layer has streams, so it is pretty straightforward to store/restore Ada 2022 syntax tree there, because it can be streamed.
I do not know if DIANA has a stream interface. Streams are Ada 95. But it would be better than clumsy relational DB, IMO.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [September 15, 2026, 6:51pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/4 "2026-09-15T18:51:14Z")
> [@dmitry-kazakov](#):
>
> I do not know if DIANA has a stream interface.
DIANA is an instance of IDL, IDL is a language/method for defining a data-structure [think “abstract data type” which is “implementable many different ways”], which produces (in the target language) the appropriate realization.
For example; in IDL there is no enumeration, however, an enumeration can be inferred via ‘empty’ classes, as per [the tutorial](https://queensu.scholaris.ca/bitstreams/d5567e9e-f517-452b-b6cb-086fe9744915/download) (pg 8):
> IDL does not have a special mechanism for creating enumeration types; instead, the strict class mechanism serves that purpose. If a class consists entirely of node types without attributes, it behaves much like an enumeration type. For example,
>
> ```binary
> operation ::= plus | minus | times | divide;
> plus =>; minus =>; times =>; divide =>;
>
> ```
>
> defines class operation, which serves as the type of the “operation code” field of binary expressions.
and page 16, detailing how “Users can also gain more explicit control by using implementation notes.” — example:
> A note with a name reference usually applies to a named type and all
> attributes of the type; thus
>
> ```ada
> operation ::= plus | minus | times | divide;
> for operation use Enumeration;
>
> ```
>
> says that type operation (a strict class type) should have an enumeration
> type as its representation.
Thus, you could have the Ada-writer default to using `Ada.Containers.Indefinite_Multiway_Tree` instantiated against a base `interface`-type, or discriminated-record, or however you wish to represent them… then simply use the Tree’s stream attribute.
> [@dmitry-kazakov](#):
>
> Streams are Ada 95. But it would be better than clumsy relational DB, IMO.
But who said anything about having it be a relational DB? It could (IMO should) be a graph DB, albeit with a ‘View’ for Relational, Hierarchical, Document, Object and/or whatever else DB-paradigm you need — is it going to be the super-fastest optimized-for-X’s-special-case! No, but we don’t necessarily _need_ that.
* * *
A note on quick-and-dirty implementation of IDL: use the two assignments `::=` and `=>` to collect classes with Maps of `Identifier` → Vector of `Identifier` for each; if the class `Identifier` shows up in `::=` and all of its “decedents” yield `Empty_Vector` in `=>`, you can use enumeration.
```ada
Function Enumerable( ID : Identifier; Classes, Attributes: Identifier_to_List ) return Boolean is
(for all X of Classes(ID) => Attribute(X) = Empty_Vector);
```
**Warning:** _Very_ quick and dirty; there are cases this is wholly inappropriate for (akin to the “just split on comma!” ‘parsing’ of CSV), but perhaps suitable for tinkering or bootstrapping.
If bootstrapping [IDL in IDL, as noted in my previous post], then you could go with a “structure first” approach [that is, the graph that _ **is** _ the structure(s) of the IDL], using the quick-and-dirty to populate the graph, then build out a proper parser/serialization pair. (See _[Pair grammars, graph languages and string-to-graph translations](https://dl.acm.org/doi/10.1016/S0022-0000%2871%2980016-8)_ [[Alt-Link](https://www.sciencedirect.com/science/article/pii/S0022000071800168/pdf?md5=5e0a7bc987269a0256ea017f08b03cbe&pid=1-s2.0-S0022000071800168-main.pdf)] — I disagree somewhat with the abstract: it is not `String` ↔ `Graph` that is of particular interest, but `Token` ↔ `Graph`; drop reading and tokenizing as concerns, considering them ‘already solved’.)
I would proffer that Byron’s `Readington` and `Lexington`, are decently good foundations for considering reading, and a good portion of tokenizing, solved — though I would say that the internals of `Lexington.Token` should be revised: using the 32 bits packed to the the record:
```ada
For Token use record
ID at 0 range 00..31;
Length at 0 range 32..63;
End record;
```
Where ID would, in the overlay-refinement be
```ada
For ID use record
Language at 00..07; -- 8-bits for the Language enumeration.
Lex_ID at 08..32; -- 24-bits for the Token-ID enumeration for the language.
End record;
```
reserving the “all-ones” (`'Last`) bit-value of each Language’s Token-ID for the unprocessed text from the reader, reserving the “all-zeroes” as a `Null_Token`. (Byron’s model has non-emittable tokens and uses them as temporary/intermediates in tokenizing; this makes things much easier afterwards: instead of dealing with `ch_Colon` [a raw/unprocessed colon] at the output, I have all the colon-containing items like semantic-separator `ss_Assign` [denoting the `:=`] in their own tokens, then we can grab all the colons-as-separators as `ns_Colon`, and thus `ch_Colon` appearing in the output of tokenization is in error.)
* * *
Once you regard reading/tokenizing as solved/separate parts you can then use what I’ve been calling the **R1/R2 test** :
- Obtain (Read in, Tokenize, Parse; or otherwise generate) some structure;
- Export the structure, this is “R1”, keep a copy;
- Read/Tokenize/Parse the export, this is R2;
- Compare R1 and R2, pass on identicality.
This testing works quite well for a “structure-first” approach and is essentially equivalent to testing seralize/deserialize round-tripping.
---
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [September 15, 2026, 7:44pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/5 "2026-09-15T19:44:13Z")
> [@OneWingedShark](#):
>
> Thus, you could have the Ada-writer default to using `Ada.Containers.Indefinite_Multiway_Tree` instantiated against a base `interface`-type, or discriminated-record, or however you wish to represent them… then simply use the Tree’s stream attribute.
Well, a naked tree is too coarse. In order to make the tree useful there need to be a lot of additional information. For example, you would like to have a reference to the loop node from the exit statement node. A link from the defining identifier to the statement containing its declaration context e.g.
```ada
type Exit_Statement
( Labels_Count : Natural; -- Each statement can have multiple labels
Named : Boolean;
Conditional : Boolean
) is new Abstract_Statement_Node (Labels_Count) with
record
Loop_Of : Loop_Statement_Ptr; -- The loop to exit
Loop_Name : Optional (Named);
Condition : Optional (Conditional);
end record;
```
That is even without names resolution as ASIS requires. Furthermore, Stream attributes are non-portable.
> [@OneWingedShark](#):
>
> It could (IMO should) be a graph DB, albeit with a ‘View’ for Relational, Hierarchical, Document, Object and/or whatever else DB-paradigm you need — is it going to be the super-fastest optimized-for-X’s-special-case! No, but we don’t necessarily _need_ that
I do not see why I need to map AST onto DB items in the first place. Why cannot a library unit be two blobs - specification and the implementation? Not sure about the second, except for generic bodies which are notoriously leaking out. Unless you want to compile under MS-DOS, you can load the AST into the memory, it is not large.
> [@OneWingedShark](#):
>
> A note on quick-and-dirty implementation of ID
OK, but why should we care about the IDL? Can you just store DIANA’s internal representation in a persistent portable format and the restore it? I imagine that an Ada library could be created after some compilation stage. E.g. the AST + some annotations would be OK for ASIS and AI. On top of that one would probably want to have some versioning. Some references between libraries as gpr projects have, since you would not want to compile the Ada environment over and over again.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [September 15, 2026, 9:21pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/6 "2026-09-15T21:21:53Z")
> [@dmitry-kazakov](#):
>
> Well, a naked tree is too coarse.
?
What’s stopping you from having a field of `cursor` on the tree in your node? (It’s kinda disgusting, but works.)
Also, I already, upthread, did say that such a system _should_ be built atop a `Graph`.
> [@dmitry-kazakov](#):
>
> That is even without names resolution as ASIS requires.
?
And I’m saying that it should actually be in graph-structures, “For Maximum Effect”.
(To be fair, `Graph` is desired because it completely solves your observed problem.)
> [@dmitry-kazakov](#):
>
> Furthermore, Stream attributes are non-portable.
Yes, which is unfortunate.
It would be nice if we had integration of ASN.1 into streams; in such a system as I outline, ASN.1 reader/writers could be generated automatically for any type… I think there is a way to use Streams with that, but that would definitely be “nonstandard”. (Though perhaps setting up a generic ASN\_1\_Stream package [with encoder/decoder as parameters] would allow a more standards-compliant way.)
> [@dmitry-kazakov](#):
>
> I do not see why I need to map AST onto DB items in the first place. Why cannot a library unit be two blobs - specification and the implementation? Not sure about the second, except for generic bodies which are notoriously leaking out. Unless you want to compile under MS-DOS, you can load the AST into the memory, it is not large.
Because as a structure inside the database, we now can apply formally-proven transformations/manipulations, and directly. (No parsing/re-parsing! All of reading, tokenizing, and parsing are done!) A rename is a simple update to a single location. Furthermore, these methods are generalizable.
Imagine such a DB-enabled IDE as proposed, with full Ada-2022, SQL-2022, and VHDL-2019. For each of these, imagine an equivalent of DIANA and an equivalent of ASIS [updated, obviously]: ‘DIANA’, ‘ISOLDE’, ‘IVAN’ and ‘ASIS’, ‘SSIS’, & ‘VSIS’, respectively. So that each of the former are operated on by the respective latter; for the ‘specification’ each is just plain Ada calls, for the implementation is SQL/PSM (eg PL/SQL) operating on the structure in the database — the implementation of SQL/PSM is in SPARK (inasmuch as possible) and the generated ISOLDE is known-correct — thus SQL/PSM acts as a meta-object language for all three of the languages… and, the other two being implemented in Ada, Ada can act as a meta-object language for both of those (ie via SSIS and VSIS).
(So you also solve the problem of self-hosting/bootstrapping a Meta-object protocol/system as noted in _The Art of the Metaobject Protocol_.)
_TL;DR — By going structure-first, you fundamentally alter the way that you interact with the program. One of the immediate benefits is dropping the unneeded work of [continually] re-parsing._
> [@dmitry-kazakov](#):
>
> OK, but why should we care about the IDL? Can you just store DIANA’s internal representation in a persistent portable format and the restore it?
Simple, looking at the above breakdown DIANA/IVAN/ISOLDE ↔ ASIS/VSIS/SSIS, we can note that all of DIANA/IVAN/ISOLDE _ **are** _ IDL instances; therefore, if we have a complete IDL along with its analog to DIANA and ASIS — say, III (IDL-In-IDL) & ISIS (with the ability to operate on instances) — we have the ability to distil the PSL/SQL implementation above to calls on ISIS and (essentially) `RENAMES` the operations.
It’s the same reason that implementing SGML in full would be better than _ad hoc_ piecing together HTML — or at least would have, I’m not so up-to-date on web-programming as I once was. (I _ **hate** _ so-called living-standards; they are not standards at all, whimsically updated/defiled at-whim.)
> [@dmitry-kazakov](#):
>
> I imagine that an Ada library could be created after some compilation stage. E.g. the AST + some annotations would be OK for ASIS and AI. On top of that one would probably want to have some versioning. Some references between libraries as gpr projects have, since you would not want to compile the Ada environment over and over again.
Yes, exactly so.
DIANA makes the most sense here, as it was designed so that you cannot represent non-valid Ada, and so that there is one; there is a single definition for each Ada-entity; and it was designed to be source-recoverable (modulo non-significant whitespace and, IIRC, some comments).
Also, “AST + Some-annotations”… So, you’re reinventing DIANA?
I would give you the link to the DITC archive, but it appears to be down.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [September 16, 2026, 2:17am UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/7 "2026-09-16T02:17:17Z")
Also, of possible interest:
- [ACE](https://attempto.ifi.uzh.ch/site/) — A small, controlled & machine readable English, which can be used for data-representation and/or query. Possibly useful in data/context representation/retention for LLMS. (ie reduce your token count, reduce areas where you need LLM.)
- SLM (Small Language Model) — Given a [comparison & evaluation paper](https://arxiv.org/pdf/2505.19529), SPARK’s provability, and Ada’s fixed-point numbers, this could be a good toy. (And if not, it would make a good research item as you could make it `generic` with a fixed-/floating-point and you could, while holding everything else constant, evaluate fixed/floats of various sizes.)
- …actually, given ACE, you could use it to mediate between technical/Ada jargon, and ACE, possibly using _that_ possible reduction of token-space, to emit better LLM prompts; or hook it into the DB as a “natural language to ISOLDE or Query-intermediate language” translator.
- [SCORION](https://foldoc.org/Scorpion) — I found an archive of version 5, it’s a bunch of C, though.
- SGML — An implementation would allow for operating on HTML, XML, OpenDocument [IIRC], and other data files.
- OLE2 — Microsoft’s OLE files, contain multiple data-streams, and can be regarded similar to its own filesystem. (See [OLEDS](https://winprotocoldoc.z19.web.core.windows.net/MS-OLEDS/%5bMS-OLEDS%5d-210625.pdf) and maybe the [olefile](https://olefile.readthedocs.io/en/latest/olefile.html) project’s documentation references.)
- PDF & PostScript — There are archived copies of the PostScript spec, and [appreciable chunks of] the PDF spec is available for free, [here](https://pdfa.org/resource/pdf-specification-archive/) (which link, goes [here](https://pdfa.org/resource/iso-32000-2/)).
- [Forth-2012](http://www.forth200x.org/documents/forth-2012.pdf) and/or [SeedForth](https://github.com/uho/preforth) — The Forth standard was made available to the community by their standards committee, just like the ARG did for Ada; SeedForth is a minimal, tokenized [ie words are encoded as a “integer” or “byte” or whatever, rather than a string]. (SeedForth [progress-report/summary](http://www.euroforth.org/ef18/papers/hoffmann.pdf))
- I do own the SQL and VHDL specifications.
---
### Author:  [@RREE](https://forum.ada-lang.io/u/RREE)
#### Post date: [September 16, 2026, 7:40am UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/8 "2026-09-16T07:40:34Z")
Thanks, Mark, for publishing this remarkable work. There is a lot of very valuable info both in the article and in the Github repo.
I am impressed at what LLMs can produce, at the same time disappointed by their lack of specific Ada knowledge. Even Claude Pro or Codex eventually start to produce Unchecked\_Conversions between accesses and System.Address when they don’t know how to avoid pointers in the first place. One of the cheaper models available through OpenCode required several attempts before it managed to place a type declaration before its use in a variable declaration.
I’d love to see an “Ada Pro” skill similar to those available for other programming languages, perhaps also a separate “SPARK Pro” skill, although I don’t personally use SPARK (yet). The guidance for writing good Ada code in the gnat-foundry-intersection is quite sparse. For example `design\code-conventions.md` contains “Leverage the Ada typing system: introduce narrow types as needed” or “There should be no global variables” but provides little deeper guidance.
I’d like to teach the LLMs about information hiding techniques such as
```Ada
type Toto is private;
private
type Toto_Impl;
type Toto is access Toto_Impl;
```
which helps to break circular dependencies. None of the models I have used have been able to come up with such a solution on their own.
Perhaps I should start my own skill file and wait for community contributions 🙂
---
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [September 16, 2026, 8:18am UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/9 "2026-09-16T08:18:44Z")
> [@OneWingedShark](#):
>
> What’s stopping you from having a field of `cursor` on the tree in your node?
Because it is heavy-weight, untyped and does Program\_Error when streamed?
> [@OneWingedShark](#):
>
> It would be nice if we had integration of ASN.1 into streams
Oh dear. ASN.1 is a monstrosity and it is not scalable because uses fixed precision formats. Portable streams are simple. I use chained code for integers and mantissa + exponent for floats. That covers it all. Note that you cannot have it both ways: portable and efficient. I wished Ada had two separate sets of stream attributes. One for internal marshalling, one for serialization/persistency/networking.
> [@OneWingedShark](#):
>
> Because as a structure inside the database, we now can apply formally-proven transformations/manipulations, and directly. (No parsing/re-parsing! All of reading, tokenizing, and parsing are done!)
Just deserialize the tree back. I remember early GCC versions. You cold dump the “image” of all C header includes precompiled and then read it back later. It even worked!
> [@OneWingedShark](#):
>
> Imagine such a DB-enabled IDE as proposed, with full Ada-2022, SQL-2022, and VHDL-2019.
I do not quite believe in a unified language format without massive concessions and compromises. C/C++ with its headers and templates will torpedo such sweet dreams, IMO.
> [@OneWingedShark](#):
>
> > [@dmitry-kazakov](#):
> >
> > OK, but why should we care about the IDL? Can you just store DIANA’s internal representation in a persistent portable format and the restore it?
>
> Simple, looking at the above breakdown DIANA/IVAN/ISOLDE ↔ ASIS/VSIS/SSIS, we can note that all of DIANA/IVAN/ISOLDE _ **are** _ IDL instances;
In effect you propose to translate from that [ID] language dropping all artefacts afterwards.
> [@OneWingedShark](#):
>
> DIANA makes the most sense here, as it was designed so that you cannot represent non-valid Ada, and so that there is one; there is a single definition for each Ada-entity; and it was designed to be source-recoverable (modulo non-significant whitespace and, IIRC, some comments).
That could be an issue, because in some cases you want to represent invalid programs, especially in the context of an IDE.I am a fan of stop-at-the-first-error approach, but sometimes the first error is not **the** error.
> [@OneWingedShark](#):
>
> Also, “AST + Some-annotations”… So, you’re reinventing DIANA?
> I would give you the link to the DITC archive, but it appears to be down.
Maybe yes, maybe no. I still do not understand DIANA at all. From your descriptions it looks like a Swiss knife. Everybody owns one or two, but always uses a proper tool instead. 😀
Maybe you and other guys familiar with DIANA could create a very short introduction from **Ada** perspective? Something **non-AI** in an old-fashioned way: introduction, problem statement, what other tools do, DIANA’s response. One page long!
---
### Author:  [@RREE](https://forum.ada-lang.io/u/RREE)
#### Post date: [September 16, 2026, 4:03pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/10 "2026-09-16T16:03:50Z")
Before starting my own skill file I found this one: [GitHub - agent-sh/ada-spark: Skill teaching agents to write idiomatic, correct, current Ada and SPARK (Ada 2022, Alire + GNAT FSF). Part of the agent-sh ecosystem. · GitHub](https://github.com/agent-sh/ada-spark). Generally, it is quite good. I only have minor remarks:
- It has some hard coded version numbers that should be updated (or the skill should describe how to retrieve the newest versions automatically)
- As I said in me previous post, I would separate Ada from SPARK skills
- There should be pointers to the AdaCore [tool skills](https://github.com/AdaCore/skills)
---
### Author:  [@Heziode](https://forum.ada-lang.io/u/Heziode)
#### Post date: [September 16, 2026, 5:07pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/11 "2026-09-16T17:07:43Z")
Can you stop doing my work? 😄
I am kinding. I working on exactly same topics for a while now, and have something similar to your approach. I will digging further to see your “foundry” in details.
Thank you
---
### Author:  [@markhermeling](https://forum.ada-lang.io/u/markhermeling)
#### Post date: [September 16, 2026, 5:51pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/12 "2026-09-16T17:51:30Z")
Great! Let us know what you think, we are keen on feedback!
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [September 16, 2026, 11:41pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/13 "2026-09-16T23:41:19Z")
> [@dmitry-kazakov](#):
>
> I do not quite believe in a unified language format without massive concessions and compromises. C/C++ with its headers and templates will torpedo such sweet dreams, IMO.
Why include C/C++?
The ones I’ve mentioned (in respect to an IDE) are all very close linguistically: Ada, VHDL, and SQL/PSM (aka PL/SQL).
> [@dmitry-kazakov](#):
>
> In effect you propose to translate from that [ID] language dropping all artefacts afterwards.
If you have the IDL, as an integrated part of the IDE and DB, then the artefacts are the DB object-schema [ok, essentially the `DOMAIN`] & DB-objects that are instances thereof [‘entries’ in the collection/`TABLE`].
> [@dmitry-kazakov](#):
>
> That could be an issue, because in some cases you want to represent invalid programs, especially in the context of an IDE.I am a fan of stop-at-the-first-error approach, but sometimes the first error is not **the** error.
Again, this won’t happen if every operation is guaranteed to end with a valid state, and you start with a valid state.
Although, there is some cause for making allowance for freeform/textual editing… **however** , editing in such a mode should be discouraged because you are forcing the code out of the controlled system (by putting it into text). — Therefore, any such editor has the responsibility of ‘quarantining’ such code until it is in an compliable state.
> [@dmitry-kazakov](#):
>
> Maybe yes, maybe no. I still do not understand DIANA at all. From your descriptions it looks like a Swiss knife. Everybody owns one or two, but always uses a proper tool instead. 😀
It’s an abstract data-type, an attributed tree structure, which is obtainable with some processing upon the AST/Parse-Tree. I’ve posted the link to the DIANA RM several times, and would do so again (as it has the introductory sections that explain exactly what DIANA is), but the DTIC.mil site is down.
> [@dmitry-kazakov](#):
>
> Maybe you and other guys familiar with DIANA could create a very short introduction from **Ada** perspective? Something **non-AI** in an old-fashioned way: introduction, problem statement, what other tools do, DIANA’s response. One page long!
Best I can do is two.
I wrote it up, but the site doesn’t allow me to upload it directly.
---
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [September 17, 2026, 7:39am UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/14 "2026-09-17T07:39:19Z")
> [@OneWingedShark](#):
>
> Why include C/C++?
> The ones I’ve mentioned (in respect to an IDE) are all very close linguistically: Ada, VHDL, and SQL/PSM (aka PL/SQL).
After parsing syntax plays no role. That is a part of my confusion about DIANA. You place it very low in the syntax but then declare it a structure for more advanced compilation stages, e.g.
> [@OneWingedShark](#):
>
> It’s an abstract data-type, an attributed tree structure, which is obtainable with some processing upon the AST/Parse-Tree.
If it is a specific structure, then there should be possible to generate it from Ada 2022 syntax tree.
> [@OneWingedShark](#):
>
> Best I can do is two.
> I wrote it up, but the site doesn’t allow me to upload it directly.
Github?
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [September 17, 2026, 3:56pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/15 "2026-09-17T15:56:20Z")
> [@dmitry-kazakov](#):
>
> Github?
I lost my acess.
(Screw 2FA).
> [@dmitry-kazakov](#):
>
> > [@OneWingedShark](#):
> >
> > It’s an abstract data-type, an attributed tree structure, which is obtainable with some processing upon the AST/Parse-Tree.
>
> If it is a specific structure, then there should be possible to generate it from Ada 2022 syntax tree.
With additions/updates for the new structures and keywords, yes.
Here’s a archive copy of the DITC entry of the [DIANA RM](https://archive.org/details/DTIC_ADA128232/page/129/mode/2up) (Rev 3).
> [@dmitry-kazakov](#):
>
> After parsing syntax plays no role. That is a part of my confusion about DIANA. You place it very low in the syntax but then declare it a structure for more advanced compilation stages, e.g.
I’m sure the pictures in the RM would help.
---
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [September 17, 2026, 4:35pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/16 "2026-09-17T16:35:59Z")
It looks similar to ASIS in the sense being rather a description of an interface rather than a concrete implementation. Both need to be augmented being outdated. It seems that ASIS has priority due to AdaControl, unless you have convincing arguments.
> [@OneWingedShark](#):
>
> > [@dmitry-kazakov](#):
> >
> > Github?
>
> I lost my acess.
> (Screw 2FA).
What about sourceforge? I hate Github too.
Or, even better. You can register under Rosetta Code and create a category (a set of) DIANA there. Rosetta Code has wider reach.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [September 17, 2026, 4:54pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/17 "2026-09-17T16:54:53Z")
> [@dmitry-kazakov](#):
>
> It looks similar to ASIS in the sense being rather a description of an interface rather than a concrete implementation.
Not really; DIANA is about representing the code/program, ASIS is more about querying the program — think the `Table`’s entry (DIANA) vs the definition/schema (the IDL for DIANA) vs a query on it (ASIS).
> [@dmitry-kazakov](#):
>
> It looks similar to ASIS in the sense being rather a description of an interface rather than a concrete implementation.
It’s an abstract data-type; you can implement it with various concrete implementations; this is plainly said in the first three paragraphs of the RM.
> [@dmitry-kazakov](#):
>
> Or, even better. You can register under Rosetta Code and create a category (a set of) DIANA there. Rosetta Code has wider reach.
There’s an idea.
* * *
In the meantime, since there’s only 4 colors; pdf-to-gif works:
---
### Author:  [@ThyMYthOS](https://forum.ada-lang.io/u/ThyMYthOS)
#### Post date: [September 17, 2026, 8:44pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/18 "2026-09-17T20:44:56Z")
The main issue why such tools, e.g. IDE that are strictly bound to a syntax, are rarely used is forward compatibility. Assume I have an IDE based on DIANA for Ada 2012 and AdaCore ships the first Compiler with support for Ada 2022. I can not even enter a valid Ada 2022 program in such an IDE. Also if I want to test some Gnat specific features that are not strict Ada: Not possible
As a developer I would probably very quickly abandon such a tool that always knows better than me what is allowed to do.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [September 17, 2026, 9:37pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/19 "2026-09-17T21:37:04Z")
> [@ThyMYthOS](#):
>
> The main issue why such tools, e.g. IDE that are strictly bound to a syntax, are rarely used is forward compatibility. Assume I have an IDE based on DIANA for Ada 2012 and AdaCore ships the first Compiler with support for Ada 2022.
Ada does a very good job with backwards compatibility; several people have complained that the ARG puts _too much_ weight on it, refusing to fix design mistakes. (eg anonymous access types.)
> [@ThyMYthOS](#):
>
> I can not even enter a valid Ada 2022 program in such an IDE.
Only partially true; the reason for a DB-first approach is that you start thinking about the structure primarily, rather than text — in order to update this system to store the new standard all you need is an updated DIANA, which is almost certainly going to be just a superset of preceding language; thus the IDL facilities are perfectly capable of handling this.
`Structure DIANA_83 Root Compilation is […]` → `Structure DIANA_95 Root Compilation From DIANA_83 is […]`
That is to say that the DIANA for Ada83 is a subset of DIANA for Ada95; the [automatically generated] readers and writers can be made for the new language-spec, _and_ translators for transitioning from the previous to the latter version to the other can be automatically constructed.
See **[IDL: sharing intermediate representations](https://dl.acm.org/doi/abs/10.1145/24039.24040)** & **[The DIANA Interfacer](https://sci-hub.st/https://link.springer.com/chapter/10.1007/3-540-13878-1_8)**.
That is to say, with a DB-first system like is proposed, you have very little work to transition to a new standard:
- Update the schema (eg DIANA-83 to DIANA-95);
- Update the SQL/PSM subprograms to handle the new constructs;
- If you are using ASIS, update it to use the new subprograms.
(You can now technically use the new standard, though not import it.)
- Update the Token\_ID enumeration (eg add `tagged` and the other new keywords);
- Update the particular tokenizing pass, if needed;
(Byron treats Tokenizing as `Procedure P( Data : in out Token_Vector )`, where Input contains a single token of the unprocessed `Text` ID, applying passes as-needed to transform `Data` into a fully processed form; that is _`(For all X of Data => Data.ID in Emittable)`_.)
- Update the parser to handle the new eywords/structures.
- Done; you can now import code in the new standard.
_ **Note: The above can be used to implement nonstandard experimental extensions; this, however, is not standards compliant. Obviously.** _
> [@ThyMYthOS](#):
>
> Also if I want to test some Gnat specific features that are not strict Ada: Not possible
See above.
Also, I am of the opinion that the GNAT extensions are more harm than good, on the whole.^1
That said, _ **they are GNAT specific** _, so would you expect ObjectAda or GreenHills to support it?
> [@ThyMYthOS](#):
>
> As a developer I would probably very quickly abandon such a tool that always knows better than me what is allowed to do.
Then why do you use Ada?
No, _seriously_. Why would you use a language that goes to such lengths to ensure correctness, such as (eg) telling you when you’ve swapped the ordering in `Type K is new Abstract Tagged Steve with null record;` or whatever and not a language that says _“The programmer knows what he’s doing”_ like C?
* * *
1 — Many of the GNAT extensions _of late_ are ill-considered “Ada should do X!” (where X is some other language’s feature, usually Python or C++) either (a) without considering Ada’s already extant strengths, or (b) without considering how such a feature encourages sloppy thinking, and therefore bad programming [eg the inline/no-declare creation of variables… now your typo compiles!].
---
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [September 17, 2026, 10:07pm UTC](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742/20 "2026-09-17T22:07:32Z")
> [@OneWingedShark](#):
>
> That is to say that the DIANA for Ada83 is a subset of DIANA for Ada95; the [automatically generated] readers and writers can be made for the new language-spec, _and_ translators for transitioning from the previous to the latter version to the other can be automatically constructed.
I think it is a oversimplification. For example, in Ada 83 you have
`... return subtype_mark`
later it becomes:
`... return {[null_exclusion] subtype_mark | access_definition}`
where `access_definition` is a recursively infinite rabbit hole. You will have to split and sometimes replace the original nodes.
Speaking formally the formal language (e.g. Ada grammar or IDL) and the language it generates (Ada program) are different things. Even if the set of Ada 83 programs is [almost] a subset of Ada 2022 programs, the grammar of or the IDL of will very unlikely be.
[Next page](https://forum.ada-lang.io/t/building-trust-in-ai-generated-artifacts-gnat-foundry-intersection/4742.md?page=2)