Configurable AI for the Carbon Lead: The Four Layered Levers Explained

Picture a Carbon Lead whose tool keeps treating electricity invoices as location-based when the company signed a market-based PPA in FY24. If the tool has one extraction pipeline with no dial to turn, the only fix is manual correction, every time.

That's the wrong shape for carbon accounting. A construction group runs different fuel policies to a property REIT. A dairy processor treats trade-waste sludge differently to a mining site. The AI needs to know your rules, not the vendor's defaults.

We built Carbonly the other way round. The Carbon Lead is the configuration owner. The AI is the executor. Four layered levers stack from tenant-wide down to per-record, and every layer is auditable end to end.

This post walks through what each layer does, when to use it, and how the four compose into a Configurable AI system that adapts to how your organisation actually operates.

What Configurable AI actually means

Configurable AI is not "the model has a settings page". It's an architecture decision.

The extraction pipeline reads a Boral concrete docket. Before it commits an emission record, it consults four layers in order: tenant-wide org instructions, per-supplier extraction templates, per-material calculation rules, and, for the long tail, sandboxed custom formulas. Each layer is set by the Carbon Lead role or higher. Each change is a typed audit event. Every match on the resulting emission record carries a badge showing which layer produced it.

The Carbon Lead configures the rules. The extraction applies them consistently. That's the frame.

Layer 1: Org Instructions

Org instructions are tenant-wide rules that apply to every extraction, factor selection, and reporting decision across the workspace. Think of them as the policy overlay the AI reads before it looks at any document.

Two examples that come up constantly in Australian carbon accounting:

"For Origin electricity invoices, always use market-based Scope 2 with the current PPA settlement." Without this instruction, the AI has to guess. Location-based is the safer default under AASB S2 paragraph 29(a)(v), but the Carbon Lead knows the organisation has a bundled PPA that changes the answer. Encoding this as an org instruction means every future Origin invoice picks the right method. No reviewer has to remember it.

"For diesel dockets with no explicit fuel grade, default to Diesel B5." The NGER Measurement Determination treats different diesel grades with different emission factors and Scope 3 shares. Fuel dockets are not always consistent about labelling grade. Instead of chasing suppliers, the Carbon Lead sets the default at the tenant level and the extraction applies it consistently.

Org instructions surface through the AI Context Generator, which composes them into the prompt used by the extraction pipeline.

Every instruction has a scope (which projects it applies to), an activation state, and an audit trail. If your assurance provider asks "why does this invoice use market-based Scope 2?", the answer is a link to the tenant rule, the person who wrote it, and the date it activated.

Layer 2: Per-Supplier Extraction Templates

Layer 2 is where the AI stops guessing at layout.

Every supplier has a house style. Concrete delivery dockets put the m3 quantity in different positions from one supplier to the next. Steel invoices lay out product lines differently. Fuel invoices use different tax breakdowns. Electricity bills separate distribution charges in different ways.

A generic AI extractor handles this by re-reading the layout every time. That's slow, and it drifts.

Per-supplier extraction templates fix the layout once. The template records the fields, the units, the position hints, and the default calculation type for that specific supplier. On the sixth invoice from that vendor, the extractor uses the template instead of re-deriving.

The auto-derive trigger is deliberate. Templates only auto-suggest after five sample documents from the same supplier hit an 80% column recurrence threshold. Below that, we don't know if the pattern is real or coincidence. Above it, the extractor drafts a template and asks a Carbon Lead to confirm before it activates.

Strictly org-scoped. We never share extraction patterns across tenants. The templates your workspace learns are yours. There is no cross-tenant learning loop, no shared corpus that leaks configuration between organisations. This is enforced at the schema layer, not the policy layer, and it's a design decision that matters most to consultants who represent multiple clients on the same platform.

Templates move through four states with typed audit events: draft (the AI proposed it), confirmed (a Carbon Lead approved it), active (currently in use), and archived (superseded or retired). Every state change is logged with actor, timestamp, and reason.

Drift detection handles the case where a supplier changes their layout mid-year. If your active template for that supplier stops matching, the extractor flags the drift, falls back to the raw AI extractor, and prompts a review. It doesn't silently mislabel. For a longer read on how the template lifecycle works in practice, see our post on per-supplier extraction templates for Boral, Ampol, and AGL.

Layer 3: Material Calculation Rules

Layer 3 handles the maths after the extraction. Because the maths is where a lot of Carbon Leads get stuck.

Material calculations support five types: direct, delta_from_previous, ratio, spend_to_activity, and custom_formula. In our design, the first four cover most of the calculations that show up in a mid-market NGER portfolio. The fifth handles the long tail (more on that in Layer 4).

Three worked examples that mirror common Carbon Lead pain points.

The odometer-reading workflow. A fleet manager exports a CSV of vehicle meter readings once a fortnight. The rule is delta_from_previous, grouped by vehicle rego, mapped to a mobile combustion factor. The engine reads the file, subtracts each reading from the prior one for the same vehicle, converts kilometres to litres of fuel using the vehicle's rated consumption, and applies the NGER emission factor. No spreadsheet. No manual delta calculation. The audit trail shows the two source readings behind every km value.

The tank-dip workflow. A remote site keeps a diesel tank and dips it weekly. The rule is delta_from_previous, grouped by tank ID, with a top-up event as a reset trigger. The engine calculates consumption between dips, handles refills as breakpoints, and produces litres consumed per period.

The kWh meter reading workflow. Same pattern, applied to a sub-metered building. The rule reads meter readings from an OneDrive folder, calculates the delta per meter, and applies the state-based NGA 2025 grid factor for the correct location.

The first reading per grouping is where a lot of tools break. If a vehicle has one reading in the file and no prior reading in the system, there's no delta to compute. Rather than silently crashing or producing a zero, the calculation config has explicit fallback strategies: skip (don't record for this row), use_zero (record zero and flag it), use_extracted (assume the reading itself is the activity value), or estimate_from_previous_n (use an average of the last N readings from a similar vehicle).

The Carbon Lead picks the fallback per rule. There's no hidden default that ends up in your NGER submission.

For teams still weighing whether to use quantity-based methods over spend-based defaults, we've written about why quantity data changes the accuracy conversation. Layer 3 is where the quantity data becomes an emission record.

Layer 4: Custom Formulas

Layer 4 exists because carbon accounting has a long tail no standard rule fits.

Chemical batch conversions with weighted blends. A refrigerant service log with three gases mixed at varying percentages. A waste stream where the emissions depend on a moisture content field extracted from a lab certificate. These don't fit direct or delta_from_previous cleanly, and forcing them into ratio produces the wrong answer.

Custom formulas let a Carbon Lead write a mathjs expression that produces an activity value from named input bindings. The expression is evaluated inside a sandbox. No filesystem access, no network, no globals. The evaluator is the mathjs library configured with a strict import allowlist and a timeout.

The schema enforces limits. A formula can reference at most 20 named input bindings. The formula string is capped at 500 characters. Every binding is typed and validated before evaluation. If the formula tries to reference something the schema doesn't declare, it fails at config time, not at run time.

An example that actually shows up in Australian carbon accounting: a chemical batch invoice with three components in different percentages. The custom formula computes the weighted activity value from three quantity fields, three percentage fields, and a shared density constant. The Carbon Lead writes it once. Every future batch invoice from that supplier applies it.

Custom formulas are the escape hatch, not the default. If your emission profile needs more than a handful of them, the pattern is usually solvable with a supplier template plus a ratio rule. Use custom formulas for the maths that genuinely doesn't compose out of the standard toolkit.

How the four layers compose in practice

The Carbon Lead configures once. Here's how a single Boral concrete docket flows through the stack.

The extractor opens the document. The AI Context Generator loads active org instructions and injects them into the extraction prompt. The supplier template matcher recognises the Boral layout from prior samples and applies the fixed field map. The material calculation engine reads the m3 quantity, applies the direct calculation with the correct embodied-carbon factor, and produces an emission record. If a formula is attached to the material, the calculation evaluator runs the sandboxed mathjs expression.

At every step, a typed audit event is written. There are 27+ event kinds in the current schema, covering configuration changes, template state transitions, factor overrides, calculation runs, and reviewer confirmations.

The Carbon Lead does not touch the invoice. The reviewer confirms the AI's output or flags a discrepancy. The next docket from the same supplier follows the confirmed template. That's the kind of consistency an auditor can follow, and we've written more on how the human-in-the-loop cycle actually improves accuracy over time.

What changed in your rules this period, on one screen

Configuration that isn't visible drifts. Configuration that everyone can see stays honest.

The Rules Changelog Widget, shipped in v1.5.58, surfaces the last 30 days of tenant rule changes in one collapsible timeline on the Carbon Lead dashboard. Every org instruction edit, template state transition, material rule change, and custom formula update lands here with actor, timestamp, and diff.

Two use cases. First, monthly configuration review. The Carbon Lead runs through what changed and confirms nothing broke. Second, audit walk-through. When the assurance provider under ASSA 5010 asks "what changed in your extraction rules this reporting period?", the answer is one screen, filterable by user, event kind, or date range. Not a manual reconstruction from email threads.

Which layer produced each number

Every emission record in Carbonly carries a Match Provenance badge showing which layer produced the match. The badge has eight states, added in v1.5.59:

Reviewer-confirmed. Tenant alias. Supplier template. Org instruction. Global NGA 2025. Calculation rule. Custom formula. AI-only.

The order matters. Reviewer-confirmed sits at the top because human judgement supersedes everything else. AI-only sits at the bottom because it means no layer above the raw extractor produced a match. That's the signal to write a rule.

A Carbon Lead reviewing records before submission filters by badge. "Show me everything that's still AI-only" surfaces the records that need a configuration decision. "Show me everything on the AGL template" gives a portfolio-level view of a single supplier. That transparency is central to how we think about graduated trust in the carbon reporting pipeline.

What the ASSA 5010 walk-through looks like with this in place

Reasonable assurance under ASSA 5010 phases in from financial years starting 1 July 2030 under AASB S2. It's stricter than limited assurance in one specific way. The assurance provider does a walk-through of controls, not just a plausibility check on the totals.

Configurable AI is built for that walk-through. Every layer is auditable end to end.

The auditor asks: how do you know this AGL electricity invoice used the right emission factor? The answer is a chain. The tenant Origin/AGL org instruction sits at the top. The AGL v2025 supplier template mapped the kWh field. The material calculation rule referenced the DCCEEW NGA 2025 NSW grid factor. The Match Provenance badge on the record confirms which layer produced the final value. The Rules Changelog shows the instruction hasn't changed during the reporting period.

Every configuration change is a typed audit event. Every emission record is traceable to the layer that produced it. Every factor lookup is versioned. That is the kind of traceability that helps under the NGER Measurement Determination and AASB S2.

Configurable AI vs black-box AI

There's a trade-off the Carbon Lead has to make when picking a platform, and it comes up more directly at reasonable assurance than at limited.

Black-box AI is easier to sell. "Upload your invoices, get your emissions." One button, no configuration. It works fine at limited assurance because the auditor is testing plausibility, not walking through controls.

At reasonable assurance, black-box AI is harder to defend. The auditor asks why. If the only answer is "the model decided", that's not traceable, and it's not repeatable across reporting periods. And when the assurance opinion is signed on the CEO's desk, "the model decided" is not the answer a CFO wants to defend.

Transparent configuration wins that walk-through. It costs more up front because someone has to configure the layers. It pays back at year-two assurance because every rule is documented, every change is logged, and every emission record is traceable to a specific layer. That's the trade we made when we designed the system.

It also happens to be the shape that lets sustainability consultants scale their practice. A consultant configuring Carbonly for a mid-market Group 2 client sets up the org instructions and templates in the first month. The client's staff run the extraction from month two onwards. The consultant comes back for quarterly reviews, and the configuration is still there between visits.

FAQ

Who configures these layers?

The Carbon Lead role or higher. Contributors and Viewers can see the configuration but can't change it. Auditors get read-only access with the Rules Changelog visible for their assurance walk-through. This is enforced through the six-role RBAC schema, not through UI hiding.

Do configuration changes affect historical records?

No. Every emission record is stamped with the configuration state at the time it was created. If you change an org instruction today, records from last quarter keep the factor selection they had. The change flows forward, not backward. If you deliberately want to restate a prior period after a rule change, the platform supports a period lock, submit, and restate workflow with the restatement documented as its own typed audit event.

Can I test a new rule before activating it?

Yes. Draft state exists for exactly this. A new template or calculation rule sits in draft while the Carbon Lead runs it against sample documents. Only Confirmed state pushes the rule into the live extraction pipeline. Auto-activation without human confirmation is not supported by design. Configuration changes to production go through a human.

What happens if a supplier changes their invoice layout mid-year?

The drift detector on the supplier template catches the change. The active template stops matching cleanly. The extractor falls back to the raw AI extractor for those documents and flags the drift to the Carbon Lead dashboard. A new template gets drafted from the new samples once five have accumulated. Nothing gets silently mislabelled during the transition, and the Rules Changelog records the moment the new template replaces the old one.

Are custom formulas safe to use in production?

Yes, within limits. The mathjs sandbox blocks filesystem access, network access, and globals. Input bindings are validated at schema level. Formula length is capped at 500 characters and at most 20 bindings. The evaluator runs with a timeout. For most calculations, custom formulas aren't needed at all because direct, delta_from_previous, ratio, and spend_to_activity cover the cases. Reach for the sandbox when the maths genuinely doesn't compose out of the standard toolkit, not before.

If you're a Carbon Lead sizing up whether to configure four layers per supplier, the honest answer is it takes work up front. That work is what makes the configuration explainable at reasonable assurance, and what keeps extraction from silently drifting. Carbonly is per-project pricing with a $100/month workspace minimum. If you want to see the four layers running against your own supplier PDFs, email hello@carbonly.ai and we'll walk through it.

Configurable AI for the Carbon Lead: Org Instructions, Supplier Templates, Calculation Rules, and Custom Formulas Explained