Domain map e attraversamento

GET /osl/domain-map

Il grafo di dominio unificato: il grafo semantico del tenant così come lo vede un consumatore di OSL. La premessa è tutto è una Entity — un unico node kind entity etichettato per composition (structured | structured+content | content), più nodi metric e candidate. Le tabelle di giunzione N-N non sono nodi: collassano a un arco N-N diretto tra le entità che collegano.

Costruito in modo deterministico dal manifest. Senza body di richiesta.

{
  "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"]
}

Deterministico di default, l'arricchimento è opt-in

Le descrizioni degli attributi sono deterministiche per ruolo (pk/fk/derived/metric) e sempre presenti. Le descrizioni dei nodi sono null a meno che tu non passi enrich=true, che lascia al suggester in-cluster riempirle a partire da un campione di contenuto governato (stessa ACL + oscuramento di /osl/sample, server-side). Il GET di default è veloce e deterministico così non paghi il modello a ogni caricamento.

Attraversamento — la forma TRAVERSE(...)

L’attraversamento è ora una forma di OSL-SQL, non un endpoint separato (/osl/traverse è stato rimosso). Fai SELECT dalla table function TRAVERSE(...) in un body POST /osl/query:

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

È una passeggiata L2 del grafo delle relazioni strutturato, salto dopo salto (incluso N-N tramite bridge) — una sequenza di lookup di uguaglianza limitati (un filtro, non un motore di join), con un tetto di cardinalità per salto obbligatorio più dedup, deterministica. Risponde alle “fatture di Pablo”: date le chiavi di un’entità ancora, restituisce le entità target correlate, ciascuna governata dalle concessioni del chiamante.

Stesso resolver, nuova superficie

Il resolver di attraversamento L2 è invariato; ora è il backend della forma TRAVERSE. Il proxy /semantic/traverse del tenant-mgmt-api della console traduce in osql. Chiavi vuote → rifiutate (niente full-scan); un anchor/target non raggiungibile → rifiutato.

Anteprima di contenuto governata — POST /osl/sample

Poche righe reali di una tabella curata o pochi chunk di un facet, filtrati per ACL e oscurati per sensibilità/PII server-side. kind è "table" o "facet"; limit di default è 8 (table) / 5 (facet). I ruoli dell’attore via X-Actor-Roles — assente → deny-by-default sui facet con ACL. La risposta elenca redacted_columns[] / redacted_fields[]; le celle mascherate contengono il literal "[redacted]".