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.
TypeScript types
Section titled “TypeScript types”@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 shapeThe 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 generatedcomponentsobject (schemas, parameters).paths— every route keyed by path.operations— every operation keyed byoperationId.
Python models
Section titled “Python models”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.
Request bodies may be plain dicts or instances of the generated models:
from lbb.models import SemanticGraphSearchRequest
req = SemanticGraphSearchRequest( query="which systems store customer identity data", top_k=5, source="persisted", consistency="strong", targets=["entities", "assertions"],)lbb.graph_search(req) # dict works tooCommon type names
Section titled “Common type names”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.
One contract, both SDKs
Section titled “One contract, both SDKs”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.