Resolve an Axis transformation input before accepting its output version

Bottom line: Resolve the transformation’s input dependency before accepting its output-version label. Keep a deliberately supplied version separate from the documented defaulting behavior, and verify actual transformed data before connecting a consumer.

Source fact: documented behavior

Axis’s Data transformation API configures transformations from an input topic to an output topic using JQ expressions for Device Data Hub JSON data.

If outputTopicVersion is omitted, its default follows the input topic’s version; when that input is absent at creation, the documented placeholder is 0.0.0 and updates when the input becomes available.

The available-input topic list is a current observation rather than a fixed catalog: the source allows transformations to be configured for topics that do not yet exist.

What the source does not establish

Do not interpret every observed 0.0.0 as proof of a missing input. First establish whether the version was explicitly configured or obtained through the described default. Do not treat successful creation of a transform as acceptance of its output schema, expression correctness or delivery to an external consumer.

Applicability questions

• Which exact input topic should supply this transformation?
• Was an output version explicitly supplied or left to default?
• Is the expected input currently available on this device?
• Which approved input and expected output will demonstrate the intended transformation?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends recording the input dependency and version-selection mode with every transformation acceptance check.

1. Read the transformation configuration and identify the input topic, expression and intended output. Record whether the output version is explicit or defaulted. Retrieve the current available-input list and compare the exact topic identifier, rather than using a similar display name. Keep an absent input visible as a dependency to resolve with its producer owner.
2. For a proposed isolated exercise, prepare an approved transformation before its test input becomes available, using the documented default-version behavior. Mark that sequence as a fixture, not an observed device state. Inspect the saved configuration and version, then introduce the supported input through its approved producer workflow. Re-read the version and retain the actual transition instead of assuming it occurred.
3. Use harmless representative JSON input and compare the resulting output with the consumer’s written requirement. Review transformation statistics through the supported interface when investigating missing or unexpected output. Keep input availability, expression processing and consumer receipt as separate observations. Do not change a version string merely to conceal an unresolved producer dependency.

Verification and evidence

Retain sanitized configuration, version-selection mode, available-topic observations and the permitted input/output comparison. Identify when the input became available and when the output was actually observed. Have a reviewer explain the placeholder case without treating the version label alone as evidence that useful data was produced.

Add a separate desk case with an explicitly chosen version and require the reviewer to avoid applying the default-placeholder explanation automatically. Preserve failures and unavailable evidence as open items. The proposed checks do not establish a tested transformation, a particular producer release or an external delivery guarantee.

Official references

• Data transformation API — Axis Communications; official VAPIX documentation.

Source review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.