Skip to content

Operator Catalog and Composition

Audience: workflow builders and platform evaluators
Status: Preview

Ophiolite’s operator catalog is a discovery surface over family-owned execution contracts. It should help a builder answer:

  • what can run against this asset or selection
  • what family owns the operation
  • what inputs, parameters, and outputs are valid
  • whether the result is a materialized derived asset, an analysis response, or a display/view payload
  • what provenance and evidence will be persisted

The catalog is intentionally family-aware:

  • Log/curve: curve transforms, semantic bindings, derived log assets.
  • Wellbore geometry: trajectory cleanup, measured-depth references, coordinate and time-depth transforms.
  • Seismic trace-local/gather: trace-local filters, same-geometry derivations, gather-native processing, previews, and selected analysis APIs.
  • Rock physics/AVO: elastic channels, layering, angle sampling, response and crossplot outputs.
  • Horizon/surface: horizon grids, residuals, surface-derived outputs, and survey-bound overlays.
  • Model-building: authored velocity/property/time-depth models compiled into reusable runtime outputs.
  • Import/preflight adapters: source inspection, evidence capture, normalization candidates, and import plans.
  • Display/view resolvers: query-time DTOs and resolved scenes for apps without making display payloads canonical assets.

These families share one platform vocabulary, but they do not all compose as one reorderable pipeline.

Catalog entries should describe:

  • stable operator id and family id
  • supported asset families and selection scopes
  • required bindings and parameter schema
  • output family and materialization behavior
  • preview support, runtime constraints, and maturity level
  • provenance/evidence records emitted by execution

Built-in operators should usually appear through typed workflow helpers:

catalog = asset.operator_catalog()
pipeline = catalog.trace_local().pipeline("Bandpass + RMS AGC")
preview = asset.preview(pipeline)
derived = asset.materialize(pipeline, output_collection="derived")

External operator packages should stay under ophiolite_sdk.operators for authoring and packaging helpers:

from ophiolite_sdk.operators import OperatorRegistry, computed_curve

That separation keeps workflow composition readable while still allowing external packages to participate in the same validation, lock, provenance, and derived-output model.

The current live catalog is strongest for log/curve operators and selected seismic runtime families:

  • log/curve transforms and semantic eligibility
  • trace-local post-stack operators such as bandpass, RMS AGC, phase rotation, normalization, and arithmetic
  • terminal geometry-changing subvolume crop as its own post-stack derivation family
  • selected gather-native preview/materialization and velocity-scan analysis paths

Other families are part of the platform taxonomy but are not all equally implemented yet. Public docs should present them as the organizing model, then be explicit about which slices are available today.