Thirty Years of Architecture Under One Modeling Tool
TL;DR — CaseTalk has been rebuilt from the inside many times without ever being rewritten. The 16-bit FCO-IM Casetool that people were still running in the early 2000s and the 64-bit, headless, LLM-connected suite of 2026 share the same conceptual core: a fact-based model held in memory as a meta-graph. Around that core we added SQLite, threads, a SQL Server repository, a web portal, semantic web exports, template-driven generation, language models, chat, a headless engine and now CaseTalk Web. Along the way, thirty years of source, tickets and tests turned out to be the thing that makes AI coding agents productive on it instead of dangerous. Every step was made in Delphi, the same tool that shipped as 1.0 in 1995 and as 13.2 in 2026. This post walks through those layers in the order they arrived, and explains why each one was needed.
Software rarely gets to grow old gracefully. Most tools that were built for Windows 3.1 either died, were rewritten from scratch, or survive as a museum piece behind a compatibility shim. CaseTalk did none of those. It kept the same codebase, the same modeling method and the same language, and it changed its architecture underneath a working product roughly every few years.
That is worth writing down, partly because the story is interesting, and partly because each change was a response to a real limitation that modelers ran into. If you use CaseTalk today, this is why the suite is shaped the way it is.
1. The Core That Never Changed: FCO-IM in a Meta-Graph
CaseTalk exists to support Fully Communication Oriented Information Modeling. The method starts from sentences that domain experts actually say, turns them into elementary fact types, and derives everything else (identification, constraints, the eventual database schema) from there.
The very first architectural decision was how to hold such a model in memory. The answer was a meta-graph: a small in-memory database engine in which object types, fact types, roles, constraints, expressions and populations are all records connected through typed links. The memory database underneath it was written in the spring of 1995, within months of Delphi 1.0 shipping, and archived that November under the name Hyperbase. By the 1998 source tree the two foundational units already carried the names they have today, the memory database and the meta-graph on top of it. In the source the graph has been called TMG ever since, and those two units are still the heart of the product.
Everything in this post is a layer around that graph. Nothing replaced it. That is the single most important reason the rest of the story was possible: the model has always had one canonical, in-memory representation, and every new capability could be added as a reader or writer of that representation rather than as a competing store.
2. 16-Bit to 32-Bit to 64-Bit
Delphi 1.0 arrived in 1995 as a 16-bit compiler for Windows 3.1. The 32-bit compiler followed a year later, but the product did not follow it for a long time. FCO-IM Casetool 4.1, released in 1998 in Desktop, Student and Book editions, listed "Windows 3.1 or later" as its requirement, shipped on three diskettes with a 16-bit installer, and was built with Delphi 1. A 32-bit branch of the source existed from December 1997, but it stayed an experiment. The 5.0 beta of late 1998 was still a Delphi 1 project, and its bug list contains the tell-tale entry about coupling the 32-bit repository package to the 16-bit tool. Version 4.1 was the last 16-bit release, and it was what people kept using into the early 2000s.
The limits were the obvious ones: a 64 KB segment model, a few megabytes of usable memory, and models that could not grow beyond what an analyst could keep on paper anyway.
The 32-bit product arrived under a new name. CaseTalk 6.0, released between 2002 and 2004 as a continuation of the code between 4.1 and the 5.0 beta, was the first 32-bit release. The beta notes of August 2002 record the moment: "File format has been updated for 32-bit compatibility. Earlier file formats are automatically transformed into the new format." Files written by the 16-bit tool still open today.
The move to 32-bit lifted the ceiling on model size, and for more than two decades that was enough. What eventually forced 64-bit was not one model but the combination of large enterprise models, several of them open at once, diagrams with thousands of elements, and a generation of exports that want the whole repository in memory while they run.
Delphi added a 64-bit Windows compiler in XE2 (2011). CaseTalk took the step in 15.0, released in September 2026, after a layer-by-layer port of the database, engine, drawing and forms code in late 2025. The 32-bit build still compiles from the same source. The port taught us the usual lessons. Pointer sizes hidden in integers, a ten-byte floating point type that becomes eight bytes on Win64 and quietly breaks a binary file format, and DLL boundaries that need matching bitness on both sides. None of this changed a line of modeling logic. It changed the plumbing under it.
3. SQLite Inside the Model
The meta-graph is fast to walk from code, but it is not queryable. Every question a modeler asks that is not "give me this record" became a hand-written traversal: which fact types have no uniqueness constraint, which object types are never played, which populations violate a rule.
The answer was to mirror the meta-graph into SQLite through virtual tables. The live model is exposed as a set of tables that SQLite reads directly from memory, with no copy step. A validation rule is now a SQL statement. A report is a query. The model quality checks that ship with CaseTalk are written that way, and a large part of what made them affordable to write and maintain is that they are declarative.
SQLite also gave us a shared cache and a set of loading optimizations that made big models open in seconds rather than minutes. It never became the store of record. The graph stayed canonical, and SQLite is a view over it.
4. Threads
A modeling tool spends most of its time waiting for a person. The exceptions are the moments when the tool has to do real work: check all rules, lay out a diagram, generate a set of artifacts, talk to a server. For years those moments froze the user interface.
Moving them to background threads was less about raw speed and more about keeping the tool responsive while it thinks. Rule checks now run in parallel. Long operations report progress and can be interrupted. A managed thread unit and a strict rule that the model is edited from one place at a time keep this sane.
The less glamorous side of threading is that it forced the codebase to be honest about ownership. Code that assumed it could touch a form from anywhere had to be separated from code that works on the model. That separation paid for itself twice later on, in the headless engine and in the web worker.
5. SQL Server as the Repository: Versioning and Teams
A single-user tool keeps its model in a file. A team needs versions, history, ownership and a way to merge. CaseTalk gained a SQL Server repository for exactly that, with a schema split into a project database and a model database, built from layered scripts and maintained with a dedicated setup utility.
The repository is not a replacement for the in-memory model. A modeler checks out a model or a namespace, works on it locally in the meta-graph, and checks it back in. The server holds the versions, the audit trail, the shared settings and the todo lists. Merge moves an object type's version forward only, so a stale copy cannot roll a colleague's work back.
This is also where the suite gained its administrative side: user management, licensing per team, and database upgrades that run as scripted layers that can be peeled back and rebuilt. Most users never see it. Their experience is that a colleague's change shows up when they refresh.
6. The Portal: Publishing Models
Once models lived on a server, the next question was who else should be allowed to read them. Not modelers, but the people the models are about: business owners, developers, data stewards, auditors.
The portal is an ISAPI module on IIS that reads straight from the repository and renders models as web pages. Verbalized fact types, populations, constraints, diagrams, an activity timeline per author, discussions on individual elements, and linked-data views. It has no engine of its own. It is a SQL front door to what the modelers have published, gated per project and per version.
That separation matters for what comes later. The portal is stateless and cheap, and it never needs a model loaded in memory.
7. Semantic Web: Speaking OWL, RDF, SKOS and SHACL
FCO-IM and the semantic web have a lot in common and one deep difference. Both are about facts. The semantic web reduces everything to triples, while FCO-IM keeps n-ary fact types intact because that is how people talk.
CaseTalk exports models as OWL and RDF, exports and imports Turtle, understands SKOS vocabularies including the Dutch NL-SBB profile, and emits SHACL shapes for value constraints. Organizations that maintain an object type library on the web, such as infrastructure owners, can feed it directly from a CaseTalk model.
Architecturally the interesting part is that these are not one-off exporters. They are readers and writers over the same meta-graph as everything else, so a model imported from Turtle gets the same rules, diagrams and repository as a model typed in from interviews.
8. Templates Instead of Plugins
For a long time, generating output from a model meant a plugin: a compiled DLL with a fixed interface that walked the model and wrote files. There was one per target, they were hard to adjust, and every customer who wanted a slightly different SQL dialect or naming convention needed a new build.
We replaced that with templates. A generator is now a text template, in a Mustache dialect, driven by a catalog of the model that the engine produces. SQL dialects, Data Vault schemas, XSD, PlantUML, documentation, ArchiMate and ADL sources are all templates today. A user can copy one, change it, and keep it with the project.
The legacy DLL plugins still load for backward compatibility, but nothing new is written that way. Moving generation out of compiled code and into data was also what made a headless generator possible: a template engine does not need a window.
9. Language Models
The most recent years added a component that would have sounded like science fiction in 1995: a language model that reads the same sentences the modeler reads.
CaseTalk talks to several services through one REST layer: OpenAI, Anthropic, Google, local models via Ollama, and DeepL for translation. The uses are practical. Verbalize a fact type in another language, suggest example populations, name a role, review a model for missing constraints, translate a glossary. The modeler stays in control. The tool proposes and the person accepts.
Keeping the service layer generic, with the provider as a setting, turned out to be the right call. Providers changed names, pricing and endpoints several times in three years. The model layer did not have to.
10. Chat Services
A chat panel inside the tool followed naturally, and then grew into something more than a text box. The in-app chat runs on an agent harness written in Delphi, with native tool calling. The assistant can inspect the open model, search it, run the same operations the menus expose, and report back in the conversation.
There is also a browser version of the same chat, served from the engine over a small HTMX front end, and pacing controls so a team's shared quota is not consumed by one enthusiastic afternoon.
What this needed architecturally was a clean, callable surface on the engine. Every operation the assistant can perform is a tool with a name, a schema and a result. That surface is the same one the next two sections are built on.
11. Headless
CaseTalk was a Windows application for its whole life, and the model engine was entangled with the forms that showed it. Untangling that has been a multi-year effort, tracked with a taint analysis that reports which units still pull in the VCL and refuses new dependencies in the wrong direction.
The result is an engine that compiles and runs without a user interface. It powers the Model Context Protocol server, so an AI coding assistant can open a project, list fact types, add constraints, generate artifacts and run the rule checks. It powers command-line tools for XSD import, template rendering and generalization analysis. And it runs the unit test suite, which is now the fastest way to find out whether a change broke anything.
Headless did not require a rewrite. It required discipline: interfaces where the engine needs to ask a question, registered by whatever shell happens to be running, and nothing else.
12. CaseTalk Web
The last piece brings the earlier ones together. CaseTalk Web puts modeling itself, not just reading, in the browser.
The portal remains the front door, because it is cheap and stateless. Behind it, a session that wants to edit gets one headless worker, a real engine with one model in memory, exactly as the desktop has always had. Check-out and check-in against the repository are the lock. The forms are HTMX over the same tool surface the chat and the MCP server use. Diagrams render from the same native format the desktop writes.
It is early, and it is deliberately unambitious about reinventing anything. Every part of it already existed for another reason. The web version is what you get when the portal, the repository, the headless engine and the tool surface are finally allowed to talk to each other.
13. The Archive Becomes the Advantage
There is a twist to a codebase this old that we did not see coming. Everything that used to look like weight has turned into the best possible training ground for an AI coding agent.
A full build of the modeler compiles about 2.5 million lines of Pascal, libraries included. Of those, 1.3 million lines are CaseTalk's own, next to a third of a million lines of form definitions and a similar amount of web code, SQL, templates, scripts and documentation. Measured in words, CaseTalk's own source is about three times the complete Dark Tower saga, and a full build compiles twice that again. It does so in under a minute: the last build log reads 2,489,414 lines in 55 seconds, producing 58 megabytes of machine code. The git history runs back to 2008, with a version stamp whose build number has never been reset and stands at 57,646 at the time of writing. The ticket system holds some six thousand reports, each with its diagnosis and its fix. On top of that sit a unit test suite, a dependency and symbol database over every unit, a taint analysis for the VCL separation, and a memory manager that reports leaks with stack traces after every run.
For a person, that archive is context you carry in your head after years on the project. For an agent, it is context it can read in seconds. Ask why a role's flags are derived the way they are, and the answer is in a commit message and a ticket from 2019. Ask whether a change is safe, and the impact database lists every unit that will notice. Ask whether it worked, and the compiler, the tests and the rule checks say yes or no, with no room for opinion.
The effect on the last year has been a step change rather than an increment. Crash reports and emails become tickets within minutes instead of days. Tickets are reproduced against the test harness, fixed, and closed faster than we could triage them before. New developments, the headless engine, the agent harness, the web modeler, moved at a pace this small team has never had.
The part that matters is what did not happen. There has been no drift into hallucinated APIs or plausible-looking code that does not fit. Not because the models are infallible, but because the project does not let them be. Every claim is checked against the same things that check a human developer: does it compile, do the tests pass, does the rule engine agree, does the ticket history say this was tried before. Thirty years of discipline turned out to be exactly what an agent needs in order to be trusted.
Delphi, 1995 to 2026
One name has been in every section without being mentioned: Delphi. Version 1.0 in 1995 compiled the memory database and the 16-bit FCO-IM Casetool. Version 13.2 in 2026 compiles the 64-bit desktop, the ISAPI portal, the MCP server, the headless tools and the test runner, from the same source tree, in the same language.
It is easy to underrate what that continuity buys. A native executable with no runtime to install, produced from two and a half million lines in under a minute by a compiler that is still, after thirty years, one of the fastest there is. A component model that let a team of very few people ship a large product for three decades. A compiler that added 64-bit, generics, anonymous methods, attributes and cross-platform targets without asking us to abandon the code that worked. A model file from the 16-bit tool of 1998 still opens, and the same unit that held the meta-graph then holds it now.
We are sometimes asked why CaseTalk is not "modern". The honest answer is that its architecture has been modernized about a dozen times, and the users never had to notice.
What Comes Next
The direction is set by the last three layers. The engine is headless, the operations are tools, and the model is reachable from a browser, from a chat and from an AI assistant. The desktop remains the richest place to model, and it will stay that way for a long time. But it is no longer the only door.
If you have been using CaseTalk since the 16-bit days, thank you for your patience through every one of these transitions. If you are new, everything above is why the tool you are looking at feels both old and new at the same time. It is.
Download 15.1
Use Online