# Documents {% hint style="info" %} For technical documentation, see [DocumentRegistry](/smart-contracts/source-code/documentregistry.md) {% endhint %} ## Overview Accounts in Mezzanine can store documents via Mezzanine's *document registry*. The document registry stores *versioned* documents on-chain for *all* Mezzanine departments and boards: it is not redeployed each time that a Mezzanine instance is created. Documents, similar to NFTs, store a *URI* that points to a decentralized storage network, such as Arweave or IPFS. Files stored on these types of networks are immutable and cannot be changed. For example, let's look at the [smart contract of *Bored Ape Yacht Club*](https://etherscan.io/token/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#readContract), a popular NFT collection. Calling the *tokenURI( )* function with the token id, 0, returns the following URI, which points to IPFS: *ipfs\://QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/0.*

Query of the tokenURI() function via Etherscan

If you go to this link, you will find the JSON file that contains the BAYC #0’s metadata:

BAYC 0's Metadata

These attributes are easily verifiable on [OpenSea](https://opensea.io/assets/ethereum/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d/0):

BAYC 0 on OpenSea

Files stored on IPFS must have nodes that *pin* them to guarantee that the file is rapidly queryable. Some of the most common providers for *pinning* are Filecoin and Pinata. Other decentralized storage networks exist that have similar functionality, such as Arweave. However, the most widely used decentralized storage network is IPFS. *Read the* [*Pinata documentation*](https://docs.pinata.cloud/docs/what-is-ipfs) *to learn more about IPFS* The immutable storage of documents in Mezzanine will follow a similar pattern. In particular, documents store four different variables, one of which is determined by a Mezzanine user: 1. A document name 2. A document URI, which points to a file on a decentralized storage network 3. A version 4. The last time that the document was modified The document name is the only variable determined by the user with one exception: each organization in Mezzanine will initially have an *incorporation document* that can only be modified by the organization's board of directors. The initial version of this document will always follow the same syntax. For company *Foo*, its incorporation document would aptly be named *Foo Incorporation Document*. Document names and URIs can always be updated by their *owner,* which in turn creates a new version of a document. All documents in Mezzanine are *versioned,* and old versions will always be queryable and immutably stored. Documents are always versioned at zero, and each time that a document is updated, this version is incremented. For example, if *Foo* updates its initial incorporation document, the new version of this document will be one. Any *versioned* document can be updated such that the document's name and URI can be changed at the discretion of the owner. A document URI will be provided and abstracted for all departments, modules, and boards that use Mezzanine. The Mezzanine team will work with a provider to make these documents easily queryable at all times. However, the provider and decentralized storage network have yet to be determined. At the time of writing, documents in Mezzanine are *not* access-controlled. It has yet to be decided whether or not access-controlled documents will be included in the initial version of Mezzanine. The team is actively considering implementing access control via [*Lit Protocol*](https://developer.litprotocol.com/v2/whatIsLit). The enforcement of access control would occur *off-chain* via clever cryptography and would not change the above methodology for storing documents. ## Uses of Documents in Mezzanine Certain functionality within Mezzanine is associated with the creation of a new document in the Document Registry. Here are some examples: * Assets in an organization's capital stack are associated with a document * An employment contract is associated with a document * A bill or invoice is associated with a document The addition of these documents is *optional*. These actions will simply create a blank document in the document registry with no name or URI if a document is not provided. For example, if an organization hires someone but decides not to provide an on-chain document, a blank document will be added to the document registry. This blank document can then be updated retroactively if desired, such that it contains a name and URI. Again, the above actions create *associated* documents. Specifically, all documents in the document registry are associated with an index. These indexes are then stored in correspondence with the above actions. For example, an asset in the capital stack *knows* its corresponding document's index. This index can then be used to query the Document Registry to clarify the intended functionality of the asset. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.mezzanine.xyz/protocol/modules/documents.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.