How do I balance details vs business need in a gherkin test?

I have a table that's going to have 3 timestamp columns: created_on, updated_on, and applied_on.

The first two are what you think. The last one is the timestamp some related external action occurs.

My business users are writing tests. I don't want their tests to shatter if I change some detail in the code. That is, the business tests should be testing business need, not technical implementation.

Here some gherkin:

Given we do all the setup for this example
When a row is created
Then created_on will be valid
And updated_on will be valid
And applied_on will be undefined
And created_on will equal updated_on

Now, this is completely logical and valid. And likely an anti-pattern. It is very low-level; we're talking about specific column names.

Take 2:

Given we do all the setup for this example
When a row is created
Then the created and updated dates are the same
And applied_on will be undefined

Maybe businessy? I don't know.

Finally, take 3:

Given we do all the setup for this example
When a row is created
Then the dates are appropriate for creation

Given we do all the setup for this example
When a row is updated
Then the dates are appropriate for update

Given we do all the setup for this example
When a row is acted upon
Then the applied date is set    

So we see here gherkin tests of different levels of detail. Where's the line between unit-test and business test? What if the non-coding QA people who are creating feature files want to be sure the dates are set 'just so'?

 Then the dates are appropriate for creation

is resilient enough, but how would this satisfy someone who wanted to be sure the dates were reasonable? Sure, the underlying code seems to work. The coders can assure the testers that the steps code meets the needs of the requirements. But how would this appease any QA person worth their salt?