What is carbon footprint assessment?

Carbon footprint assessment measures Scope 1 (direct), Scope 2 (electricity), and Scope 3 (supply chain) greenhouse gas emissions from your organization, aligned with ISO 14064 standards.

What is CBAM compliance?

CBAM (EU Carbon Border Adjustment Mechanism) is EU Regulation 2023/956 requiring non-EU companies exporting to the EU to report embedded emissions and purchase CBAM certificates. Carbonaa's simulator helps calculate your exposure and compliance roadmap.

How does satellite-powered emissions monitoring work?

SatClimate uses real-time satellite imagery and AI to detect industrial emissions patterns, methane leaks, flaring activity, and fraud indicators across 100+ global datasets. This provides real-time carbon market signals and compliance monitoring.

What is carbonaa plugin?

carbonaa plugin helps stores, miners, and data centers manage carbon offsets with merchant tools, climate verification, pricing, collaboration, and 295 pages.

What is AOI and how do AI agents use it?

AOI (Environmental Intelligence for AI Agents) is an environmental intelligence platform that gives AI agents trusted scientific reasoning about climate and the environment. AI agents query AOI through REST API, MCP (Model Context Protocol), or agent-to-agent communication to access climate risk analysis, carbon market signals, emissions monitoring, and decision support with confidence-calibrated outputs.

How can my AI agent connect to AOI?

AI agents connect to AOI through REST API for direct HTTP calls, MCP (Model Context Protocol) for tool use in LLM applications, or agent-to-agent communication. Authentication uses an evolving trust model — agents obtain an identity and build trust over time through successful interactions.

What environmental intelligence capabilities does AOI provide?

AOI provides climate risk analysis, carbon market signals, environmental monitoring (industrial activity, emissions, land use), and environmental decision support. All outputs include confidence estimates and evidence so AI agents can make informed decisions.

Is AOI safe to use in production AI agents?

AOI is designed with built-in safety and governance. Requests pass through governance checks before execution, internal reasoning remains private, and customer data isolation is enforced. The platform is currently in Developer Preview.

How is AOI priced for AI agent usage?

AOI uses transparent, capability-based pricing — each capability is priced independently so you only pay for what your agents use. No hidden fees. Enterprise agreements are supported. See the pricing page for details.

Trust & Safety

Trust is engineered, not just claimed. Built-in governance, data isolation, and IP protection are designed to make AOI safe for your agents and your data.

Six pillars of trust

Each pillar is designed to make AOI trustworthy by design, not by claim.

Built-in safety & governance

Requests are designed to pass through governance checks before capability execution is authorised. Safety is built in, not bolted on.

Governance checks before execution
Mission alignment designed in
Misuse prevention

Dual-use prevention

Requests are designed to be assessed for potential misuse before being authorised.

Risk assessment
Misuse prevention
Safety by design

Customer data isolation

Customer data isolation is designed to prevent cross-customer data leakage.

Data isolation
No cross-customer leakage
Isolation by design

IP protection

Internal reasoning and source methodology are designed to remain internal. Business outputs are returned to requesting agents.

Internal reasoning protected
Source methodology protected
Business outputs only

Auditability

Requests are designed to create auditable records for compliance and transparency.

Auditable records
Request provenance
Compliance support

Trust evolution

Agents build trust over time through successful interactions. Trust is designed to evolve based on observed behaviour.

Evolving trust
Behaviour-based
Reliable access

How AOI scientific outputs are evaluated

Every AOI capability returns a 20-parameter scientific quality profile alongside its result. These parameters form an evidence framework — not a guarantee that every capability has a calculated value for every parameter. Applicability varies by capability and data source.

B. The 20 scientific quality parameters

Each parameter tells your agent something specific about the evidence behind an output. Absent metrics are reported explicitly — never fabricated.

Measurement integrity

accuracy
Whether the output has been validated against independent ground truth.
Always NOT_CALCULATED. AOI has no validation pipeline and never fabricates accuracy figures.
uncertainty
The quantified uncertainty range of the underlying measurement.
The uncertainty range from the satellite sensor when the source provides it; NOT_AVAILABLE when it does not.
confidence
The reasoning model's self-reported certainty in the output.
A number (0–100) from the model, always marked NOT_VALIDATED. It is a self-report, not an independent measurement.
observed_vs_derived
Whether the output is a direct physical observation or a model-derived inference.
One of the 7 semantic data modes (DIRECTLY_OBSERVED, DERIVED_FROM_SATELLITE, MODELLED_FROM_SATELLITE, HISTORICAL, LLM_KNOWLEDGE, NO_DATA, NOT_APPLICABLE).
completeness
How many of the 20 expected parameters are populated for this output.
A breakdown: parameters available, conditional, not calculated, not validated, not available, and not applicable — plus a coverage percentage.

Data resolution & freshness

spatial_resolution
The ground resolution of the underlying satellite or sensor data.
The sensor's native resolution (e.g., 10m for Sentinel-2, 375m for VIIRS, 1km for ERA5, 7km for Sentinel-5P); NOT_AVAILABLE for LLM-only capabilities.
temporal_resolution
How frequently the underlying data is sampled.
The source cadence (e.g., 5-day for Sentinel-2, daily for ERA5, twice-daily for VIIRS); NOT_AVAILABLE for LLM-only capabilities.
temporal_coverage
The time span of historical data available for this capability.
The archive depth of the source (e.g., Sentinel-2 from 2015, ERA5 from 1940); NOT_AVAILABLE when not applicable.
data_freshness
The age of the underlying observation data at execution time.
The time elapsed since the source observation; NOT_APPLICABLE for LLM-only capabilities that use no physical data.
latency
The time from satellite overpass to result availability.
The processing delay from observation to signal; NOT_AVAILABLE when not measured.
applicable_geographic_domain_scope
The geographic regions where this capability produces valid results.
The geographic validity range (global, regional, or per-facility); NOT_AVAILABLE when not specified.

Source & methodology

source_dataset
The specific satellite dataset or API source used.
The dataset identifier (e.g., Sentinel-2 L2A, Sentinel-5P L2, NASA FIRMS VIIRS, ERA5, OpenAQ, GFW); NOT_AVAILABLE for LLM-only capabilities.
model_methodology
The algorithm or model version used to derive the output.
The algorithm version or method name; NOT_AVAILABLE for LLM-only capabilities.
provenance
The full chain from satellite sensor to output.
A list of provenance sources: provider, dataset, product, sensor, observation time, observation type, and access level; NOT_AVAILABLE for LLM-only capabilities; never fabricated when data is missing.
quality_control_status
The quality control state of the underlying data source.
QC flags from the source (cloud mask, data quality flag, sensor anomaly); NOT_AVAILABLE when the source does not provide QC metadata.
missing_data_behavior
How the system responds when data is missing.
Explicitly reports NO_DATA when a source is attempted but returns no observation. The system never interpolates or invents values to fill gaps.

Validation & limitations

validation_method
The method used to validate results against ground truth.
NOT_VALIDATED for all capabilities. AOI has no real-time validation pipeline. Retrospective validation methodology is documented separately for SatClimate signals.
validation_period
The time period over which validation was performed.
NOT_AVAILABLE for real-time capabilities. SatClimate signals document a retrospective validation sample period (2018–2024) in the methodology document.
validation_population_area
The geographic or population scope of validation.
NOT_AVAILABLE for real-time capabilities. SatClimate methodology documents the geographic scope of retrospective validation events.
limitations
Known limitations of this capability.
An explicit list of satellite, model, processing, and usage constraints. Stated honestly per capability — never hidden.

C. Semantic data modes

Each output is classified by how its data was derived, so agents know whether they are acting on observation or inference.

DIRECTLY_OBSERVED

Output is a direct measurement from a satellite or ground API (e.g., FIRMS fire detection, VIIRS night lights, USGS earthquake).

DERIVED_FROM_SATELLITE

Output is computed from satellite observations (e.g., NDVI from Sentinel-2, flood extent from Sentinel-1).

MODELLED_FROM_SATELLITE

Output is a model inference based on satellite inputs (e.g., risk scores, activity indices).

HISTORICAL

Output is based on historical archive data, not current observation (e.g., historical deforestation baseline).

LLM_KNOWLEDGE

Output is based on LLM reasoning without physical observation (e.g., advisory or assessment capabilities).

NO_DATA

The data source was attempted but returned no observation. The system never fabricates data to fill this gap.

NOT_APPLICABLE

This capability does not require physical data (e.g., confidence assessment, evidence generation).

D. Provenance

When a capability uses real satellite or API data, every output carries a provenance chain that traces the result back to its source. For each data source used, AOI reports:

Provider — the organisation that operates the source (e.g., Copernicus, NASA, ECMWF)
Dataset — the specific data product (e.g., Sentinel-2 L2A, ERA5)
Sensor — the instrument that captured the data (e.g., MSI, TROPOMI)
Observation time — when the source data was captured
Access — whether the source is public or requires credentials

For LLM-only capabilities, provenance is NOT_AVAILABLE because no physical data was used. The system never fabricates provenance.

E. Anti-fabrication rules

AOI explicitly reports when a parameter cannot be calculated or validated. These status labels are not deficiencies — they are honest statements about what AOI does and does not claim.

NOT_CALCULATEDNot calculated

The parameter exists in the schema but AOI does not compute it. For example, accuracy is always NOT_CALCULATED because no validation pipeline exists. This is not a deficiency — it is an honest statement that the value is not available.

NOT_VALIDATEDNot independently validated

A value exists (e.g., the model's self-reported confidence) but it has not been independently validated against ground truth. The value is shown for transparency but is explicitly marked as unvalidated.

NOT_AVAILABLENot available

The parameter is not applicable to this capability or the data source did not provide it. For LLM-only capabilities, provenance and source_dataset are NOT_AVAILABLE because no physical data was used.

NO_DATANo source observation available

The system attempted to retrieve data from the source but the source returned no observation for the requested location or time window. The system does not fabricate data to fill this gap.

NOT_APPLICABLENot applicable

This parameter does not apply to this capability. For example, data_freshness is NOT_APPLICABLE for LLM-only capabilities that use no physical data.

F. Limitations and non-claims

AOI is designed to be transparent about what it does NOT claim:

AOI does not claim validated scientific accuracy for any real-time capability.
AOI does not publish static confidence percentages in the catalog. Confidence is reported per execution and marked NOT_VALIDATED.
AOI does not fabricate data when a source returns no observation. NO_DATA is reported explicitly.
AOI does not fabricate provenance for LLM-only capabilities. Provenance is NOT_AVAILABLE.
AOI does not collapse the 20 parameters into a single score. Each parameter remains individually inspectable.
AOI does not guarantee that every capability has a calculated value for every parameter. Applicability varies by data source.

G. How to interpret an AOI result

When your agent receives an AOI execution result, follow these steps to assess the evidence:

Check the semantic data mode

Look at the semantic_data_mode field. DIRECTLY_OBSERVED means the output is a direct measurement. DERIVED_FROM_SATELLITE means it was computed from satellite data. LLM_KNOWLEDGE means it came from model reasoning without physical observation. This tells you what kind of evidence you are acting on.

Review provenance

If the mode is DIRECTLY_OBSERVED, DERIVED_FROM_SATELLITE, or MODELLED_FROM_SATELLITE, check the provenance field to see which satellite, sensor, dataset, and observation time the output is built on. If provenance is NOT_AVAILABLE, the output is LLM-only.

Check what is NOT calculated or NOT validated

Accuracy is always NOT_CALCULATED. Confidence is always NOT_VALIDATED. Validation fields are NOT_AVAILABLE for real-time capabilities. These are not defects — they are honest statements about what AOI does and does not claim.

Read the limitations

Every capability lists its known limitations explicitly. Read them before relying on the output for decisions. If limitations include missing data or insufficient coverage, treat the result with appropriate caution.

Do not infer unsupported certainty

A confidence value of 80 does not mean 80% accuracy. It means the model self-reports 80% certainty — and this is NOT independently validated. Never treat model confidence as scientific accuracy.

Data backbone — powered by SatClimate

AOI capabilities are powered by SatClimate — the satellite climate data platform. Every output carries the same 20-parameter scientific quality profile, applied to real satellite sources: Sentinel-1, Sentinel-2, Sentinel-3, Sentinel-5P, NASA FIRMS, ERA5, and more.

SatClimate methodology Data sources in docs

Why developers can trust AOI

Most AI platforms ask you to trust their model. AOI is designed to show you its governance model — built-in safety checks, auditable request handling, and IP protection designed to keep your internal reasoning from leaking.

Explore capabilities Check status