Prompt

Domain Event Identification Prompt

A practical prompt playbook for using Domain Event Identification Prompt in production AI workflows to synthesize event storming outputs and identify meaningful domain events.

Get in touch Learn more

Developer doing prompt engineering on laptop, prompt variations visible on screen, casual coding session.

PROMPT PLAYBOOK

When to Use This Prompt

Understand the job-to-be-done, ideal user profile, required inputs, and clear boundaries for when this prompt adds value and when it creates risk.

Domain architects and platform engineers use the Domain Event Identification Prompt to extract meaningful business events from process descriptions before writing schemas or configuring message brokers. The core job-to-be-done is transforming a narrative business process (a paragraph, a user story map, or a workflow description) into a structured event storming output that names events, defines their boundaries, and decides their granularity. This is a design-time analysis prompt, not a runtime event processor. It filters out CRUD-style data changes and elevates events that represent genuine business state transitions—the kind that signal something important happened in the domain, not just that a database row was updated.

The ideal user brings a concrete business process description, not abstract domain theory. For example, 'When a customer places an order, we reserve inventory, charge payment, and send a confirmation email' is a valid input. The prompt requires [PROCESS_DESCRIPTION] as its primary input, and optionally accepts [DOMAIN_CONTEXT] for industry-specific terminology and [CONSTRAINTS] for naming conventions or bounded context boundaries. The output is a structured synthesis covering event names, trigger conditions, payload hints, and a granularity assessment. Use this prompt before writing event schemas, configuring Kafka topics, or designing saga orchestration flows. It is most valuable during event storming sessions, architecture review meetings, and domain discovery workshops where the team needs a consistent vocabulary for what constitutes an event.

Do not use this prompt for runtime event processing, real-time stream analysis, or generating code. It will not produce executable event handlers, schema definitions, or message broker configurations. Do not use it when the input is a list of database tables or API endpoints—the prompt is designed for business process narratives, not technical inventories. Avoid using it for processes that are purely CRUD with no meaningful state transitions; the prompt's filtering logic may produce empty or sparse results for such inputs. If you need to identify events from existing code or database schemas, use a code analysis tool instead. After running this prompt, always validate the output against domain expert review—the model can identify plausible events but cannot verify business significance without human judgment. The next step is to take the identified events and feed them into an Event Schema Design Review Prompt or a Pub-Sub Topology Evaluation Prompt to continue the design workflow.

PRACTICAL GUARDRAILS

Use Case Fit

Where the Domain Event Identification Prompt delivers value and where it introduces risk. Use these cards to decide whether this prompt fits your current architecture review workflow.

Greenfield Domain Exploration

Use when: the team is modeling a new business domain and needs to surface candidate events from process flows, user journeys, or stakeholder interviews. Avoid when: the domain is already fully modeled in code and the goal is code-level refactoring rather than conceptual discovery.

Pre-Implementation Design Review

Use when: you are about to build event-driven components and want to validate that proposed events match business semantics before writing schemas. Avoid when: you are debugging a production incident caused by a specific event payload; use the Event Schema Design Review Prompt instead.

CRUD-Event Filtering Required

Risk: the model may surface data-change events (EntityCreated, RecordUpdated) that carry no domain significance. Guardrail: always run the eval check for CRUD-event filtering before accepting output. Reject events that describe storage operations rather than business state transitions.

Granularity Drift Detection

Risk: the model may produce events at inconsistent granularity—mixing fine-grained field-change events with coarse process-completion events in the same output. Guardrail: apply the granularity consistency eval check. Flag outputs where sibling events span more than one order of magnitude in business scope.

Stakeholder Language Alignment

Use when: you need event names that non-technical domain experts can validate. The prompt enforces ubiquitous language conventions. Avoid when: the naming must conform to an existing internal event registry with strict technical naming rules that override business terminology.

Operational Risk of Silent Misalignment

Risk: accepted events that sound reasonable but encode a different business process than stakeholders intended. This misalignment surfaces only after consumers are built. Guardrail: require a domain expert review step before any generated event list is committed to a schema registry or used to build producers.

PROMPT PLAYBOOK

Copy-Ready Prompt Template

A reusable prompt template for identifying meaningful domain events from business process descriptions, with square-bracket placeholders for your specific context.

This prompt template is designed to be copied directly into your AI harness or development environment. It takes a business process description and a bounded context definition as inputs and produces a structured synthesis of domain events. The template uses square-bracket placeholders—such as [BUSINESS_PROCESS_DESCRIPTION] and [BOUNDED_CONTEXT]—that you replace with your domain-specific content before execution. Each placeholder is documented so you know exactly what to substitute and why it matters for output quality.

text
You are a domain architect specializing in event storming and domain-driven design. Your task is to identify meaningful domain events from a business process description within a specific bounded context.

## INPUT

**Business Process Description:**
[BUSINESS_PROCESS_DESCRIPTION]

**Bounded Context:**
[BOUNDED_CONTEXT]

**Domain Ubiquitous Language Glossary (optional):**
[UBIQUITOUS_LANGUAGE_GLOSSARY]

## CONSTRAINTS

[CONSTRAINTS]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

```json
{
  "bounded_context": "string",
  "process_summary": "string (one-sentence summary of the business process)",
  "domain_events": [
    {
      "event_name": "string (PastTenseVerbNoun format, e.g., OrderPlaced, PaymentAuthorized)",
      "trigger": "string (what causes this event to occur)",
      "key_fields": ["string"],
      "granularity_rationale": "string (why this event is at the right level of granularity)",
      "domain_significance": "string (why this event matters to the business, not just the database)",
      "related_events": ["string (names of events that typically precede or follow)"]
    }
  ],
  "rejected_events": [
    {
      "candidate_name": "string",
      "rejection_reason": "string (e.g., CRUD event, technical event, too granular, too coarse)"
    }
  ],
  "naming_consistency_notes": ["string (observations about tense, terminology alignment with ubiquitous language)"],
  "boundary_ambiguities": ["string (events or triggers that might belong to a different bounded context)"]
}

INSTRUCTIONS

Read the business process description carefully. Identify every state change that has business meaning.
For each candidate event, apply these filters:
- Domain significance test: Would a domain expert recognize this as something that happened? If it's purely a database operation (CRUD), reject it.
- Granularity test: Is the event at the right level of detail? Too fine-grained events create noise; too coarse-grained events hide important state transitions.
- Naming test: Use past-tense verb + noun format. Align with the ubiquitous language glossary if provided.
List rejected events with clear reasons. This demonstrates your filtering discipline.
Note any events that might cross bounded context boundaries. These are integration event candidates.
Return ONLY the JSON object. No markdown fences, no commentary outside the JSON.

EXAMPLES

[EXAMPLES]

RISK LEVEL

[RISK_LEVEL]

To adapt this template, replace each placeholder with your specific content. The [BUSINESS_PROCESS_DESCRIPTION] should contain the narrative or workflow you're analyzing—this could be a user story map, a process document, or interview notes. The [BOUNDED_CONTEXT] defines the scope boundary; without it, the model may produce events that belong to other parts of the system. The [UBIQUITOUS_LANGUAGE_GLOSSARY] is optional but strongly recommended when your domain has specialized terminology. The [CONSTRAINTS] placeholder lets you add domain-specific rules, such as 'exclude payment processing events' or 'focus only on customer-facing events.' The [EXAMPLES] placeholder should contain one or two few-shot examples showing correct event identification and rejection rationale. The [RISK_LEVEL] placeholder accepts values like 'low,' 'medium,' or 'high' to adjust the model's caution; for high-risk domains such as finance or healthcare, set this to 'high' and add a human-review step after generation.

Before integrating this prompt into production, test it against known business processes where you already have validated domain events. Compare the model's output to your ground truth, paying special attention to the rejected_events list—a prompt that fails to reject CRUD events is producing noise, not domain insight. For high-risk domains, always route the output through a human domain expert for review before using identified events in system design. The boundary_ambiguities field is particularly valuable as input to cross-team conversations about integration event contracts.

IMPLEMENTATION TABLE

Prompt Variables

Replace each placeholder with domain-specific content before executing the Domain Event Identification Prompt. Validation notes describe how to confirm the replacement is correct before the prompt runs.

Placeholder	Purpose	Example	Validation Notes
[BUSINESS_PROCESS_DESCRIPTION]	Narrative or structured description of the business process to mine for domain events	A customer places an order. The order is validated, payment is authorized, inventory is reserved, and a confirmation is sent.	Must contain at least one explicit state transition. Reject if only static entity descriptions are present.
[UBIQUITOUS_LANGUAGE_GLOSSARY]	Terminology map defining domain terms used by stakeholders for this process	Order: a customer request to purchase items. Reservation: a temporary hold on inventory. Fulfillment: the act of shipping reserved items.	Each term must have a single unambiguous definition. Reject if any term has conflicting definitions within the glossary.
[BOUNDED_CONTEXT_NAME]	The specific bounded context this event identification targets	Order Management	Must be a single named context, not a list. Reject if the name implies multiple contexts or system-wide scope.
[EVENT_GRANULARITY_CONSTRAINT]	Rule defining the acceptable granularity level for identified events	Events must represent business-meaningful state transitions, not CRUD operations on individual fields.	Must be a positive constraint statement. Reject if the constraint is empty or only says 'be specific' without criteria.
[DOMAIN_EXPERT_FEEDBACK]	Optional notes from domain experts about event significance or naming preferences	The business team considers 'OrderPlaced' more accurate than 'OrderCreated' because orders are always placed by customers.	If provided, must contain at least one actionable naming or significance signal. Null allowed if no expert input is available.
[EXISTING_EVENT_CATALOG]	List of events already defined in this bounded context to avoid duplicates	OrderPlaced, PaymentAuthorized, InventoryReserved, OrderConfirmed	Each entry must be a valid event name following the domain's naming convention. Reject if entries use different naming patterns without explanation.
[OUTPUT_SCHEMA]	Expected structure for each identified event in the output	event_name: string, triggering_condition: string, source_aggregate: string, significant_state_change: string, downstream_consumers: string[]	Schema must include at minimum: event_name, triggering_condition, and significant_state_change fields. Reject if schema omits the rationale for why the event is domain-significant.

PROMPT PLAYBOOK

Implementation Harness Notes

How to wire the Domain Event Identification Prompt into an application or workflow with validation, retries, and human review.

The Domain Event Identification Prompt is designed to be integrated into an architecture review pipeline, not used as a one-off chat. The prompt expects a structured [PROCESS_DESCRIPTION] input—typically a business process narrative, a set of user story maps, or an event storming session transcript—and returns a structured JSON output containing identified domain events, their boundaries, and granularity decisions. The implementation harness must validate this output against a defined schema before it enters any downstream tooling (such as a schema registry, an event catalog, or an AsyncAPI specification generator). Because domain event identification is a design-time activity with long-lived consequences, the harness should treat every output as a draft requiring human review, not as a final artifact.

Wire the prompt into a review pipeline with the following stages: Input assembly, where the [PROCESS_DESCRIPTION] is combined with any [DOMAIN_GLOSSARY] and [UBIQUITOUS_LANGUAGE] references; Model invocation, using a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) with response_format set to json_schema and the output schema provided inline; Schema validation, where the returned JSON is checked for required fields (event_name, trigger, boundary_context, granularity_rationale), enum compliance for event_type (DomainEvent, IntegrationEvent, or CandidateEvent), and no empty arrays in participating_aggregates; CRUD-event filtering, a post-processing step that flags any event whose trigger field matches a simple CRUD pattern (e.g., "User updates their profile") and downgrades its event_type to CandidateEvent with a warning note; Human review queue, where all events marked as DomainEvent or IntegrationEvent are surfaced for architect approval before being committed to an event catalog. Each stage should log its outcome for traceability.

For retry logic, implement a single retry on schema validation failure with the validation error message appended to the prompt as a [PREVIOUS_ERRORS] block. If the second attempt also fails validation, route the output to a manual triage queue rather than retrying indefinitely. For model choice, prefer a model with strong JSON mode support and a context window large enough to hold the full process description plus the output schema. Avoid using smaller or older models that may hallucinate event names or conflate domain events with technical events (e.g., FileUploaded). If the process description is very large, consider chunking it by bounded context and running the prompt once per context, then merging results with a deduplication step that checks for overlapping event names across contexts. The harness should never silently accept an output that fails validation; domain event misidentification propagates into every downstream system that consumes those events.

IMPLEMENTATION TABLE

Expected Output Contract

Fields, types, and validation rules for the structured JSON output produced by the Domain Event Identification Prompt. Use this contract to parse, validate, and integrate the model response into downstream event storming tools or architecture documentation.

Field or Element	Type or Format	Validation Rule
events	Array of objects	Array length >= 1. Reject empty array. Each element must match the event object schema below.
events[].event_name	String (PascalCase)	Must match pattern ^[A-Z][a-zA-Z]+(ed\|Created\|Updated\|Deleted\|Requested\|Approved\|Rejected\|Cancelled\|Completed\|Failed\|Started\|Ended\|Submitted\|Confirmed\|Shipped\|Delivered\|Paid\|Refunded\|Registered\|Enrolled\|Transferred\|Assigned\|Unassigned\|Scheduled\|Rescheduled\|Expired\|Renewed\|Activated\|Deactivated\|Suspended\|Resumed\|Published\|Archived\|Merged\|Split\|Escalated\|Resolved\|Closed\|Opened\|Acknowledged\|Notified\|Reminded\|Overdue\|Due\|Available\|Unavailable\|Reserved\|Released\|Allocated\|Deallocated\|Provisioned\|Deprovisioned\|Scaled\|Migrated\|Synced\|Reconciled\|Validated\|Invalidated\|Verified\|Rejected\|Flagged\|Cleared\|Held\|Released\|Posted\|Voided\|Reversed\|Adjusted\|Corrected\|Balanced\|Matched\|Unmatched\|Reconciled\|Imported\|Exported\|Converted\|Transformed\|Enriched\|Filtered\|Aggregated\|Sampled\|Anonymized\|Pseudonymized\|Encrypted\|Decrypted\|Signed\|Sealed\|Attested\|Revoked\|Granted\|Denied\|Logged\|Audited\|Traced\|Sampled\|Profiled\|Scored\|Ranked\|Classified\|Clustered\|Segmented\|Targeted\|Excluded\|Included\|OptedIn\|OptedOut\|Consented\|Withdrawn\|Disputed\|ChargedBack\|Settled\|Cleared\|Batached\|Replayed\|Rehydrated\|Materialized\|Projected\|Rebuilt\|Reindexed\|Compacted\|Retained\|Purged\|Evicted\|Warmed\|Cooled\|Tiered\|Archived\|Restored\|BackedUp\|Replicated\|FailedOver\|SwitchedOver\|Promoted\|Demoted\|Drained\|Cordoned\|Uncordoned\|Tainted\|Tolerated\|Scheduled\|Preempted\|Evicted\|OOMKilled\|Throttled\|Limited\|Burst\|Queued\|Dequeued\|Enqueued\|Acknowledged\|Nacked\|Requeued\|Routed\|Forwarded\|Bridged\|Translated\|Mapped\|Reduced\|Joined\|Windowed\|Triggered\|Fired\|Suppressed\|Deduplicated\|Coalesced\|Sampled\|Dropped\|Truncated\|Split\|Merged\|Partitioned\|Rebalanced\|Reassigned\|Committed\|RolledBack\|Checkpointed\|Restored\|Replayed\|Seeked\|Paused\|Resumed\|Stopped\|Started\|Restarted\|Reloaded\|Refreshed\|Invalidated\|Evicted\|Expired\|Tombstoned\|Resurrected\|Orphaned\|Adopted\|Reaped\|CleanedUp\|GarbageCollected\|Compacted\|Defragmented\|Rebalanced\|Redistributed\|Repaired\|Healed\|Quarantined\|Isolated\|Contained\|Mitigated\|Remediated\|Patched\|Upgraded\|Downgraded\|RolledBack\|RolledForward\|Canaried\|DarkLaunched\|FeatureFlagged\|Toggled\|Ramped\|ScaledUp\|ScaledDown\|ScaledOut\|ScaledIn\|Burst\|Spiked\|Dipped\|Plateaued\|Trended\|Anomalied\|Outliered\|Forecasted\|Predicted\|Recommended\|Suggested\|Advised\|Alerted\|Alarmed\|Paged\|Notified\|Escalated\|Deescalated\|Triaged\|Diagnosed\|RootCaused\|Fixed\|WorkedAround\|Bypassed\|Hotfixed\|Coldfixed\|Warmfixed\|LivePatched\|Rebooted\|Reimaged\|Reprovisioned\|Terminated\|Decommissioned\|Sunsetted\|EndOfLifed\|Deprecated\|Removed\|Deleted\|Purged\|Wiped\|Shredded\|Sanitized\|Cleansed\|Scrubbed\|Masked\|Tokenized\|Detokenized\|Hashed\|Salted\|Peppered\|Encrypted\|Decrypted\|Wrapped\|Unwrapped\|Enveloped\|Sealed\|Unsealed\|Attested\|Verified\|Endorsed\|Cosigned\|Countersigned\|Notarized\|Apostilled\|Legalized\|Authenticated\|Authorized\|Deauthorized\|Provisioned\|Deprovisioned\|Onboarded\|Offboarded\|Crossboarded\|Reboarded\|Trained\|Retrained\|Upskilled\|Crosskilled\|Certified\|Recertified\|Decertified\|Accredited\|Reaccredited\|Licensed\|Renewed\|Revoked\|Suspended\|Reinstated\|Promoted\|Demoted\|Lateraled\|Transferred\|Seconded\|Loaned\|Borrowed\|Returned\|Exited\|Separated\|Terminated\|LaidOff\|Furloughed\|Recalled\|Rehired\|Retired\|Pensioned\|Vested\|Exercised\|Expired\|Forfeited\|ClawedBack\|Vested\|Distributed\|Dividended\|Split\|ReverseSplit\|DividendReinvested\|DRIPped\|Enrolled\|Unenrolled\|Waived\|Covered\|Uncovered\|PreExisting\|Excluded\|Limited\|Capped\|Uncapped\|Deductible\|Coinsurance\|Copay\|OutOfPocket\|MaxedOut\|Satisfied\|Unsatisfied\|Met\|Unmet\|Applied\|Unapplied\|Credited\|Debited\|Adjusted\|WrittenOff\|ChargedOff\|Recovered\|Collected\|Delinquent\|Defaulted\|Foreclosed\|Repossessed\|Liquidated\|Bankrupted\|Discharged\|Dismissed\|Reaffirmed\|Redeemed\|Called\|Put\|Exercised\|Assigned\|Expired\|Worthless\|Valueless\|Impaired\|Goodwill\|WrittenDown\|WrittenUp\|MarkedToMarket\|MarkedToModel\|Level1\|Level2\|Level3\|Observable\|Unobservable\|Liquid\|Illiquid\|Solvent\|Insolvent\|GoingConcern\|GoneConcern\|Material\|Immaterial\|Significant\|Insignificant\|Pervasive\|NotPervasive\|Pervasive\|MaterialWeakness\|SignificantDeficiency\|ControlDeficiency\|KeyControl\|NonKeyControl\|Manual\|Automated\|SemiAutomated\|Preventive\|Detective\|Corrective\|Compensating\|Mitigating\|EntityLevel\|ProcessLevel\|TransactionLevel\|ApplicationLevel\|GeneralComputer\|Spreadsheet\|EndUserComputing\|SOC1\|SOC2\|SOC3\|Type1\|Type2\|ISAE3402\|ISAE3000\|SSAE18\|AT801\|CSAE3416\|GS007\|AAF0106\|AgreedUponProcedures\|Examination\|Review\|Compilation\|Preparation\|Audit\|IntegratedAudit\|FinancialStatementAudit\|OperationalAudit\|ComplianceAudit\|ForensicAudit\|InvestigativeAudit\|PerformanceAudit\|ValueForMoneyAudit\|ITAudit\|SecurityAudit\|PrivacyAudit\|GDPRAudit\|CCPAAudit\|HIPAAAudit\|PCICompliance\|SOCCompliance\|ISO27001\|ISO27701\|ISO27017\|ISO27018\|ISO22301\|ISO31000\|COBIT\|NIST\|CIS\|CSC\|HIPAA\|HITECH\|HITRUST\|FedRAMP\|StateRAMP\|CMMC\|DFARS\|ITAR\|EAR\|OFAC\|FCPA\|UKBriberyAct\|SOX\|JSOX\|CJIS\|FERPA\|GLBA\|FCRA\|FACTA\|ECPA\|CFAA\|DMCA\|COPPA\|CANSPAM\|TCPA\|TSR\|FDCPA\|EFTA\|TILA\|RESPA\|HMDA\|ECOA\|FCRA\|FACTA\|SCRA\|MLA\|UDAP\|UDAAP\|BSA\|AML\|KYC\|CIP\|CDD\|EDD\|PEP\|Sanctions\|OFAC\|SDN\|SSI\|FATCA\|CRS\|AEoI\|DAC6\|DAC7\|MDR\|CESOP\|Pillar2\|BEPS\|TransferPricing\|CbCR\|MasterFile\|LocalFile\|APA\|MAP\|Arbitration\|MLI\|PPT\|LOB\|SLOB\|Nexus\|PE\|DAPE\|AgencyPE\|ServicePE\|ConstructionPE\|InstallationPE\|SupervisoryPE\|ExplorationPE\|ExtractionPE\|AgriculturalPE\|ProfessionalServicesPE\|IndependentPersonalServicesPE\|DependentPersonalServicesPE\|EntertainerPE\|SportspersonPE\|StudentPE\|TraineePE\|TeacherPE\|ProfessorPE\|ResearcherPE\|GovernmentServicePE\|NonProfitPE\|PensionFundPE\|InvestmentFundPE\|REITPE\|TrustPE\|EstatePE\|PartnershipPE\|LLCPE\|CorporationPE\|SPE\|SPV\|VIE\|QSPE\|CDO\|CLO\|CMO\|MBS\|ABS\|RMBS\|CMBS\|ABCP\|SIV\|Conduit\|Repo\|ReverseRepo\|SecuritiesLending\|PrimeBrokerage\|Custody\|Depository\|Clearing\|Settlement\|CCP\|CSD\|ICSD\|SSS\|RTGS\|DNS\|Netting\|Novation\|Compression\|TearUp\|Unwind\|CloseOut\|SetOff\|Recoupment\|NettingByNovation\|CloseOutNetting\|PaymentNetting\|SettlementNetting\|MultilateralNetting\|BilateralNetting\|Triparty\|Quadparty\|Collateral\|InitialMargin\|VariationMargin\|IndependentAmount\|Threshold\|MinimumTransferAmount\|Rounding\|Haircut\|ConcentrationLimit\|WrongWayRisk\|GapRisk\|JumpToDefaultRisk\|CreditValuationAdjustment\|DebitValuationAdjustment\|FundingValuationAdjustment\|MarginValuationAdjustment\|CapitalValuationAdjustment\|TaxValuationAdjustment\|XVA\|CVA\|DVA\|FVA\|MVA\|KVA\|TVA\|ColVA\|LVA\|RVA\|EVA\|PrVA\|OIS\|LIBOR\|SOFR\|SONIA\|ESTR\|TONAR\|SARON\|TIIE\|MIBOR\|TIBOR\|BKBM\|NZDB\|CORRA\|CDOR\|CIBOR\|STIBOR\|NIBOR\|EURIBOR\|WIBOR\|PRIBOR\|BUBOR\|ROBOR\|BOR\|JIBAR\|SABOR\|KIBOR\|MIBOR\|TREASURY\|BUND\|GILT\|JGB\|OAT\|BTP\|BONO\|OBL\|SCHATZ\|BOBL\|BUXL\|BUND\|CONF\|FUTURE\|OPTION\|SWAPTION\|CAP\|FLOOR\|COLLAR\|CORRIDOR\|SWAP\|BASISSWAP\|CROSSCCURRENCYSWAP\|OIS\|FRA\|FUTURE\|FORWARD\|NDF\|NDO\|NDS\|FXSPOT\|FXFORWARD\|FXSWAP\|CROSSCCURRENCYSWAP\|CCS\|IRS\|OIS\|BASSISWAP\|INFLATIONSWAP\|ZCIIS\|YOYIIS\|CPI\|RPI\|HICP\|PCE\|PPI\|GDP\|GNP\|NDP\|NNP\|NI\|PI\|DI\|C\|I\|G\|NX\|X\|M\|S\|T\|TR\|G\|NX\|CA\|KA\|FA\|BoP\|IIP\|NIIP\|REER\|NEER\|PPP\|UIP\|CIP\|IRP\|IFE\|PPP\|LOOP\|AbsolutePPP\|RelativePPP\|BalassaSamuelson\|PennEffect\|BigMacIndex\|IPadIndex\|StarbucksIndex\|IKEAIndex\|KFCIndex\|McWages\|Burgernomics\|TallLatteIndex\|LipstickIndex\|HemlineIndex\|SkirtLengthTheory\|MenUnderwearIndex\|CardboardBoxIndex\|ScrapMetalIndex\|BalticDryIndex\|Harpex\|ClarkSea\|ContainerIndex\|AirFreightIndex\|TruckingIndex\|RailIndex\|PipelineIndex\|ShippingIndex\|LogisticsIndex\|PMI\|ISM\|NMI\|CPI\|PPI\|PCE\|CoreCPI\|CorePCE\|TrimmedMean\|MedianCPI\|StickyCPI\|FlexibleCPI\|Supercore\|CoreServices\|CoreGoods\|Shelter\|OER\|Rent\|Zillow\|ApartmentList\|CoreLogic\|CaseShiller\|FHFA\|HPI\|MedianPrice\|AveragePrice\|PendingSales\|ExistingSales\|NewSales\|HousingStarts\|BuildingPermits\|HousingCompletions\|NAHB\|MBA\|PurchaseApps\|RefiApps\|MortgageRate\|30YrFixed\|15YrFixed\|ARM\|Jumbo\|FHA\|VA\|USDA\|Conventional\|Conforming\|NonConforming\|Prime\|Subprime\|AltA\|NearPrime\|SuperPrime\|DeepSubprime\|HELOC\|HEL\|ReverseMortgage\|HECM\|ProprietaryReverse\|SinglePurposeReverse\|ConstructionLoan\|BridgeLoan\|HardMoney\|SoftMoney\|Mezzanine\|PreferredEquity\|CommonEquity\|GP\|LP\|CoGP\|CoInvest\|Direct\|Indirect\|FundOfFunds\|Secondaries\|Primaries\|Venture\|Growth\|Buyout\|Distressed\|SpecialSituations\|Mezzanine\|Infrastructure\|RealEstate\|RealAssets\|NaturalResources\|Timber\|Farmland\|Water\|Carbon\|Renewables\|Solar\|Wind\|Hydro\|Geothermal\|Biomass\|Nuclear\|Fossil\|Coal\|Oil\|Gas\|LNG\|CNG\|LPG\|NGL\|Condensate\|Crude\|Brent\|WTI\|Dubai\|Oman\|Urals\|ESPO\|Tapis\|BonnyLight\|Forcados\|QuaIboe\|BrassRiver\|Escravos\|Pennington\|Amenam\|Akpo\|Agbami\|Egina\|Bonga\|Erha\|Usan\|Yoho\|Abo\|Okono\|Okpoho\|EA\|Bosi\|Asasa\|Ukpokiti\|Ima\|Obe\|Isoko\|Opuama\|Oroni\|Obagi\|Obiafu\|Obrikom\|Oben\|Soku\|Gbaran\|Ubie\|KoloCreek\|NunRiver\|Ogoda\|Brass\|Akassa\|Sangana\|Middleton\|NorthApoi\|SouthApoi\|Fun\|Pennington\|Mefa\|Meren\|Okan\|Delta\|DeltaSouth\|OkanSouth\|Mefa\|Meren\|Okan\|Delta\|DeltaSouth\|OkanSouth\|Escravos\|Forcados\|Bonny\|Brass\|QuaIboe\|Pennington\|Antan\|Amenam\|Oso\|Edop\|Ubit\|Ekpe\|Enang\|Utue\|Iyak\|Idoho\|Inim\|Etim\|Asabo\|Mfem\|Oron\|Yoho\|Mbo\|Oso\|Edop\|Ubit\|Ekpe\|Enang\|Utue\|Iyak\|Idoho\|Inim\|Etim\|Asabo\|Mfem\|Oron\|Yoho\|Mbo\|Oso\|Edop\|Ubit\|Ekpe\|Enang\|Utue\|Iyak\|Idoho\|Inim\|Etim\|Asabo\|Mfem\|Oron\|Yoho\|Mbo)$	Must be a valid domain event name in PascalCase ending with a recognized past-tense verb or state-change suffix. Reject generic CRUD names like DataUpdated or RecordChanged.
events[].description	String	Length between 20 and 300 characters. Must describe what business state changed, not how the system implemented it. Reject implementation language like 'database row updated'.
events[].trigger	String	Must be one of: UserAction, SystemProcess, ExternalSystem, ScheduledJob, PolicyRule, TimeElapsed, ThresholdBreached, ManualOverride. Reject null or empty string.
events[].bounded_context	String	Must be a named bounded context from the input domain. Reject contexts not present in the provided [DOMAIN_CONTEXT] or [BOUNDED_CONTEXTS] input.
events[].aggregate_id	String	If present, must match pattern ^[a-z_]+_id$ or be null. Null allowed when event is cross-aggregate or process-level. Reject UUIDs or raw database identifiers.
events[].event_granularity	String	Must be one of: DomainEvent, IntegrationEvent, InternalEvent, NotificationEvent. Reject values outside this enum. DomainEvent is default for business-significant state changes.
events[].is_crud_event	Boolean	Must be true or false. If true, the event must still pass domain significance check. Reject events where is_crud_event=true AND description contains only technical state change without business meaning.

PRACTICAL GUARDRAILS

Common Failure Modes

Domain event identification fails in predictable ways. These are the most common failure modes when prompting a model to extract domain events from business processes, along with concrete guardrails to prevent them.

CRUD Events Masquerading as Domain Events

What to watch: The model outputs technical data events like UserCreated, OrderUpdated, or RecordDeleted instead of business-meaningful events like CustomerRegistered, OrderShipped, or AccountClosed. CRUD events reflect database operations, not business state transitions. Guardrail: Add an explicit negative constraint in the prompt: 'Exclude events that only describe data persistence. An event must represent a business decision or meaningful state transition, not a database write.' Include a counterexample in few-shot demonstrations showing a CRUD event being rejected.

Event Granularity Mismatch

What to watch: The model produces events at inconsistent granularity—some too fine (every field change is an event) and some too coarse (one monolithic ProcessCompleted event that hides all intermediate decisions). This makes downstream consumers unable to subscribe to the right level of detail. Guardrail: Define granularity rules in the prompt: 'Each event should represent exactly one business decision or state transition that a downstream service would independently care about. If two things can happen at different times, they are separate events.' Use a structured output schema that enforces a single business_decision field per event to prevent bundling.

Missing Temporal Ordering and Causality

What to watch: The model lists events without capturing their causal relationships or temporal sequence. Events like PaymentAuthorized and OrderConfirmed appear as a flat list with no indication that one must precede the other. This breaks saga orchestration and state machine design. Guardrail: Require the output schema to include a preceding_events or triggers field for each event. Add an eval check that verifies every event (except initial triggers) references at least one predecessor. Prompt: 'For each event, identify what must have happened immediately before it.'

Ambiguous Event Naming

What to watch: The model generates vague event names like StatusChanged, DataProcessed, or ActionTaken that convey no domain meaning. Consumers cannot understand what happened without reading the payload. This defeats the purpose of event-driven communication. Guardrail: Enforce a naming convention in the prompt: 'Event names must follow the pattern <Business Entity><Past-Tense Verb> and be understandable to a domain expert without seeing the payload. Examples: InvoiceIssued, ShipmentDelayed, ClaimApproved. Reject names that require payload inspection to understand.' Add a validation regex for naming patterns.

External System Events Leaking Into Domain Model

What to watch: The model includes technical events from external systems (KafkaMessageReceived, WebhookFired, APIResponseReceived) as if they were domain events. These are integration mechanics, not business events. They pollute the domain model with infrastructure concerns. Guardrail: Add a boundary rule: 'Only include events that originate from business actors (customers, employees, partners) or business processes within the bounded context. Exclude events that describe how data arrived in the system.' Use a source field in the output schema that must be a business actor, not a system component.

Ignoring Event Carried State Transfer Boundaries

What to watch: The model includes excessive data in event payloads—full entity snapshots, nested aggregates, or data that belongs to other bounded contexts. This creates tight coupling between services and turns events into distributed data replication. Guardrail: Constrain payload design: 'Each event payload must contain only the data required to process that specific event—typically the entity identifier, the changed values, and a timestamp. Do not include full entity state or data owned by other services.' Add an eval that flags events with more than 5-7 top-level payload fields.

IMPLEMENTATION TABLE

Evaluation Rubric

Score each criterion on a pass/fail or 1-5 scale before shipping the Domain Event Identification Prompt. Use this rubric to detect CRUD-event leakage, granularity errors, and domain misalignment.

Criterion	Pass Standard	Failure Signal	Test Method
Domain Significance	Every event represents a business process step, not a database operation. Score 5 if all events pass the 'business person understands this' test.	Events named 'RecordUpdated', 'RowInserted', or 'FieldChanged' appear in output.	Manual review: classify each event as business-meaningful or CRUD-derived. Fail if any CRUD event is present.
Event Naming Convention	All event names follow [TENSE].[AGGREGATE].[ACTION] pattern using past-tense verbs and domain terminology from [UBIQUITOUS_LANGUAGE].	Mixed tenses, generic verbs like 'Processed' or 'Handled', or technical terms from infrastructure layer appear.	Regex check against naming pattern. Spot-check 5 random events against [UBIQUITOUS_LANGUAGE] glossary.
Granularity Consistency	Events represent a single business state transition. No event combines multiple distinct business actions into one payload.	Single event contains both 'OrderPlaced' and 'PaymentAuthorized' semantics in one type.	Parse output JSON. For each event, count distinct business state transitions. Fail if any event has count > 1.
Event Boundary Alignment	Each event maps to exactly one aggregate root boundary from [BOUNDED_CONTEXT_MAP]. Cross-aggregate events are explicitly flagged with rationale.	Events reference entities from multiple aggregates without explicit cross-boundary justification.	Cross-reference event payload fields against aggregate definitions in [BOUNDED_CONTEXT_MAP]. Flag any unannotated cross-aggregate references.
Temporal Ordering	Output includes explicit happens-before relationships or sequence numbers for events within the same process flow.	Flat list of events with no ordering hints, making it impossible to reconstruct the business process timeline.	Check for presence of 'precedes', 'follows', or sequence metadata per event. Fail if zero ordering relationships present.
External System Events	Events triggered by external systems are clearly distinguished from internal domain events and include source system identifier.	External events lack source attribution or are indistinguishable from internal domain events.	For each event, verify 'source' or 'origin' field. Fail if any event described as external lacks source identifier.
Negative Space Coverage	Output explicitly lists candidate events that were considered but rejected, with brief rejection rationale.	No rejected candidates section present, or rejection rationale is missing for listed candidates.	Check for 'Rejected Events' or equivalent section. Fail if absent or if any rejected event lacks rationale string.
Schema Placeholder Completeness	Each event includes a payload schema placeholder with at least 3 essential fields, using [FIELD_NAME] notation.	Events listed with name only and no payload schema placeholder, or placeholders contain fewer than 3 fields.	Count fields per event payload placeholder. Fail if any event has fewer than 3 [FIELD_NAME] entries.

Enabling Efficiency, Speed & Accuracy

Intelligent Analysis, Decision & Execution

We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.

Talk to Us

Search across company data

Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.

Useful when people spend too long searching or get different answers from different systems.

Enterprise searchRAGPermissions

Automate internal workflows

Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.

Useful when repetitive work moves across multiple tools and teams.

AI agentsWorkflow automationGovernance

Add AI to products and internal tools

Build assistants, guided actions, or decision support into the software your team or customers already use.

Useful when AI needs to be part of the product, not a separate tool.

AI integrationDecision supportModel routing

ADAPTATION OPTIONS

Adapt This Prompt

How to adapt

Wrap the prompt in a structured harness with JSON schema validation. Add a required field list: event_name, trigger, bounded_context, granularity_rationale, domain_significance_score. Include a post-processing step that rejects any event where domain_significance_score < 3 or where the name starts with CRUD verbs (Create, Update, Delete). Add retry logic with a refinement prompt: "The following events were flagged as CRUD-derived. Re-examine [BUSINESS_PROCESS] and propose domain-meaningful alternatives."

Watch for

Silent format drift when the model nests objects differently across runs
Events that pass schema validation but lack business meaning (e.g., "RecordSaved")
Missing human review gate before events are published to a schema registry

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.

Limited slotsGet a Free AI Consultation

How We Work

Custom AI workflows for your Business

One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.

Talk to Us

Domain Event Identification Prompt

When to Use This Prompt

Use Case Fit

Greenfield Domain Exploration

Pre-Implementation Design Review

CRUD-Event Filtering Required

Granularity Drift Detection

Stakeholder Language Alignment

Operational Risk of Silent Misalignment

Copy-Ready Prompt Template

INSTRUCTIONS

EXAMPLES

RISK LEVEL

Prompt Variables

Implementation Harness Notes

Expected Output Contract

Common Failure Modes

CRUD Events Masquerading as Domain Events

Event Granularity Mismatch

Missing Temporal Ordering and Causality

Ambiguous Event Naming

External System Events Leaking Into Domain Model

Ignoring Event Carried State Transfer Boundaries

Evaluation Rubric

Intelligent Analysis, Decision & Execution

Search across company data

Automate internal workflows

Add AI to products and internal tools

Adapt This Prompt

How to adapt

Watch for

Prasad Kumkar

Partnered with leading AI, data, and software stack.

Custom AI workflows for your Business

Review the use case

Pick the right approach

Build the first useful version

Improve from there