Tag it and bag it: A DCB profile for reliable government registers
22 October 2026 – Maarten-Jan van Gool and Marc van Andel
This position paper was written as an article towards our talk The Architecture of Accountability: How to Build Reliable Government Registers using event sourcing and the DCB at Axoniq Conference 2026, 28 October 2026 in Utrecht.
Two people get married. A civil servant records the marriage in the population register, and from there, the tax office, the pension fund and the bank act on it. Government registers like this – of people, land, vehicles, companies and more – are the official record of a country. Each has a well-defined bounded context: the law is specific on what a register is about. What registers record about these 'things' are not simply events. Government agencies make determinations based on well founded facts and grounded in law.
Event sourcing fits registers naturally: an append-only journal is exactly the memory a register needs. The Dynamic Consistency Boundary, or DCB in short, fits the decision process of registers: multiple entities can be involved in making decisions (like a marriage), so we require a dynamic consistency boundary to make determinations. In this article, we will propose an implementation of DCB tuned to reliable government registers. We propose a profile: DCB, narrowed by four rules that follow from what a reliable government register requires. We developed them at Uit betrouwbare bron (from a reliable source), where we are designing the mechanics of a reliable government register.
DCB in one marriage
Marriage is a convenient example when explaining DCB. A marriage is about three things: two partners and the marriage itself. A new marriage can only be entered into if neither partner is already married, so the consistency check has to look to both partners.
In classic event sourcing, every event belongs to exactly one aggregate, so only one of the three guards the marriage. Say two clerks work at the same time: one registers Anna's marriage to Ben, the other Anna's marriage to Chris. If each marriage is its own aggregate, both checks pass, and Anna is now married twice. A bigger aggregate holding both partners does not work either: anyone can marry anyone, so it would have to hold the whole register. Neither does a process manager that cleans up afterwards: in a register, afterwards is too late, because others may have already acted on the second (illegal) marriage.
The DCB closes this gap. It does not fix a boundary in advance: each decision draws its own. Every event gets tags that name what it is about. For Anna and Ben's marriage, that is person:p-1, person:p-2 and marriage:m-7. To decide, you read the events you need by type and tag: here, everything about both partners. The store appends the new event only if nothing matching your query has been stored since you read them. If something was, the append fails and the decision has to be reconsidered.
What a register demands
DCB is no longer a fringe idea. Since Sara Pellegrini introduced it in 2023, more than twenty implementations in eleven languages have appeared, Axon Framework 5 among them. But practitioners disagree on implementing the DCB. DCB.events proposes using tags, while critics oppose tagging as a premature interpretation. Labels should be inferred after publication, not attached to them, and a tag duplicates the payload while fixing one interpretation at the moment of writing. In Fritzsche's words: "Let the event store be the source of truth and not the source of structure. […] Let correlation happen downstream. Let meaning emerge. Let consumers decide." At a deeper level, the whole discussion is about when an event gets its meaning.
For a register, the answer is clear: an event gets its primary meaning at the moment of determination. An event in a register is decided by a competent authority on a specific legal basis within a specific bounded context. Consumers must act on that meaning, or at least be aware of their own reinterpretation. Decision context matters: The Cadastre records living addresses of people at the time of a deed. A consumer could use this information to determine current home addresses, but should be aware of the fact that not all address changes require a deed. The context in which an event is produced decides its meaning.
New meaning may still emerge downstream – that is what projections are for. We do not wholly oppose this notion. But in a reliable government register, the primary meaning of a determination, and what it is about, belongs to the register that determines. Tags give us exactly that: a spine of the things each event is about.
A register makes three demands of that spine:
- Accountable. The spine has to show, for any event, whom and what it was decided about, and lead to whatever later doubted or withdrew it.
- Long-lived. The spine should be able to outlast the code that wrote it. A register lives for decades: laws change and the software around the journal is rewritten more than once, while a marriage from 1987 still has to be explained.
- Confidentiality-preserving. The spine should not expose information by itself. It has to protect the things or people it is about. The store reads the tags, so they stay in plain text, in every index, for as long as the journal exists – even after the record itself has had to go.
Our profile consists of four rules, each answering one or more of these demands:
| Rule | Demand | |
|---|---|---|
| 1 | Tags are derived from the payload | accountable |
| 2 | Tags are opaque | long-lived, confidentiality-preserving |
| 3 | What an event is about stays as determined | long-lived, accountable |
| 4 | Relations between events are part of the message | accountable |
Rule 1: Tags are derived from the payload
Accountability starts with knowing what an event is about. If tags can say something different from the payload, a register has two versions of that answer, and no way to tell which one counts.
An event travels in an envelope – an event message – that holds the payload, which is what was decided, and the metadata the journal needs to store, find and check it. Metadata generally is not arbitrarily chosen by whoever creates the event, it is determined by the context at the time of event creation. The type and its version follow from the payload, the producing component and its version from the context, and the identifier, position and moment of recording are assigned by the journal.
Tags should not be chosen arbitrarily either. Events are about specific 'things': the payload describes those. Consequently, tags should be derived from the payload as a matter of implementation: Each event type should implement a function that derives its tags from the payload, and the framework extracts the tags when the event is appended. Axon Framework supports this with its AnnotationBasedTagResolver: the event class marks with @EventTag which payload fields become tags. In our profile, that is the only way: the caller hands in an event and nothing else, and there is no way to add a free-form tag at the call site.
Rule 2: Tags are opaque
A tag is kind:id, and the id is an opaque identifier for the things its events are about: person:p-1, never person:anna or user:anna.devries – and for a person, not even a social security number.
The first reason is the oldest one for opaque keys: anything that means something will change. Names, addresses and municipalities do not age well. Codd already observed in 1979 that keys chosen by users "must therefore be subject to change by them", and introduced surrogates instead: keys the system assigns, over whose value users "have no control". In a database table, a key that carries meaning is a nuisance. A key, and so a tag, has to age better than any other field.
Identifiers are not absolute either. A license plate does not make a vehicle: it points to one. A register does not keep the entities themselves, but assertions about them, each with their own source and history: a plate changes when a vehicle moves to another country. Tags should not be bound to external identifiers that can change over time.
Confidentiality is a concern as well regarding tags. Specifically for people, privacy may be a concern. A name, an email address or a social security number are keys that expose private information. We can prevent certain projections from reading certain confidential event types, it is much harder to prevent it from reading certain tags. Encrypting payloads, or even making them permanently inaccessible (how exactly is still debated1), is possible, while being hard for tags.
While we require tag opaqueness for the reasons stated above, opaqueness does not resolve all confidentiality concerns. Opaque ids do not expose information by themselves, but tags in an event store do expose which tags relate to each other, and why. That person:p-1 and person:p-2 once shared a marriage is visible in the tag index. Whether or not to expose your tags to the outside world should be a carefully considered decision.
Rule 3: What an event is about stays as determined
A register makes determinations about the 'things' it is about. The tags of a determination make these things explicit. Tags should not be redetermined. Changing an event or changing tags is changing the determination, essentially falsifying history and fundamentally undermining the entire event sourcing paradigm.
But what if the original tags were wrong? Take one person registered twice, as p-1 and p-77. No tag check notices: opaque ids do not solve identity for you. Merging the two is a new event: an authority decides that they are the same person.2 The old events and tags do not change.
Let's say a marriage event records the officiant as well. A later consumer is interested in the officiant and wants to record officiants and the marriages he or she has performed, by officiant. Should the register tag the officiant? What if we haven't up until now?
In a reliable government register, tags are not a convenience. We do not tag lightly. The question in this example is a fundamental one: Is the register about officiants? Do we simply record the officiant at the time of marriage? Or do we track the life cycle of officiants? Do we correct wrongly written officiant names? Do we record officiant name changes separately from marriages? In other words: Are officiants properties of a marriage or a 'thing' of their own in our register?
Laws may change, and a register may take on additional responsibilities. If that is the case, yes: we would feel some pain reinterpreting earlier events and adding tags. But we think this is pain that should be felt.
Rule 4: Relations between events are part of the message
Accountability does not end at the moment of decision. A register must also be able to show how its events hang together, and whether an event still stands. Those are relations between events, and like tags, they are derived from the payload and stored in the message, for the same reasons: one truth, an index to it, and fixed at the moment of decision. The store can then follow them directly, without reading every payload.
Some relations need nothing more than tags. The 'merge persons' event from the previous chapter is an example: the merge event is about both p-1 and p-77, so a decision about either of them finds it, and from then on combines both event timelines.
Other types of relations point to another event, to say whether it still stands. The Dutch guidelines describe how a reliable register corrects itself. Every event a register appends is a determination it endorses. When a determination is reported as probably wrong, the register first casts doubt on it, while the authority that supplied it investigates: it still stands, but with less certainty. If it turns out right, the doubt is lifted. If it turns out wrong, a correction withdraws the previous endorsed event, and can add new events in its place, as they should have been. Doubt, lifting it and withdrawal are each new events that point to the earlier one. The earlier event itself never changes – that is rule 3 again. What a register still endorses is its endorsed sequence: the journal, minus what has been withdrawn. How corrections and projections build on that is a story for another article.
Concluding
A register does not just store what happens. It records determinations, and others act on them. DCB lets each decision draw its own consistency boundary. We have defined four additional rules a reliable government register has to follow.
The bounded context of a reliable government register is well defined: it makes determinations about specific things – people, marriages, vehicles, plots of land – and is precise about each of them. Its tags make that explicit. So the rules all come down to one thing: a register has to know what each of its events is about – the day it was recorded, and decades later. Each rule guards a part of that answer:
- Decided, not inferred. Tags are derived from the payload, at the moment of decision (rule 1).
- Built to age. Tags are opaque and are meaningless by themselves, so nothing in them goes stale or identifies anyone directly (rule 2).
- Never rewritten. What an event is about stays as determined; a register adds new events instead (rule 3).
- Reaching beyond the event. Some relations need nothing more than tags, like the merge that joins two histories. Others point to another event, like the correction that withdraws an earlier one. Together they show how events hang together, and whether one still stands (rule 4).
Being required by law to destroy certain information under specific circumstances is something we have taken account of, but we do not yet know how to implement. Once content is destroyed a decision can no longer be recomputed. What a register still is allowed to know about an event then, and whether that is enough, we have yet to work out. Destroying evidence is hard to rhyme with accountability.
In this article, we have described what accountability requires of an event-sourced register: a well-defined bounded context and tags as the spine of the things it records determinations about, chosen with care. What are the determinations your register records, and what are they about?
In our upcoming talk at Axoniq Conference 2026 in Utrecht, we go beyond tags, to talk about what follows the event: projections, corrections and the repeatable query. We would love to hear what you think!