Imagine a team six months into an #EventModeling engagement. They’ve shipped two slices. Business stakeholders are happy. Developers are moving faster than before. But at the sprint review, an architect asks the question that always comes up eventually:

“This all sounds great. But seriously—how do you test it?”

It’s a fair question. Most organizations have decades of muscle memory around this: someone writes requirements in a document, developers build something, then testers scramble to figure out what was actually built and write tests to verify it. It’s the familiar rhythm of enterprise software.

But that separation between specification and testing? That’s exactly where things start going wrong. Quietly, almost invisibly, but inevitably.

Consider the usual pattern. The specification lives in Confluence. The tests live in Jira or in code. Someone quietly updates the spec to reflect new understanding. The tests don’t get updated; they still reflect March’s understanding. Or QA discovers edge cases and expands the test suite, but no one tells the business analyst who owns the requirements. Six months later, the system has two conflicting descriptions of what it should do. No one is quite sure which one is “true.”

This isn’t a process failure. It’s a structural problem.

EventModeling doesn’t solve it by adding more process. It solves it by removing the separation entirely.

The Scenario Is the Specification

Here’s what actually happens in practice.

Picture a pharmaceutical company building a system for clinical trial patient eligibility. A critical eligibility rule arrives as, you guessed it, a twenty-page regulatory document. Clinical protocols. Inclusion criteria. Exclusion triggers. Safety thresholds. The development team reads it one way. QA interprets it another. The clinical researchers who wrote the protocol have a third understanding in their heads.

You can imagine how that goes.

Six months later, there’s working code that passes QA’s test suite, but the clinical team keeps finding “bugs” that turn out to be specification misunderstandings. Everyone is frustrated. Everyone is doing their best. The structure itself made failure probable.

Now consider what happens when the same rule is expressed as executable scenarios.

In the regulatory document, the rule says something like:

“If the patient is over 75 and presents with elevated liver enzymes, the case must be escalated to the principal investigator for manual review.”

Simple, right?

But real clinical protocols are never simple. And that’s the point.

Given, When, Then — But for Real

In #EventModeling, that regulatory requirement doesn’t become a bullet point in a requirements document. It becomes an executable scenario; something that looks like this:

Given:
  PatientScreeningCompleted
    - patientAge: 78
    - liverEnzymes: "elevated"
    - baseLineHealth: "otherwise_stable"

When:
  AssessTrialEligibility

Then:
  EligibilityRequiresPIReview

Now here’s where it gets interesting. This isn’t pseudo-code. It isn’t documentation we’re hoping someone maintains. It’s a concrete example, the rule, expressed in business language, in a format that can actually be executed.

The “Given” part spells out what we already know, the facts that exist. The “When” is the moment of decision, the command someone (or something) issues. The “Then” is what must happen, the business event that results.

Look at what you’ve got now:

• The business person reads it and says, “Yes. That’s exactly what we meant.”
• The developer runs it and knows immediately if their code works.
• The new team member reads it and understands what the system actually does.

Same artifact. Three purposes. No drift. No wondering if the Confluence page matches the Jira tests matches the reality of the code.

Living Scenarios, Never Stale

Here’s where most documentation dies. You write it at the start of the project when you barely understand the domain. Then the world shifts. Requirements change. Edge cases emerge. The spec lives on as a museum piece, frozen in time, increasingly wrong, increasingly ignored. Eventually people stop looking at it altogether. “Just read the code to see what it really does.”

I’ve been there. We all have.

Executable scenarios age differently because they’re alive. They live in your codebase. They run in your CI pipeline. When the business rule changes, someone updates the scenario. When the scenario changes, the test fails. When the test fails, you have two choices: fix the code, or have a conversation about whether the rule actually changed.

Either way, the drift is visible. It’s caught immediately, not discovered six months later when an auditor asks uncomfortable questions.

And because these scenarios are maintained right alongside the production code, reviewed in pull requests, executed on every build, they stay current. They have to. The build goes red otherwise.

From Abstract Rules to Concrete Examples

Usually someone raises a hand about now: “But clinical protocols are complex. One eligibility rule might reference five biomarkers, two comorbidities, and three exclusion criteria. Are you saying we need scenarios for every combination? That’s overwhelming.”

Exactly.

When a rule needs twenty scenarios to cover its conditions, the problem isn’t the testing strategy. The problem is the rule itself is too complex for anyone—including the clinical team—to reason about clearly. #EventModeling scenarios force this complexity into the open where it becomes visible and manageable.

Back to that liver enzyme rule. On the surface it’s simple: over 75 plus elevated enzymes means escalate to PI. But dig into the protocol with actual clinicians and the edge cases multiply:

• What if the patient is exactly 75? Birthday next week. Does the threshold apply?
• What if the enzymes are only mildly elevated, trending down, and the patient has no other risk factors?
• What if this is a compassionate use case—different rules because standard protocols don’t apply?

In the regulatory document, these become footnotes. “See protocol amendment 4.3 for age threshold clarification.” They’re discovered during site monitoring, often too late to fix easily.

In #EventModeling, each scenario becomes explicit:

Scenario: Patient exactly at age threshold
Given: patientAge: 75, liverEnzymes: "elevated", daysToBirthday: 5
Then: StandardEligibilityApproved

Scenario: Mild elevation with improving trend
Given: patientAge: 78, liverEnzymes: "mildly_elevated", enzymeTrend: "decreasing", otherRiskFactors: []
Then: StandardEligibilityApproved

Scenario: Compassionate use protocol
Given: patientAge: 78, liverEnzymes: "elevated", trialType: "compassionate_use"
Then: EligibilityRequiresPIReview

Each scenario represents a conversation that happened—and agreement reached. Clinical researchers and developers look at the same concrete example and confirm: “Yes, given these facts, this is the decision.” The complexity doesn’t disappear. It becomes visible, discussable, testable.

What This Means for Implementation

At this point, someone usually asks: “So do we write the scenario first, or the implementation?”

The honest answer: it depends on where the team is in the slice.

Early in development, scenarios almost always come first. The #EventModeling session produces them. They become the definition of done; the team implements until the scenarios pass. Everyone knows what “done” means because the scenarios state it explicitly.

Later, during refactoring or adding small behaviors, scenarios might be written alongside the code. Sometimes slightly after, capturing what the clinical team confirms is correct behavior. There’s no purity test here. What matters is the outcome.

Eventually, every meaningful behavior has a scenario. The collection becomes the executable specification. It’s how new team members learn the system. It’s how clinical stakeholders verify what has been built. It’s how regulatory affairs gets their evidence: concrete, traceable, undeniable.

The scenarios are the system, fully described.

From Specification to Confidence

The unexpected benefit of this approach isn’t technical. It’s psychological.

When specification and testing are separate artifacts, uncertainty always creeps in. Did the team capture everything? Are they testing the right things? Does the documentation match what was actually built? Will regulators accept the evidence that rules were followed?

It creates drag. Debates in meetings. Rework during audits. Reconciliation projects to figure out what drifted. The organization slows down more than it realizes.

When specification and testing become the same thing, namely executable scenarios, visible to everyone, that uncertainty evaporates. The system does exactly what the scenarios describe. The scenarios describe exactly what the clinical team agreed was correct. The agreement is right there, in plain language, in version control.

Teams move faster not because they skip testing. They move faster because testing is no longer a phase. It’s not a checklist. It’s not handed off to a separate team while development moves forward. It’s continuous, inherent, trustworthy.

Comprehensive documentation and comprehensive test coverage were both attempts at the same goal: having a single source of truth that everyone, clinical researchers, developers, regulatory affairs, auditors, new team members, can consult to understand what the system actually does and why.

In #EventModeling, that single source is the scenario suite.

The specification is no longer a document to maintain, not Confluence pages gathering dust, not Jira tickets representing someone’s interpretation, not Word documents with tracked changes from four stakeholders.

The specification is the test. The test is the specification. Both tell the same story that was told at the beginning.

And that story is something everyone can finally believe, from the first developer to the last auditor.

Originally published on LinkedIn (2026-04-14): https://www.linkedin.com/pulse/how-we-test-just-became-specification-gabriel-n-schenker-mcbze