> For the complete documentation index, see [llms.txt](https://dataipo.gitbook.io/dataipo-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-5-trusted-evidence-and-tds.md).

# Chapter 5 — Trusted Evidence and TDS

Evidence is the smallest unit of responsibility in the data plane. Every usable claim must state its source, attestor, time, scope, validity, and revocation status. What goes on-chain is the recomputable granular fact; the file itself stays in its data domain.

## 5.1 Granular Data: from files to granular facts

Granular Data means business events of minimal completeness produced in the digital space, composed of core business attributes and their logical relations. It decomposes an asset's physical attributes, ownership relations, dynamic value, and compliance information into data fragments that can be identified independently, updated in real time, and verified on-chain. Each granular record contains at least AssetID, EventType, Timestamp, Value, ValidatorSig, and AuditHash, and is signed and notarized by multiple validating nodes.

Effective granularity states its semantics, responsibility, time, source, privacy, and update rules. Over-aggregation hides differences and conflicts; over-splitting loses context and raises access cost. The protocol takes the business event as the unit of granularity.

Trust does not come from self-reporting. The protocol requires material facts to be recorded separately by mutually independent sources (business systems, payment and banking, logistics and warehousing, third-party verifiers, IoT devices) and cross-confirmed: after field alignment and deduplication, a fact lands on-chain only when at least two independent sources agree; conflicts are flagged record by record and traceable; every record can be recomputed.

## 5.2 GranularHash

GranularHash is an integrity commitment over granular data or a canonicalized data set. It lets a receiver verify that data matches the registered version, and it lets a publisher disclose only the commitment while keeping the sensitive original. GranularHash proves consistency of bytes or canonical form; it does not prove that content is true, complete, lawful, or still valid, so it must be used together with Source, Attestor, time, and status information.

## 5.3 Source, Attestor, and Oracle

A Source is where data is first produced, maintained, or formally published. An Attestor bears attestation responsibility for a claim and signs it verifiably. An Oracle delivers off-chain data, events, or computation results to the protocol under a defined mechanism. The three roles may rest with different parties or coincide under controlled arrangements; the protocol registers each separately.

| Role     | Must declare                                                                                     | Key risks                                                                            |
| -------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |
| Source   | Identity, data class, scope of authority, update time, access conditions                         | Wrong, stale, unauthorized, or semantically incomplete sources                       |
| Attestor | Identity, qualification or mandate, claim type, signature, validity period, revocation mechanism | Attestation beyond mandate, conflicts of interest, key leakage, lapsed qualification |
| Oracle   | Data sources, transformation rules, timestamps, fault tolerance, governance, conflict policy     | Single-point manipulation, delay, malformed data, selective relay                    |
| Consumer | Purpose, authorization scope, dependency version, verification result                            | Use beyond scope; mistaking "verifiable" for "true" or "compliant"                   |

SimpleChain's oracles run on decentralized nodes and multiple data sources. Nodes synchronize through an off-chain reporting protocol and drop outliers; aggregated data forms only when more than a preset share of nodes agree; nodes stake, and feeding false data is slashed. Oracles are modular by data type: Fact Oracle for operating events, Price Oracle for mixed-asset pricing, and industry oracles for sector indicators, with dynamic refresh driven by deviation thresholds and heartbeat intervals.

## 5.4 EvidenceEnvelope

EvidenceEnvelope is SimpleChain's evidence wrapper. It unifies the claim identifier, asset subject, source, claim type, observation and creation times, attestor, proof references, privacy class, validity status, and revocation information. Originals may stay in TDS, institutional data domains, object storage, or formal registries.

| Field group | Core fields                                             | Verification semantics                                       |
| ----------- | ------------------------------------------------------- | ------------------------------------------------------------ |
| Identity    | evidence\_id, asset\_subject, claim\_type               | Stable binding of evidence to asset, subject, and claim type |
| Source      | source\_id, source\_uri, source\_class, provenance      | Source identity, location, class, derivation                 |
| Time        | observed\_at, created\_at, effective\_from, expires\_at | Separates fact time, creation time, and validity window      |

| Field group | Core fields                                          | Verification semantics                              |
| ----------- | ---------------------------------------------------- | --------------------------------------------------- |
| Attestation | attestor\_id, credential\_ref, signature, proof\_ref | Attestor qualification, signature, external proof   |
| Privacy     | privacy\_class, access\_policy, data\_commitment     | Access to sensitive data and consistency commitment |
| Status      | validity\_status, revocation\_ref, dispute\_ref      | Valid, expired, revoked, disputed, superseded       |

## 5.5 Trusted Data Space (TDS)

TDS is the trusted data space for sensitive asset data: partitioning, access policy, key and credential checks, purpose constraints, audit records, version management, and controlled computation. It has four layers: an intake layer (IoT, mobile endpoints, enterprise APIs in real time), a verification and signing layer (ZKP and BLS multi-signature over sources), a hashing and anchoring layer (GranularHash embedded in the state tree), and an access layer (CaaS, oracles, regulatory nodes, and other authorized readers).

SimpleChain stores the commitments, access decisions, proof references, and audit results of key TDS objects, so multiple institutions build a shared evidence base without exposing full originals. TDS follows six principles: data minimization, provable access, traceable versions, identifiable derivations, propagating revocation, and exportable audit.

## 5.6 Evidence lifecycle and verification order

Evidence passes through eight stages: intake, normalization, attestation, registration, use, update, revocation and dispute, archiving and export. Consumers verify in a fixed order: parse the identifier and canonical form; verify integrity, attestor identity, and attestation authority; check observation time, validity window, scope, privacy authorization, revocation, and supersession; finally apply the PolicyProfile to conflicts and purpose limits. If any required step fails, the evidence enters no state and grounds no execution.

| Stage                  | Inputs                                                         | Normative output                                 |
| ---------------------- | -------------------------------------------------------------- | ------------------------------------------------ |
| Parsing and integrity  | Identifier, schema, canonicalization rules, GranularHash       | parsed / malformed; integrity\_valid             |
| Identity and authority | Source, Attestor, Credential, attestation scope                | identity\_valid; authority\_sufficient           |
| Time and status        | observed\_at, effective\_from, expires\_at, revocation\_ref    | valid / expired / revoked / superseded           |
| Scope and privacy      | Asset, fields, jurisdiction, purpose, access policy            | in\_scope / out\_of\_scope; disclosure\_allowed  |
| Conflict and adoption  | Competing claims, priority rules, human review, dispute status | accepted / pending\_review / disputed / rejected |

## 5.7 Evidence quality and conflict

Evidence quality covers at least source authority, attestor qualification, integrity, freshness, coverage, reproducibility, independence, and dispute status. When evidence conflicts, SimpleChain neither overwrites the old value nor simply adopts the newest: the system keeps the conflicting claims, sources, attestors, validity windows, and dispute handling status, the applicable PolicyProfile decides priority rules, human review, or suspension, and the resolution produces a new LifecycleEvent and Asset State version.

> **Evidence claim**
>
> What goes on-chain is a set of granular facts recorded separately by mutually independent sources, cross-confirmed, and recomputable record by record. Trust comes from an auditable chain of sources and responsibility; a self-reported PDF is not on that chain.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-5-trusted-evidence-and-tds.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.