Domain-mapa i trawersacja

GET /osl/domain-map

Ujednolicony graf domeny: graf semantyczny tenanta tak, jak widzi go konsument OSL. Założenie jest takie, że wszystko jest Entity — jeden rodzaj węzła entity oznaczony przez composition (structured | structured+content | content), plus węzły metric i candidate. Tabele łączące N-N nie są węzłami: zwijają się do bezpośredniej krawędzi N-N między encjami, które łączą.

Budowany deterministycznie z manifestu. Brak ciała żądania.

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

Domyślnie deterministyczne, enrich jest opt-in

Opisy atrybutów są deterministyczne według roli (pk/fk/derived/metric) i zawsze obecne. Opisy węzłów są null, chyba że przekażesz enrich=true, co pozwala suggesterowi in-cluster wypełnić je z nadzorowanej próbki treści (te same ACL + redakcja co /osl/sample, po stronie serwera). Domyślny GET jest szybki i deterministyczny, więc nie płacisz za model przy każdym załadowaniu.

Trawersacja — forma TRAVERSE(...)

Trawersacja jest teraz formą OSL-SQL, a nie osobnym endpointem (/osl/traverse został usunięty). SELECT-ujesz z funkcji tabelarycznej TRAVERSE(...) w ciele POST /osl/query:

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

To L2 przejście ustrukturyzowanego grafu relacji, skok po skoku (wliczając N-N przez mosty) — sekwencja ograniczonych wyszukiwań po równości (filtr, a nie silnik joinów), z obowiązkowym limitem kardynalności per skok plus dedup, deterministyczna. Odpowiada na „faktury Pabla“: mając klucze encji kotwiczącej, zwróć powiązane encje docelowe, każda nadzorowana przez nadania wywołującego.

Ten sam resolver, nowa powierzchnia

Resolver trawersacji L2 jest niezmieniony; jest teraz backendem formy TRAVERSE. Proxy konsoli tenant-mgmt-api /semantic/traverse tłumaczy na osql. Puste klucze → odrzucone (brak full-scanu); nieosiągalna kotwica/cel → odrzucone.

Nadzorowany podgląd treści — POST /osl/sample

Kilka prawdziwych wierszy kuratorowanej tabeli lub kilka chunków fasety, przefiltrowanych przez ACL i zredagowanych według wrażliwości/PII po stronie serwera. kind to "table" lub "facet"; limit domyślnie 8 (table) / 5 (facet). Role aktora przez X-Actor-Roles — ich brak → deny-by-default na fasetach z ACL. Odpowiedź wymienia redacted_columns[] / redacted_fields[]; zamaskowane komórki przechowują literał "[redacted]".