> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Event-driven architecture: facts and reactions

An event-driven system connects parts of an application through facts that have
occurred. A publisher records a fact; subscribers decide what it means for their
own responsibilities.

## Messages and meaning

| Kind         | Meaning                               | Pharos example                       |
| ------------ | ------------------------------------- | ------------------------------------ |
| Command      | Request for an owner to decide or act | SetPartyAccessState                  |
| Domain event | Private fact in an owner's language   | PartyAuthenticationChanged           |
| Query        | Request for information               | GetProjectIntegrationSnapshot        |
| Reply        | Recorded result of a request          | changed or unchanged command outcome |

A message is a delivery unit. RabbitMQ supplies transport; contracts and ownership
define the business meaning. A consumer's unfinished reaction leaves the original
fact intact.

## Domain facts and integration contracts

A domain event expresses a fact in the owner's model. An integration event is a
published contract with compatibility obligations. Owner adaptors map between
them. Shared infrastructure supplies delivery mechanisms.

Party's private facts carry canonical identity and the authentication generation.
The <a href="/source/services/beto/contexts/party_governance/domain/events.go.txt">domain definitions</a>
exclude issuer, subject, proof references and profile attributes. Read the
[context guide](/reference/services/beto/contexts/party_governance/README.md) for the
published mappings and receiving boundary.

```mermaid
flowchart LR
    Root[Owner transition] --> Intent[Committed outgoing intent]
    Intent --> Relay[Delivery adaptor]
    Relay --> Consumer[Consumer-owned reaction]
    Consumer --> Recovery[Persisted progress and recovery]
```

The precise number of private/public deliveries belongs to the owner's contract.
Select a durable hand-off and its recovery owner explicitly; a generic teaching
diagram cannot establish a particular service's registration or activation.

## Contract design

Published schemas identify the occurrence and the facts a consumer may use.
Edit contract sources and generators, regenerate with `pnpm generate:contracts`,
and check wire identities and stored-byte compatibility separately from drift.

An event ID identifies a fact or message; correlation groups a workflow; causation
identifies a trigger; aggregate identity and revision identify business state.
These identities support different deduplication and ordering requirements.

Event notification, event-carried state transfer and event sourcing have different
purposes. Current-state persistence remains the platform default. Operational
evidence must expose pending work and recovery even when queues are empty.

Next: [Consistency and delivery](/learn/consistency-and-delivery.md).

Adapted from the [architecture reference](/learn/attribution.md), with Pharos examples.

<details class="page-source"><summary>Page source</summary>

<a href="/source/docs/content/learn/event-driven-architecture.md.txt">Source snapshot</a> · Revision `f928834c8`.

</details>