> ## Documentation Index > Fetch the complete documentation index at: https://docs.cula.tech/llms.txt > Use this file to discover all available pages before exploring further. # Concepts > Core resources used throughout the API ## Organisation An **organisation** represents a registered producer within the Cula platform. Organisations own projects registered with carbon registries and receive credit issuances from verified production. Each organisation is linked to production facilities and sites where operations occur. ## Site A **site** represents a unique location where a tracking step of a carbon removal activity happens, or between which deliveries take place. A site can belong to an organisation, if that organisation is registered with Cula. ## Configs and Versions Many resources are **created from a config**: a site-owned definition of one kind of record. A material sourcing config defines a kind of sourcing a site records, a delivery config a kind of delivery, a container config a kind of container, and so on. The config determines which data points are captured on the records created from it. A config's definition lives in **versions**: each config references one active, published version, from which new records are created. A record permanently references the exact version it was created from, so later config changes never affect existing records. ## Material Pool A **material pool** represents bulk storage of loose material at a site — for example a pile of biomass or a tank of bio-oil. Each pool is owned by a site and tracks a current balance per material. Balances change as material is added to or withdrawn from the pool during production and deliveries. ## Material Batch A **material batch** represents a production lot of a material — for example the biochar a site produced during one month, or a bio-oil batch from a liquefaction line. It is created from a [material batch config](#configs-and-versions), which determines the material the batch can describe, whether its validity period tracks whole days or exact times, and which data points are captured on it. The batches of a material form a contiguous timeline of validity periods, so at any instant at most one batch is valid per material. A batch starts as an editable `draft`, is `locked` once its data is complete, and becomes `submitted` — and final — once a sink is submitted from it. Files such as certificates and lab reports can be attached to a batch, and delivery payloads reference the batch their material was drawn from. ## Material Container A **material container** is a tracked unit of material moving through the system — for example a big bag of biochar produced by pyrolysis, or a tank filled from a fermentation run. Each container is based on a [container config](#configs-and-versions) and carries data point values. ## Material Sourcing A **material sourcing** records material entering the system at a site — for example biomass collected for pyrolysis, or corn delivered as fermentation feedstock. It is created from a [material sourcing config](#configs-and-versions), carries data point values, and produces output containers. ## Material Conversion A **material conversion** records material being transformed at a site — for example biomass pyrolyzed to biochar, corn fermented to ethanol, or fermentation output liquefied to bio-oil. It is created from a [material conversion config](#configs-and-versions), carries data point values, and consumes input containers and produces output containers per the config's container configs. ## Delivery A **delivery** records material moving between sites, such as raw material arriving at a production site. It is created from a [delivery config](#configs-and-versions), which carries a direction (`incoming` or `outgoing`, from the perspective of the config-owning site) and determines which data points are captured on the delivery and its payload. A delivery consists of one or more transport legs (each from a sender site to a receiver site), data point values, and a payload — the material containers carried by the delivery. A delivery starts as an editable `draft`, which may still be missing data point values, payload or leg sites, and becomes `finished` once complete; only then does its payload actually change sites. ## Material Utilization A **material utilization** records material reaching its final application or storage — for example biochar applied to soil or mixed into concrete. It is created from a [material utilization config](#configs-and-versions), carries data point values, and consumes input containers. Utilizations are the final tracking step of a material's journey and the basis for [sinks](#sink). ## Sink A **sink** represents a verified unit of carbon removal. Each sink tracks gross CO2e removal (carbon content in applied material) and net CO2e removal (gross minus supply chain emissions). A sink contains a complete history of tracking steps — from sourcing the raw material through processing to final application or storage — that trace material flow through the supply chain. ## Machine A **machine** represents a physical device or system at a site that produces measurements — for example a scale, a pyrolysis unit, or a sensor gateway. Machines are managed within Cula (they cannot be created through the API) and are owned by a site. ## Machine Variable A **machine variable** is a single measured quantity emitted by a machine — for example an outlet temperature or a flow rate. Each variable belongs to a machine and carries a value type that ingested values are validated against, an optional unit, and an optional factor that is applied to raw values during ingestion. ## Webhook A **webhook** represents a subscription to events happening within Cula, such as the creation or verification of a sink. Configured webhook endpoints are automatically notified of new events. See [Receiving Event Updates](/guides/receiving-event-updates) to set one up. ## Event An **event** is a recorded change of state of an API resource. For example, the `sink.verified` event carries a payload with the ID of the sink that has been verified, along with associated metadata.