> For the complete documentation index, see [llms.txt](https://docs.mezzanine.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mezzanine.xyz/smart-contracts/documents.md). # Documents The *document registry* is a non-core contract used throughout the protocol. It is not redeployed each time that a Mezz organization is created. Rather, all instances of Mezzanine use the same document registry. Notably, the document registry in Mezzanine is not access-controlled. Anyone can add documents to the registry if desired. A document is made up of four different variables:

Code snippet from Mezzanine's DataTypes.sol

Documents are always versioned, and previous versions are always stored on-chain:

Whenever a document is updated, *nextVersion’s* current value is set to the updated document, and it is subsequently incremented. Only a document that exists can be updated. Versioned documents are always associated with an *owner*, and each document is associated with an index.

The exact methods for access control for documents have yet to be determined. Access control for documents would occur off-chain, such as by using [Lit Protocol.](https://www.litprotocol.com/) The URIs, themselves, will likely be stored on IPFS with the providers either being Filecoin or Pinata. However, this has yet to be determined. Initial versions of Mezzanine may have document URIs that point to a centralized interface. Generally, a document's name and URI are set by the users, themselves. There is a single exception: a company will always be created with an incorporation document and its initial name will be “*Company Name Incorporation Document*”. The owner of the Incorporation Document is the Treasury contract. The name and URI can always be updated by the Treasury later on if desired. At various points throughout the codebase, certain mappings keep track of a document index. For example, an asset in a company's capital stack will always point to a document. However, this document is not guaranteed to have an accurate, valid name and URI. Certain actions in Mezzanine will always create a document: * Adding an asset to the *capital stack* * Sending an invoice via the *billing router* * Hiring an employee via the *payroll manager* * Creating a Mezzanine company Old versions of a document are always queryable and immutable. The URI of an old version cannot be changed on-chain. However, depending on the system used for URIs, a URI may point to a new document if Mezzanine does not use a decentralized storage system. Departments and Treasuries are multi-signature wallets. Therefore, they can execute arbitrary transactions on their own. However, modules and ancillary contracts are standalone contracts and are unable to execute arbitrary transactions. Each of them contains logic to update their documents. "Removing" documents is akin to setting the document’s name and URI to null values. The Document Registry is upgradeable and can only be upgraded by the owner of the Mezz Hub, which will be the Mezzanine’s multi-signature wallet. Notably, the document registry's functionality is not aware of protocol state, since its functionality never deals with user funds. Therefore, it realistically never needs to be paused or frozen. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.mezzanine.xyz/smart-contracts/documents.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.