# 7: Validating data
> Holochain applications specify **validation rules** for every type of entry or link. This empowers end-users to **check the integrity** of the data they see. When called upon to validate data, it allows them to identify corrupt peers and publish a **warrant** against them.

You may recall, from way back at the beginning, that Holochain's first pillar of trust is [**intrinsic data integrity**](https://hackmd.io/s/SkNLBMT9V). We said that each type of [**app entry**](https://hackmd.io/s/SJBBJFyiE#Source-chain-your-own-data-store) can contain any sort of string data whose correctness is determined by custom **validation rules**. Then we showed how [**peer validators**](https://hackmd.io/s/rJJbk6yoN#A-cloud-of-witnesses) subject entries to those same rules before accepting them.
If you're using our [Rust HDK](https://developer.holochain.org/api/latest/hdk/), you can create basic validation rules with built-in tools that let you define app entries as [structs](https://doc.rust-lang.org/rust-by-example/custom_types/structs.html), which can be converted to JSON and back again. This enforces a data schema for each type of app entry. But apps can (and should) define more finely-grained rules too.
The purpose of validation is to **empower a group of individuals to hold one another accountable to a shared agreement**. This is a pretty abstract claim, so let's break it down into a few categories. With validation rules, you can define:
* **The shape of valid data**---upper/lower bounds on numbers, non-empty fields, or correctly formatted email addresses
* **Rules of the game**---traditional games like Chess, or socioeconomic games like currencies, supply chains, and voting systems
* **Write privileges**---enforcing permissions for [creating](https://hackmd.io/s/rJJbk6yoN), [updating, and removing](https://hackmd.io/s/rJ2ByWBj4) entries and links
* **Entry membranes**---who's allowed to join the network
_Because every participant in this app holds a copy of the validation rules, everybody has the power to hold their peers to them._ As a user, you can refuse to participate in a fraudulent interaction. As a peer validator, you can blow the whistle on others who are committing fraud. When all these actions are aggregated, they allow a collection of individuals to form a self-policing network---a social organism with its own **immune system**.
#### Learn more
* [Guidebook: Validate Agent](https://developer.holochain.org/guide/latest/zome/validate_agent.html)
[Tutorial: **MicroBlog140** >](#)
[Tutorial: **ForgivingMicroBlogWithWriteControl** >](#)
[Next: **Handling data conflicts with CRDTs or resolution callbacks** >>](https://hackmd.io/@XYOAnQcjRD-lWNVnC2p2GA/S1KpBgA0V)
###### tags: `Holochain Core Concepts`
---
deleted example of validation rules...
To make it concrete, let's use a concrete example: a ['mutual credit' cryptocurrency](http://ceptr.org/whitepapers/mutual-credit) app. Mutual credit is a big subject, but we can use it to illustrate the importance of good validation rules. Here's how this currency works:
* Everyone's account starts at zero.
* Every transaction consists of a debit from the spender's account and a credit to the recipient's account.
* A participant's account balance consists of the sum of all their debits and credits.
* Limits may be set on negative and positive balances, in order to keep currency supply within a reasonable range.
To make this work as a Holochain app, we need validation rules like:
* Every debit entry written to a spender's account must be offset by a credit entry written to a recipient's account.
* Every debit/credit pair must be signed by both parties.
* The spender's current balance minus the transaction value must not exceed the community's agreed-upon negative credit limit.
* Conversely, the recipient's current balance plus the transaction value must not exceed the positive credit limit.
If we didn't have rules like this, we would see all sorts of fraud: credits without corresponding debits (counterfeiting), unauthorized transactions, or spending past credit limits.