Couche semantique

Reflexion en cours.

Mon erreur intuitive serait de réduire la sémantique à un glossaire. Il y a en fait plusieurs niveaux de sens à préciser, et c’est en sautant les derniers que le bug passe.

Terminologique

Quels termes apparaissent (organisation, tenant, structure, compte) et désignent-ils le même concept, des concepts proches, distincts, ou des rôles contextuels ? Sinon le LLM traite orgId, tenantId et accountId comme interchangeables. On déclare les alias et surtout les not_equivalent_to.

Ontologique

Quels types de choses existent et comment ils se relient : User, Organisation, Membership, Project, Session, ActiveOrganisation, Permission. Voir analyse-ontologique. C’est ce que formalise OWL (classes, propriétés, individus, relations), même si je ne suis pas obligé d’utiliser OWL.

Normative

Ce qui est obligatoire, autorisé, interdit, conditionnel. « Un utilisateur ne doit voir que les projets de son organisation active » devient une règle avec sujet, modalité (must), résultat (exactly where ...). C’est le terrain de SBVR (sémantique des vocabulaires et règles métier).

Opérationnelle

L’effet d’une capacité sur le monde : selectOrganisation(orgA) change l’état de session, recalcule les projets accessibles, met à jour la collection. Indépendant de React/PostgreSQL/RLS.

Observationnelle

Comment un effet devient observable : accessibleProjects = [A1, A2] se lit dans la réponse API, les IDs visibles à l’écran, le store, un événement, l’état persistant. Question clé : quelle observation constitue une manifestation de la propriété ?

De preuve

Ce qui suffit à considérer l’intention démontrée : observed == semanticallyExpected, et non « la page s’affiche et aucune erreur visible ». C’est ce dernier niveau qui transforme une assertion en preuve.

À creuser : ces six niveaux sont-ils toujours tous nécessaires, ou y a-t-il des features où trois suffisent ? Liés : analyse-ontologique, monde-ferme-vs-owl, compiler-intention-en-preuve