> For the complete documentation index, see [llms.txt](https://docs.zama.org/concrete/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zama.org/concrete/developers/contributing/layout.md).

# Project layout

## Concrete layout

Concrete is a modular framework composed by sub-projects using different technologies, all having theirs own build system and test suite. Each sub-project have is own README that explain how to setup the developer environment, how to build it and how to run tests commands.

Concrete is made of 4 main categories of sub-project that are organized in subdirectories from the root of the Concrete repo:

* `frontends` contains **high-level transpilers** that target end users developers who want to use the Concrete stack easily from their usual environment. There are for now only one frontend provided by the Concrete project: a Python frontend named `concrete-python`.
* `compilers` contains the sub-projects in charge of actually solving the compilation problem of an high-level abstraction of FHE to an actual executable. `concrete-optimizer` is a Rust based project that solves the optimization problems of an FHE dag to a TFHE dag and `concrete-compiler` which use `concrete-optimizer` is an end-to-end MLIR-based compiler that takes a crypto free FHE dialect and generates compilation artifacts both for the client and the server. `concrete-compiler` project provide in addition of the compilation engine, a client and server library in order to easily play with the compilation artifacts to implement a client and server protocol.
* `backends` contains CAPI that can be called by the `concrete-compiler` runtime to perform the cryptographic operations. There are currently two backends:
  * `concrete-cpu`, using TFHE-rs that implement the fastest implementation of TFHE on CPU.
  * `concrete-cuda` that provides a GPU acceleration of TFHE primitives.
* `tools` are basically every other sub-projects that cannot be classified in the three previous categories and which are used as a common support by the others.

## Concrete Python layout

The module structure of **Concrete Python**. You are encouraged to check individual `.py` files to learn more.

* concrete
  * fhe
    * **dtypes:** data type specifications (e.g., int4, uint5, float32)
    * **values:** value specifications (i.e., data type + shape + encryption status)
    * **representation:** representation of computation (e.g., computation graphs, nodes)
    * **tracing:** tracing of python functions
    * **extensions:** custom functionality (see [Extensions](/concrete/operations/other-operations/extensions.md))
    * **mlir:** computation graph to mlir conversion
    * **compilation:** configuration, compiler, artifacts, circuit, client/server, and anything else related to compilation


---

# 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://docs.zama.org/concrete/developers/contributing/layout.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.
