Domain map & traversal

GET /osl/domain-map

The unified domain graph: the tenant’s semantic graph as an OSL consumer sees it. The premise is everything is an Entity — one entity node kind tagged by composition (structured | structured+content | content), plus metric and candidate nodes. N-N junction tables are not nodes: they collapse to a direct N-N edge between the entities they link.

Built deterministically from the manifest. No request body.

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

Deterministic by default, enrich is opt-in

Attribute descriptions are deterministic by role (pk/fk/derived/metric) and always present. Node descriptions are null unless you pass enrich=true, which lets the in-cluster suggester fill them from a governed content sample (same ACL + redaction as /osl/sample, server-side). The default GET is fast and deterministic so you don’t pay the model on every load.

Traversal — the TRAVERSE(...) form

Traversal is now a form of OSL-SQL, not a separate endpoint (/osl/traverse has been removed). You SELECT from the TRAVERSE(...) table function in a POST /osl/query body:

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

It is an L2 walk of the structured relationship graph, hop-by-hop (including N-N via bridges) — a sequence of bounded equality lookups (a filter, not a join engine), with a mandatory per-hop cardinality cap plus dedup, deterministic. Answers “Pablo’s invoices”: given an anchor entity’s keys, return the related target entities, each governed by the caller’s grants.

Same resolver, new surface

The L2 traversal resolver is unchanged; it is now the backend of the TRAVERSE form. The console’s tenant-mgmt-api /semantic/traverse proxy translates to osql. Empty keys → refused (no full-scan); an unreachable anchor/target → refused.

Governed content preview — POST /osl/sample

A few real rows of a curated table or a few chunks of a facet, filtered by ACL and redacted by sensitivity/PII server-side. kind is "table" or "facet"; limit defaults to 8 (table) / 5 (facet). Actor roles via X-Actor-Roles — absent → deny-by-default on ACL’d facets. The response lists redacted_columns[] / redacted_fields[]; masked cells hold the literal "[redacted]".