What is OptixLog?

OptixLog is a graph-based workflow and observability platform for technical teams running document-heavy engineering workflows. It gives you a structured place to record, connect, and query the artifacts that flow through complex engineering processes — simulations, measurements, layouts, analyses, and more.

Domain entities

Organizations

Every OptixLog deployment is scoped to an organization. An organization holds the top-level identity: name, description, industry, contact information, and a company logo. Your API key is issued for an organization; all data you write belongs to that organization.

Projects

An organization contains one or more projects. A project is the unit of schema ownership: it has its own set of allowed node types, its own team structure, its own workflow-node graph, and its own audit log. Projects are identified by a stable id (e.g. proj_grating_7f3a) and a human-readable name.

Project metadata is captured in ProjectConfig:

config.id
config.name
config.description
config.category
config.icon
config.notes
config.status
config.created_at
config.updated_at

Teams and members

Each project has teams. A team groups members of the project with a shared role or function (e.g. "Photonics Engineering", "Layout"). Teams carry an optional category, a description, and notes.

Members are users who belong to one or more teams in a project. Membership records the user, the team, the user's role in that team, and when they joined. You access project-wide members (deduplicated across all teams) through project.get_all_members(...).

The workflow-node graph

The workflow-node graph is the heart of OptixLog. A workflow node is a typed, property-bearing unit of work in your engineering process — a simulation run, a measurement, a layout file, an analysis. Nodes form a directed graph through parent/child edges: each node records which upstream nodes produced it and which downstream nodes it feeds into.

Each node has:

• A label — the node's type, chosen from the project's schema (e.g. SimulationRun, MeasurementResult).
• Properties — a dict[str, str] of key-value metadata (e.g. {"solver": "fdtd", "wavelength_nm": "1550"}).
• Attachments — a list of FileRef objects pointing to associated files.
• Parent refs — nodes this node was derived from (origin edges).
• Child refs — nodes derived from this node (forward edges).
• Creator — who or what created the node.
• Timestamps — created_at and updated_at.

Audit log

Every project has an audit log. Audit events record who did what, when, and to which entities. Each event carries an action, a category, a severity level (debug/info/warn/error), timestamps, actor and target references, and an optional metadata payload. The audit log is append-only and accessible through project.audit_events.

What the SDK does

The Python SDK gives you programmatic access to all of this:

• Management API — read the organization, project config, teams, members, workflow nodes, and audit events.
• Pipeline API — ingest (create or update) workflow nodes, with the graph edges resolved from a natural-language prompt or explicit node IDs.
• Generated bindings — per-project typed dataclasses that make schema mismatches into static type errors.

See Architecture for how the three SDK surfaces fit together.