Domain event for the claims "Services" abstraction (BC-24318). Published on meaningful ClaimService transitions. One class, with the transition folded into the topic (claims.claim_service_<transition>). It is registered in the Workflows catalog (service.workflow_catalogs, "Claim Service Update"), so a workflow can use it as a trigger and create claim tasks or alerts per carrier config -- the producer never creates tasks itself (the pattern PM endorsed on BC-22871). Every transition is the same event class, so a workflow must put a Gateway on the transition field (options come from TRANSITIONS), or it fires on every transition the producer emits. The Gateway can also match status, vendor_stage, reserve_axis and reserved_amount; fields outside the catalog entry (e.g. claim_item_id) are not available to Gateway conditions. Like every HandledEvent, a successful emit also hands the payload to the Workflows engine (HandledEvent._evaluate_workflows). The synchronous internal handler (handle_internal) is a no-op, so no schema registry / celery lookup is needed for it.
Field
Value
Topic
claims.claim_service_lifecycle
Schema ID
BritecoreClaimService.v1
Version
1.0.0
Payload schema
Code
{ "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://docs.britecore.com/schemas/events/claim_service_lifecycle.json", "title": "ClaimServiceLifecycleEvent", "description": "Domain event for the claims \"Services\" abstraction (BC-24318). Published on meaningful ClaimService transitions. One class, with the transition folded into the topic (`claims.claim_service_<transition>`). It is registered in the Workflows catalog (`service.workflow_catalogs`, \"Claim Service Update\"), so a workflow can use it as a trigger and create claim tasks or alerts per carrier config -- the producer never creates tasks itself (the pattern PM endorsed on BC-22871). Every transition is the same event class, so a workflow must put a Gateway on the `transition` field (options come from `TRANSITIONS`), or it fires on every transition the producer emits. The Gateway can also match `status`, `vendor_stage`, `reserve_axis` and `reserved_amount`; fields outside the catalog entry (e.g. `claim_item_id`) are not available to Gateway conditions. Like every HandledEvent, a successful emit also hands the payload to the Workflows engine (`HandledEvent._evaluate_workflows`). The synchronous internal handler (`handle_internal`) is a no-op, so no schema registry / celery lookup is needed for it.", "type": "object", "properties": { "event_id": { "type": "string", "format": "uuid", "description": "Unique identifier for this event instance." }, "event_date": { "type": "string", "format": "date-time", "description": "Timestamp the event was emitted (UTC)." }, "schema_id": { "type": "string", "description": "Schema identifier. Stable per event type.", "const": "BritecoreClaimService.v1" }, "version": { "type": "string", "description": "Schema version.", "const": "1.0.0" }, "topic": { "type": "string", "description": "Topic the event was published on." }, "triggering_user": { "type": "object", "description": "User that triggered the event.", "properties": { "id": { "type": "string" }, "external_system_reference": { "type": "string" } } }, "data": { "type": "object", "properties": {} } }, "required": [ "event_id", "event_date", "schema_id", "version", "topic", "data" ]}
The schema is also published as a standalone JSON Schema artefact you can
fetch and consume programmatically. See schemas/events/claim_service_lifecycle.json
on the published portal.