Is ECA the same as a database trigger?

Many triggers fit an ECA structure, but the pattern also applies outside databases.

Must the event be a database change?

No. A timer, message, user action or other detected occurrence can trigger evaluation.

Can several rules respond to one event?

Yes. Their ordering, conflicts and combined effects must be defined by the rule system or application.

AI Glossary / Data engineering and architecture / Intermediate

Event - condition - action

Definition

Event - condition - action, or ECA, is a structure for reactive rules: when a specified event occurs, test a condition and perform an action if that condition holds. It separates what starts a check, what permits a response and what the response does.

What it means

For example: when an order is submitted, if it requires manual review, create a review task. “Order submitted” is the event. “Requires manual review” is the condition. “Create a review task” is the action.

This separation matters because a condition can be true without the relevant event occurring. An account may be eligible for a reminder, but the rule might check eligibility only when a daily timer event arrives. The event specifies when evaluation is triggered; the condition determines whether the action is appropriate at that point.

ECA appears in active databases, rule systems and event-driven applications. It is a general structure rather than a single programming language, and it does not inherently involve AI. A learned model can supply information used by a condition, but the surrounding rule still needs defined behavior.

How it works

An event detector or dispatcher identifies events matching a rule's event specification. The rule evaluates its condition using event details and relevant state. If the condition succeeds, the system invokes the defined action.

Implementations must decide what state the condition observes: before an update, after it, or at a later processing time. They must also define ordering when several rules match, and what happens if an action fails or the event is delivered again.

Actions can generate further events, causing other rules or the same rule to run. This supports useful chains but can also create cycles. Designers examine triggering relationships and ensure that repeated evaluation terminates or remains appropriately controlled.

The three-part notation does not itself guarantee atomicity. If state changes between checking a condition and executing an action, the initial decision may no longer be valid. The implementation needs the concurrency and retry behavior appropriate to the business requirement.

Three practical examples

On receipt of a newly submitted application, if required information is missing, create one request-for-information task for that submission.
On a scheduled daily event, if an equipment inspection is due and no inspection task is open, create a maintenance reminder.
When an AI-generated document is ready, if its evaluation indicates review is required, route it to a human reviewer instead of marking it accepted.

Think of it this way

Think of a receptionist following the instruction: when a visitor arrives, if an appointment is recorded, notify the host. Arrival prompts the check; the appointment condition governs the notification.

The analogy is limited because software can receive duplicate arrival messages, process several visitors concurrently or fail partway through notification. The instruction alone does not resolve those details.

Worked example

Handling repeated events without repeated tasks

An invented rule says: on DocumentSubmitted, if the document is longer than twenty pages and has no open review task for this submission, create a review task. Three submissions contain twelve, twenty and twenty-seven pages respectively.

Only the twenty-seven-page submission satisfies the length condition. The twenty-page submission does not, because “longer than twenty” means strictly greater than twenty. If each event arrives once, the rule creates one review task.

Now the twenty-seven-page event is delivered again after the first task is stored. A correct state check finds the existing task and creates none. But if two copies run concurrently, both could observe no task before either writes one.

The implementation can enforce uniqueness for the submission's review task or use an equivalent atomic mechanism. Merely placing “no task exists” in the condition is insufficient to prove duplicate prevention. Rule intent differs from execution guarantees.

Illustrative case study

A fictional equipment-rental company automates reminders for outstanding returns. A timer event evaluates whether an item remains overdue and whether a reminder has already been issued for the relevant period. The action creates a notification request.

Testing reveals that a return recorded shortly before the timer is processed can make an old event description misleading. The team defines which current state the condition must check and how the notification service handles a duplicate request. It distinguishes a queued notification from a confirmed delivery.

Another rule updates a reminder counter. The developers check that this update does not trigger an endless cycle of new reminders. The case illustrates the importance of timing, identity and rule interactions.

Common misconceptions and mistakes

If a condition is true, an ECA rule must act immediately. Its event specification determines when the condition is checked.
An event proves the action succeeded. An event triggering a rule is different from a recorded action outcome.
Conditions alone prevent all duplicate effects. Concurrent execution and retries need appropriate implementation controls.
Rules cannot loop because each rule is simple. Actions can trigger further events and cycles.

Business use

ECA is useful for expressing operational policy in a form that business and technical teams can discuss. Ask stakeholders to name the triggering event, the exact eligibility test and the expected action separately. Replace vague eligibility phrases with precise tests.

Record the rule version and relevant context when investigating an automated decision. Test boundary values, duplicate events, delayed events, changed state and interacting rules, not just the expected happy path.

For AI-assisted workflows, distinguish model output from permission to act. A classification or score can inform a condition, but the rule still needs a clear policy, suitable input quality and an action whose outcome can be observed.

Check your understanding

A rule creates a task when a submission exceeds twenty pages. A document has exactly twenty pages. Should the task be created under that condition?

Answer: No. “Exceeds twenty” is false at twenty. If the intended policy includes twenty, the condition must say “at least twenty” or an equivalent precise test.

Related terms

Concurrency control
Reactive rule
event-driven architecture
database trigger
rule engine
idempotency
complex event processing

Learn next

Read database trigger and idempotency. Express one workflow as “on event, if condition, do action,” then specify the behavior for duplicate delivery, changed state and action failure.

Sources

WebRule: An Event-based Framework for Active Collaboration among Web Servers: https://www.ra.ethz.ch/cdstore/www6/Technical/Paper045/Paper45.html. Indexed primary research text on ECA roles; direct page retrieval unavailable.

W3C RIF working-group material, Rulesystem Arrangement Framework: https://www.w3.org/2005/rules/wg/wiki/Rulesystem_Arrangement_Framework.html. Primary discussion of event, condition and action semantics; this working material is not presented as a normative ECA standard. Examples are original illustrations.

Previous: Event calculus Next: Event correlation