Core Concepts
event7 is subject-centric. Every feature — enrichments, specs, channels, rules, scores — is attached to a subject, not to a schema version. Understanding this model is the key to using event7 effectively.
The subject — event7's central entity
A subject is the unique identifier of a schema in your registry (e.g. com.event7.Order-value). It's the entity that event7 governs. Everything hangs off the subject:
The Schema Registry is the source of truth for schema content. event7 is the source of truth for everything else.
The six entities
Schema
The technical content of a subject at a specific version. Avro record, JSON Schema, or Protobuf (planned). Schemas are versioned, immutable once registered. event7 reads them from the registry — it never modifies them.
Enrichment
Business metadata that the registry doesn't store: description, owner team, tags, data classification (public/internal/confidential/restricted), and data layer (RAW/CORE/REFINED/APPLICATION). Provider-agnostic — enrichments survive registry migrations.
AsyncAPI Spec
An AsyncAPI 3.0 document describing the subject's messaging contract. Can be generated from the schema + enrichments, or imported from an external spec. Tracks origin (imported/generated), status (documented/ready/raw), and sync_status (in_sync/outdated) for drift detection.
Channel
A messaging channel — a Kafka topic, RabbitMQ exchange, Redis stream, etc. Channels have an address, broker type, resource kind, data layer, and broker-specific config (partitions, routing keys). Subjects are bound to channels via bindings with a role (value, key, header) and strategy (channel_bound, domain_bound, app_bound).
Governance Rule
A governance constraint — either a technically verifiable rule (CEL condition, compatibility check, encryption transform) or an organizational policy (naming convention, ownership requirement). Rules have severity (critical/error/warning/info), scope (runtime/control-plane/declarative/audit), and an enforcement lifecycle (declared → expected → synced → verified).
Governance Score
A 0–100 score with grade (A–F) computed from three axes: enrichments (20 pts — description, owner, tags, classification), rules compliance (50 pts — weighted by severity and verifiability), and schema quality (30 pts — compatibility, documentation, references, versioning). A confidence indicator (high/medium/low) reflects how many rules are objectively verifiable.
Where things live
| Entity | Stored in | Why |
|---|---|---|
| Schema versions | Schema Registry | The SR is the source of truth for schema content. event7 reads, never writes (except on import). |
| Enrichments | event7 DB | Registries have limited metadata support. Enrichments are provider-agnostic. |
| AsyncAPI specs | event7 DB | Specs are governance artifacts, not registry data. Tracks drift independently. |
| Channels + bindings | event7 DB | The channel model is multi-broker. No registry stores cross-broker channel mappings. |
| Rules + policies | event7 DB | Rules are provider-agnostic. Can be synced to providers (Pro), but source of truth is event7. |
| Scores | Computed | Calculated on the fly from enrichments + rules + schema metadata. Never persisted. |
This separation is deliberate. Schemas stay in your registry — event7 never creates vendor lock-in on schema storage. Everything else is portable and survives registry migrations.
How the UI maps to concepts
The event7 UI is organized around what you're doing, not around data entities. Here's how the sidebar sections map to the underlying model:
- ·Explorer — browse subjects, view schema content and versions
- ·Diff Viewer — compare two versions of the same subject
- ·References — dependency graph between subjects
- ·Catalog — business view of all subjects (enrichments, scores, AsyncAPI status)
- ·Rules — governance rules and policies (per-subject or global)
- ·Validate — pre-publish check (SR compatibility + rules + diff preview)
- ·AsyncAPI — specs overview, generate, import, drift detection
- ·Channels — messaging channels and subject bindings across brokers
Common questions
Why is the enrichment on the subject, not on a specific schema version?
Because business metadata (who owns it, what it's for) doesn't change with every schema version. When you add a field to Order v4, the owner team is still the same. Enrichments describe the subject as a concept, not a specific version.
What's the difference between the Catalog and the Explorer?
The Explorer shows schema content — fields, types, versions, format. It's for developers looking at the technical structure. The Catalog shows enrichments — owner, tags, classification, data layer, governance score, AsyncAPI status. It's for platform teams doing governance work. Both show the same subjects, from different angles.
Is event7's Catalog the same as EventCatalog?
No. event7's Catalog is a governance workspace inside the app — you enrich subjects, track scores, manage documentation status. EventCatalog is a separate documentation portal. event7 exports to EventCatalog via the generator-event7 plugin.
Why are channels in Documentation, not in Governance?
Channels describe the messaging topology — where schemas flow (Kafka topic, RabbitMQ exchange, etc.). That's documentation of your architecture, not a governance constraint. Governance rules can reference channels, but the channel model itself is about documenting your infrastructure.
Can a subject have both an imported and a generated AsyncAPI spec?
No. One active spec per subject. If you import a spec for a subject that already has a generated spec, the import overwrites it. The origin field tracks where the current spec came from.