> 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-7-verifiable-compliance.md).

# Chapter 7 — Verifiable Compliance

Compliance completes before execution. Rule sources, applicability scopes, credentials, human approvals, authorization, and execution conditions become versioned policies bound to every transaction.

## 7.1 What verifiable compliance means

Verifiable compliance lets any party review the formal rule source, policy version, covered assets and participants, verified credentials, approver, effective time, and revocation status behind a rule decision. Legal interpretation stays with professional responsible parties, and each jurisdiction determines the meaning of its own rules. A compliance decision returns an explicit status such as approve, reject, pending\_evidence, manual\_review, expired, or disputed, and keeps reason\_codes, missing\_requirements, approver, and formal\_source.

## 7.2 PolicyProfile

| Field group  | Core fields                                                         | Purpose                                            |
| ------------ | ------------------------------------------------------------------- | -------------------------------------------------- |
| Scope        | jurisdiction, asset\_scope, offering\_scope, participant\_scope     | Limits what the rule covers; no unbounded reuse    |
| Version      | policy\_id, version, effective\_from, effective\_to                 | Guarantees the right version and time at execution |
| Requirements | required\_credentials, evidence\_rules, limits, prohibited\_actions | States credentials, evidence, limits, prohibitions |
| Decision     | decision, reason\_codes, conditions, expires\_at                    | Reviewable, time-bounded outcomes                  |
| Authority    | formal\_source, policy\_owner, approver, signature                  | Names the rule basis and the responsible party     |
| Governance   | change\_ref, review\_date, revocation\_ref                          | Manages change, review, revocation                 |

## 7.3 CaaS: Compliance as a Service

CaaS organizes rules across jurisdictions, asset classes, offering paths, participant types, and transaction stages into callable PolicyProfiles, with credential verification (KYC/KYB), AML screening, rule decisions, human approval routing, version updates, and audit export. The design principle: before DataIPO initiates an action, CaaS verifies first.

CaaS runs a core engine with pluggable modules: the engine handles rule parsing, execution scheduling, and result verification; modules attach per scenario (KYC, transaction limits, cross-border data) and adapt quickly to regional detail. Every rule links a formal source, an interpretation note, an applicability scope, test cases, an owner, and a review date; policy updates keep old versions so historical execution can be reconstructed. Creation, update, and execution records of every rule anchor on-chain.

## 7.4 SLC: Smart Legal Contracts

SLC connects formal legal documents, key clauses, responsible parties, signatures, conditions, events, and technical execution. Clauses that structure cleanly map to referencable conditions; clauses requiring professional judgment or external procedure remain under human or institutional control. The legal document stays the authoritative text; the protocol stores its identifier, version, signatures, validity, and integrity commitment. Amendments, supplements, waivers, and terminations appear as new versions and events, never as overwrites. SLC supports parameterized loading of regulatory standards such as MiCA, HKMA, MAS, and FinCEN, giving Policy-as-Code contract templates.

## 7.5 PCT: Proof-Carrying Transaction

PCT is the proof-carrying wrapper for controlled execution and a native transaction type of SimpleChain. It binds the execution intent to asset state, evidence, policy, participant credentials, authorization, settlement conditions, nonce, expiry, and signatures, checked in a fixed order split between the consensus and execution layers. On-chain transactions, institutional API instructions, and cross-system workflows can all carry a PCT.

| Order       | Check                                                                 | On failure                   |
| ----------- | --------------------------------------------------------------------- | ---------------------------- |
| 1. Intent   | Action, object, quantity or scope, expected result parse cleanly      | Invalid request              |
| 2. State    | Referenced state version exists, unexpired, free of blocking disputes | State conflict or suspension |
| 3. Evidence | Required evidence valid; sources and attestors satisfy policy         | Missing or invalid evidence  |

| Order            | Check                                                                | On failure                 |
| ---------------- | -------------------------------------------------------------------- | -------------------------- |
| 4. Policy        | Policy applies, version correct, decision permits execution          | Reject or human review     |
| 5. Credential    | Participant identity, role, and eligibility credentials valid        | Ineligible or expired      |
| 6. Authorization | Initiator and agent powers cover action, limits, period, object      | Reject as unauthorized     |
| 7. Settlement    | Asset leg, cash leg, custody, delivery conditions complete           | Incomplete or unexecutable |
| 8. Replay        | nonce, idempotency\_key, expires\_at valid                           | Duplicate or expired       |
| 9. Signature     | Required human, institutional, wallet, or account signatures present | Insufficient signatures    |

## 7.6 Privacy enhancement and selective disclosure

Selective disclosure proves that a participant meets eligibility, geography, limit, or status conditions while controlling how much identity and asset data is revealed. Zero-knowledge proofs and similar mechanisms work together with credentials, TDS, and audit access, with full support for revocation, regulatory access, error correction, and dispute handling.

> **Compliance claim**
>
> Every transaction carries its own compliance proof. PCT moves compliance from an audit after the fact to a condition of execution: a failing transaction never enters a block, with no need for later reversal.


---

# 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-7-verifiable-compliance.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.