Why the API Changed

The current API asks you to describe more of an application's intent: what data an operator accepts, when it should run, which samples it should use, and what resources its outputs need. That may feel more deliberate than an older application style, but it gives the graph enough information to catch mistakes earlier and makes runtime behavior easier to inspect.

The practical question is not “Which old method name becomes which new method name?” It is “Which application decision was hidden before, and where should I express it now?”

Make Connections Explicit

An operator's ports are its public data interface. A connection says which output feeds which input, and the payload type is part of that contract. This makes a mismatch visible during composition or compilation and gives the consumer a clear data contract.

When adapting an existing operator, review three things together:

the payload it publishes and accepts;
the configuration that determines how it processes that payload; and
the timing rule that determines when it is ready to run.

The Ports, Samples, and Payload Types page explains the representations, and Migration Concept Map maps the application concepts across the migration.

Keep Timing out of the Processing Algorithm

Consider a camera that produces frames at one rate and an IMU that produces measurements at another. A fusion step may need the newest IMU value, a bounded time window, or a safe result when no suitable measurement exists.

A temporal contract expresses those choices before the processing callback runs. The callback can focus on its selected inputs while the contract manages queue readiness, freshness, and missing-data behavior. Temporal Contracts and Input Selection explains the decisions in detail.

The contract does not make bad data disappear. The operator still needs to handle the missing-data policy it selected, and the application still needs to measure timing on the target. It only puts the policy where the graph can describe and review it.

Make Resource Decisions Visible

Queues, Tensor pools, memory placement, and process boundaries affect whether data can remain in flight. Making those requirements explicit lets the application reason about capacity without depending on unbounded allocation or accidental copies.

This does not mean every application needs to understand allocator internals. Start with the user decision: how many samples may be retained, whether a consumer reads or forwards a Tensor, whether a result needs a new allocation, and whether a process boundary changes the memory path. Then use Allocation Ownership and Tensor Pools and Tensor Contracts and Memory Types when those choices need deeper analysis.

A plan can be accepted while a runtime resource is unavailable, and a declared memory kind does not by itself prove that a complete pipeline avoided copies. Keep compile-time evidence, startup evidence, and measured runtime behavior separate.

Separate the Graph from the Run Session

A graph describes the application pipeline. A run session owns an active execution and gives the surrounding application a place to request a cooperative stop, wait for cleanup, and inspect the terminal outcome. This separation helps when the graph runs alongside a user interface, device service, recorder, or control loop.

The Architecture and Execution Model page introduces that compose–compile–run sequence. The Running and Stopping guide shows the complete run-control pattern with the API definitions placed after the working path.

Use the Change as an Application Checklist

Application question	Where to express it
What data can this stage receive and publish?	Typed ports and a payload representation. See Ports, Samples, and Payload Types.
When should the stage run?	A temporal contract and its input-selection policy. See Temporal Contracts and Input Selection.
How much data may remain in flight?	Queue and Tensor-capacity choices. See Rates, Queue Sizing, and Derived Tensor Capacity.
How should the application stop and report the result?	A blocking run or a run session, followed by explicit wait and outcome handling. See Running and Stopping.
What changed in an existing application?	Compare its graph, payload, timing, and run-control assumptions with the Applications, Fragments, and Graphs migration guide.

See the Decisions in a Small Example

The slow_fast_fusion example makes the timing decision visible with fast and slow scalar sources, a bounded-age selector, and a fused result. The camera_imu_control example applies the same idea to a camera/IMU-shaped graph and exports a scalar control result. Both use synthetic inputs so the graph behavior can be studied without treating the example as a complete device integration.

Continue

Continue with Migration Concept Map if you are adapting an existing application. If you are starting a new operator, continue with Writing a Minimal Operator after reading Operator Lifecycle.

Source reference

❯