> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mangrovesystems.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 6.2: Advanced Techniques

> Configure uncertainty propagation, work with system ledgers, handle methodology versioning, and set up multi-project configurations.

<Panel>
  <Card title="Accounting Academy" className="accounting-academy-card">
    <div className="accounting-academy-content">
      <Steps className="my-0">
        <Step title="MODULE 1: Fundamentals" icon="bookmark" iconType="solid" stepNumber={1} titleSize="p">
          * [1.1: Core Concepts & the Data Lifecycle](/accounting-academy/module-1/1-1-core-concepts-data-lifecycle)
          * [1.2: Translating Methodologies to Mangrove](/accounting-academy/module-1/1-2-translating-methodologies-to-mangrove)
          * [1.3: Events and Datapoints](/accounting-academy/module-1/1-3-events-and-datapoints)
          * [Exercise: Design and Build](/accounting-academy/module-1/1-exercise-design-and-build)
        </Step>

        <Step title="MODULE 2: Calculations" icon="bookmark" iconType="solid" stepNumber={2} titleSize="p">
          * [2.1: Calculation Architecture](/accounting-academy/module-2/2-1-calculation-architecture)
          * [2.2: Expanding Your Data Model](/accounting-academy/module-2/2-2-expanding-your-data-model)
          * [Exercise: Multi-Step Calculations](/accounting-academy/module-2/2-exercise-multi-step-calculations)
        </Step>

        <Step title="MODULE 3: Batch Partitioning & LCA" icon="bookmark" iconType="solid" stepNumber={3} titleSize="p">
          * [3.1: What Is a Batch?](/accounting-academy/module-3/3-1-what-is-a-batch)
          * [3.2: Batch Partitioning Strategies](/accounting-academy/module-3/3-2-batch-partitioning)
          * [3.3: Life Cycle Assessment & Emissions](/accounting-academy/module-3/3-3-lca-and-emissions)
          * [3.4: Allocating Emissions to Batches](/accounting-academy/module-3/3-4-allocating-emissions-to-batches)
          * [Exercise: Batch Partitioning & LCA](/accounting-academy/module-3/3-exercise-batch-partitioning-and-lca)
        </Step>

        <Step title="MODULE 4: Mass Balance with Ledgers" icon="bookmark" iconType="solid" stepNumber={4} titleSize="p">
          * [4.1: Introduction to Mass Balance](/accounting-academy/module-4/4-1-intro-to-mass-balance)
          * [4.2: Designing the Ledger Structure](/accounting-academy/module-4/4-2-designing-the-ledger-structure)
          * [4.3: Multiple Batch Types for Different Stages](/accounting-academy/module-4/4-3-multiple-batch-types)
          * [Exercise: Design & Build Mass Balance](/accounting-academy/module-4/4-exercise-design-and-build-mass-balance)
        </Step>

        <Step title="MODULE 5: Integration Testing" icon="bookmark" iconType="solid" stepNumber={5} titleSize="p">
          * [5.1: The Complete Model Assembly](/accounting-academy/module-5/5-1-the-complete-model-assembly)
          * [5.2: Testing Patterns](/accounting-academy/module-5/5-2-testing-patterns)
          * [5.3: Common Integration Pitfalls](/accounting-academy/module-5/5-3-common-integration-pitfalls)
          * [Exercise: Integration Testing](/accounting-academy/module-5/5-exercise-integration-testing)
        </Step>

        <Step title="MODULE 6: Advanced Patterns & Production" icon="bookmark" iconType="solid" stepNumber={6} titleSize="p">
          * [6.1: Model Design Best Practices](/accounting-academy/module-6/6-1-model-design-best-practices)
          * [6.2: Advanced Techniques](/accounting-academy/module-6/6-2-advanced-techniques)
          * [6.3: Production Readiness](/accounting-academy/module-6/6-3-production-readiness)
          * [Exercise: Production Deployment](/accounting-academy/module-6/6-exercise-production-deployment)
        </Step>
      </Steps>
    </div>
  </Card>
</Panel>

<Check>
  **What you'll learn in this lesson:**

  * Understand uncertainty propagation and how it affects reported values
  * Work with system ledgers for embodied emissions and renewable instruments
  * Handle methodology versioning and updates in existing projects
  * Design multi-project configurations for complex operations
</Check>

This lesson covers techniques you'll encounter in complex production projects — situations where the basic patterns from earlier modules need to be extended or adapted.

## Uncertainty propagation

Carbon accounting methodologies often require reporting **uncertainty ranges** alongside point estimates. Uncertainty propagates through calculations — if your input measurement has ±5% uncertainty, the output will also have uncertainty.

```mermaid theme={null}
flowchart LR
    INPUT["Mass: 10 ± 0.5 t<br/>(±5%)"] --> CALC["× Carbon %:<br/>80 ± 4%<br/>(±5%)"]
    CALC --> OUTPUT["Carbon: 8 ± 0.57 t<br/>(±7.1%)"]

    style INPUT fill:#42a5f5,stroke:#1976d2,stroke-width:2px,color:#000
    style CALC fill:#66bb6a,stroke:#388e3c,stroke-width:2px,color:#000
    style OUTPUT fill:#ef5350,stroke:#c62828,stroke-width:2px,color:#000
```

### How uncertainty compounds

When you multiply values with uncertainty, the relative uncertainties add (approximately):

* Mass: ±5% uncertainty
* Carbon content: ±5% uncertainty
* Result: approximately ±7.1% uncertainty (√(5² + 5²))

<Note>
  Different methodologies have different rules for uncertainty propagation. Some use simple addition of relative uncertainties, others use root-sum-of-squares (RSS), and some specify fixed deductions. Always follow the methodology's approach.
</Note>

### Implementing uncertainty in Mangrove

You can model uncertainty as:

* **Separate calculation branches** — one for the point estimate, one for the upper bound, one for the lower bound
* **Deduction factors** — a methodology-specified discount (e.g., report the 95% lower confidence bound instead of the mean)
* **Keisan expressions** — for complex uncertainty formulas

<Accordion icon="code" title="Example: Uncertainty deduction as a model node">
  If the methodology requires a conservative approach (report at 95% confidence):

  ```
  conservative_output = point_estimate × (1 - uncertainty_deduction)
  ```

  Where `uncertainty_deduction` is a static input defined by the methodology (e.g., 0.05 for 5% deduction).
</Accordion>

## System ledgers

Beyond production ledgers that track physical material, some projects need **system ledgers** for tracking non-physical quantities:

<Tabs>
  <Tab title="Embodied emissions ledger">
    Tracks the amortized carbon cost of facilities and equipment.

    * **Credits:** Annual amortization amount (e.g., 50 tCO2e/year from facility construction)
    * **Debits:** Monthly allocation to production batches
    * **Purpose:** Ensures embodied emissions are spread evenly and don't distort individual batch calculations

    This is configured as a separate ledger in the <a href="/production-accounting/mass-balance-accounting" target="_blank" rel="noopener noreferrer">mass balance</a> section, linked to the production model's embodied emissions node.

    For a complete guide, see [Embodied Emissions](/production-accounting/embodied-emissions).
  </Tab>

  <Tab title="Renewable instruments ledger">
    Tracks renewable energy certificates (RECs) or similar instruments that offset grid emissions.

    * **Credits:** Purchased RECs (in MWh)
    * **Debits:** Applied to production batches (reduces grid emission calculation)
    * **Purpose:** Projects that purchase renewable energy can reduce their reported emissions

    The ledger balance ensures RECs aren't double-counted across batches.

    For a complete guide, see [Instruments](/production-accounting/instruments).
  </Tab>
</Tabs>

<Tip>
  System ledgers follow the same mass balance principle as production ledgers — what goes in must come out or remain in inventory. This prevents double-counting of embodied emissions or renewable instruments.
</Tip>

## Methodology versioning

Methodologies evolve — emission factors get updated, calculation requirements change, new sources must be included. Your project needs to handle these transitions.

### Key challenges

| Challenge                    | Impact                                                             |
| ---------------------------- | ------------------------------------------------------------------ |
| Updated emission factors     | Historic batches used old factors; new batches should use new ones |
| New calculation requirements | New model nodes needed without breaking existing batches           |
| Changed reporting boundaries | More or fewer emission sources included                            |

### Handling version transitions

<Steps>
  <Step title="Create a new model version">
    In the <a href="/production-accounting/models" target="_blank" rel="noopener noreferrer">Model Editor</a>

    , create a new version of the model with the updated calculations. Previous versions remain linked to historic batches — they aren't affected by the change.
  </Step>

  <Step title="Update static inputs">
    Change emission factors and methodology parameters in the resource library. Set effective dates if the platform supports it, so historic and future calculations use the correct values.
  </Step>

  <Step title="Document the change">
    Record what changed, when, and why. This is critical for verification — auditors will want to see that the transition was handled correctly.
  </Step>

  <Step title="Test the transition">
    Generate batches for a period that spans the transition date. Verify that batches before the change use the old methodology and batches after use the new one.
  </Step>
</Steps>

<Warning>
  Never modify a model version that's already linked to generated batches. Always create a new version. Modifying an existing version could retroactively change historic batch outputs and break the audit trail.
</Warning>

## Multi-project configurations

Some operations span multiple projects — for example, a company with three biochar facilities, each configured as a separate Mangrove project.

### When to use multiple projects

* Different facilities with different operational parameters
* Different methodologies or registries
* Separate reporting requirements
* Independent mass balance tracking

### Shared components

Even with separate projects, some components can be shared:

| Component              | Can Be Shared? | How                                      |
| ---------------------- | -------------- | ---------------------------------------- |
| Emission factors       | Yes            | Same static inputs across projects       |
| Event type definitions | No             | Each project has its own event types     |
| Model logic            | Partially      | Similar structure but separate instances |
| Feedstock types        | Yes            | Common feedstock definitions             |
| Reporting templates    | Yes            | Standardized report formats              |

<Note>
  Multi-project configurations are an advanced topic. For most implementations, start with a single project and only split into multiple projects when the operational differences genuinely require it. See the <a href="/production-accounting/accounting-101" target="_blank" rel="noopener noreferrer">Guide to Production Accounting</a>

  for project configuration guidance.
</Note>

```mermaid theme={null}
flowchart TB
    subgraph Shared["Shared Resources"]
        EF["Emission<br/>Factors"]
        FS["Feedstock<br/>Types"]
    end

    subgraph P1["Project 1: Facility A"]
        M1["Models"]
        L1["Ledgers"]
    end

    subgraph P2["Project 2: Facility B"]
        M2["Models"]
        L2["Ledgers"]
    end

    EF --> M1
    EF --> M2
    FS --> P1
    FS --> P2

    L1 --> R["Consolidated<br/>Reporting"]
    L2 --> R

    style EF fill:#42a5f5,stroke:#1976d2,stroke-width:2px,color:#000
    style FS fill:#42a5f5,stroke:#1976d2,stroke-width:2px,color:#000
    style M1 fill:#66bb6a,stroke:#388e3c,stroke-width:2px,color:#000
    style M2 fill:#66bb6a,stroke:#388e3c,stroke-width:2px,color:#000
    style L1 fill:#ab47bc,stroke:#7b1fa2,stroke-width:2px,color:#000
    style L2 fill:#ab47bc,stroke:#7b1fa2,stroke-width:2px,color:#000
    style R fill:#78909c,stroke:#455a64,stroke-width:2px,color:#000
```

***

### Check your understanding

<Accordion icon="circle-question" title="Why should you never modify a model version that's linked to generated batches?">
  Modifying an existing model version would **retroactively change historic batch outputs**, breaking the audit trail. Verifiers expect that generated batches reflect the calculations as they were at the time of generation. Always create a **new model version** for methodology updates — this preserves historic batches while applying new logic to future ones.
</Accordion>

<Accordion icon="circle-question" title="What is a system ledger and when would you use one?">
  A **system ledger** tracks non-physical quantities like embodied emissions or renewable energy certificates. You'd use one when: (1) the emission source isn't tied to a specific production event (like annual facility construction costs amortized monthly), or (2) you need to track instruments like RECs to avoid double-counting when offsetting grid emissions across batches.
</Accordion>

***

Next, prepare your project for production deployment in [Lesson 6.3: Production Readiness](/accounting-academy/module-6/6-3-production-readiness).