Over the last weeks, I have written about missing shared language, about the absence of a blueprint, about boundaries following decisions, about trust, compliance, and separation of duties not being cultural problems but structural ones.

Individually, these ideas resonate with many people. Together, they raise a reasonable question:

What does this look like from start to finish?

What follows is not a new concept. It is the same story, told once — without handovers, without translation loss, and without switching mental models halfway through.

Let’s follow a single business thread inside a term life insurance product, from the first business idea all the way to running, auditable software.

A Business Idea Arrives

As usual, the initial request does not arrive as a decision problem. It arrives as a solution-shaped sentence.

“We need to speed up underwriting and get policies confirmed faster.”

No one is wrong here. But no one is precise either. Hidden inside this sentence are multiple business decisions, legal responsibilities, and regulatory constraints — none of which are visible yet. So the first step is not implementation. It is clarification. The question becomes:

What are the actual business decisions involved?

Two Business Activities That Matter

When we slow down and look closely, two tightly coupled but clearly distinct business activities emerge.

The first is underwriting.

Underwriting is not data processing. It is a decision. A decision made at a specific point in time, based on the facts known then, under rules that were valid then, by a person who was authorized then. The output of underwriting is not a modified policy record. It is a single business fact: An underwriting decision has been made. Accepted. Accepted with conditions. Or rejected.

The second activity is coverage confirmation.

Coverage confirmation is not a continuation of underwriting. It is a separate legal act. Here, the business decides whether coverage actually becomes effective. This decision relies on the underwriting decision as input — but it must not re-evaluate risk, and it must not be performed by the same role.

If underwriting decides whether something may be insured, coverage confirmation decides whether we are now legally on the hook. This separation is not optional. It exists because liability exists.

Making the Decisions Visible Together

To reason about these activities properly, all relevant stakeholders need to see the same picture. Not a requirements document. Not a backlog. Not a flowchart translated three times. They need a shared business model that makes decisions, facts, responsibilities, and timing explicit. This is where EventModeling enters — not as a technique, but as a necessity.

In an EventModeling session, underwriting and coverage confirmation are not described in prose. They are placed on a timeline. Business events appear first. Then the commands that caused them. Then the policies and rules that govern those commands. Then the views people actually look at when making decisions. What emerges is not documentation. It is an agreement. At the end of such a session, everyone in the room can point to the same place on the model and say:

“This is where underwriting ends.” “This is where coverage confirmation begins.” “This is the fact that connects them.”

That alone removes an enormous amount of ambiguity.

From One Big Picture to Implementable Slices

The EventModel is information-complete, but it is not implemented as one thing. Instead, it naturally breaks down into slices. Each slice corresponds to a specific business decision. Each slice has a clear trigger, clear rules, and a clear outcome.

One slice evaluates underwriting facts and produces an underwriting decision. Another slice consumes that decision and produces coverage confirmation. They are connected only by published business facts. No shared database tables. No hidden coupling. No need for coordination meetings to keep them in sync.

This is where architecture quietly aligns with the business instead of fighting it.

Making Rules Explicit — Where They Belong

Underwriting rules are usually the first thing people worry about. They are complex, regulated, and constantly changing. In this approach, they are not buried in code. They are made explicit directly on the model, in the form of concrete scenarios.

Given certain medical facts. When an underwriting decision is requested. Then a specific outcome must be produced. These scenarios are not “tests written later”. They are the executable expression of business intent. There is no separate translation step from business rules to technical rules. The model already is that translation.

Implementation Without Aggregates, Without Guesswork

When implementation starts, developers do not invent structure. They follow the slices. Each slice is implemented vertically: from command handling, through decision logic, to event publication and projections.

There is no central aggregate guarding shared state, because decisions are not made by mutating state. They are made by evaluating facts. Boundaries emerge dynamically from the decisions themselves — not from data ownership diagrams drawn upfront.

This is what allows multiple developers to work in parallel without stepping on each other’s toes. The coupling is explicit and intentional. Everything else is autonomous.

Separation of Duties by Construction

Underwriting decisions and coverage confirmation are handled by different slices. They expose different commands. They require different roles.

No one needs to “remember” to enforce separation of duties later. It is visible in the model and reflected one-to-one in the implementation.

Compliance does not inspect this system by reading code. They inspect the story.

And the story is coherent.

Auditability Without Reconstruction

Because the system is event-sourced, nothing important is overwritten. Every underwriting decision exists as a fact. Every coverage confirmation exists as a fact. Each is linked to the rules, inputs, and authority that applied at the time.

When an auditor asks, years later: “Why was this policy confirmed?” The system does not reconstruct an answer. It already has one.

Project Management Without Process Theater

Something unexpected happens once the EventModel becomes the signed-off source of truth. There is no need for backlog grooming. The slices already exist. There is no need for estimation poker. The number and type of slices are visible, and the effort per slice is known. There is no need for daily coordination meetings to avoid collisions. The coupling is explicit and minimal. Progress is shown directly on the model itself. Slices move from undecided to implemented to live. Color coding replaces status reports.

The artifact the business helped create becomes the primary management tool.

One Continuous Flow

What makes this approach powerful is not any single technique. It is the absence of translation gaps. The business idea becomes a business model. The business model becomes executable slices. The slices become software. The software produces facts. The facts tell the same story the model told.

From intent to audit, the language does not change.

And when that happens, predictability, trust, and compliance stop being goals. They become side effects.

Prior posts in the series:

This post tries to tie all those previous post together…

• Post 1: We lack a shared language and blueprint
• Post 2: We can work with a small set of repeatable building blocks
• Post 3: We need a living map for the enterprise
• Post 4: When “change state” quietly reshapens our boundaries
• Post 5: Where does a domain get the facts it needs to make a decision?
• Post 6: Boundaries Follow Decisions, Not Data
• Post 7: When software makes simple business decisions hard
• Post 8: Why Systems Forget What the Business Never Did
• Post 9: Why EventModeling Still Struggles in the Enterprise
• Post 10: Why “Current State” Is a Dangerous Lie in Decision-Heavy Systems
• Post 11: Audit, Compliance, and Governance Don’t Need More Controls — They Need the Story
• Post 12: Trust Is Not a Cultural Problem — It’s an Architectural Outcome
• Post 13: Separation of Duty is a Modelling Problem

Originally published on LinkedIn (2026-01-17): https://www.linkedin.com/pulse/from-business-intent-auditable-software-one-story-gabriel-n-schenker-cef0e