Protect business information and verify its evidence

Before you start.

Set up your workspace

Open the object-list operation and confirm vault:read in the intended test workspace. The authenticated principal determines the workspace; this walkthrough does not add a vault selector. If no object exists, arrange one through the authorized client before continuing.

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/data-vault/objects

Use a trusted terminal and a scoped, non-production read credential supplied by your approved credential manager. The command sends the authorization header through standard input, not a literal token in the command. Do not enable shell tracing or paste the response into a public report; returned metadata may be private.

# Your approved credential manager must set HC_GUIDE_TOKEN first.
: "${HC_GUIDE_TOKEN:?Set a scoped test credential in this trusted terminal}"
printf 'Authorization: Bearer %s\n' "$HC_GUIDE_TOKEN" | \
  curl --fail-with-body --silent --show-error --header @- \
  'https://api.hybrid-chain.com/api/v2/data-vault/objects'

Read the response deliberately

• Use object_id from items to select the detail read. Record version_id as the returned evidence-version reference.
• encrypted_content_root is an opaque locator. The legacy content_sha256 field must not be treated as a hash of the source file; its schema says Core returns it empty.
• Inspect storage_readiness and evidence without inferring key access, download permission or a successful reconstruction.

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.

A finance team needs to show that a reviewed document matches a retained integrity reference, without exposing its contents in a public report. Start by inspecting what the object-read contract reveals, then separately plan an authorized retrieval test.

Keep one working record throughout

Use a non-sensitive test document already provisioned in the authorized workspace. Build an evidence worksheet with object_id, version_id, storage_readiness, encrypted_content_root, observation time and a separate retrieval-test status. Never store decryption material in the worksheet.

1. 01

   Discover the object inside the correct workspace

   List the authenticated workspace's top-level objects. Select an identifier returned by the collection route; do not guess another workspace's IDs. Note the minimized owner-use metadata and any storage readiness information actually present.

   Do this

   1. Run the owner-scoped read and inspect items and total.
   2. Select one non-sensitive object returned by the service and record object_id, version_id and observation time.
   3. Open the detail contract and replace only its documented object_uuid path parameter with the returned identifier.

   Expected result

   The worksheet points to one actual object in the intended workspace rather than a guessed or cross-workspace reference.

   If your result is different

   An empty collection is not a retrieval failure. If the expected object is missing, verify the principal/workspace with the owner; do not probe other owners' identifiers.

   Result: You have a real object reference within the intended ownership boundary.

2. 02

   Inspect the object evidence without overstating it

   Read that object's detail. Treat encrypted_content_root as an opaque integrity locator, not a download URL, a decryption key, or a grant of access. Record the reference privately alongside the test observation time. Do not infer document contents from a commitment.

   Do this

   1. Compare the detail evidence with the list entry using the returned object/version references.
   2. Mark a null or missing encrypted-content root as unavailable rather than inventing a value.
   3. Write one sentence beside the record: this reference does not disclose the document or grant retrieval access.

   Expected result

   Your display explains the observed evidence while keeping metadata visibility distinct from content access.

   If your result is different

   Do not compare a local plaintext SHA-256 to the opaque encrypted root. Use only the matching scheme defined by the actual storage/verifier workflow.

   Result: Your UI explains what the evidence establishes and avoids presenting metadata visibility as file access.

3. 03

   Define a separate retrieval and integrity exercise

   If retrieval is in scope, confirm the authorized client, key handling, exact content/version reference, and verification procedure with the team. Compare like-for-like commitments using the documented scheme; a plaintext file hash is not automatically comparable to an encrypted content root.

   Do this

   1. Add retrieval client, key custodian, exact version and verification procedure as separate worksheet fields.
   2. If a retrieval test is authorized and enabled, use that client with the non-sensitive document and record its actual outcome.
   3. If it is not enabled, mark RETRIEVAL NOT TESTED in the worksheet and finish the metadata exercise honestly.

   Expected result

   The report distinguishes a completed metadata inspection from a separately observed or still-planned retrieval exercise.

   If your result is different

   A missing key or client is a blocker for recovery, not a reason to expose secret material in a ticket or public demonstration.

   Result: A deployment-specific test plan explains who may reconstruct the document and how its integrity will be verified.

4. 04

   Rehearse a realistic recovery boundary

   Choose an agreed failure scenario using non-production material. Record which keys, available storage pieces, and operators are required by that deployment. Run recovery only through a confirmed workflow, and retain the observed outcome rather than assuming a demonstration's shard counts apply to your data.

   Do this

   1. Agree a non-production failure scenario with the recovery owner before changing any availability condition.
   2. Record the required keys, storage pieces and operator responsibilities for that deployment.
   3. Compare the observed recovered version and documented integrity check; retain failures and unresolved dependencies as well as success.

   Expected result

   The recovery section states what was actually tested and does not borrow shard counts or durability claims from an illustration.

   If your result is different

   If the recovered version differs, preserve both references and stop the acceptance review. Do not overwrite the expected reference to make the comparison pass.

   Result: The review identifies verified behavior, remaining dependencies, and the owner of each recovery responsibility.

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.

Principal lacks vault:read or owner authority

Handle denial without returning protected payloads or treating a cached success as current access.

Identifier belongs outside the workspace

Do not expose another owner's metadata. Handle the documented not-found/denied response without leaking existence.

Object evidence service is unavailable

Mark the result unavailable and preserve that distinction from an integrity failure.

Retrieval route or required key is missing

Stop the retrieval exercise. A successful metadata read is not evidence that recovery is possible.

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.