Transformations

Separate mapping from side effects

A transformation changes data shape or meaning. Keep pure mapping distinct from network calls so you can test it with small, deterministic fixtures. Define missing-field, type, precision, and encoding behavior rather than relying on implicit coercion.

No ZERNOVA transformation language, expression engine, or Runtime API is specified here.

A portable JavaScript example

The following is ordinary JavaScript, not Runtime flow syntax. It illustrates a small mapping with explicit validation. This exact function is exercised by this website’s local test suite.

Conceptual data mapping — ordinary JavaScript

export function summarizeOrder(input) {
  if (typeof input.id !== 'string' || input.id.trim() === '') {
    throw new TypeError('A non-empty order id is required');
  }
  if (!Number.isSafeInteger(input.quantity) || input.quantity < 1) {
    throw new TypeError('Quantity must be a positive safe integer');
  }
  return { orderId: input.id.trim(), units: input.quantity };
}

For example, an input with id equal to " ORD-7 " and quantity equal to 2 produces { orderId: "ORD-7", units: 2 }. Passing the string "2" as the quantity is rejected.

Test the edges

Test empty and whitespace-only identifiers, missing quantities, negative values, fractions, and unsafe integers. Decide separately whether trimming an identifier is appropriate for the actual business contract.

Money and timestamps require their own precision and timezone decisions. This example does not establish those semantics or validate an entire order.

Publish real syntax with a release

Future Runtime transformation documentation must be generated or reviewed against verified implementation and tests. Until then, keep example data separate from any proposed engine configuration.