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 execution will persist

Family Taxonomy

• 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.
• Import/preflight adapters: source inspection, evidence capture, normalization candidates, and import plans.

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

Catalog Shape

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

Composition Guidance

Use cataloged platform operations through the CLI, Python automation, or Workbench. Do not add a second Python operator-authoring story that bypasses the Rust-owned validation, execution mode, provenance, and project governance paths.

Current Maturity

The 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
• section-scoped .tbflow methods backed by catalog metadata, currently including amplitude_scalar(factor), trace_rms_normalize(), and agc_rms(window_ms)

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.