Stuntman FAQs
General & Getting Started
How does the Anthropic Claude licensing work?
We provide a complete solution in our software package — Anthropic’s AI is embedded directly into our software. We provide example scripts and a knowledge base the AI can use for creating and modifying designs so that they are compatible with Stuntman. Unchained Labs handles all licenses, support, and knowledge base.
Can I turn the AI off?
Yes. You can use Stuntman without AI or use AI only for specific steps like design creation.
How does data sharing work across sites?
Stuntman files (.stunt files) behave like standard Windows files. Customers can use standard file-sharing practices or shared network drives for data sharing. There is no proprietary cloud lock-in.
Does the subscription cover only AI?
The Stuntman software subscription includes the full software suite for design, execution, data review, AI and programmatic control.
What experiment throughput and data volume can Stuntman support?
Experiment throughput and data volume depend on the specific workflow, experiment duration, instrumentation, and the amount of data generated (for example simple dispense logging versus high-frequency analytical measurements). With appropriate system configuration and scheduling, Stuntman can support high-throughput experimental workflows involving large numbers of experiments.
How much does it cost?
Stuntman hardware is fully custom to your workflow, so it’s hard to give a price. We should discuss the details. Let’s get you set up to have a conversation with your field team.
Software is an annual subscription, and it comes with built-in AI, API packages and GUI package for creating designs, running experiments and viewing results.
Can we schedule a demo?
Yes. We’re happy to provide live demonstrations, virtual demos, detailed technical discussions for Stuntman. Please contact us to schedule a session.
AI & Model Questions
Who is responsible for the AI service used by Stuntman AI?
Stuntman AI integrates Anthropic’s Claude model through a secure API. Anthropic is responsible for the operation and availability of the Claude model service and API infrastructure. Unchained Labs is responsible for the implementation of the AI integration within the Stuntman platform, including how experiment data is handled within the application and how AI-generated outputs are validated and executed within the automation environment.
Can users guide Stuntman AI to follow preferred experiment design patterns or workflows?
Yes. Stuntman AI is configured with platform-specific documentation, example scripts, and structured prompts that guide the model to generate outputs aligned with Stuntman’s experiment design schema, hardware capabilities, and execution rules. Users can further guide the outputs by using templates or reference designs, specifying constraints within prompts (for example preferred optimization methods or experiment structures), and reviewing or modifying designs within Stuntman Plan before execution.
In practice, many users start from an existing design or template and ask Stuntman AI to modify or extend it, which helps maintain consistent workflow structure without needing to provide detailed instructions each time.
Does Stuntman AI use or access scientific literature, and do users need to provide references?
Stuntman AI uses a general-purpose LLM and is configured with Stuntman-specific documentation, example scripts, and structured prompts to generate valid designs for Stuntman. It is not pre-trained on scientific literature and does not have access to real-time or external literature sources. Users do not need to provide references for standard workflows (e.g., generating a design for a common reaction such as a Hartwig amination), as the model can generate designs based on general scientific knowledge and the Stuntman framework. For specialized protocols, or when reproducing a specific published procedure, users should provide the relevant reference or content (for example via a file path or input text) to guide the design.
Can Stuntman AI access paywalled or subscription-based literature sources?
Stuntman AI cannot independently access paywalled or external literature sources. If users have access to such content, they can provide it to Stuntman AI by supplying a file path to locally stored documents or including relevant content in the input. Integration with external literature access systems (such as subscription-based platforms) is possible through a custom orchestration layer that handles authentication and data retrieval. This type of integration can be implemented by the user or scoped as a custom solution with Unchained Labs.
What aspects of an experiment can be modified when using templates?
Templates can be modified at multiple levels depending on the workflow. At the simplest level, users can replace variables such as volumes, concentrations, sample locations, or other experimental parameters while keeping the overall workflow structure the same. Templates can also be adapted more broadly. For example, users can modify sample counts, experimental conditions, or labware selections. Stuntman will validate that the updated design is compatible with the configured hardware and deck layout.
Stuntman AI can also assist by modifying an existing template based on natural-language instructions while maintaining the operational intent of the workflow and ensuring the resulting design passes system validation.
How can customers monitor the availability of the AI service used by Stuntman AI?
Anthropic provides service status and incident updates for the Claude API through its public status page at status.anthropic.com. This page reports real-time operational status and incident communication for the Claude service.
What happens if Anthropic experiences service disruption or supply chain constraints? What would the impact be if Anthropic can no longer provide LLM service?
Stuntman is not vendor-locked to a single AI provider. If Anthropic were no longer available, Stuntman could transition to a different LLM provider if necessary. Any such transition would include validation to ensure workflow output remains consistent with Stuntman’s schema and execution rules.
Anthropic operates enterprise-grade infrastructure for the Claude service and provides service status and incident communication through https://status.claude.com/. As with any cloud service dependency, Stuntman architecture allows contingency planning and flexibility to transition between model versions or providers if needed.
You also have the flexibility to use your own internal LLMs to generate scripts, which can then be reviewed, validated, and executed within Stuntman — provided they conform to Stuntman’s validated design structure.
Also, Stuntman automation platform and execution framework operate independently of the LLM layer. Without AI, Stuntman continues to function fully for GUI-based design, script execution, data logging, and closed-loop workflows using user-defined optimization scripts.
Does the AI model update automatically over time? How frequently is the model changed? What happens when the model is changed? Does AI require retraining?
The model version used by Stuntman AI is explicitly defined in the CLI (Command Line Interface) call. Stuntman AI currently uses Anthropic’s Claude 4.5 Haiku model. Models are not switched automatically. Users have flexibility to select another available model version for a specific session if desired using the model selection option in the application interface.
Changing the model does not require AI retraining. The LLM is used to generate structured workflows based on defined prompts and schema constraints. As long as the model can understand and follow the required structure for Stuntman’s validated environment, it can generate compatible scripts. If a different model version is selected, validation testing would be performed to ensure the output remains consistent with Stuntman’s design schema and execution rules.
Anthropic publishes model lifecycle updates and deprecation timelines through its documentation (docs.claude.com) and provides advance notice before retiring model versions. Service availability and incident updates are communicated through Anthropic’s public status page https://status.claude.com/. Stuntman’s architecture maintains flexibility to transition between supported model versions if needed.
How are Claude model updates communicated?
Anthropic publishes model lifecycle updates and deprecation timelines through its documentation (docs.claude.com) and provides advance notice before retiring model versions (https://status.claude.com/). This allows partners such as Stuntman to plan transitions between supported model versions when necessary.
Can Stuntman AI be used for scheduling or orchestration?
Stuntman AI focuses on experiment design and script generation. It is not a built-in scheduling engine. However, Stuntman AI could be used to write a Python program that uses Stuntman Software API to orchestrate and schedule script execution on Stuntman instruments.
Does Stuntman AI rely on external AI infrastructure (e.g., MCP servers)?
No, Stuntman AI does not rely on MCP (Model Context Protocol) servers or external orchestration layers to function. Stuntman AI connects directly to Anthropic’s Claude through a secure CLI (command-line interface) integration. This allows Stuntman to send prompts and receive responses directly from the model without relying on MCP infrastructure.
Does Stuntman’s UI/UX and agent architecture support flexible, configurable workflows across different applications?
Stuntman provides configurable, high-level workflow control, with flexibility shaped by hardware capabilities and LLM selection rather than by fixed, hard-coded task structures.
Stuntman is designed to support flexible workflows at the application layer by allowing users to define high-level task parameters, experiment conditions, and optimization goals without requiring low-level control or coding. Workflow flexibility is determined by system configuration and the capabilities of the underlying hardware. Stuntman enables users to configure and execute different experimental or analytical workflows within the constraints of the connected system. Stuntman integrates with LLMs provided through Anthropic, and users may select from available models depending on their needs. This allows adaptability in reasoning depth and performance across applications.
Can the AI model be trained on legacy data?
Stuntman AI uses Anthropic’s Claude as a foundational model. The foundational LLM (Anthropic Claude) is not retrained on customer data. However, there are two important ways legacy data can still play a role:
First, you can provide historical data to your own optimization layer. Users are free to train and use their own machine learning models, Bayesian optimizers, open-source Python frameworks or other algorithms using legacy datasets.
Second, you can ask Stuntman AI to generate an optimization script based on your experimental objectives and constraints. For example, you can prompt it to create a Bayesian optimization routine, initial condition generator, or data processing workflow. That script can then be reviewed, validated, and executed programmatically.
So, while the LLM itself is not trained on your data, your optimization logic can be — and Stuntman is designed to support that flexibility.
Design Validation
How accurate is Stuntman AI when generating experiment designs from natural language?
Stuntman AI is generally very accurate because it operates within a constrained environment. The model is provided with Stuntman documentation, example scripts, and structured prompts so it understands how to generate valid Stuntman experiment designs and Python workflows. Like any AI system, outputs should be reviewed by the user. AI-generated designs can be reviewed and edited before execution, and they also pass through Stuntman’s built-in validation checks to confirm compatibility with the hardware configuration and experiment constraints. If a generated design does not meet those constraints, it will fail validation and can be adjusted by the user.
Is human confirmation required before AI-generated experiments are executed?
AI-generated experiment designs can be reviewed, edited, and validated in Stuntman Plan before they are executed on the hardware. In many workflows, users review and approve designs prior to running them.
Stuntman also supports closed-loop workflows where scripts analyze experimental results and automatically generate the next set of experiments. Whether human approval is required between iterations depends on how the workflow is configured and the level of automation desired.
How does Stuntman validate multi-sample experiments before proceeding to downstream characterization?
Stuntman validates multi-sample experiments at both the design and execution levels. Before execution, the system performs schema validation, hardware compatibility checks, and resource allocation verification to ensure the batch design is internally consistent and executable on the configured system. During execution, each sample is tracked using a unique identifier, and all dispense events, process parameters, timestamps, and instrument responses are logged for each sample.
Security & Data Privacy
What if our lab cannot connect to the internet?
If your lab cannot connect to the internet, Stuntman AI cannot be used. However, you can still use:
- Stuntman Plan (GUI-based design)
- Stuntman Run (GUI-based design execution application)
- Manual script development using your own script writing tools (Python or other supported workflows)
AI assistance is optional. All core design, scripting, and execution capabilities remain available without internet connectivity.
How does Stuntman maintain compatibility with experiment data across software updates?
Stuntman stores experiment designs and results using structured HDF files. Breaking changes to data models are handled through versioning of the HDF files. File versioning is implemented within the application to maintain backward compatibility, ensuring that software updates do not break existing functionality or access to previously generated data.
How does Stuntman track experiment inputs, execution details, and results to support traceability and reproducibility?
Stuntman design files (.stunt) and associated scripts are stored as standard files within the operating system. Stuntman does not include built-in revision history or internal change tracking for design files. Version control is typically managed using the customer’s existing file management or version control systems (for example shared drives, Git repositories, or document control platforms). During execution, Stuntman logs the specific design file, script, and software version used. This allows historical experiments to be reproduced provided the hardware configuration and software environment remain consistent.
Access to the application is managed through the host system environment rather than through a separate authentication layer within the application itself.
Does Stuntman provide traceability of materials and experiment data across the workflow?
Stuntman maintains structured execution traceability across the experimental workflow. Each sample is assigned a unique identifier, and all associated dispense events, process parameters, timestamps, instrument states, and analytical results are logged within the structured HDF output.
Material identifiers such as precursor lot numbers can be captured as part of the experiment design metadata and are retained alongside execution and characterization data. This enables end-to-end traceability from input materials through final analytical results, supporting reproducibility and detailed data lineage within R&D workflows.
How are system configuration settings and sensitive operational parameters managed in Stuntman deployments?
Environment-specific configuration is managed through system configuration files within the Stuntman deployment environment. Access to these configuration files is governed by the permissions and controls of the underlying operating system environment rather than by a separate configuration protection layer within the application.
Can Stuntman generate reports for regulatory or compliance documentation (for example GLP, ISO, or patent records)?
Stuntman is an R&D automation platform and does not function as a standalone compliance or quality management system. However, it generates structured, time-stamped experimental records in HDF format, including execution parameters, sample identifiers, and analytical results. These records can be stored and managed within enterprise document control or quality systems to support traceability, reproducibility, and documentation for research records, regulatory submissions, or patent filings.
Closed-Loop & Algorithms
What optimization methods are supported?
Stuntman provides a Python-based framework that allows customers to implement their preferred optimization strategy. This may include:
- Bayesian optimization
- Design of experiments (DoE)
- Custom Python algorithms
- Open-source machine learning libraries (for example scikit-learn)
- Proprietary optimization models
These optimization routines are implemented within user-controlled Python workflows. This allows customers to define their own analysis logic, integrate external libraries, and manage package versions to support reproducible experimental workflows.
What is the user responsible for in closed-loop workflows?
Users are responsible for:
- Selecting the optimization method
- Validating algorithms
- Providing data inputs
- Defining objectives and constraints
Stuntman provides the execution framework and API access.
Can Stuntman function as a data-generating node in our AI/ML closed-loop workflow?
Yes, Stuntman is designed to operate as an execution and data-generation layer within AI/ML-driven closed-loop workflows. It bridges optimization logic and physical experimentation by providing structured design validation, controlled hardware execution, and machine-readable experimental output suitable for iterative model updating. It provides:
- Python-based programmatic experiment design and modification
- Programmatic execution control via Python and the exposed SiLA API
- Structured, machine-readable data output in HDF file format
- Logging of execution state, metadata, and sample identifiers
External optimization engines can generate new experimental conditions, which can then be translated into valid Stuntman designs through a Python orchestration layer before execution.
Can Stuntman automatically analyze analytical data (such as HPLC results) and generate the next set of experiments in a closed-loop workflow?
Yes, Stuntman supports closed-loop experimentation where experimental results are analyzed and used to generate the next set of experimental conditions automatically. A common approach is to run a closed-loop experiment controlled by a Python orchestration script. In this workflow, analytical data is processed using user-defined analysis logic, and the results are passed to an optimization method (Bayesian optimization, design of experiments (DoE), or custom machine learning models) to determine the next set of conditions. In these workflows, the results of the optimization algorithm determine the next set of experimental conditions, allowing experiments to run iteratively without manual intervention if the workflow is configured that way.
If analytical instruments such as HPLC are integrated with the system, their data can be incorporated directly into this loop. The resulting conditions are then executed automatically through the Stuntman execution framework. The analysis methods and optimization algorithms are defined by the user within the Python workflow, giving customers full control over how results influence the next experiment.
Can Stuntman support different analytical metrics or evaluation criteria when analyzing experiment results in a closed-loop workflow?
Yes, in closed-loop workflows, the data interpretation step is implemented using user-defined Python analysis code. This allows customers to define whichever metrics are relevant for their experiment. For example, users could evaluate results using peak area percentages, normalized peak areas based on an internal standard, calculated yield, conversion, or other derived metrics. Because the analysis logic is defined in the workflow code, the evaluation criteria can be adjusted depending on the experiment or workflow requirements.
How does Stuntman handle variability or complexity in analytical data during closed-loop workflows (for example peak drift in chromatographic data)?
Handling analytical variability is typically managed in the data-processing step of the workflow. In closed-loop experiments, analytical interpretation is implemented through user-defined Python analysis code or external analytical tools.
This allows users to implement peak identification logic, retention-window adjustments, signal filtering, or other data-processing strategies needed to make the analysis robust. Stuntman provides the automation and execution framework, while the analytical interpretation and optimization logic remain fully customizable within the workflow.
What data analysis capabilities are available in Stuntman?
Stuntman provides tools for visualizing experiment results and supports flexible data analysis workflows through Python scripting and external tools. Experimental results can be viewed in Stuntman Show, which displays numerical data, plots, and images generated during experiment execution. For automated workflows, users can implement data-processing and analysis logic in Python scripts that run as part of the experiment workflow. Experiment data is stored in structured HDF files, which makes it straightforward to integrate with external analysis environments, machine-learning pipelines, or internal data systems.
What is the data latency in Stuntman? Is experiment data available during a run, and how quickly is it available after a run completes?
Stuntman writes execution data locally during runtime, and users can monitor experiment progress in real time through the software interface. While a run is in progress, users can view execution status such as which sample is being processed, which step is active, and associated system states. Intermediate data can also be accessed programmatically if incorporated into the orchestration logic. After a run completes, the full structured HDF dataset is immediately available locally for downstream processing, analysis, or export.
API & Integration
What control interfaces does Stuntman Run (execution software) expose? Does Stuntman support a REST API or OPC UA? Can hardware be controlled through firmware instead of SiLA API?
Stuntman Run exposes a SiLA API for workflow execution and automation control. SiLA is the standardized interface used for remote control of Stuntman hardware. Stuntman Run does not natively expose a REST API for execution control, an OPC UA interface, or direct firmware-level external control. Hardware is controlled either through the SiLA API or through Stuntman Run scripts/widgets.
However, Stuntman can operate within enterprise environments that use REST-based systems or OPC UA devices. A client or orchestration layer can communicate with Stuntman via SiLA, communicate with ELNs and data systems or other applications via REST or other APIs to enterprise systems such as LIMS and ELNs, and communicate with other instruments or facility systems via OPC UA. This architecture allows Stuntman to integrate into broader digital ecosystems while maintaining SiLA as the standardized control interface for execution.
Are low-level controls available?
Yes. Users can create scripts using exposed hardware resource objects to achieve low-level controls available within the object. Users will have access to hardware resource objects and methods used in the master scripts.
Can Stuntman be used as a low-level execution engine where we generate and send small scripts (e.g., Python or .stunt files) from our own orchestration system? Do you have examples of atomic commands?
Stuntman is primarily designed to operate as an integrated system where experiment design, orchestration, execution, and error handling are managed within the Stuntman environment. However, we recognize building self-driving labs or using your own orchestration stacks requires more direct, programmatic control. For these use cases, Stuntman can be operated in a headless, Python-driven mode, where simple Python scripts are used to directly control device-level operations (e.g., moving an arm, executing a dispense, interacting with consumables). These scripts can run independently of the Stuntman Run UI.
This enables you to execute atomic operations through Python, integrate with an external orchestration system that generates and triggers scripts dynamically, and use Stuntman as an execution layer with higher-level logic residing in your system.
It is important to note that users are responsible for orchestration, sequencing, and error handling when operating in this mode. Stuntman does not provide built-in UI feedback or recovery mechanisms in headless operation.
Does the software allow experiment queueing, including during a closed-loop run?
Yes, Stuntman Run (execution software) supports experiment queuing via the exposed SiLA API. Designs and associated Python scripts can be queued within Stuntman Run even while a closed-loop workflow is running. Additional validated Stuntman designs can be added to the queue and executed sequentially. All queued designs must be valid Stuntman-native designs, and Python scripts must be written using UL-provided Python objects.
How does Stuntman manage experiment scheduling when multiple users share the system?
Experiment execution is managed through the queue system in Stuntman Run. Users can submit validated experiment designs and associated scripts to the queue, which are then executed sequentially. The queue status can be viewed through the user interface, showing designs that are pending, in progress, or completed. Users can reorder or remove pending items before execution begins. This approach allows multiple users to submit experiments while maintaining controlled execution on the system.
Can Stuntman AI connect directly to our ELNs such as Dotmatics or other AI tools?
Stuntman supports structured data exchange to export files and documentation to a format that can be uploaded into your ELN or other systems including AI tools:
- Experiment results are generated in HDF format
- HDF to JSON conversion is possible
- Structured data export enables results to be uploaded into ELNs
Integration with ELNs is feasible through structured file exchange and client-layer orchestration. If required, a client or orchestration layer can translate structured ELN inputs into valid Stuntman designs and communicate with Stuntman via the exposed SiLA API. Designs must conform to Stuntman’s validated internal schema and cannot be submitted as arbitrary JSON files. This architecture allows Stuntman to integrate into broader ELN and AI ecosystems through structured file exchange and client-layer orchestration.
Will Stuntman interface with non-UL software?
Yes, Stuntman can integrate into non-UL software through its programmatic interface and structured data framework. Stuntman exposes APIs for execution control and generates structured output data, enabling external tools to feed conditions into Stuntman and receive experimental results back for modeling, analysis, or optimization.
Does Stuntman provide an API for programmatic design creation? How does it compare to Library Studio API or SiLA2 API for execution?
Yes, Stuntman includes an internal, object-oriented API for programmatic design creation. This API exposes structured design objects (e.g., StuntmanDesign, StuntmanLibrary, StuntmanChemical, StuntmanMap) along with helper classes, enabling designs to be constructed within the Stuntman environment using a Python-based, SDK-style approach.
This is distinct from Library Studio API, which is a function-based SDK (e.g., CreateNewDesign, AddLibrary) intended for external customer integrations. It is also different from SiLA2 APIs, which are network-based interfaces used for instrument communication and execution.
Stuntman’s design API is intended for use within the Stuntman environment and is not exposed as a public integration interface. If customers choose not to use the Stuntman interface, they may generate designs externally using their own scripts or LLMs, potentially using Stuntman script examples as reference. However, this is not a supported workflow. Any externally generated designs must still conform to Stuntman’s required schema and validation rules, and customers are responsible for ensuring compatibility.
Can analytical or purification systems be incorporated into Stuntman workflows?
Analytical or purification systems can be incorporated into Stuntman workflows if they are integrated with the platform through supported interfaces such as SiLA APIs or other supported integration layers. Once integrated and exposed through the Stuntman control layer, those instruments can be included in automated workflows and closed-loop experiments alongside Stuntman hardware.
For example, analytical results can be used in closed-loop workflows where experiment outcomes are analyzed and used to generate the next set of experimental conditions. The specific integration approach depends on the instrument and available interfaces.
What data can be visualized? Can the software visualize only results from connected instruments such as HPLC, Raman, or EIS, or can other evaluation results also be incorporated?
Stuntman Show visualizes data collected directly through Stuntman Run, including results from connected instruments. Data formats include numerical data, X-Y plots, and images. Incorporating data from third-party equipment that is not directly connected to Stuntman can be supported through custom development. We can scope and implement a file loader or data import workflow to bring externally generated results into Stuntman Show for visualization. The level of effort depends on the data format and integration requirements.
What data formats are supported for results export?
Stuntman’s native data output format is HDF (Hierarchical Data Format). HDF provides a hierarchical structure that preserves relationships between samples, operations, and results. HDF files contain structured, machine-readable experimental data, including information such as:
- Dispensed mass and volume
- Process parameters (for example temperature or gas flow)
- Timestamps and execution metadata
- Unique sample identifiers and experiment context
JSON or CSV are not native export formats, but conversion from HDF can be implemented programmatically using standard HDF libraries as part of a downstream data pipeline for integration with ELNs, ML platforms, or other data systems. The HDF schema supports structured metadata storage, enabling experiment context, process parameters, and analytical results to be linked to specific samples and runs.
If a customer has their own database or internal data system, can they build their own data import or export integration with Stuntman?
Yes, Stuntman generates experiment results in a structured HDF data format. Customers can build their own integration layer to export and translate this data into the format required by their internal database, ELN, or other data systems.
If external analytical data needs to be imported into Stuntman, the data would need to be converted into the Stuntman HDF format. Customers can develop their own data loader to generate compatible HDF files, or Unchained Labs can support this through a scoped custom development effort depending on the file format and integration requirements.
How does the Stuntman API interact with laboratory hardware? Can users define high-level experiment goals or directly control automation components?
Stuntman uses high-level SiLA APIs to interact with laboratory hardware. These APIs abstract many of the underlying hardware calls so users can focus on defining experiment designs and objectives rather than individual device commands. For advanced workflows, users can create and run custom scripts that directly interact with supported automation components.
How is the Stuntman software architecture structured and how do system components communicate with laboratory hardware?
Stuntman Run is implemented as the primary execution application responsible for coordinating experiment workflows and instrument interactions rather than as a distributed set of services. For communication, the platform exposes only high-level SiLA APIs as the external communication interface used to interact with laboratory instruments and automation components, and no additional internal services are exposed externally. Within the Stuntman Run environment, users can execute custom scripts through supported APIs. Experiment designs can be created using Python scripting or AI-assisted workflows.
Does the Stuntman API support synchronous and asynchronous operations, and when are each used?
Stuntman exposes a mix of synchronous and asynchronous APIs depending on the purpose of the operation. Short-lived actions such as configuration or status queries are handled synchronously and return immediately, while long-running processes such as experiment execution are handled asynchronously. The synchronous or asynchronous behavior is determined by the intended function of the API and the system architecture, and users do not select between synchronous and asynchronous modes for a given operation.
How can users or third parties extend Stuntman workflows without modifying the core software?
Third parties can extend Stuntman without modifying core code by using Python scripting and SiLA APIs. Users can create their own experiment designs using Python scripts and modify execution scripts to align with their specific workflows. In addition, users can run their own Python scripts within Stuntman Run or integrate third-party modules into the automation workflow through supported SiLA APIs.
How are Stuntman APIs versioned and maintained for compatibility with existing integrations?
Stuntman manages multiple API versions through versioning and backward compatibility practices. APIs are typically maintained in a backward-compatible manner to support existing integrations. In rare cases, an API may be deprecated, which may require users to update their code when adopting newer versions.
Can Stuntman AI generate workflows that include operations on third-party devices?
Yes. If a third-party device is integrated with Stuntman through supported interfaces (such as SiLA APIs), it can be incorporated into Stuntman workflows. In these cases, Stuntman AI can generate experiment designs or scripts that include operations involving those devices as part of the natural-language experiment design workflow.
How accessible is the Stuntman software documentation and API?
Stuntman provides documentation for the Python APIs, hardware resource objects, and workflow structure used within the platform. These materials are available to customers as part of the software environment and support development of custom workflows, integrations, and automation logic.