> ## Documentation Index > Fetch the complete documentation index at: https://docs.chainloop.dev/llms.txt > Use this file to discover all available pages before exploring further. # Overview > Get an overview of the core concepts of Chainloop. ## Data Gathering Primitives ### Material In Chainloop, a material is any piece of evidence (metadata) generated as part of the software development lifecycle (SDLC), or in more general terms, in any activity from the company compliance process. Examples of materials are: * A container image built in a CI pipeline, referenced by its OCI URL (oci://my-registry/my-repo\@mytag) * A software bill of materials (SBOM) * A test or code coverage report * A vulnerability scan result * An infrastructure scan, and more Materials can be attached to an attestation during the attestation process. [Read the docs](/concepts/material-types) ### Attestation An attestation is a unit of data sent to Chainloop. Users and CI systems use the Chainloop CLI to “craft” attestations, add pieces of evidence (materials) to them, and “push” them to Chainloop service (the evidence store). Attestations are performed with the Chainloop CLI and its lifecycle looks like this ```bash theme={"dark"} # initialize the attestation. Downloading the contract > chainloop att init --workflow workflow-name --project project-name # add materials to the attestation > chainloop att add --value ghcr.io/chainloop-dev/chainloop/control-plane:latest > chainloop att add --value reports/cyclonedx.json --kind SBOM_CYCLONEDX_JSON # generate, sign and push the attestation to chainloop > chainloop att push ``` [Read the docs](/concepts/attestations) ### Workflow A workflow represents a source of data to be sent to Chainloop. It usually corresponds to a CI pipeline, but it doesn't necessarily need to match. For example, users might send data from other sources, like a custom integration from Jira. Workflows are just an umbrella term for all data ingestions from the same source. [Read the docs](/concepts/workflows) ### Workflow Run A workflow run represents an execution of a workflow. A successful workflow run will be associated with an attestation. [Read the docs](/concepts/workflows) ### Contract A contract is the interface between development pipelines and the Chainloop service. It defines the materials that are expected to be sent to Chainloop and some additional constraints, like the type of source (Github, Dagger …, etc.) and the policies that must be evaluated. A contract can also be seen as the interface between the developers who must instrument their CI/CD pipelines and the other teams. [Read the docs](/concepts/contracts) ## Compliance Primitives ### Policy Policies are rules evaluated against materials and/or the whole attestation document. They represent acceptance criteria for the system to ingest those materials. Even in failure cases (when there are policy violations), attestations are still sent to Chainloop but clearly marked as “not compliant.” This way, Chainloop keeps track of everything that is happening in the system, even if it's not acceptable. Policies are written in Rego language. [Read the docs](/concepts/policies) ### Policy Groups Policy groups are a way to group policies together. They are used to be able to attach a set of policies to a workflow contract. [Read the docs](/concepts/policy-groups) ### Frameworks Frameworks represent high-level regulatory standards or good practices. They are usually promoted by governments and required for companies to fulfill, such as SDDF, SOC2, CRA, etc. Frameworks can also represent internal, custom checklists and normative for release management, security compliance, etc. In any case, Chainloop will help automate those by giving tools to manage and automate frameworks and requirements in terms of policies and data ingestions. [Read the docs](/concepts/compliance-frameworks) ### Requirements Requirements are a high-level representation of Compliance criteria that the project must meet. They are not necessarily technical but written in high-level natural language by Compliance teams. It's the responsibility of SecOps teams to map high-level requirements into low-level policies. Requirements are grouped in a framework. [Read the docs](/concepts/compliance-frameworks) ### Exceptions Sometimes, it's acceptable for some organizations to release software without fulfilling all internal requirements. In these cases, Chainloop provides a way to register “exceptions” to those requirements, marking them as exempt and thus not counting against compliance criteria. Exceptions and their authors are recorded in the system for future auditing. [Read the docs](/concepts/compliance-frameworks#record-requirement-exceptions) ## Organizational Primitives ### Organization Organizations represent the tenant entity in Chainloop. All users belong to one or more organizations and might have different role levels. You can select or create an organization in the top left corner of the Chainloop Web UI. or using the CLI under `chainloop org` prefix. ```bash theme={"dark"} chainloop org --help ``` ```bash theme={"dark"} Organizations management Usage: chainloop organization [command] Aliases: organization, org Available Commands: api-token API token management create Create an organization describe Describe the current organization leave leave an organization list List the organizations this user has access to member Organization members management set Set the current organization to be used by this CLI update Update an existing organization ``` ### Business Units This feature is only available on Chainloop's platform [paid plans](https://chainloop.dev/pricing). Business Units are top-level organizational entities that help structure your organization by grouping products. They enable you to model your company's organizational hierarchy, whether by department, division, team, or any other logical grouping. [Read the docs](/concepts/business-units) ### Products This feature is only available on Chainloop's platform [paid plans](https://chainloop.dev/pricing). Products can be seen as a collection of projects (components) to enable product management capabilities and become an entry point to manage compliance, alerting, and user access configuration at scale. Products can be organized within Business Units. [Read the docs](/concepts/products) ### Project and Versions Projects and versions can be used to model software products. By associating workflows to projects, you can get an aggregated overview of the compliance status of the software product. [Read the docs](/concepts/projects-versions)