Published

Event Register

vr.wm-xct-015 · wm-xct-015-event-register

Describe governed domain event histories with explicit admission, order, time, integrity, replay and retention contracts.

World Models Cross-cutting context XCT.EVREG

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

6 bundles · 12 layers · 18 findings · 54 questions

Mandate and representation Identify the register and the event assertions it can represent.

Register boundary

Declare identity and stewardship separately from event identity.

Proposed adoption contract for one logical register, its domain, registrar role, profiles and lifecycle. One domain may use several logs and partitions; exclusivity must be evidenced rather than assumed.

Which domain and event classes fall within this register mandate? definition
Which registrar role has authority for the current register profile? ownership
Which state permits admission, reading, freezing or retirement of this register? lifecycle

Event identity and admission identity

Separate producer event identity from each register admission and storage position. Copying an event to another register does not necessarily create a new occurrence; a payload digest does not safely substitute for identity.

What source-qualified event key identifies the producer assertion across retries? identity
How is each local admission linked to its register, position and original event key? relationship
How are same-key events with different content handled without silent replacement? exception

Representation contract

Pin envelope, payload and reference semantics.

Typed envelope and schema evolution

Separate the envelope version from the event-type and payload-schema versions. Reference domain meaning and subject identities; unknown extensions and unresolved references require explicit handling.

Which envelope, event type and payload schema versions govern this submitted record? classification
Which subject and actor references are carried, with what roles and resolution state? composition
Which incompatible or unknown fields cause rejection, quarantine or a documented lossy mapping? interoperability

Admission and correction Record admission decisions without turning receipts into truth or execution authority.

Admission discipline

Validate producer scope, retries and acknowledgement evidence.

Producer authorization and validation

Proposed admission gate binds a producer grant to a register, event class and policy version. The register consumes an external authorization decision; schema acceptance does not certify the assertion.

What authorization evidence permits this producer to submit this event class now? authority
Which validation checks and payload limits determine admission eligibility? validation
Where does a refused or suspicious submission remain accessible under a bounded quarantine policy? security

Commit evidence and retry outcomes

A receipt distinguishes rejected, pending, committed, duplicate and unknown outcomes under an adopted runtime contract. Lost acknowledgements require reconciliation. Local deduplication never establishes exactly-once downstream effects.

Which durable acknowledgement condition was met before the register reported a committed admission? evidence
What retry key and retention window allow a timed-out producer to reconcile an uncertain result? process
How are producer-state changes reconciled when their event handoff is missing or duplicated? exception

Assertion revision

Keep attributed corrections separate from silent mutation.

Correction and attribution

A correction adds an attributed assertion referencing earlier records. It preserves original admission evidence subject to disposition policy and does not silently turn a disputed report into a fact.

Which earlier record is corrected, superseded or disputed and by whose authority? provenance
How does the domain profile interpret the correction without rewriting original record bytes? state
Which evidence distinguishes reported, observed, derived and contested event claims? quality

Order and temporal evidence State which history and temporal ordering claims are supported.

Sequence and coverage

Preserve scoped positions and explain absent records.

Ordering scope and positions

Declare whether order is per register, partition or stream and preserve epochs across replacement. Append order, temporal order and causal relationships are different assertions. Global order is an optional evidenced profile.

Within which register, partition and epoch is the position order defined? definition
Which explicit event references support causal or correlation claims across streams? relationship
What prevents a repartition or failover from making old positions ambiguous? constraint

Continuity and durable history coverage

Distinguish retained history from filtered, compacted, unavailable or lost ranges. A healthy local sequence does not establish that every real-world event was produced or captured.

What retained range and committed high-water mark bound this history claim? measurement
Which absent positions are explained by filtering, control records, compaction or suspected loss? quality
What recovery evidence supports the durability claim after an interrupted append or replica failure? evidence

Time semantics

Represent asserted and recorded times with uncertainty.

Occurrence, observation and recording times

Keep source occurrence time, observation time and register recording time distinct. Preserve approximate intervals, unknowns and clock evidence; an ingestion timestamp must not masquerade as a measured occurrence.

What occurrence instant, interval or unknown value did the source assert? temporal
When was the event observed and durably recorded, with which clock and offset evidence? provenance
How are late arrivals, conflicting clocks or insufficient precision represented without resequencing history? exception

Integrity evidence Describe protected representations and bounded verification claims.

Commitment representation

Select a reproducible protected representation.

Integrity profile and protected representation

Define exactly which bytes or canonical representation are committed and how envelope, payload and detached references bind together. A digest, a signature and a chain are distinct mechanisms; choose and test a profile before claiming tamper evidence.

Which representation, fields and detached content are covered by the integrity commitment? definition
Which encoding, algorithm identifiers and verification profile make the commitment reproducible? interoperability
How are re-encoding, redaction or algorithm changes prevented from silently preserving an obsolete assurance claim? constraint

Checkpoints and proofs

Keep issuance, release and verification evidence distinct.

Checkpoint and publication evidence

Record the range or tree size covered by a checkpoint and any signature or witness evidence. Checkpoints may have zero or several proofs. Disclosure is policy-bound; public availability is not a default requirement.

Which register epoch, size or range and root commitment define this checkpoint? identity
Which signing or witnessing evidence and trust reference support this checkpoint? authority
Where and to whom was checkpoint evidence released, and with what freshness limits? access

Inclusion, consistency and verification limits

Inclusion is relative to one commitment; consistency compares compatible checkpoints. Neither proves event truth or independent absence of divergent histories. Missing evidence is indeterminate, not verified.

Which leaf and checkpoint does this inclusion assessment bind, using which verifier profile? validation
Which earlier and later checkpoints are compared for consistency under the same log profile? relationship
What suspected fork, stale evidence or missing proof prevents a positive verification conclusion? exception

Consumption and disclosure Read and derive views within current grants and actual retained history.

Replay and projection

Track requested, delivered and interpreted history separately.

Replay selection and consumer checkpoints

A replay request declares its scope and position vector; the receipt declares what was actually delivered. Consumer acknowledgement and external processing success are separate. Expired or incompatible cursors require explicit recovery.

Which authorized scope, position vector and isolation boundary define this replay request? process
Which delivered and acknowledged positions are recorded without assuming downstream effects? state
What response is required for an expired cursor, unavailable history or revoked grant? exception

Projection, export and reconstruction limits

A subject timeline or snapshot is a derived view with source bounds, filters and transformation version. State rebuilding requires domain rules and adequate history; register replay alone does not authorize business actions.

Which source ranges, filters and transform version produced this timeline or export? provenance
What omissions or schema migrations limit reconstruction from the supplied history? quality
Which external domain process owns interpretation and any side effects of replayed records? authority

Read access

Control payload and metadata disclosure.

Payload, metadata and proof disclosure

Read decisions cover payloads, indexes, cursor metadata and proofs separately. A permitted proof can still reveal association or activity. Views must recheck current grants and preserve the distinction between hidden and absent records.

Which current authorization decision permits this recipient to see payloads and context metadata? access
What linkage or inference risk is introduced by indexes, digests, proof paths or counts? privacy
How is a redacted or filtered response described without revealing protected existence details? security

Preservation and continuity Govern the end of retention and the evolution of the register.

Preservation and disposition

Document component schedules, holds and loss of capability.

Retention, preservation holds and replay horizon

Apply an adopted retention schedule separately to payloads, metadata, proofs and consumer checkpoints. Hold decisions are externally authorized. A compacted stream may support a latest-state view while losing event history.

Which retention class and clock start govern each record component? retention
Which preservation hold covers the selected records and who can review or release it? authority
What minimum replay and verification capabilities remain after the proposed compaction? requirement

Controlled disposition and residual evidence

Disposition changes availability under explicit authority rather than rewriting historical claims. Hashes, encrypted payloads and tombstones may retain sensitive associations; none automatically resolves erasure obligations.

What approved disposition action and hold check cover these payloads and replicas? decision
What residual identifiers, digests or proof material can lawfully remain under the adopting policy? privacy
What evidence records completed, partial or failed disposal and its effect on future verification? evidence

Operational continuity

Keep health, recovery and closure evidence.

Health, recovery and register succession

Record lag, capacity, failed admissions and verification outcomes with observation scope. Freezing or migrating a register preserves resolvable lineage and explicit lost capabilities. Infrastructure recovery is delegated to the operator.

Which observed lag, failure and capacity measures trigger a review of the register service? measurement
Which restore or migration evidence proves the available range and identity mapping? validation
What final checkpoint, successor reference and read policy govern a frozen or retired register? lifecycle

Classifiers Filled

Family: World Models
Category: Cross-cutting context
Entry kind: pattern
Navigation path: NAV.XCT.EVREG
Domain: XCT.EVREG
Industry: Cross-industry
Tags: eventregisterxct.evreg
Also called: R3

What it is Filled

A reusable pattern instantiated as a governed logical event register. It owns record admission and the declared history surface, including log-local positions, evidence, checkpoints and read boundaries. It does not own the truth or lifecycle of the domain objects described by events. Append-only means no silent rewrite of admitted history within the declared retention and integrity profile; lawful disposition is a separate governed operation with explicit loss of replay or verification capability.

In scope

Register identity, domain coverage, producer contracts, event envelopes and admission receipts
Scoped ordering, occurrence and recording times, corrections, provenance and continuity evidence
Integrity profiles, checkpoint and proof evidence, authorized replay, consumer positions, preservation and retirement

Out of scope

Domain object master state, the occurrence itself, accounting balances and business transaction execution
Identity issuance, access-policy evaluation, access-audit semantics and federation conflict resolution
Implementing consensus, cryptographic algorithms, broker operations, key custody, legal advice or universal exactly-once processing

Why it exists Filled

Describe governed domain event histories with explicit admission, order, time, integrity, replay and retention contracts.

Distinguishing features Derived, awaiting review

Unlike WM-XCT-013: The frozen inbound COMPOSE candidate sends registry changes here. The producer owns registry state and change meaning; this pattern owns admission, scoped order, replay, integrity evidence and retention. The edge does not guarantee atomic registry-plus-log writes; the adopting producer must evidence its handoff.
Unlike WM-ACT-015 Occurrence / Event: An occurrence may have several reports and appear in several logs. The local record is an attributed account with admission identity, not the occurrence itself.
Unlike WM-XCT-014 Ledger / Account: No balances, debit-credit constraints or financial finality are inferred from an admitted event or a sealed checkpoint.
Unlike WM-XCT-016 Identity Register: Producer, registrar, consumer and verifier identities are references. Identity creation and trust resolution remain delegated through a pinned adoption binding.
Unlike WM-XCT-004 Access Audit: Record an external audit-evidence reference for register operations; do not duplicate audit policy, disclosure interpretation or investigation lifecycle.
Unlike WM-XCT-018 Registry Federation: A replay export can support mirroring, but remote authority, topology, cross-register reconciliation and federation execution remain outside this pattern.
Unlike Transport, proof and event-envelope profiles: Envelope validity is not durable admission. A broker position is not portable event identity. A proof is relative to its tree, checkpoint, algorithm and trust assumptions, not proof of real-world truth.

Note: Derived from boundary notes against neighbouring models.

What robots and AI may and may not do Derived, awaiting review

Must not

Deny access when grant or scope is unknown.
No automated business action is authorized merely because an event was admitted or replayed.
Deny by default; an external current policy decision must permit the recipient, purpose, field scope and operation.

May

Admit event: Proposed, unimplemented operation contract. Assess and, only through an adopted runtime binding, append a domain event. This research run performs no append.
Record correction link: Proposed, unimplemented operation contract. Admit a new correction assertion under the same admission contract.
Record sealed checkpoint: Proposed, unimplemented operation contract. Bind selected committed history to externally produced checkpoint evidence.
Assess proof evidence: Proposed, unimplemented operation contract. Invoke an adopted verifier and record its bounded result.
Read authorized history slice: Proposed, unimplemented operation contract. Read a bounded retained slice and issue a qualified receipt.
Assess disposition proposal: Proposed, unimplemented operation contract. Prepare a reviewable component-level retention and disposal assessment.

Note: Derived from functions, policies, CRUD and access rules; prohibitions were not authored for agents as such.

Moral aspects Derived, awaiting review

Declare event, integrity, ordering, retention, privacy and consumer profiles with versions.
Do not guarantee perpetual immutable personal data.
No legal jurisdiction, retention period or privacy-compliance claim is universal.
Jurisdiction-specific retention, privacy, licensing and lawful residual-data review remain unresolved.

Note: Sentences mentioning harm, privacy, consent or similar, collected from the specification.

Owners Filled

Steward

Identify the domain registrar by role and governed reference; never use a brand as owner.

Roles

Domain registrar: Approve scope, profiles and register succession; resolve mandate references.
Producer: Supply attributed event keys and schema-qualified assertions; reconcile uncertain receipts.
Register operator: Operate the adopted admission and storage binding; report failure and recovery evidence.
Consumer: Use current grants and declared cursors; own downstream processing and effects.
Verifier: Assess exact proof inputs under a pinned profile and report limitations.
Records custodian: Review schedules and holds; coordinate authorized disposition and replica evidence.

Links to other meta-models Filled

references

WM-XCT-013 - Proposed backlink to the producer in the frozen inbound COMPOSE candidate. It does not reverse or replace that candidate edge or import producer-state lifecycle.
WM-ACT-015 - Optional domain occurrence reference; preserve reported-event identity independently. Pin the binding before adoption.
WM-XCT-016 - Candidate identity-master binding for registrar, producers, consumers and verifiers; identity issuance remains external.
WM-XCT-004 - Candidate external access-audit evidence binding; no local reimplementation of audit-trail semantics.
WM-XCT-018 - Optional federation consumer and provenance references; do not inherit legacy mandatory federation composition.

aligned

CloudEvents v1.0.2 - Optional envelope mapping; preserve identity and explicit mapping losses without assuming durability or universal payload schema.
PROV-O Recommendation 2013-04-30 - Optional attribution and derivation vocabulary, not a truth or legal-admissibility certificate.
RFC 9162 selected proof concepts - Conceptual alignment only; the experimental certificate protocol is not a general event-register standard.
RFC 8785 - Optional JSON canonical representation where its input restrictions are satisfied; no required storage format.

neighbor

WM-XCT-013 - The frozen inbound COMPOSE candidate sends registry changes here. The producer owns registry state and change meaning; this pattern owns admission, scoped order, replay, integrity evidence and retention. The edge does not guarantee atomic registry-plus-log writes; the adopting producer must evidence its handoff.
WM-ACT-015 Occurrence / Event - An occurrence may have several reports and appear in several logs. The local record is an attributed account with admission identity, not the occurrence itself.
WM-XCT-014 Ledger / Account - No balances, debit-credit constraints or financial finality are inferred from an admitted event or a sealed checkpoint.
WM-XCT-016 Identity Register - Producer, registrar, consumer and verifier identities are references. Identity creation and trust resolution remain delegated through a pinned adoption binding.
WM-XCT-004 Access Audit - Record an external audit-evidence reference for register operations; do not duplicate audit policy, disclosure interpretation or investigation lifecycle.
WM-XCT-018 Registry Federation - A replay export can support mirroring, but remote authority, topology, cross-register reconciliation and federation execution remain outside this pattern.
Transport, proof and event-envelope profiles - Envelope validity is not durable admission. A broker position is not portable event identity. A proof is relative to its tree, checkpoint, algorithm and trust assumptions, not proof of real-world truth.

What else AI and robots need to interact with it Incomplete

Sources Filled

CloudEvents Specification - Cloud Native Computing Foundation
Date and Time on the Internet: Timestamps - Internet Engineering Task Force
PROV-O: The PROV Ontology - World Wide Web Consortium
Guide to Computer Security Log Management - National Institute of Standards and Technology
Certificate Transparency Version 2.0 - Internet Engineering Task Force
JSON Canonicalization Scheme - Internet Engineering Task Force
Apache Kafka Design - Apache Software Foundation
Time Ontology in OWL - World Wide Web Consortium

Open questions

Complete direct HTTP retrieval, version and errata checks, licensing assessment and independent claim-level source review without treating retrieval success as substantive verification.
Develop conditional instance schemas and operational fixtures for retry collisions, uncertain commits, producer handoff gaps, epoch changes, clock uncertainty, invalid proofs, expired cursors, revoked grants and partial disposal.
Pin identity, authorization, audit, federation, storage and proof bindings; review cryptographic and legal profiles before any operational deployment.
Restore independent external review before any canonical or publishable-draft promotion.
Independent external review is absent; Claude and Grok were skipped by owner instruction.
No executable instance schema, atomic admission implementation, broker configuration or proof verifier is delivered.
No evidence of operational throughput, global order, complete capture, end-to-end exactly-once effects or recovery objectives.
Cryptographic suite selection, key rotation, witness coordination and fork detection require a tested security profile.
Jurisdiction-specific retention, privacy, licensing and lawful residual-data review remain unresolved.
No live HTTP status or response hashes were measured; check_sources.py is prepared for coordinator execution.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-xct-015-event-register/spec.yaml