CHAPTER 07
Evidence, Verification, and Auditability
Make relevant events and decisions inspectable while keeping confidential inputs within their boundaries.
- Record
- References
- Check result
- Review trail
A system becomes easier to operate when it can explain the relationship between a request, a decision, and a result. Evidence is the material that supports that explanation. Hybrid-Chain includes evidence-oriented capabilities across its products, together with public verification surfaces for records that are appropriate to expose.
Different records answer different questions
| Record or evidence | Question it can help answer | What should not be inferred automatically |
|---|---|---|
| Integrity commitment | Does the checked material match this reference? | The material is true, legally sufficient, or currently retrievable. |
| Decision record | What outcome was recorded for the reviewed subject? | The proposed action has executed. |
| Operation receipt | What stage did the responsible service acknowledge? | Every downstream stage has completed. |
| Publication or inclusion evidence | Is the referenced record present in the relevant published history? | The underlying private content is public or available to the reader. |
| Execution lineage | Which recorded package and context relate to this result? | Every possible workload is enabled or the result is correct for every business purpose. |
Continuity across systems
Evidence Streams addresses the need to follow admitted events and their context over time. In an investigation, the goal is not merely to collect more logs. It is to locate the relevant records, understand their provenance, and identify gaps or changes in continuity. Other modules contribute evidence specific to their own responsibility, such as a governance decision, a funding observation, or an execution record.
Applications can connect these records to their business workflow without treating them as interchangeable. A notification may report that a stage occurred, while the authoritative service supplies the current state. A lost response may require reconciliation. A retry should not be assumed safe merely because an earlier attempt was not visible to the caller.
PRECISE CLAIMS, USEFUL CHECKS
A verification glossary
These terms describe different kinds of assurance. The linked interface is an example of where the concept matters, not a claim that every record supplies a complete proof.
- Commitment
A reference that binds an integrity check to particular material under the relevant scheme.
Who can check it: A verifier with the specified comparison procedure and the material or proof it requires.
Interpretation limit: The reference is not the content, an access grant, or proof that its assertions are true.
Inspect object metadata and evidence- Receipt
An acknowledgment of the stage described by the issuing service, such as acceptance of a request.
Who can check it: The authorized caller or reviewer who can inspect the corresponding operation state.
Interpretation limit: Acceptance does not imply that every downstream action has completed.
Read the machine-readable contract- Publication or inclusion evidence
Evidence that a specified record appears in the relevant published history, according to that history's verification rules.
Who can check it: A reader of the public record or a verifier with the required supporting evidence.
Interpretation limit: Publication does not make associated private content accessible or establish its real-world truth.
Inspect a public evidence stream- Retention information
Policy or observed lifecycle information describing how a record is intended to be retained or what has been observed over time.
Who can check it: An authorized records owner or auditor with the applicable policy and lifecycle evidence.
Interpretation limit: Policy and observation are different. Metadata reads do not themselves expose every retention function or prove current recoverability.
Inspect object metadata and evidence- Policy decision
The result of evaluating a particular subject against the applicable policy and context.
Who can check it: The authorized evaluator or reviewer who can inspect the returned decision and reasons.
Interpretation limit: An allowed dry-run result is not an approval, reservation, signature, payment, or guarantee about future state.
Evaluate an agent's proposed action- Execution outcome
The recorded state or result associated with an identified execution and the references available for its review.
Who can check it: A public-evidence reader or an authorized reviewer, depending on the record's exposure.
Interpretation limit: Traceable execution does not establish that the inputs or algorithm are appropriate for every business purpose.
Inspect execution evidence- Settlement finality
The completion posture supported by the applicable network and settlement evidence.
Who can check it: A party with access to the relevant authoritative records and an understanding of the network's confirmation rules.
Interpretation limit: A submitted request, reserved amount, or broadcast alone is not final settlement.
Inspect settlement stages
Private context and public verification
Public verification is most valuable when it exposes what is needed to check the public claim and excludes unrelated private material. Explorer records can support transparency around selected events without becoming a directory of confidential documents, personal information, wallet secrets, or internal operating arrangements.
For organizations, this creates a practical path between complete opacity and indiscriminate disclosure. An authorized reviewer can inspect detailed context where permitted, while another party can inspect a narrower public record. The evidence's subject, scope, freshness, and authority determine which conclusions are justified.
FROM ARCHITECTURE TO INTERFACE
Engineering references
Use public records to inspect the evidence actually available, following returned relationships rather than assuming that unrelated records belong together.
Inspect a public evidence stream
Connect event-continuity claims to the stream's public record.
GET/api/v2/explorer/evidence-streams/{stream_uuid}- Observable result
- The evidence-stream detail exposed by the public Explorer interface.
- Authority and limits
- Public visibility does not expose every private event or prove the truth of a real-world assertion.
Inspect execution evidence
Trace a reported result to the execution record available for review.
GET/api/v2/explorer/execution/executions/{identifier}- Observable result
- The public execution detail and the references made available by that record.
- Authority and limits
- An execution record is not permission to invoke a workload or perform an external business action.
Follow the referenced package
Inspect the package actually referenced by an execution.
GET/api/v2/explorer/execution/packages/{identifier}- Observable result
- The package evidence exposed by the public interface.
- Authority and limits
- Matching package references does not establish algorithm correctness or access to private inputs.
Selected operations were checked against the public OpenAPI contract on October 1, 2026. Links open documentation; they do not invoke an operation. Authentication, exact schemas, and deployment requirements remain defined by the current contract.
READ THE EVIDENCE
What an object evidence record actually tells you.
The following partial, synthetic projection uses field names from the public DataVaultObject contract. Angle-bracket values are placeholders, not real identifiers or valid proof material. Omitted fields remain defined by the full schema. This example teaches interpretation; it is not a complete API response or a cryptographic verification fixture.
{
"object_id": "<owner-scoped-object-id>",
"version_id": "<immutable-version-event-id>",
"created_at": "2026-09-29T12:00:00Z",
"content_sha256": "",
"encrypted_content_root": "<opaque-integrity-locator>",
"evidence": {
"event_id": "<lifecycle-event-id>",
"event_commitment": "<lifecycle-event-commitment>",
"recorded_at": "2026-09-29T12:00:00Z",
"anchor_state": null
}
}Resolve identity and version before comparing values
object_id identifies the protected object within its owner-scoped boundary. version_id identifies the immutable evidence event for the exact version represented. Preserve both. A matching filename is not a sufficient join, and a later object read may describe a different version than the one used for an earlier decision.
- Retain for review
- Object identifier, version identifier, authorized workspace context, and the time you performed the read.
- Acceptance check
- Are both records about the same version and the same authority boundary?
Separate lifecycle evidence from content evidence
evidence.event_id and evidence.event_commitment refer to the associated lifecycle event. created_at and evidence.recorded_at describe the transitions represented by those fields, not the current observation time. A content_proof, when supplied, concerns the upload commitment and is distinct from later validation or access events.
- Retain for review
- The event reference and commitment exactly as returned, with the applicable evidence scheme and verification procedure.
- Acceptance check
- Have you identified what is committed before comparing it? Do not hash arbitrary JSON and assume that it reproduces an unspecified commitment construction.
Keep opaque locators and legacy fields in their lane
encrypted_content_root is an opaque integrity locator, not a URL, key, or access grant. The legacy content_sha256 field is not evidence of SHA-256 over source bytes; the current contract describes it as empty. Neither field should be relabeled as a verified plaintext file hash.
- Retain for review
- Field names and their original meanings, without inventing a download route or comparison algorithm.
- Acceptance check
- If the reviewer needs to verify content, do they possess the separately authorized material or proof and the documented comparison method?
Report the narrow result of each check
A null anchor_state supplies no affirmative publication or inclusion claim. A populated value must be interpreted under the corresponding evidence rules. Matching an identified record or validating a supported commitment does not prove supplier truthfulness, current recoverability, content-access permission, or final payment settlement.
- Retain for review
- Which checks were performed, which passed or failed, which were not possible, and the supporting references.
- Acceptance check
- A sound conclusion might be: the inspected metadata refers to this object version; content comparison and inclusion verification were not performed. Do not upgrade that into a blanket verified badge.
Retain the authorized original response privately, record a separate observation time and effective request identifier where returned, and make any shared report deliberately narrower. Evidence becomes useful when another reviewer can reproduce the stated check—not merely recognize a hash-shaped string.
Auditability as a product property
The platform's advantage is the opportunity to make evidence part of normal operation rather than reconstructing it only after an exception. Reviewable outcomes help engineering, operations, and governance teams discuss the same event with clearer terms. They do not replace independent assurance, responsible interpretation, or the legal requirements of a particular organization.
Hybrid Explorer: a public route from claim to evidence
Hybrid Explorer is the dedicated public, read-only interface for finding published Hybrid-Chain records and examining their available evidence. Its directories span ledger and wallet activity, identity and authority records, markets, assets, execution, contracts, and other proof domains. Public browsing gives engineers and reviewers a common reference without granting access to account operations or confidential source material.
The distinction between a searchable record and a verified conclusion is essential. A directory can contain historical, test, incomplete, or differently scoped evidence. An interface label describes the check or state presented by that interface; a reviewer must still identify the exact subject and supporting material before relying on it. An unavailable response or empty result should remain an unavailable or empty observation, not be promoted into a successful check or a claim that an event never occurred.
A repeatable Explorer walkthrough
| Step | What to do | What to retain |
|---|---|---|
| 1. Find the exact subject | Search a public identifier or select the appropriate evidence directory. Use the returned record type and references, not a similar name. | Record URL, identifier, evidence class, and the question being investigated. |
| 2. Establish network and time | Check Mainnet, Testnet, or Devnet context and distinguish event time from the time you observed the record. | Network, relevant version or event, observation time, and any freshness limitation. |
| 3. Follow supplied references | Open the supporting records or base-layer references actually associated with the subject. | The relationship between records and any missing or inaccessible evidence. |
| 4. Inspect the stated verification | Identify what was checked, which evidence supports it, and whether a further check is available to the reviewer. | Passed, failed, and unperformed checks, with their method and scope. |
| 5. State a bounded conclusion | Describe only what those checks establish for that subject. Reconcile business completion with the responsible service where required. | The supported conclusion, unresolved questions, and separate conditions for completion. |
For example, a Data Vault public event can support review of a protected-state transition through published commitments and associated evidence. It does not provide the underlying file or grant permission to retrieve it. Checking that an event is included in a published batch is a different question from establishing current authorized retrieval, and neither establishes that the document's business assertions are true.
Publication, verification, and finality are distinct
Explorer settlement views explicitly separate development, testing, and production contexts, and distinguish operational evidence from financial settlement. Technical readiness describes an observed condition; governance approval concerns a permitted change; settlement finality concerns the exact completed operation under its applicable rules. A wallet activation, test credit, or infrastructure proof must be interpreted in its own class.
This makes Explorer useful as a shared inspection surface rather than a substitute for the responsible system. Its public evidence can help a team explain what happened and locate what remains unproven. It does not move assets, expose private identity or signing material, or convert a displayed record into authority to act.