Skip to content

Types & generated models

Every request and response shape in little big brain has a stable, named type. The TypeScript and Python SDKs are generated from a single API contract, so the shapes match across languages: a SemanticGraphSearchRequest has the same fields whether you build it in TS or Python.

You’ll see these type names referenced throughout the docs (e.g. Schemas["SemanticGraphSearchRequest"], lbb.models.GraphSummaryResponse). This page is what those references point to.

@lbb/client exports every generated shape under the Schemas map, keyed by type name:

import { LbbClient, type Schemas } from "@lbb/client";
// Build a strongly-typed request and pass it in.
const req: Schemas["SemanticGraphSearchRequest"] = {
query: "which systems store customer identity data",
top_k: 5,
source: "persisted",
consistency: "strong",
targets: ["entities", "assertions"],
};
const lbb = new LbbClient({ baseUrl: "https://db.eu.littlebigbrain.com", apiKey: process.env.LBB_API_KEY });
const res = await lbb.search.hybrid(req.query, req);
// ^? typed as the search response shape

The raw generated artifacts are exported too, so you can address the contract directly:

  • Schemas["TypeName"] — a request or response shape by name.
  • components — the full generated components object (schemas, parameters).
  • paths — every route keyed by path.
  • operations — every operation keyed by operationId.

lbb ships generated Pydantic models in lbb.models. The plain, dict-returning methods are stable for scripts and notebooks; the typed models are there when you want validation and IDE autocompletion.

Use the matching *_model / *_page helper to get a typed response object:

from lbb.models import GraphSummaryResponse, SchemaBundleView
summary: GraphSummaryResponse = lbb.summary_model()
schema: SchemaBundleView = lbb.schema.view_model()
entities = lbb.entities.list_page(fields="*")
for row in entities.data:
print(row.name, row.attributes or {})
# Or type any raw response after the fact:
raw = lbb.raw_request("GET", "/v1/graph/summary")
typed = raw.model(GraphSummaryResponse)

Typed helpers cover the high-use surfaces: commit_model, commit_dry_run_model, graph("main").facts.create_model, graph("main").retract_model, summary_model, metadata_model, list_graphs_model, ontology_view_model, ontology_conformance_model, sparql_select_model, schema.view_model, schema.preview_model, schema.publish_model, schema.audit_model, entities.list_page, entities.filter_by_attributes_model, and graph_edges_page. Async clients expose the same helpers as awaitables.

A cross-reference for the shapes you’ll meet most often. The TypeScript column is what goes inside Schemas["…"]; the Python column is the class under lbb.models.

Concept Type name (TS Schemas[…] / Py lbb.models.…)
Hybrid search request SemanticGraphSearchRequest
Structured SPARQL SELECT/aggregate SparqlSelectRequest
Graph summary response GraphSummaryResponse
SHACL schema bundle view SchemaBundleView

Paged reads return typed page objects through their helpers rather than a bare type name — e.g. entities.list_page and graph_edges_page in Python, whose results expose .data and paging fields.

This is a starter set, not the full list — the complete, authoritative catalog is the generated src/schema.ts (TypeScript) and lbb/models.py (Python) that ship inside the installed SDK packages, so your editor autocompletes every field.

Both first-party SDKs are generated from the same API contract, so their shapes stay compatible by construction — a type name here means the same thing in TypeScript and Python. So the type names on this page are a reliable reference, not documentation that can silently fall out of sync with the API.