Domain-map y travesía

GET /osl/domain-map

El grafo de dominio unificado: el grafo semántico del tenant tal como lo ve un consumidor de OSL. La premisa es todo es una Entity — un único node kind entity etiquetado por composition (structured | structured+content | content), más nodos metric y candidate. Las tablas puente N-N no son nodos: colapsan a una arista N-N directa entre las entidades que enlazan.

Construido de forma determinista a partir del manifest. Sin body de petición.

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

Determinista por defecto; enrich es opt-in

Las descripciones de atributos son deterministas por rol (pk/fk/derived/metric) y siempre están presentes. Las descripciones de nodo son null salvo que pases enrich=true, lo que deja al suggester in-cluster rellenarlas a partir de una muestra de contenido gobernada (misma ACL + redacción que /osl/sample, server-side). El GET por defecto es rápido y determinista para que no pagues el modelo en cada carga.

Travesía — la forma TRAVERSE(...)

La travesía es ahora una forma de OSL-SQL, no un endpoint separado (/osl/traverse ha sido eliminado). Haces SELECT sobre la función de tabla TRAVERSE(...) en un body de POST /osl/query:

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

Es un recorrido L2 del grafo de relaciones estructurado, salto a salto (incluyendo N-N vía bridges) — una secuencia de búsquedas por igualdad acotadas (un filtro, no un motor de joins), con un tope de cardinalidad obligatorio por salto más dedup, determinista. Responde “las facturas de Pablo”: dadas las claves de una entidad ancla, devuelve las entidades destino relacionadas, cada una gobernada por los grants del llamante.

Mismo resolver, nueva superficie

El resolver de travesía L2 no cambia; ahora es el backend de la forma TRAVERSE. El proxy /semantic/traverse del tenant-mgmt-api de la consola traduce a osql. Claves vacías → rechazadas (sin full-scan); un ancla/destino inalcanzable → rechazado.

Previsualización de contenido gobernada — POST /osl/sample

Unas pocas filas reales de una tabla curada o unos pocos chunks de una faceta, filtradas por ACL y redactadas por sensibilidad/PII server-side. kind es "table" o "facet"; limit por defecto es 8 (tabla) / 5 (faceta). Los roles del actor vía X-Actor-Roles — ausente → deny-by-default en facetas con ACL. La respuesta lista redacted_columns[] / redacted_fields[]; las celdas enmascaradas contienen el literal "[redacted]".