Event Register

Findings

Catalogue-native findings must describe the information grouped by each layer. This legacy version does not declare them separately.

Questions & artifacts

Questions, artifact requirements and serial naming rules are required by Vercy vNext; they remain unassigned in this reference version.

Dimension & namespace

• COMPOSE (inbound): domain models across the catalogue, for example `world.registry` (R1), `world.ledgerAndAccount` (R2) and `world.lifeEventsAndCivilStatus` (B12), publish their Events into logs of this model
• REFERENCE `world.identityRegister` (R4): producers, consumers and event actors resolve to anchored identities
• EXTEND (inbound) `world.audit` (S4): the audit trail specializes this model for access and disclosure events
• COMPOSE `world.registryFederationAndMirroring` (R6): mirrors synchronize by replaying source logs under federation rules
• imports: mu-event (ALIGN): the shared semantic shape of an event, its subject references and time semantics
• imports: merkle-logs (ALIGN): hash-chained log structure for tamper evidence
• imports: rfc-6962 (ALIGN): verifiable log proofs, signed tree heads and consistency checking

Canon, patches & standards

• COMPOSE (inbound): domain models across the catalogue, for example `world.registry` (R1), `world.ledgerAndAccount` (R2) and `world.lifeEventsAndCivilStatus` (B12), publish their Events into logs of this model
• REFERENCE `world.identityRegister` (R4): producers, consumers and event actors resolve to anchored identities
• EXTEND (inbound) `world.audit` (S4): the audit trail specializes this model for access and disclosure events
• COMPOSE `world.registryFederationAndMirroring` (R6): mirrors synchronize by replaying source logs under federation rules
• imports: mu-event (ALIGN): the shared semantic shape of an event, its subject references and time semantics
• imports: merkle-logs (ALIGN): hash-chained log structure for tamper evidence
• imports: rfc-6962 (ALIGN): verifiable log proofs, signed tree heads and consistency checking

Artifact formats & serial data

Format-independent core. Concrete artifact formats and naming prefixes are not declared in this legacy version.

Policies & accepted processes

• `appendContract`: which producer may append which event types to a log, under what schema version
• `replayContract`: a consumer's scope for reading or subscribing, by subject, type and time range
• `proofVerificationContract`: public terms for obtaining inclusion and consistency proofs without payload access
• `retentionContract`: the agreed retention period, compaction rules and legal-hold behavior for a log

Read / add / edit / delete

CRUD procedures and interface bindings are not declared in this legacy version.

Ownership, roles & access

Each log is owned by the domain registrar whose history it keeps; the registrar guarantees append-only discipline and proof publication. Read and replay access is granted by that owner through the S1/S2 access and consent models, with all access itself auditable via S4.

Objects

• `eventLog`: one append-only store for a domain's events; key attributes: domainRef, sequenceScheme, retentionRuleRef
• `recordedEvent`: a single immutable event in a log; key attributes: eventType, occurredAt, recordedAt, sequenceNumber, payloadHash
• `eventRef`: a typed link from an event to the world objects it concerns; key attributes: subjectCsn, subjectId, role
• `sequenceMarker`: a sealed checkpoint over a contiguous range of events; key attributes: fromSequence, toSequence, sealedAt
• `integrityProof`: a verifiable proof over sealed ranges; key attributes: proofKind, rootHash, signature
• `consumerCursor`: a reader's position in a log; key attributes: consumerRef, position, subscriptionScope
• `retentionRule`: what survives and for how long; key attributes: period, compactionPolicy, legalHoldFlag

Relationships

• `recordedEvent` -> appendedTo -> `eventLog` (many-to-one): every event lives in exactly one log
• `recordedEvent` -> carries -> `eventRef` (one-to-many): an event names each object it concerns
• `integrityProof` -> seals -> `sequenceMarker` (one-to-one): each checkpoint gets exactly one published proof
• `consumerCursor` -> positionedIn -> `eventLog` (many-to-one): many readers advance independently through one log
• `eventLog` -> governedBy -> `retentionRule` (many-to-one): retention is declared per log, not per event
• `sequenceMarker` -> checkpoints -> `eventLog` (many-to-one): a log accumulates an ordered chain of checkpoints

Events

• `eventAppended`: a new domain event was written at the next sequence position
• `checkpointSealed`: a range of events was closed under a sequence marker
• `proofPublished`: an integrity proof for a sealed range was made available to verifiers
• `retentionApplied`: expired payloads were compacted while hashes and proofs were preserved
• `integrityViolationDetected`: verification found the chain inconsistent with a published proof
• `subscriptionOpened`: a consumer began following a log from a stated position

Projections

• `subjectTimelineView`: all events concerning one subject in order; omits events of other subjects sharing the log
• `inclusionProofView`: proof material for one event; omits the payload entirely
• `logHealthView`: sequence continuity, checkpoint cadence and lag for operators; omits payloads and subjects