Trace an execution result back to its package and evidence

Before you start.

Set up your workspace

Open /explorer/execution/executions and select an available record. The collection API below is a public read. This walkthrough inspects an existing computation; it does not publish a package, deploy a runtime or invoke a job.

Examples are illustrative test plans, not customer results. Use only agreed access and non-production material.

Make the first read, then interpret it.

GET /api/v2/explorer/execution/executions

This public request needs no credential. It only reads existing information; it does not generate a sample or run an execution.

curl --fail-with-body --silent --show-error \
  'https://api.hybrid-chain.com/api/v2/explorer/execution/executions'

Read the response deliberately

• Use execution_id from executions to open the documented detail route; an empty array is not a completed demonstration.
• Follow the actual package reference and compare package_hash rather than matching a display name.
• A hash or attestation reference is evidence to inspect, not automatic access to the underlying private material.

Request paths, authentication modes and named response fields were checked against the published OpenAPI contract. Values are deliberately not filled with a fake live response. Follow the operation links for current schemas and errors.

The workflow at a glance.

Work through one useful case.

An operations team receives a computed business result. Before using it in a decision, it wants to identify the package behind it and understand the evidence retained around that execution. This walkthrough inspects records; it does not run a new job.

Keep one working record throughout

Choose one public execution and build a trace table with execution_id, package_hash, input_hash, output_hash, policy_hash, termination and available attestation references. Record only what the public response actually returns; do not infer downloadable private inputs.

1. 01

   Start from an identifiable execution

   Inspect the public execution collection and one detail record. Capture the identifier, observed state, and references actually returned. If the collection is empty or the requested record is unavailable, say so; do not substitute an unrelated result or a simulated success.

   Do this

   1. Run the public collection read and choose one actual execution.
   2. Record execution_id, termination and observation time in the trace table.
   3. Open its detail route and retain missing or incomplete fields as gaps.

   Expected result

   The review is anchored to one inspectable execution rather than a fabricated job result.

   If your result is different

   If the collection is empty or the record is unavailable, record that limitation and use an agreed test reference; do not substitute a static example as live evidence.

   Result: The review is tied to a real inspectable record, or clearly marked incomplete when no record is available.

2. 02

   Follow the package reference

   Open the package linked by the execution record and inspect its available commitments, source/build information, and runtime profile. Compare the exact references instead of relying on a human-readable name. Mark any missing relationship as unresolved rather than guessing a join between records.

   Do this

   1. Follow the package reference provided by the execution evidence.
   2. Compare the exact package commitment and inspect available source/build/runtime information.
   3. Record which relationships are directly evidenced and which cannot be established from the returned record.

   Expected result

   The reviewer can explain which package the result refers to and where the evidence trail stops.

   If your result is different

   Do not join packages and executions by similar names. An unresolved commitment relationship remains unresolved.

   Result: The reviewer can identify the package evidence supporting this execution and any gaps in the relationship.

3. 03

   Inspect result and runtime evidence together

   Review the input, output, policy, node, and timing references that the record actually makes public. Do not imply private inputs are downloadable because a commitment is visible. Separate a consistency check from a full independent reproduction; record exactly which checks were possible.

   Do this

   1. Inspect input_hash, output_hash, policy_hash and available attestation context using the current detail contract.
   2. Write down each verification you can actually perform with the available data.
   3. Label a public consistency check separately from a full independent reproduction with the original inputs.

   Expected result

   The report states the exact checks performed without overstating private-input access or reproducibility.

   If your result is different

   If the raw inputs are unavailable, do not claim to have reproduced the computation. Record the limited evidence check instead.

   Result: The report states what was verified from public evidence without overstating access or reproducibility.

4. 04

   Decide whether the result is fit for its purpose

   Have the acceptance owner examine the input assumptions and algorithm alongside the retained evidence. A reproducible wrong calculation is still wrong. If a later action would trade, sign, transfer, or change another domain, route it through that domain's separately authorized workflow.

   Do this

   1. Have the acceptance owner inspect input assumptions and the intended business meaning of the result.
   2. Add a case where a reproducible computation uses wrong input assumptions and document the rejection rationale.
   3. Keep any later trade, transfer or other domain mutation behind its own authority and enabled operation.

   Expected result

   An inspectable result supports a review but does not silently become a business action or a correctness guarantee.

   If your result is different

   If a needed write contract is absent from live OpenAPI, treat it as unavailable even if a source documentation page exists.

   Result: The business decision has explicit acceptance criteria and does not inherit action authority merely from a computation.

Test where the workflow stops.

A useful pilot explains failure as clearly as success. Record what you observed rather than presenting these expected checks as completed results.

Execution references an unexpected package

Flag the mismatch and inspect the exact references before using the result.

Evidence is missing or the record is incomplete

Keep the review incomplete; do not convert the absence of a warning into verification.

Result is reproducible but input assumptions are wrong

Reject or escalate the business conclusion independently of the integrity check.

A documented write is absent from live OpenAPI

Treat it as unavailable for this integration; a source-ready page is not production activation.

Your acceptance checklist.

Retain the environment, contract version, test time, redacted observations, unresolved dependencies, and responsible reviewer in your private evaluation report.

Keep the contract close.

These links point to documented operations, not executable controls. Check the current request schema, scopes, errors, and implementation status before using them. No credentials or live customer responses are embedded in this guide.

Read the published OpenAPI definition

Choose your next step.

Keep your worksheet and error notes. Continue with the next technical exercise using the same reference trail, and mark any stage that remains untested rather than treating the checklist as a completed deployment.

Need help with access or an unavailable integration? Contact the team with a redacted error and the guide step. Never send credentials or private records.