> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudeval.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Platform model

> Reference the main CloudEval AI objects and how they relate to each other.

This page is the shortest stable description of how CloudEval is structured.

## Core objects

| Object        | What it represents                                 | Why it matters                                         |
| ------------- | -------------------------------------------------- | ------------------------------------------------------ |
| Connection    | A source of live cloud data or infrastructure code | It tells CloudEval what to analyze                     |
| Project       | The main working unit                              | It holds files, topology, status, reports, and sharing |
| Report        | A generated evaluation output                      | It surfaces cost or architecture findings              |
| Sharing state | Visibility and access configuration                | It controls who can see or collaborate on a project    |

## Object relationship

```mermaid theme={null}
flowchart LR
  connection["Connection<br/>sync or template"] --> project["Project<br/>files, graph, status"]
  project --> reports["Reports<br/>cost and architecture"]
  project --> sharing["Sharing state<br/>private, collaboration, links"]
  reports --> sharing
```

<AccordionGroup>
  <Accordion title="Connection" icon="plug">
    A connection is the source CloudEval reads from. It can represent live Azure resources through Cloud sync or infrastructure-as-code content through template-backed imports.
  </Accordion>

  <Accordion title="Project" icon="folder">
    A project is the working unit that ties source data, files, topology, report history, status, and sharing together. Most automation commands and app workflows target a project.
  </Accordion>

  <Accordion title="Report" icon="clipboard-list">
    A report is a generated output attached to a project. Current public docs focus on cost and architecture reports because those are the main review surfaces.
  </Accordion>

  <Accordion title="Sharing state" icon="share-2">
    Sharing state controls whether a result stays private, is visible to invited collaborators, or is exposed through a read-only share link.
  </Accordion>
</AccordionGroup>

## Connection types and setup paths

CloudEval stores two internal connection categories:

* `sync`
* `template`

Users see three setup paths:

| User-facing path                        | Internal category | Source shape                                                                 |
| --------------------------------------- | ----------------- | ---------------------------------------------------------------------------- |
| Cloud sync                              | `sync`            | Deployed Azure resources read from scoped subscriptions or resource groups   |
| Infrastructure as code: single template | `template`        | One ARM JSON template and optional parameters file                           |
| Infrastructure as code: workspace       | `template`        | Multiple files, linked or nested ARM templates, and `.cloudeval/config.yaml` |

This distinction matters for automation. A multi-file IaC workspace is not a new
live cloud connection type; it is a richer template-backed source that resolves
to the same diagram and report pipeline.

## Project types and status

Projects can track status for:

* sync
* architecture
* cost
* unit tests

A project can also expose latest report metadata and dashboard summaries for cost and architecture.

## Share views

CloudEval share links support these read-only view modes:

* `preview`
* `code`
* `split`

## Collaboration roles

Projects support:

* owner
* editor
* viewer

## Next step

Use [Report types and statuses](/reference/report-types-and-statuses) if you need more detail on output structure, or [Share links](/reference/public-sharing) if you are documenting access behavior.