This example shows how data from several source systems can flow into the Food & Beverage model over the course of a production process.
It is not a sequence an engineer performs manually. In a real integration, these records are usually submitted automatically by systems such as ERP, MES, historians, QMS, maintenance systems, or file-based interfaces.
Example flow
A dairy site receives raw milk, processes it into a bulk yogurt Batch, packs the Product on a Production line, and later records quality or maintenance information linked to that production history.
1. Synchronize master data
Stable records are typically synchronized before operational data begins to arrive.
For this example, the integration may register:
These records are referenced later by their business codes.
2. Register definitions and rules
Before submitting measurements and other operational records, register the definitions and rules required by the integration.
These may include:
For example, Measurements define the codes used later by Readings and Settings, while Reasons provide consistent classifications for operational and quality records.
3. Register incoming material lots
When traceable raw material is received, register the corresponding Lot.
For example, a raw-milk Lot can identify:
- the Material;
- the Supplier;
- the received quantity and unit;
- expiry information;
- lot-specific analysis values.
Supplier
↓
Incoming Lot
↓
Material available for production
This establishes the first traceability link in the production flow.
4. Record the process batch
When bulk processing starts, create a Batch.
The Batch identifies the Vessel and can reference the Recipe used during processing.
For example:
Incoming Lots
↓
Batch
↓
Bulk Lot
The Batch itself produces a bulk Lot with the same business code.
Actual ingredients, utilities, Labor, equipment, and other resources used during processing are submitted through Consumption.
Process measurements such as temperature, pH, pressure, or Brix are submitted as Readings.
Expected resource use can be recorded beforehand through Planned use.
5. Record the production run
When bulk Product is filled or packed, create a Run.
The Run identifies the Production line and Product and can also reference:
- Recipe;
- Shift;
- Crew;
- one or more source Lots.
For example:
Bulk Lot
↓
Run
↓
Packed Product
Execution steps within the Run can be represented through Stage records.
During the Run, the integration can submit:
- Consumption for actual Material, Labor, utility, equipment, and other resource use;
- Output for good production, waste, downgrade, and reject quantities;
- Reading for measured process values;
- Setting for commanded or configured Machine values.
This keeps measured values and equipment setpoints separate:
Measured value → Reading
Commanded value → Setting
6. Record line conditions and events
When a Production line is not operating normally, record the interval through Line time.
For example:
{
"line": "LINE001",
"condition": "breakdown",
"reason": "DTCU010",
"toldBy": "equipment",
"from": "2026-08-11T03:40:00+02:00",
"to": "2026-08-11T04:05:00+02:00"
}
Only non-running or constrained conditions are submitted. Productive running time can be derived from the gaps between recorded intervals.
Discrete occurrences such as stoppages, waste incidents, deviations, or changeovers can be recorded separately as Events.
The two resources are complementary: Event makes an occurrence countable and attributable, while Line time accounts for its duration.
7. Record cleaning
Cleaning between Products is represented through Clean.
A Clean identifies:
- the Production line;
- the Clean regime;
- the Product before cleaning;
- the Product after cleaning;
- the actual cleaning interval.
The Product transition can be compared with the applicable Cleaning rule.
Expected resources can be submitted through Planned use, while actual chemicals, water, energy, Labor, or other resources are submitted through Consumption.
8. Record maintenance
Maintenance work is represented through a Work order.
A Work order identifies the maintained Machine or component, whether the work was corrective or preventive, and its planned and actual timing.
Resources associated with maintenance are submitted through Parts and Labor.
For example:
Work order
├── planned Labor
├── actual Labor
├── spare parts
└── other maintenance costs
When lineState is supplied on the Work order, Pulse automatically creates the corresponding Line time interval for the owning Production line.
Do not submit the same Line time interval separately.
9. Record quality holds
If Product is temporarily withheld while a quality decision is made, create a Hold.
The Hold identifies:
- the affected Lot;
- the Product when applicable;
- the Reason;
- the affected quantity;
- when the Hold started;
- when it ended;
- the resulting decision.
Supported decisions are:
released
downgraded
scrapped
A Hold remains open while end is null.
10. Record customer complaints
A customer-side issue that becomes known later can be recorded as a Complaint.
A Complaint references:
- Customer;
- affected finished Lot;
- Product;
- reported Reason;
- when the Customer noticed the issue;
- when the Complaint reached the producer.
The finished Lot provides the production traceability.
Pulse can connect it back to the Run that produced it and the Production line on which that Run took place.
The Complaint can later be enriched with the investigation outcome, settlement, cost, and cause found.
Resulting traceability
Across these resources, Pulse can preserve a production chain such as:
Operational context remains connected to the relevant part of that flow:
Together, the master data, definitions, production activities, operational records, and maintenance and quality records provide the context needed to reconstruct what happened during production and why.
Next steps
Use the individual resource pages for field-level requirements, validation rules, and API examples.
For supported resources and operations, see the API reference.