Dsl et ir

Reflexion en cours.

Le résultat de l’analyse, c’est un DSL métier lisible et borné. Il décrit le sens fonctionnel, pas les sélecteurs DOM ni le SQL ni le RLS : feature, actor, context (avec la source du scope : Session), ontology (les relations), selection (Project.organisation equals Context.active_organisation), outcomes, invariants (empty_state iff visible_projects is_empty), et un unresolved: [] qui doit rester vide.

Je ne ferais pas la transfo spec → DSL d’un coup, mais en passes contrôlées : extraction terminologique, analyse ontologique, formalisation normative (must / must not / may / only if / iff), formalisation opérationnelle (préconditions, actions, transitions, résultats), construction des competency-questions, production du DSL candidat (chaque nœud garde sa provenance), puis validation déterministe. La compilation est refusée si le modèle a des termes inconnus, confond deux concepts, a des règles contradictoires, ne répond pas à une CQ, ne dit pas comment observer un résultat, ou laisse une clause source sans représentation.

Ensuite le DSL humain est abaissé vers une IR canonique (JSON normalisé) à sémantique fermée : chaque opérateur a une définition, chaque relation est typée, chaque ensemble dérivé est calculable, chaque propriété évaluable, chaque observation a un adaptateur runtime. C’est l’IR, pas le DSL, qu’on exécute.

À creuser : le format exact de l’IR, et où vit le registre des opérateurs et de leur sémantique ? Liés : competency-questions, policies-semantiques, inference-data-tests, compiler-intention-en-preuve