Distinguish an Axis on-screen option from its device operation

Bottom line: Review a feature’s visibility separately from its operational state. When an on-screen option is hidden, require the appropriate device-operation evidence before claiming that the underlying function has been disabled.

Source fact: documented behavior

Axis’s On-screen controls provides feature descriptions through its CGI and includes separate operations for displaying or hiding a feature’s enable/disable option.

The show/hide example does not require removing the feature; a disabled feature is omitted from the response to a feature request.

What the source does not establish

Do not accept an absent button or feature-list entry as sufficient proof of the hardware’s state. Do not infer that hiding a control changes account permissions or blocks another management interface. Confirm the exact application and product support, and keep visibility policy separate from the approved procedure for changing the device function.

Applicability questions

• Is the request to hide an option or to change an actual device operation?
• Which on-screen feature name and client presentation are in scope?
• Which supported operation and observation establish the underlying function’s state?
• Who approves the visibility policy and any separate operational change?

DSE recommendation: controlled next steps

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

DSE recommends recording presentation and device-operation requirements as separate acceptance items.

1. Write the intended outcome before choosing an API method. For a presentation change, identify the client, feature description and users whose view should change. For an operational change, obtain the exact device function’s supported procedure and an independent state observation. Do not turn an interface cleanup request into an undocumented hardware configuration change.
2. Capture the current feature response and the permitted client view. Apply only the approved on-screen visibility operation through its supported interface, then retrieve the feature response and inspect the client again. Record which option is present or absent. Avoid naming the result hardware disabled unless the separately approved operation and observation establish that conclusion.
3. If the task includes changing the underlying function, perform that as its own authorized step and retain its evidence independently of the visibility change. Review other permitted management paths with the responsible owner when access restrictions are part of the requirement. Resolve any mismatch between presentation, operational state and access policy instead of treating a hidden control as a substitute for those checks.

Verification and evidence

Retain the feature name, before-and-after description responses, approved visibility action and permitted client screenshots. Keep any independent device-state result alongside its own supported operation. Ask another reviewer to identify exactly what the on-screen evidence proves and what remains untested.

Use a proposed desk case in which an operator closes a hardware-disable request with only a screenshot of a missing button. Require the reviewer to request the missing operational evidence. These checks do not report a tested device state or establish a security boundary across every management path.

Official references

• On-screen controls — 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.