Tickets.CaseTalk - Issues

0005889: Files kept outside the project folder are re-searched on every open, and may be matched to the wrong file

Fri, 14 Aug 2026 18:56:43 +0200

A project can refer to files that are not stored in the project folder itself. CaseTalk remembers where those files live through a Windows shortcut, so that the project keeps working when a file is moved elsewhere on the same computer.

Two things go wrong with that.

Opening a project is slow when such a file has moved. Windows is able to find the file in its new place, but CaseTalk does not remember the answer: the shortcut on disk keeps pointing at the old location, so the search starts again from scratch the next time the project is opened, and the time before that. Windows allows itself three seconds for each search. A project holding a dozen or more external files can therefore appear to hang for the better part of a minute on every open, showing nothing at all while it waits.

A file can also be silently replaced by the wrong one. When Windows can no longer follow a file, it falls back to looking for one with the same name, and that search can land on an unrelated file elsewhere on the machine. The project then quietly starts working with a file the user never chose.

Note that this way of remembering files only works within one computer. A project folder that travels through a sync service such as OneDrive arrives on the other machine as a fresh copy, and no shortcut in it can be followed. For that reason files belonging to a project are best kept in the project folder itself.

0005884: Hide example data from readers who are not cleared for it

Thu, 13 Aug 2026 09:33:24 +0200

A model's example population is often real: rows lifted from a production system to make a fact type concrete. Until now CaseTalk showed all of it to whoever had the file open, and printed all of it into reports.

Expected: what a reader sees depends on what they are cleared to see.

- A permission level in the options says what the person at this CaseTalk may read. Everything remains readable by default, exactly as before.
- Example data classified above that level is shown as a placeholder instead of the real value, wherever a sentence is verbalized.
- A single tuple can state its own classification, which overrides the object/fact type in both directions. This matters because example data is not all of a kind: a row somebody invented to illustrate a fact type is marked Public and stays readable however sensitive the type is, while a row taken from production stays protected however ordinary the type looks.
- The population editor shows masked rows as such and will not let them be edited, since what is on screen is a placeholder and typing over it would replace the real value. A deliberate 'Reveal masked values' step lifts that for the current editing session, in the same way an object/fact type is temporarily unlocked, and it is handed back when the editor closes.
- The project report carries a confidentiality notice when the model classifies anything, because once a report leaves CaseTalk there is no reader left to check.

0004024: For your eyes only - classifications

Thu, 13 Aug 2026 09:33:24 +0200

According to a post on LinkedIn this makes sense for modeling (artifacts).

[url=https://www.linkedin.com/feed/update/urn:li:activity:7084824295603884032" rel="noopener,nofollow]https://www.linkedin.com/feed/update/urn:li:activity:7084824295603884032[/url]

0005883: See and filter which concepts hold sensitive data

Thu, 13 Aug 2026 09:31:08 +0200

A concept can be classified as Public, Internal, Protected or Restricted, but until now that classification was only visible by opening the concept and looking at its property. On a model of any size there was no way to see at a glance where the sensitive data sits, and no way to concentrate on it.

Expected: the classification is visible where you are already working, and can be used to narrow down what you see.

- On a diagram, a concept holding classified data is marked with a security icon, and the legend explains what the icon means.
- In the ontology view, concepts are grouped under Data Sensitivity by the level they carry, so a governance review can be done from one place.
- In the filter, sensitivity levels can be ticked to hide them. Hiding 'Unclassified' is how you ask to see only what has actually been assessed; the choice is stored with a saved filter like any other setting.

One mark is used for every classified level rather than one per level: on a diagram what matters is that the concept carries data under some level of security - which level it is, is read in the editor.

0005885: Mark a constraint as obligatory rather than necessary

Thu, 13 Aug 2026 09:17:26 +0200

Today every constraint in CaseTalk is absolute: if the model says a value must be in a list, no other value can ever be recorded. That is the right reading for rules that describe what is physically possible, but not for rules that describe policy.

A policy rule can be broken. A discount above 25% is out of policy but it does happen and someone has to approve it; a contract signer under 18 is not allowed but the record still exists and has to be reported. For those rules the data must be recordable AND flagged, not rejected.

ORM calls the first kind alethic (necessarily true) and the second deontic (obligatory, but violable), and lets a modeller say which one a rule is.

The request is to let a constraint carry that distinction, so that:
- generated database code enforces only the absolute rules, and never turns a policy rule into something that blocks the data it is meant to report on;
- example populations may hold values that break a policy rule;
- "which records currently break policy" becomes a report the model can produce.

DEFERRED for now - see the notes for why this is more than a single checkbox.

0005887: Value constraint ranges can exclude a bound and be left open-ended

Thu, 13 Aug 2026 08:27:10 +0200

A value constraint range could only ever say "from here to there, both included". Two things ORM allows were missing.

An open-ended range. "18 or older" or "up to and including zero" had no way to be written: leaving the maximum empty was read back as the single value, so the range quietly became one number the next time the editor was opened.

An excluded bound. "above zero, up to a hundred" is not the same rule as "zero to a hundred", but both had to be written the same way.

Both can now be expressed, and both survive a round trip through the Range editor. A range written the old way keeps meaning exactly what it did, so existing models are untouched and nothing needs converting.

The rest of the product follows: the bounds of such a range are used correctly when a value constraint is turned into a state machine, and the ORM export now carries the open end and the excluded bound instead of flattening them.

Rules read in words rather than punctuation - a range that leaves a bound out verbalizes as "must be 0..100 (not including 0)".

0004002: Constraint scope

Wed, 12 Aug 2026 17:59:25 +0200

Constraints could be modeled for a specific scope.

Business needs
System needs
Data validation

These scopes should be set by the user.

0002067: Make constraints conditional

Wed, 12 Aug 2026 17:59:25 +0200

MRC can be required for some artifacts, and optional for others. Making them conditional is therefore desired.

0005319: Constraints may be context specific, and need annotation

Wed, 12 Aug 2026 17:57:43 +0200

The constraints are context specific and need that disctinction. This requires constraints on roles to allow overlap when the context differs. This allows preferred constraints, mandatory constraints, final state constraints, or application specific constraints.

The GLR now needs to honor the appropriate context, and model well-formedness, and placing constraints needs to be fine tuned for these situations.

0005856: Mark source data as sensitive in a data catalog

Wed, 12 Aug 2026 11:03:14 +0200

A data catalog describes the source systems a model is mapped onto: schemas, tables, columns and their descriptions. Some of those columns hold personal or confidential data, and the catalog is often the only place that knows it.

Today a catalog carries no sensitivity marking at all, so the classification has to be re-entered by hand on every concept it is mapped to - and column names, sample values and descriptions from the catalog are shown and handed on freely, including to an AI assistant.

Expected: a catalog can record a sensitivity for a source column (and for a whole table or schema, inherited by its columns), the browser shows it, and anything that reads the catalog - including an AI assistant - respects it the same way the model does.

0005881: Diagrams occasionally out of sync: renaming a concept leaves it listed under its old name

Tue, 11 Aug 2026 13:46:23 +0200

When an object or fact type is renamed, the model keeps a record of which diagrams show that concept - and that record kept the OLD name. Because the record still pointed at the right concept internally, none of the existing repairs could tell it was outdated, so the wrong name stayed behind for as long as the model lived.

The result was that the list of diagrams a concept appears on could be wrong, or show the same concept twice, and turning on 'Force diagram synchronization' did not put it right: diagrams that were closed, disconnected, or simply unchanged were never revisited.

Related situations that were also not kept up to date:
- A change made while a diagram was busy synchronizing could be missed entirely.
- With more than one model in a project, a diagram's content could be registered against whichever model happened to be open rather than its own; diagrams under a transformed model were never registered at all.
- Removing a diagram from a model, and adding a previously saved diagram back to it, did not update the record.

0005880: Value constraints: say what kind of constraint it is, and edit it that way

Tue, 11 Aug 2026 13:14:26 +0200

A value constraint could only be typed as free text, and its syntax was the only clue to what it meant: a plain list of values, a range written as 1..10, a value with a label written as X=Something, or a state machine written with arrows. Nothing in the dialog told you which of those you had, and switching to the state view could quietly throw away the labels you had typed.

The editor now names the kind and lets you choose it. Each kind gets the editor that suits it: a list for plain values, a Minimum and Maximum column for ranges, a value-and-label table for coded values, and a matrix for a state machine. The kind shown when you open the dialog is read from the values themselves, and you are free to change it.

Plain values, ranges and coded values sit happily together in one constraint. Giving one value a label means every value can carry one, and writing one range means a single value counts as a range that begins and ends at the same point. Nothing has to be rewritten to move between them, so those choices never cost you anything.

A state machine is the exception, because it holds transitions rather than values. You can still switch to the list to add or remove states and then return to the matrix, which will have gained the states you added and dropped the transitions that no longer lead anywhere. Nothing is lost while the dialog is open: only pressing OK stores the choice, and if that means giving up the transitions you are asked first.

The description of a transition moved out of the grid cell into a field of its own, a state that stands for a code shows its label in the matrix, and a state may now have a transition to itself.

0005879: Line and fill color buttons in the object/fact type editor show up black

Tue, 11 Aug 2026 13:12:02 +0200

In the object/fact type editor, the Line Color and Fill Color buttons under Appearance are drawn as solid black rectangles. The button only shows its normal background while the mouse hovers over it, and turns black again as soon as the pointer leaves, which makes it hard to see what is a button and what colour is set.

0005877: Diagram style: annotation notes get their own background color and font

Tue, 11 Aug 2026 12:10:20 +0200

Annotation notes on a diagram had no styling of their own. They were drawn in the diagram's background color with the diagram's outline color and the generic text font, which made them blend into the canvas instead of standing out as a remark attached to a concept.

The diagram properties now offer two extra entries: a Notes color and an Annotation notes font. A note is drawn in the note color with the note font, and by default those are the familiar tooltip colors - a pale note with dark text - so notes read as stickers on the diagram without any setting up.

Notes already on a diagram follow the style: picking another note color or font recolors them right away, and a saved style carries both settings with it.

An annotation shown inside a concept follows the note font as well, but keeps the colors of the concept it is written on.

0005878: Diagram properties: preview the style on the real diagram

Tue, 11 Aug 2026 11:19:00 +0200

The diagram properties dialog showed a small sample drawing - one object type, one fact type and one label - as its preview. It was never finished, and it said nothing about the diagram actually being styled: colours, fonts and line settings could only be judged on three shapes that were not the model at hand.

The dialog now has a Preview button that applies the settings to the real diagram behind it, so a style can be judged on the model it is meant for. Previewing decides nothing: cancelling the dialog puts the diagram back the way it was, redrawn. When there is no diagram to preview on - the default diagram properties from the main menu - the button is disabled.

With the sample preview gone the dialog is a good deal smaller, so it covers less of the diagram it is now previewing on.

Two smaller things this also settles: picking a style from the Profiles menu could not be undone with Cancel, and the settings of a diagram that is viewed zoomed in are no longer at risk of coming back at the wrong font size.

0005710: Verbalize alternate keys: allow object types to carry their own expressions over role paths

Sun, 09 Aug 2026 17:41:02 +0200

Currently a model's readable sentences (expressions/verbalizations) are built from text combined with single roles. There is no way to attach a verbalization directly to an object type that describes one of its alternate (candidate) keys.

We would like the ability to add an object-type-level expression that can verbalize an alternate key. To support this, an expression component should be able to consist of not only text, text+role, or a single role, but also a role path (a chain of roles), or text combined with a role path.

Benefit: users could describe and read back alternate identification schemes for an object type in natural language, making composite or indirect keys understandable in the model documentation and reports.

0005737: Align model quality reporting with the ISO/IEC 25010 quality model

Sun, 09 Aug 2026 17:22:55 +0200

Reference the ISO/IEC 25010 product-quality characteristics for software. Perhaps there's something similar for models?
* [url=https://iso25000.com/en/iso-25000-standards/iso-25010" rel="noopener,nofollow]https://iso25000.com/en/iso-25000-standards/iso-25010[/url]
* [url=https://quality.arc42.org/standards/iso-25010" rel="noopener,nofollow]https://quality.arc42.org/standards/iso-25010[/url]
When reporting model quality, so the quality metrics and grading map onto a recognized international standard.

0005712: Add (De)compose function

Sun, 09 Aug 2026 16:56:25 +0200

For composite fact types, we need a function to decompose. For decomposed fact types we may need to compose.

0005868: Welcome page shows straight away, then refreshes in the background

Sun, 09 Aug 2026 16:54:53 +0200

The welcome page no longer waits for the news and changelog feeds to be downloaded before it appears.

Previously the announcements and changelog items were only shown right away while the downloaded copy was less than a day old. On any later start CaseTalk replaced them with a 'Fetching the latest news and updates...' message and went out to the internet before anything could be read - which on a slow or unavailable connection left the welcome page half empty for as long as the request took.

Now the welcome page always shows the last downloaded announcements and changelog immediately, however old they are, and only goes looking for newer ones a few seconds later, once the window is up. The page quietly updates itself when the new items arrive.

The 'Fetching the latest news and updates...' message is now only seen on a first ever run, when there is genuinely nothing to show yet.

0005869: Report the business rules as SBVR in the project report

Sun, 09 Aug 2026 16:54:41 +0200

The project report describes the model's terms, concepts and value types, but says very little about the rules that govern them. All the constraints in the model can be phrased as business rules, and SBVR Structured English is the standard way of writing them down for a business audience.

The project report now carries a Business Rules chapter that verbalizes every constraint in the model, grouped by kind: identification, uniqueness, mandatory participation, subset, equality, ring constraints, value restrictions, subtypes, frequency and derivation. Each group is listed in the table of contents so a specific kind of rule can be found quickly.

Only the rules are included. The SBVR vocabulary chapters describe the same terms and fact types the report already covers in its own notation, so repeating them would only make the document longer.

The chapter can be switched off, like every other part of the report, under Options - Project Report.

0005872: Diagram style colours are applied correctly, and the list shows every kind as it is drawn

Sun, 09 Aug 2026 16:54:26 +0200

Setting a colour in the diagram style (Fonts and Colours) had no effect on the diagram: whatever colour was picked, the diagram was drawn in a near-white shade. Picking a colour for the constraints, for example, made the constraint lines white instead of the chosen colour.

The colour is now taken from the picker as chosen, and the picker also opens showing the colour that is currently in effect for the selected entry.

On top of that, the list of texts and colours now shows every entry the way it is drawn in the diagram: each text kind in its own font family, style and colour, and each colour entry with a sample of its colour, all on the diagram background. Every line is shown at the same size, so the list stays readable no matter how large or small a font is configured.

0005871: Ring constraint visualization in the diagram, and editing a constraint from the diagram

Sun, 09 Aug 2026 16:54:08 +0200

Two things around constraints in the diagram, for 15.0.

RING CONSTRAINT VISUALIZATION

A ring constraint is a property of its fact type rather than a numbered constraint, and the diagram treats it as a second-class citizen because of it:

- It is drawn as a glyph parked against the bottom-right corner of the fact type, with no way to move it. On a busy diagram it lands on a reading or another shape and there is nothing the reader can do about it.
- Nothing says which roles it runs between. Every other constraint draws its dashed lines to the roles it constrains; the ring draws none, so once it sits anywhere but hard against its fact type it says nothing about what it applies to.
- A fact type can ring in more than one way at once - a hierarchy that also forbids shortcuts is acyclic AND intransitive - and a single symbol cannot show that.
- It gives no feedback when selected, where every other constraint fills with the selection colour.

CONSTRAINT EDITING FROM THE DIAGRAM

Asking to edit a constraint in the diagram opens an object/fact type editor instead of the constraint's own dialog. This holds for uniqueness, totality, subset, equality and cardinality constraints alike: the edit command reaches the selection rather than the constraint that was clicked, and the selection is a type.

The cardinality constraint suffers most, because it is also the one that cannot be usefully placed without editing: it is created saying 'exactly once', which is never what it was placed for, and the numbers have to be found somewhere else afterwards.

0005876: Project report runs the source model name into the sentence: " originates fromAcme v3"

Sat, 08 Aug 2026 12:43:41 +0200

Where the project report says which model a borrowed term comes from, the name of that model was stuck straight onto the preceding word, for example " originates fromAcme v3" instead of " originates from Acme v3". The same happened in the line listing the source of borrowed expressions, and in every language.

0005875: German, French and Spanish rule wording was incomplete, and corrected wording never reached an existing installation

Sat, 08 Aug 2026 12:43:36 +0200

The file that holds the wording of the rules and report labels had fallen behind CaseTalk. 63 of the wordings it uses had no entry at all, so they appeared in English whatever language you had chosen, and the ring constraint rules were missing from German, French and Spanish altogether.

Every language is now complete: English and Dutch carry all of them, German, French and Spanish everything that applies to them. The GegevensSpraak and RegelSpraak keywords stay Dutch, because that language is defined in Dutch.

Separately, corrected or added wording could never reach an installation that already existed. The file is only put in place when it is not there yet, and an upgrade carries the old one forward, so anything added after your first install stayed English forever. CaseTalk now reads the delivered wording first and your own on top of it, so new and corrected wording arrives with an update while anything you changed yourself is kept.

0005874: Rules are worded in the language of the computer instead of the language of the model

Sat, 08 Aug 2026 12:43:33 +0200

A model carries its own language. The rules, though, were worded in the language of the user interface, which CaseTalk picks up from Windows when it starts. A Dutch model opened on an English machine therefore produced English rules, and an English model on a Dutch machine produced Dutch ones.

Verbalization now follows the language of the model itself. Where a report or an export asks for a particular language, that request still wins over the model.

The SBVR wording follows the model as well - "It is necessary that ..." introduces the rule and belongs to the sentence, so it cannot be in a different language from the rule it introduces.