Concepts
The mental models behind OptixLog — the entity hierarchy, workflow-node graph, SDK surfaces, typed codegen, and credential model.
Understanding these concepts will help you use the SDK effectively and avoid common mistakes. This section covers the domain model first (what OptixLog stores), then the SDK surfaces (how you access it), then the developer tooling (how types and credentials work).
Concept map
Domain
Organization
└── Project
├── Teams → Members
├── Workflow-Node Graph
│ └── Node (type, labels, properties, attachments, edges)
└── Audit Log
SDK surfaces
SDKClient core identity / session
Management read the domain
Pipeline write nodes into the graph
OptixClient generated wrapper (wraps SDKClient + Pipeline)
Developer tooling
optixlog.toml project config (committed)
credentials.toml secrets (never committed)
optixlog generate emits typed bindingsPages in this section
What is OptixLog?
Organizations, projects, teams, the workflow-node graph, and the audit log.
Architecture
The three SDK surfaces and how they relate to each other.
Projects, Organizations, Teams
The entity hierarchy and how you access each through Management.
Workflow Graph
Nodes, edges (origin vs forward), labels, properties, and how ingest builds the graph.
Node Types and Schemas
Per-project schemas, typed fields, and the many-to-many node-to-project mapping.
Typed Codegen
How optixlog generate derives types from schemas and enforces them statically.
Credentials vs Config
credentials.toml (secret) vs optixlog.toml (committed) — what goes where.
Pagination, Filtering, Includes
Page[T], iter(), AND filters, include=(), order_by, and cursor.
Lookup Patterns
get vs get_or_none vs one vs first vs count vs iter and their raise semantics.
Error Model
The exception hierarchy and when each error is raised.