Domain map et traversée

GET /osl/domain-map

Le graphe de domaine unifié : le graphe sémantique du tenant tel que le voit un consommateur d’OSL. La prémisse est tout est une Entity — un unique node kind entity étiqueté par composition (structured | structured+content | content), plus des nœuds metric et candidate. Les tables de jonction N-N ne sont pas des nœuds : elles se réduisent à une arête N-N directe entre les entités qu’elles relient.

Construit de manière déterministe depuis le manifest. Sans body de requête.

{
  "nodes": [
    {
      "id": "entity:Customer",
      "kind": "entity",
      "name": "Customer",
      "plane": "mixed",
      "state": "existing",
      "composition": "structured+content",
      "description": null,
      "attributes": [
        { "name": "customer_id", "role": "pk", "type": "string", "description": "Primary key of the entity." },
        { "name": "sentiment", "role": "derived", "type": null, "description": "Derived attribute, extracted from content (AI)." }
      ],
      "meta": { "pk": "customer_id", "model": "customer", "legs": ["call_transcripts"] }
    },
    { "id": "metric:arr", "kind": "metric", "name": "arr", "plane": "structured", "state": "existing", "composition": null, "attributes": [{ "name": "arr", "role": "metric", "type": null, "description": null }], "meta": {} }
  ],
  "edges": [
    { "id": "asignacion~advisor:customer", "source": "entity:Customer", "target": "entity:advisor", "kind": "nn", "label": "asignacion · N-N", "declared": true, "source_attr": "customer_id", "target_attr": "advisor_id" }
  ],
  "bridges": ["asignacion"]
}

Déterministe par défaut, l’enrichissement est opt-in

Les descriptions d’attributs sont déterministes par rôle (pk/fk/derived/metric) et toujours présentes. Les descriptions de nœud sont null sauf si vous passez enrich=true, ce qui laisse le suggester in-cluster les remplir à partir d’un échantillon de contenu gouverné (mêmes ACL + caviardage que /osl/sample, server-side). Le GET par défaut est rapide et déterministe pour que vous ne payiez pas le modèle à chaque chargement.

Traversée — la forme TRAVERSE(...)

La traversée est désormais une forme d’OSL-SQL, pas un endpoint séparé (/osl/traverse a été supprimé). Vous faites un SELECT sur la fonction de table TRAVERSE(...) dans un body POST /osl/query :

SELECT concepto, amount_eur
FROM TRAVERSE(anchor => 'customer',
              target => 'orders',
              keys   => ('c-anna', 'c-bruno'))

C’est une marche L2 du graphe de relations structuré, saut par saut (y compris N-N via bridges) — une séquence de lookups d’égalité bornés (un filtre, pas un moteur de joins), avec un plafond de cardinalité par saut obligatoire plus dedup, déterministe. Répond aux « factures de Pablo » : étant données les clés d’une entité ancre, renvoie les entités target liées, chacune gouvernée par les grants de l’appelant.

Même resolver, nouvelle surface

Le resolver de traversée L2 est inchangé ; il est désormais le backend de la forme TRAVERSE. Le proxy tenant-mgmt-api /semantic/traverse de la console traduit en osql. Clés vides → refusé (pas de full-scan) ; une ancre/target inatteignable → refusé.

Aperçu de contenu gouverné — POST /osl/sample

Quelques lignes réelles d’une table curée ou quelques chunks d’une facette, filtrées par ACL et caviardées par sensibilité/PII server-side. kind vaut "table" ou "facet" ; limit vaut 8 (table) / 5 (facet) par défaut. Les rôles de l’actor via X-Actor-Roles — absent → deny-by-default sur les facettes avec ACL. La réponse liste redacted_columns[] / redacted_fields[] ; les cellules masquées contiennent le littéral "[redacted]".