HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network
HYBRID-CHAIN
Execution Studio / HybridScripts

A result needs context.
Make the computation inspectable.

When software produces a business result, your team should be able to inspect the package, inputs, policy, and resulting evidence. Execution Studio brings those stages into a deterministic execution model. Start with public records and confirm the exact enabled API operations before planning package publication or invocation.

See how it works ↓Discuss your use case

Evidence & integration planning · Check the exact operation and deployment.

Computation evidenceWhich package produced this result?
  1. Package commitment
  2. Runtime & policy
  3. Result evidence
Illustrative workflow · availability and access controls apply
A familiar challenge

A business process has produced a result. Your reviewer needs more than a success message: which code, inputs, runtime, and policy were involved?

A more useful way forward

Inspect retained execution lineage and plan against enabled contracts. Public records do not establish that your workload can be deployed or invoked.

See a practical example ↓
Why it matters

Look beyond the success message.

For platform developers, node operators, and verification teams.

Explain where a result came from

Give technical reviewers a route from the reported output back to its package and retained execution context.

Plan around explicit limits

Review supported runtimes, capabilities, and resource policies instead of assuming arbitrary code can run anywhere.

Keep business authority separate

Computing a result does not authorize a payment, trade, or data mutation in another service.

Core capabilities

The capabilities behind the outcome.

Match these capabilities to your workflow. Enabled operations and access are confirmed during integration planning.

Package provenance

Inspect available package and source commitments. Establish which immutable version a result refers to rather than relying on a mutable name.

Validation and policy context

Review the declared runtime, resource limits, and available validation evidence. A validation result applies to specific inputs and policy, not every later version.

Execution lineage

Connect retained invocation, runtime, and node references where available. Keep admission, execution completion, and external effects separate.

Result verification

Compare available input, output, and receipt commitments against the same lineage. Define your own acceptance checks before relying on a result.

Inspect public records Review documented operations

Public records illustrate inspectable data; they are not customer results or confirmation of production activation.

How Execution Studio / HybridScripts works

Inspect the package, the run, and the result.

  1. 01
    Establish the package

    Find the exact package and source commitments and inspect the available policy and validation context.

  2. 02
    Follow the execution

    Review the retained execution and runtime references. An accepted request is not proof of completed computation.

  3. 03
    Verify the outcome

    Compare output and receipt commitments and apply your acceptance policy. Independently verify any permitted external business effect.

A practical example · illustrative

Review a computed allocation before using it.

An illustrative operations team receives an allocation result. A reviewer wants to establish the exact package and inputs before a separate system considers acting on it.

Version
Locate the package and its immutable commitments.
Context
Inspect available input, runtime, and execution references.
Decision
Verify the output under your acceptance policy; authorize any later business action separately.
What the team takes away

The reviewer has evidence for assessing the computation—not an implied instruction to trade or move funds.

Evidence & integration planning

Plan your first deployment.

Public package, node, and execution evidence is a starting point for evaluation. Package creation, validation, publication, deployment, invocation, and trigger workflows include planned contracts. Source-ready documentation does not establish production activation. Call an operation only when its exact contract is present in live production OpenAPI and your workspace is authorized.

Before your first integration

  • Select an existing public package and execution record and trace their available commitments.
  • Check the live OpenAPI for each intended write or invocation; treat missing and planned contracts as unavailable.
  • Define acceptance tests for inputs, runtime policy, outputs, and any separately authorized external effect.
Plan the integration Check the API contract
Open the account workspace
Questions before you build

Execution Studio / HybridScripts, explained.

Can we deploy and invoke every documented package operation today?

No. Some contracts are planning references. Confirm each exact operation in live production OpenAPI, along with workspace access, runtime support, and deployment prerequisites.

Is this an unrestricted code runner?

No. The model uses bounded artifacts, runtime profiles, schemas, capabilities, and resource policies. Do not assume support for arbitrary shell commands, destinations, or dependencies.

Does deterministic mean the result is correct?

No. Reproducibility and integrity evidence do not establish that the inputs, algorithm, or business conclusion are correct. Your application needs its own acceptance criteria.

Can execution access our wallet or change a market?

Not merely because a package ran. External domain effects require separate owning-domain authority. Nothing here enables frozen trading controls, signing, or settlement.

What should we agree before starting a pilot?

Use the product-specific checklist above to define scope and acceptance tests. Ask the team to confirm the deployment environment, access, supported operations, integration responsibilities, support arrangements, and commercial terms. Availability labels are not a pricing quote or a service-level commitment.

Start with one useful result

Make it work for your team.

Bring your workflow. We’ll help identify the scope, access, and acceptance checks for a practical pilot.

Plan your pilot
Build the next part of your workflow

Connected products.

Start with Execution Studio / HybridScripts. Review these adjacent capabilities when your requirements call for them.

Automation

Connect platform events to controlled, retry-safe business actions.

Explore Automation
Plan your integration Discuss a scoped pilot All products