Single-event processing

Scope

This page defines user-facing behavior for converting one event into ratings.

What triggers this path

When an event is accepted:

• it is queued for event-to-rating processing
• /events may process it immediately
• /events/batch defers processing to worker/sweep

As a user, treat processing as asynchronous and eventually consistent.

Policy selection semantics

Processing selects policy versions by event business time (occurred_at):

• only active versions are considered
• version effective time must be <= occurred_at
• matching uses exact event_type

Required data dependencies

• Active contract is resolved as-of event occurred_at.
• Required DSL term keys are read from contract terms of kind e2r_param.
• For each key, latest effective term value up to event time is used.

If required terms are missing or invalid, rating is not finalized until those terms are fixed.

Rating emission rules

For a selected policy evaluation:

• each emitted intent becomes one rating write
• emitted ratings are idempotent for the same event/policy intent
• event-to-rating links are written for traceability

Outcome classes you should handle

• processed: rating output produced
• skipped: no applicable rule or event not billable in this path
• failed: temporary or fixable issue (for example missing dependencies)
• quarantined: ambiguous/unsafe condition that needs operator intervention

Verify checklist

• A billable event eventually appears in rating outputs.
• No duplicate ratings are created for event replay.
• Fixing missing contract terms allows previously blocked events to rate.
• Traceability can connect event -> rating links.