Operator

An Operator is executable logic with an explicit contract.

That contract defines:

• what asset family or runtime scope it accepts
• what inputs and bindings it needs
• what parameters it accepts
• what output family it produces
• what provenance and evidence must be recorded

Built-in Rust operators and external packages should feel like one operator system to the user.

Operator Families

Ophiolite does not model every computation as one flat list. Operators are grouped by family so validation, composition, runtime execution, and derived-output semantics stay explicit.

Current and planned families include:

| Family | Typical inputs | Output shape | Maturity | | --- | --- | --- | --- | | Log/curve | log assets, semantic curve bindings | derived log or curve assets | Implemented for the deepest current slice | | Wellbore geometry | trajectories, depth references, coordinate transforms | derived geometry or resolved trajectory outputs | Partly implemented through typed wellbore assets | | Seismic trace-local/gather | post-stack traces, gather-native stores, compatible trace matrices | derived traces, volumes, gathers, previews, or analysis results | Implemented for selected trace-local, crop, gather, and velocity-scan paths | | Rock physics/AVO | elastic log sets, layer definitions, angle sampling | response, crossplot, or derived analysis outputs | Preview design with selected examples | | Horizon/surface | interpreted horizons, grids, survey context | surface assets, residuals, or resolved display payloads | Emerging | | Model-building | authored models, wells, horizons, control points, trends | compiled runtime fields or reusable model assets | Planned and intentionally separate from generic processing | | Import/preflight adapters | source files, vendor projects, external stores | evidence reports, normalized source assets, or import candidates | Implemented in selected import paths and widening | | Display/view resolvers | project assets plus view intent | frontend-safe DTOs and resolved scene payloads | Implemented for focused app-boundary views |

Current section-scoped seismic authoring uses this split directly:

PostStack3DVolume -> PostStack2DSectionView -> PostStack2DSectionResult

The current .tbflow section methods, amplitude_scalar(factor), trace_rms_normalize(), and agc_rms(window_ms), are catalog-backed and lower into linked procedure execution. They produce view-first section results unless the workflow asks to materialize or export something durable.

Composition Rule

An operator chain should preserve family meaning. A same-geometry trace filter, a gather-native analysis, a horizon-guided model build, and a display resolver may all be executable, but they do not have the same contract or persistence rules.

When Ophiolite exposes composition, it should tell the builder:

• which family owns the operator
• whether the step materializes a derived asset or returns an analysis/view result
• which inputs are canonical assets versus temporary bindings
• what evidence and provenance will be persisted
• whether the runtime supports preview, materialization, or both