> 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-6-verifiable-asset-state-tasm.md).

# Chapter 6 — Verifiable Asset State: TASM

TASM (Trusted Asset State Machine) upgrades an asset from a static identifier to a stateful object. Every state dimension carries its source, responsible party, validity window, proof references, and version relations.

## 6.1 Asset State is a nine-dimensional vector

Asset state consists of dimensions that are independent yet related. SimpleChain expresses Asset State as a nine-dimensional vector: Identity + Evidence + Rights + Compliance + Operations + Cashflow + Risk + Settlement + Lifecycle.

| Dimension  | Content                                                                      | Typical triggers                                                      |
| ---------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| Identity   | Asset, subject, contract, account identifiers and relations                  | Registration change, renaming, relation change, credential revocation |
| Evidence   | Evidence set, quality, validity, disputes                                    | New evidence, expiry, revocation, conflict resolution                 |
| Rights     | Right types, beneficiaries, restrictions, priority, legal documents          | Signing, transfer, pledge, release, judicial or contractual events    |
| Compliance | Applicable policies, participant eligibility, disclosure and approval status | Rule updates, credential updates, changes of geography or role        |
| Operations | Operating data, service status, performance, key events                      | Formal data updates, anomalies, acceptance, maintenance, shutdown     |
| Cashflow   | Accrued, received, distributable, distributed, reconciliation                | Payment, collection, distribution, adjustment, reversal               |
| Risk       | Risk factors, thresholds, alerts, mitigation, disposal status                | Data changes, model updates, human review, event triggers             |
| Settlement | Asset leg, cash leg, custody, settlement receipts                            | Submission, confirmation, failure, return, final reconciliation       |
| Lifecycle  | Onboarding, active, suspended, disputed, disposed, terminated, archived      | Formal process events and decisions of responsible parties            |

Aggregate labels such as "investable" or "normal" may appear only as display results, never as substitutes for dimension status.

## 6.2 AssetStateRecord and LifecycleEvent

AssetStateRecord is the snapshot of one asset at a given version and effective time. It contains at least asset\_id, version, the state dimensions, evidence\_refs, policy\_refs, authorized\_updater, effective\_time, prior\_state, signatures, and dispute\_flag. State that depends on external systems also stores the external record identifier, receipt, and last verification time, with synchronized caches marked explicitly as derived records.

LifecycleEvent is the smallest audit unit of a state transition. It contains at least event\_type, before\_state, after\_state, actor, authorization, evidence, event\_time, result, and audit\_ref. It binds "what happened" to "why it was allowed to happen," so every state change traces to evidence, policy, and authorization.

| Stage         | Conditions to pass                                                     | On failure                                     |
| ------------- | ---------------------------------------------------------------------- | ---------------------------------------------- |
| Identity      | asset\_id, actor, and role resolve; credentials within validity        | Reject or hold for completion                  |
| Version       | prior\_state matches the current state; no concurrent update           | Return conflict; never overwrite               |
| Evidence      | Required evidence exists, valid, unrevoked, meeting the quality policy | Suspend; flag gap or dispute                   |
| Policy        | PolicyProfile applies; version and effective time correct              | Reject or route to human review                |
| Authorization | Actor or agent covers the action, limits, scope, and validity          | Reject; record the attempt                     |
| Result        | Event completed; external receipts match the expected state change     | Enter failure, compensation, or reconciliation |

## 6.3 Concurrency, idempotency, and time

One asset may be read and updated by several systems at once. TASM uses an explicit version precondition: an update is accepted only when its referenced prior\_state matches the current version; conflicting submissions return an identifiable error and must recompute. Every event carries a unique idempotency\_key, and repeated submissions return the same result.

State time separates at least observed\_at, event\_time, effective\_time, and recorded\_at: fact observation, business occurrence, legal or economic effect, and protocol registration usually differ. Queries can reconstruct history by effective time and by record time, keeping intact the state that past decisions relied on.

## 6.4 Revocation, dispute, and recovery

Revocation is expressed as a new event, with the original credential and state fully preserved. A dispute lets multiple claims coexist and freezes or limits actions that depend on the disputed dimension. Recovery must rest on a new EvidenceEnvelope, PolicyProfile, or authorization decision, producing a new AssetStateRecord. When an external system rolls back, a settlement is returned, an account is frozen, or a legal document lapses, TASM takes the external fact in as a new event and recomputes the affected dimensions; on-chain technical finality describes only the ledger's own state.

## 6.5 The read-consistency contract

A state query response must let the consumer reproduce its reading context. It returns at least asset\_id, state\_version, effective\_time, recorded\_at, dimension\_status, evidence\_refs, policy\_refs, dispute\_flags, freshness\_boundary, and proof\_summary.

| Read mode      | Consistency semantics                                                              | Boundary handling                                            |
| -------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| current        | Returns the confirmed current version and its record time                          | Returns blocked explicitly under a blocking dispute          |
| as-of          | Reconstructs what was visible at a given effective and record time                 | Historical results keep the information visible at that time |
| pinned version | Returns the named version with full before/after references                        | Rejects when the version is missing or unauthorized          |
| subscription   | Pushes dimension changes, evidence revocation, policy supersession, dispute events | Reconnection resumes from the cursor; never skips silently   |
| execution read | Binds the state version to a PCT and its idempotency key                           | Version change before submission invalidates and re-prepares |

When AICOS reads Asset State it receives the current state, named historical versions, evidence summaries, policy versions, and dispute and expiry flags. Model output must cite the state version it used; when that state updates, the system identifies which conclusions need recomputation.

> **State claim**
>
> The asset changes from a snapshot taken on issuance day into a state stream that is versioned, signed, disputable, and reconstructable at any historical point. For the first time, secondary markets have an object they can price continuously.


---

# 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-6-verifiable-asset-state-tasm.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.