Skip to main content
What you’ll learn in this lesson:
  • Decide when to add new event types vs. extend existing ones
  • Connect multiple event types in a single model
  • Handle unit conversions and standardization
  • Build validation checks that prevent bad data propagation
In Module 1 you worked with a single event type (Biochar Delivery). Real projects capture data from multiple activities — feedstock receipts, lab analyses, energy consumption. This lesson teaches you how to expand your data model to handle these additional inputs.

​
When to create a new event type

Not every piece of data needs its own event type. Use these guidelines to decide:
  • The data comes from a different operational activity (e.g., receiving feedstock vs. delivering biochar)
  • The data has a different cadence (e.g., lab tests happen weekly, deliveries happen daily)
  • The data has a different source (e.g., weighbridge system vs. lab instrument)
  • The data needs separate evidence (e.g., a delivery ticket vs. a lab certificate)
When in doubt, start with a new event type. It’s easier to merge event types later than to split one into two. Separate event types give you cleaner data and more flexible models.

​
New event types for Mangrove Biochar

To build a complete carbon accounting model, Mangrove Biochar needs at least two additional event types beyond Biochar Delivery:

Feedstock Receipt

Captures raw material entering the system.

Lab Analysis

Captures lab test results for biochar quality.
Configure these in Data Inputs > Input Settings , just as you did for Biochar Delivery in Module 1. Define each datapoint with a clear slug so the model can reference it.

​
Connecting multiple event types in a model

A single model can reference datapoints from any event type in the project. The model’s input nodes specify which datapoint slug to pull from — Mangrove matches them to events within the accounting period.
Event matching: When generating batches, Mangrove pulls datapoints from events whose date range falls within the accounting period. If a model references datapoints from multiple event types, all referenced events must exist for that period — otherwise validation will flag missing data.

​
Unit conversions and standardization

Different event types may record values in different units. Your model must handle conversions explicitly. Common conversions in carbon accounting:
Handle unit conversions as explicit intermediate nodes in your model rather than embedding them in complex Keisan expressions. This makes conversions visible and auditable.
The Model Editor supports the Unitwise library for automatic unit tracking. Define units on each node to help Mangrove validate dimensional consistency.

​
Building validation checks

Bad data in → bad results out. Validation helps catch problems before they propagate through calculations.

​
What to validate

  • Range checks — Is the value within a reasonable range? (e.g., moisture content between 0-100%)
  • Presence checks — Are all required datapoints present for the accounting period?
  • Consistency checks — Do related values make sense together? (e.g., dry mass should be less than wet mass)

​
Where validation happens

1

At data entry

When adding events, Mangrove validates required fields and data types. Configure datapoints as required in the event type to enforce this.
2

In the model

Use Keisan expressions to add runtime validation — for example, flagging negative values or out-of-range inputs. The model’s test Console helps you verify these.
3

At batch generation

When you generate batches, Mangrove validates that all required datapoints are present. Missing data shows as validation messages you must resolve before submitting.
If a model references a datapoint slug that doesn’t exist in any event type, the model will silently produce no output for that node. Always verify that datapoint slugs in the model exactly match those configured in the event type.

​
Check your understanding

Create a new event type when the data comes from a different operational activity, has a different cadence, comes from a different source, or needs separate evidence. Extend an existing event type when the data is captured at the same time and comes from the same operational step.
Static inputs are values that don’t change from batch to batch — emission factors, conversion constants, or methodology-defined parameters. They come from the project’s resource libraryand are referenced by model nodes just like event datapoints. Unlike constants hardcoded in the model, static inputs can be updated without modifying the model itself.
A model can reference datapoints from any event type in the project using the datapoint’s slug. When generating batches, Mangrove pulls values from all events whose date range falls within the accounting period. If a referenced datapoint is missing for the period, validation will flag it before batch submission.
You’re now ready to put this into practice in the Module 2 Exercise: Build a Multi-Step Calculation Pipeline.