ASIC

Because the dimensions did the structuring in advance, four aggregations cover most of what teams compute. Point at an event type, get the number.

Because ASIC separates the object from the conditions, segmentation is derivable from the format rather than authored by hand. The two segment families come straight from the item and context dimensions.

Validate against the JSON Schema: /asic-1.0.schema.json

A mapping is a function. Read the raw payload, decide which fields carry meaning, place them in the four positions. Copy one of these and edit the field names.

type AsicEvent = {
  asic_version: "1.0";
  timestamp: string;
  action: string;
  scope: { grain: string; id: string; parent_grain?: string; parent_id?: string };
  items: { type: string; id: string; category?: string; value?: number; currency?: string; quantity?: number }[];
  context?: Record<string, string | number | boolean>;
};

export function toAsic(payload: OrderCompleted): AsicEvent {
  return {
    asic_version: "1.0",
    timestamp: payload.created_at,
    action: "completed",
    scope: { grain: "user", id: payload.customer.id },
    items: payload.line_items.map((line) => ({
      type: "product",
      id: line.sku,
      category: line.category,
      value: line.price,
      currency: payload.currency,
    })),
    context: {
      device: payload.user_agent.includes("iPhone") ? "mobile" : "desktop",
      locale: payload.locale,
      channel: "web",
    },
  };
}

def to_asic(payload: dict) -> dict:
    return {
        "asic_version": "1.0",
        "timestamp": payload["created_at"],
        "action": "completed",
        "scope": {"grain": "user", "id": payload["customer"]["id"]},
        "items": [
            {
                "type": "product",
                "id": line["sku"],
                "category": line["category"],
                "value": line["price"],
                "currency": payload["currency"],
            }
            for line in payload["line_items"]
        ],
        "context": {
            "device": "mobile" if "iPhone" in payload["user_agent"] else "desktop",
            "locale": payload["locale"],
            "channel": "web",
        },
    }

-- Top item categories by scope over the last 30 days.
select
  scope.id    as scope_id,
  item.category,
  count(*)    as interactions,
  sum(item.value) as total_value
from asic_events
cross join unnest(items) as item
where timestamp >= current_date - interval '30' day
group by scope.id, item.category;

This is just subject, verb, object with extra steps.

Fair, and the ancestry is real. The addition is the split between item and context, and the requirement that scope names its grain explicitly. Those two constraints are what make the format generative rather than merely tidy.

How is this different from a track call?

A track call from an event emitter is an event name plus a flat properties object. The name is free text, and the same properties bag mixes the item, the actor, the device, and every other circumstance together.

{
  "event": "Order Completed",
  "properties": {
    "order_id": "ord_123",
    "line_items": [
      { "sku": "SKU-4417", "category": "dry-food", "price": 42.50 },
      { "sku": "SKU-2201", "category": "treats", "price": 8.00 }
    ],
    "currency": "EUR",
    "customer_id": "cus_8fJ2K",
    "user_agent": "Mozilla/5.0 (iPhone; ...)",
    "locale": "en-GB"
  }
}

ASIC takes the same facts and assigns them to fixed positions. The event name becomes a normalized verb in action. The actor lands in scope with an explicit grain. The products land in items. The device, locale, and channel land in context.

{
  "action": "completed",
  "scope": { "grain": "user", "id": "cus_8fJ2K" },
  "items": [
    { "type": "product", "id": "SKU-4417", "category": "dry-food", "value": 42.50, "currency": "EUR" },
    { "type": "product", "id": "SKU-2201", "category": "treats", "value": 8.00, "currency": "EUR" }
  ],
  "context": { "device": "mobile", "locale": "en-GB", "channel": "web" }
}

The data is identical. The contract is different. A track call says "send any name with any properties." ASIC says "name the action, name the scope grain, and keep the object separate from the circumstances." You can keep emitting track calls and map them into ASIC at the edge; that is a transformation, not a migration.

What about events that do not fit?

Some do not. Pure system telemetry with no actor has no meaningful scope. Financial transactions between two parties have two scopes and the format expresses that awkwardly. ASIC is a format for behavioral events, not a universal event format.

Does something get lost in the mapping?

Yes, by design. Mapping forces a decision about which fields carry meaning. Keep the raw payload, and treat ASIC as the queryable layer over it rather than a replacement.

Do I need Chordis to use this?

No. It is plain JSON, implementable in any stack, in an afternoon.