Inconsistencies in openEHR specifications at the speed of AI

The propagate later occurred at the speed @rubentalstra works - 3 days later :wink:

Ruben’s agent produced a 111 page report. I’ve read through half of it and its findings seem reasonable. I hope everybody at SEC reads at least some of it.

Ruben did his part by propagating the findings to the SEC. What happens next? Resolving issues found with the aid of AI cannot be done manually anymore.

How will @SEC react to this new era? I know @sebastian.iancu and @erik.sundvall have experience with AI. Can the SEC invite Ruben to help resolve the issues (assuming he is willing)?

Thanks @borut.jures,

For keeping up with the speed of light :wink:

One correction on the “an AI produced a report” framing, because it overstates the autonomy.

The AI finds candidates. For every candidate I make it show me the exact passage and explain why it thinks there is a problem, and then I decide whether it is a real inconsistency or not. The ones that did not hold up were closed as refuted and are not in the corpus. So the speed is in how many candidates get in front of me. The decision is still me reading the spec text.

What is actually in the corpus: 225 reports, each citing the exact file and section. A lot of them also have tests in the implementation, one fixture that must be accepted and one that must be refused, so you can check a claim without trusting me or the tool.

One thing you should know before anyone reads them: the report text itself is written by the AI. I verified the citations and the claims, but the wording still needs a critical read, so expect sentences that need fixing during review.

On volume, I agree nobody should get 225 tickets. I curated everything into one dossier per component, around 200 entries after merging duplicates. Contradictions come first (a spec conflicting with its own example or model), then model defects, then the underdefined or silent areas.

And yes, I am happy to support and assist the SEC in this.