Event Sourcing Event Stream Generation Prompt Template

This prompt is designed for test engineers and developers who need to validate event-sourced systems, projections, and event handlers. The job-to-be-done is generating a realistic, ordered event stream for a given aggregate that exercises critical production behaviors: event versioning, out-of-order arrival, duplicate event detection, and projection rebuild correctness. The ideal user has a working knowledge of their domain's event types and aggregate lifecycle but needs a fast, repeatable way to produce test fixtures that are more realistic than hand-crafted JSON arrays.

Use this prompt when you are building integration tests for event handlers, verifying that projections rebuild to the correct state, or testing that your system correctly rejects duplicate events with the same event_id. It is also appropriate when you need to validate that event upgrades (e.g., v1 to v2 payload shapes) are handled without breaking downstream consumers. The prompt requires you to supply an aggregate type, a list of valid event types with their JSON schemas, and a set of test scenarios you want to exercise. You should not use this prompt for performance testing with millions of events; it is optimized for correctness and scenario coverage, not volume. For large-scale seeding, use the Large Volume Database Seeding Prompt Template instead.

Do not use this prompt if you lack a defined event catalog or if your event schemas are in flux. The output quality depends on the precision of the input schemas and the clarity of the scenarios you describe. If you are testing a system that does not use event sourcing, or if you only need simple CRUD test data, the Schema-Compliant Record Generation Prompt Template is a better fit. After generating the stream, always run the provided projection verification queries to confirm the aggregate state is correct before committing the fixture to your test suite. For regulated environments, ensure that any synthetic data remains free of production information and that event payloads do not inadvertently encode real user identifiers.

This prompt template generates ordered event streams for testing event-sourced aggregates, projections, and event handlers. It produces sequences with aggregate IDs, event types, timestamps, and payloads that deliberately exercise event versioning, out-of-order arrival, duplicate detection, and schema evolution scenarios. Use it when you need to verify that your projections rebuild correctly, your event handlers are idempotent, and your system handles late-arriving or malformed events gracefully.

textCopy
You are an event sourcing test data generator. Your task is to produce a realistic, ordered event stream for testing event-sourced systems and projections.

## INPUT SPECIFICATION
- Aggregate type: [AGGREGATE_TYPE]
- Event type catalog (name, version, schema): [EVENT_CATALOG]
- Number of aggregates to generate: [AGGREGATE_COUNT]
- Events per aggregate (min, max): [EVENTS_PER_AGGREGATE_RANGE]
- Time window start: [TIME_WINDOW_START]
- Time window end: [TIME_WINDOW_END]

## SCENARIO REQUIREMENTS
Generate events that exercise these conditions:
- [SCENARIO_LIST]
  (Examples: normal ordered sequence, out-of-order event with earlier timestamp, duplicate event with same event ID, event with deprecated schema version, event with missing required field, event with future schema version, concurrent events with same timestamp, aggregate with single event, aggregate with maximum events)

## OUTPUT SCHEMA
Return a JSON array of event objects with this structure:
[
  {
    "event_id": "uuid",
    "aggregate_id": "string",
    "event_type": "string",
    "event_version": integer,
    "timestamp": "ISO 8601 with timezone",
    "payload": {},
    "metadata": {
      "causation_id": "uuid or null",
      "correlation_id": "uuid or null",
      "sequence_number": integer,
      "scenario_label": "string describing which scenario this event exercises"
    }
  }
]

## CONSTRAINTS
- [CONSTRAINTS]
  (Examples: sequence numbers must be monotonically increasing per aggregate, timestamps must fall within the specified window, payloads must conform to the event type schema for the specified version, duplicate events must share the same event_id, out-of-order events must have timestamps earlier than the preceding event but higher sequence numbers)

## EXAMPLES
[EXAMPLES]
  (Provide 2-3 example events showing normal, out-of-order, and duplicate scenarios with correct payload shapes)

## OUTPUT FORMAT
Return ONLY the JSON array. No explanation, no markdown fences, no commentary.

Adapt this template by replacing each square-bracket placeholder with concrete values from your domain. The [SCENARIO_LIST] is the most critical control point: specify exactly which failure modes and edge cases your system must handle. For projection testing, include scenarios that exercise every event type in your catalog at least once. For idempotency testing, ensure duplicate events appear with identical event_ids. Always include at least one out-of-order event and one event with a deprecated schema version to verify your upcasters or schema resolvers. After generation, validate the output against your event schema registry before feeding it into your test harness.

Integrating this prompt into an application requires treating the generated event stream as a structured artifact that must pass schema validation before it touches your event store or projection tests. The prompt produces a JSON array of events, each with an aggregateId, eventType, timestamp, and payload. Your harness should parse this output, validate each event against a JSON Schema or equivalent contract that enforces required fields, ISO 8601 timestamps, and payload shapes matching your domain event types. Do not assume the model will always produce perfectly ordered streams—your harness must be the gatekeeper.

Build a wrapper function that calls the LLM with the prompt template, then runs the raw output through a validator. If validation fails, retry once with the error details injected into the prompt as additional context: 'The previous output failed validation with these errors: [ERRORS]. Please correct the event stream and return valid JSON only.' If the second attempt also fails, log the failure, capture the raw output for debugging, and fall back to a deterministic event generator for the specified aggregate IDs. This prevents a brittle prompt from blocking your test pipeline. For model choice, prefer models with strong JSON mode or structured output support (e.g., GPT-4o with response_format, Claude 3.5 Sonnet with tool use set to a typed output schema). Avoid models known to inject markdown fences or commentary into JSON outputs unless your parser explicitly strips them.

After validation, feed the event stream into your projection rebuild harness. The prompt includes projection verification queries as part of its output—execute these queries against your projection after replaying the generated events. Compare the query results to the expected values embedded in the prompt output. If they mismatch, flag the event stream as potentially inconsistent and investigate whether the model hallucinated event payloads that don't produce the claimed projection state. For high-assurance workflows, add a human review step before committing generated event streams to shared test fixtures, especially when the events will be used to validate production projection logic or compliance reporting. Wire observability around generation success rate, validation failure rate, and projection mismatch rate so you can detect prompt drift or model behavior changes over time.