ESG & Sustainability Policy

1. Why this matters

The AI industry is trending toward larger models, more compute per call, and more cooling water per unit of output. That trend is well documented, and we do not think it is necessary for the work most organisations actually need AI to do.

Blankstate is built on a different principle. Our measurement layer projects every interaction against a pre-compiled spectral geometry rather than generating a token trace. Because the work of one measurement is bounded by that projection, the compute needed to run the platform is predictable, projectable, and can be federated to the edge when appropriate. The environmental footprint stays proportional to the underlying spectral operation, not to the length or complexity of the surrounding workflow. We treat that architectural discipline as both a moral and a commercial advantage.

This policy sets out the commitments behind that posture across environmental, social, and governance dimensions.

2. The shape of the footprint

Blankstate does not do the same job as a generative AI system, so we do not benchmark ourselves against one. The figures in this section present the environmental footprint of the Blankstate platform on its own terms. Four properties matter, and each has its own figure below.

First, the platform’s current annual footprint is small in absolute terms at its present operational capacity. Second, the compute per measurement does not scale with the size or complexity of the surrounding workflow, because it is bounded by a fixed spectral projection. Third, the architecture is compact enough by construction to be federated toward the user or the customer when that is lawful and appropriate, which removes the cloud leg entirely for those workloads. Fourth, projected growth in usage translates into a linear, not exponential, growth in footprint, which keeps the platform’s environmental profile within a defensible ceiling even at population scale.

2.1 Current annual footprint

The figures below describe the platform’s estimated annual environmental footprint at its current operational capacity, defined as sustained service of approximately one million measurements per day in the production cloud region. The equivalents are provided so the numbers can be sanity-checked against everyday reference points.

2.2 Compute per measurement is bounded by the spectral projection

Many AI systems get more expensive as the surrounding task gets longer, because they read, generate, and reason across a growing token trace. A Blankstate measurement is projected against a pre-compiled spectral surface, so the compute needed to answer it is bounded by the projection, not by the length or complexity of the surrounding workflow. The line below is flat by construction.

2.3 Federate when local

Where measurement can lawfully and effectively run closer to the user, either cached against a pre-compiled spectral surface or executed on the customer’s own infrastructure, the cloud leg drops out and with it the associated grid draw and cooling water. This is only possible because the platform’s compute footprint is compact by construction, which lets the same measurement be served from the cloud, from a cached surface, or from the edge.

2.4 Projected footprint at population scale

The spectral principle in §2.2 means the platform’s total footprint grows in proportion to the number of measurements served, not in proportion to the size or complexity of the surrounding workflow. Growth in usage translates into linear, not exponential, growth in energy, water, and carbon. The chart below projects the annual electricity footprint against two realistic growth scenarios, and translates each into European household equivalents so the ceiling can be seen at a glance.

3. Environmental commitments

3.1 Low-compute architecture

• The Blankstate measurement engine is proprietary, deterministic, and small. A typical measurement runs in a fraction of a second on modest compute, at the levels documented in §2.
• We do not route customer data through third-party generative model providers in the production data path, so we avoid the upstream energy and water cost that would come with that inference.
• New features are reviewed for compute efficiency alongside functional and security requirements. Designs that reduce per-request compute are preferred.

3.2 Low water consumption

• Data-centre cooling water is the largest water cost associated with running AI in the cloud. Because a Blankstate measurement is short and small, the water associated with a single call is a fraction of a millilitre, as documented in §2.
• We select our hosting regions partly on published cooling-water intensity and water-replenishment commitments by the underlying cloud operator, in addition to the legal data-residency requirements our customers contract for.
• We do not run on-premises data-centre cooling.

3.3 Sustainable cloud sourcing

• Our production cloud operator is selected, among other criteria, on the published sustainability commitments of its infrastructure: 100% renewable-energy matching at organisation level, a public 24/7 carbon-free energy target, transparent regional carbon-intensity reporting, and a published water-replenishment commitment.
• We track our cloud operator’s progress against those targets and report it alongside our own metrics.
• We minimise idle compute through right-sized instances, autoscaling, and routine review of unused resources (per BKS-AM-001).
• We prefer regional storage and avoid duplicative cross-region replication where customer data-residency commitments do not require it.

3.4 Federate-when-local principle

We treat each measurement as belonging to the smallest sufficient compute envelope:

• Where measurement can lawfully and effectively run on the user’s own device or the customer’s own infrastructure, it should — eliminating the network leg, the cloud leg, and the marginal cooling-water cost. The deterministic, small-footprint shape of our engine is what makes this possible at all.
• Where measurement must run server-side, it runs at the nearest viable region — keeping inference inside the operational and legal boundary of the customer.
• Federation, not centralisation. Designs that compound population insight without compounding compute are preferred. Coverage scales by adding nodes, not by adding load.

This principle is encoded in product design reviews and is the architectural reason our energy and water curves stay flat as usage grows, as shown in §2.2.

3.5 Hardware and devices

• We minimise the hardware footprint of the team — predominantly remote-working personnel using a small, long-life laptop fleet. We do not operate an office data centre.
• Endpoints are kept in service for their full supported life; end-of-life devices are recycled through certified e-waste channels and storage is securely wiped per BKS-AM-001 §10.

3.6 Travel

• Default to remote / asynchronous work; in-person travel is purposeful (customer engagements, regulated workshops, team off-sites) rather than routine.
• We prefer rail over short-haul flight where journey time and cost permit.
• Material travel is reviewed quarterly.

3.7 Measurement and reporting

• We track and report annually: estimated GHG emissions (Scope 1, 2 market-based and location-based, and material Scope 3 categories including purchased goods and services, business travel, and employee commuting where a remote allowance is provided), production cloud spend as a proxy for compute energy, and counts of issued and decommissioned hardware.
• Per-model energy, water, and CO₂e are self-measured, not asserted from marketing. Our methodology is standards-aligned:
  • Compute power is captured from device telemetry during representative inference runs and integrated over the wall-clock time of each run, at the concurrency levels actually observed in production.
  • Carbon intensity is computed against published hourly grid-mix figures for the production region and applied to measured energy consumption using the CodeCarbon methodology.
  • Water intensity is computed against the on-site Water Usage Effectiveness figures published by our cloud operator for the specific production region, combined with published off-site grid water intensity for the same region.
  • Environmental metadata on the Blankstate model card follows the schema Hugging Face defines for displaying carbon emissions on a model card, the same schema used across the wider open-model community.
  • Our benchmark protocol follows the shape of the AI Energy Score methodology developed by Hugging Face, Salesforce, Cohere, and Carnegie Mellon, and launched at the Paris AI Action Summit in 2025: fixed hardware profile, standardised task batch, and device-level power integration. Where our task set differs from the leaderboard’s, we document the deviation.
• Assumptions, formulas, and reference sources are published in the methodology annex (§10) and refreshed alongside each material release.
• As we grow we will commit to a science-aligned reduction trajectory and publish progress through the Trust Center.

3.8 Climate-aware roadmap

• Product roadmap decisions are reviewed for compute and inference-cost implications; energy- and water-intensive architectures are not adopted by default.
• We will not introduce third-party generative-model dependencies into the production data path without explicit executive approval and a documented environmental impact assessment.

4. Social commitments

4.1 People

• We are an equal-opportunity employer (see §6 below and BKS-HRS-001).
• We pay personnel fairly for the work and the market, including through the use of independent salary benchmarks.
• We support flexible and remote-first working, with explicit recognition of personnel obligations outside work.
• We provide a safe, respectful, and inclusive workplace (BKS-COC-001).

4.2 Modern slavery and supply chain

• We have a zero-tolerance approach to slavery, servitude, forced labour, and human trafficking in our operations and our supply chain.
• We expect our material suppliers and sub-processors to maintain equivalent commitments and we assess this as part of BKS-TPR-001.
• Our voluntary statement is published as BKS-MSS-001 (Modern Slavery Statement).

4.3 Community and customers

• We bring deterministic, auditable measurement to AI — a public good that supports regulators, auditors, civil-society groups, and the people whose lives are increasingly shaped by AI systems.
• We engage with relevant standards (ISO/IEC 42001, ISO/IEC 27001, NIST AI RMF, the EU AI Act, the UK government’s emerging AI assurance ecosystem) and contribute where invited.

5. Governance commitments

5.1 Information security and privacy

• We protect customer and personnel data through the controls in BKS-ISP-001, BKS-DPP-001, and the wider InfoSec corpus.
• Our zero-personal-data-retention architecture in the measurement path is a privacy-by-design choice — explicitly avoiding the accumulation of personal data as a default. The only personal data persisted by the platform is what is structurally necessary to operate it (sign-in identifiers and user-profile records for authenticated platform users).

5.2 Responsible AI

• We measure AI, we don’t generate it. Our principles are in BKS-AI-001 (Responsible AI & AI Governance Policy).
• We do not use customer data to train or fine-tune models without explicit customer consent.

5.3 Ethical business

• We comply with applicable anti-bribery and anti-corruption law (BKS-ABC-001).
• We comply with applicable sanctions and trade-compliance law (BKS-SAN-001).
• Our conduct standards are in BKS-COC-001.
• We maintain a Speak-Up channel for concerns (BKS-WHB-001).

5.4 Tax

• We pay tax in the jurisdictions where economic activity occurs, in compliance with applicable law and the spirit of that law.
• We do not use artificial structures to reduce tax below the level required by the substance of the activity.

5.5 Board and accountability

• ESG matters are owned at co-founder level.
• Material ESG commitments and progress are reviewed annually and published through the Trust Center.

6. Diversity, equity, and inclusion

Blankstate is committed to building a diverse team and an inclusive workplace.

• Recruitment is based on relevant skill, judgement, and potential. We use structured interviews and consistent assessment criteria.
• We do not discriminate on the basis of age, disability, gender reassignment, marriage and civil partnership, pregnancy and maternity, race, religion or belief, sex, sexual orientation, nationality, or any other protected characteristic (UK Equality Act 2010; equivalents abroad).
• We support flexible and remote-first working that broadens the talent pool.
• Harassment, bullying, and discrimination are prohibited and treated as gross misconduct (BKS-COC-001 §5; BKS-HRS-001 §8).
• We measure and report the demographics of our team annually, recognising that small absolute numbers require care in disclosure to protect individual privacy.

7. Targets and roadmap

Initial commitments (subject to refinement as we publish baseline measurement):

• Cloud region: maintain a single primary production region for European customers chosen for low water intensity and required data residency.
• Architecture: maintain the no-third-party-LLM-in-the-data-path posture as a public commitment — change requires executive approval and customer notification.
• Federate-when-local: advance the share of measurements that can lawfully and effectively run on-device or on-customer-premises, removing the cloud leg entirely from those workloads.
• Inference efficiency: improve median per-measurement compute year-over-year (specific target to be published once baseline is set).
• Standards: progress towards ISO/IEC 27001 certification (already aligned), ISO/IEC 42001 AIMS adoption, and (when proportionate) B Corp or equivalent third-party verification of social and environmental performance.
• Self-attested model energy reporting: publish a standards-aligned per-model energy, water, and CO₂e report on the Hugging Face model card and Trust Center for every material SGM release, using CodeCarbon-derived measurements in the Hugging Face co2_eq_emissions schema and the AI Energy Score benchmark shape. We do not gate this on external certification cycles.
• Transparency: annual ESG update published through the Trust Center, together with the raw methodology annex (§10) so numbers are reproducible without asking us.

8. Reporting

The ESG owner reports annually on:

• Environmental baseline and progress.
• Social and DEI baseline and progress.
• Governance commitments, audits, and material exceptions.
• Material risks and forward commitments.

9. Approval and review

This policy is approved by Blankstate’s executive ownership and reviewed annually. The current version is published at the Blankstate Trust Center.

10. Methodology and sources

This annex documents the assumptions and public sources behind the figures in §2. It exists so the numbers can be sanity-checked without asking us. Values are refreshed alongside each material release.

10.1 How the per-call numbers are calculated

For each measurement served in the production cloud region, we combine four inputs:

• Compute power during inference, sampled from device telemetry and integrated over wall-clock time.
• Datacenter overhead, using the Power Usage Effectiveness (PUE) published by our cloud operator for the specific region.
• Grid carbon intensity, taken from published hourly grid-mix data for the same region.
• Water intensity, combining the on-site Water Usage Effectiveness (WUE) figures published by our cloud operator with the off-site grid water intensity for the same region.

Per call:

• energy (Wh) equals the average compute power in watts, multiplied by the call’s wall-clock duration in seconds, divided by the concurrency at which the workload is served, multiplied by the datacenter PUE, divided by 3,600
• CO₂e (grams) equals the per-call energy in kilowatt-hours multiplied by the grid carbon intensity in grams of CO₂e per kilowatt-hour
• water (litres) equals the per-call energy in kilowatt-hours multiplied by the sum of on-site and off-site WUE in litres per kilowatt-hour

The figures in §2 use the conservative case: warm, on-demand, unbatched. Steady-state batched operation is roughly twenty times lower per call.

10.2 Reference points used for equivalents

10.3 What is not claimed

• We do not claim zero environmental cost. The residual is honestly reported in the figures above.
• We do not benchmark ourselves against any specific competitor model, and no figure in §2 refers to a specific vendor’s product.
• We do not claim third-party certification of these numbers. What we do claim is that the numbers are calculated using widely available public data and standard measurement tools that any auditor already knows how to run.

10.4 Standards alignment

• Hugging Face model-card carbon schema. Environmental metadata on the Blankstate model card follows the co2_eq_emissions schema documented in the HF Hub docs, the same schema used by AutoTrain and the wider open-model community.
• CodeCarbon. Open-source emissions tracker from MILA, BCG Gamma, and Comet ML. Used to instrument training and inference and to emit machine-readable reports.
• AI Energy Score. Standardised AI-model energy-efficiency framework from Hugging Face, Salesforce, Cohere, and Carnegie Mellon, launched at the Paris AI Action Summit in February 2025. Our benchmark shape follows the same protocol.
• MLPerf Power. MLCommons standardised inference-energy benchmark. Adopted as a reporting target when deployment scale justifies public submission.
• EU AI Act (Article 40 and GPAI Code of Practice). Reporting expectations for general-purpose AI models. Our per-model compute is well below the threshold that triggers mandatory disclosure. We voluntarily meet the shape of the disclosure regardless.
• ISO 14067 (Carbon Footprint of Products). Used as a checklist for what an audited per-service carbon-footprint declaration would need to contain.