I’d like to teach/share about a methodology I’m learning about right now, which is “Behaviour driven design”.
What?
This actually has a few other names, Business Driven Development and Acceptance Test Driven Development - depending on the cultural/historical context you come from. While most developers are aware of Test Driven Development, which is down in the weeds to granularly test things that are imperative to code functionality - it doesn’t necessarily address the higher levels of intended behaviour from a declarative perspective.
The best definition I’ve found is the following:
BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.
Why?
"it does exactly what I asked for, but not what I want"
Having stepped on several landmines in my lifetime and eaten my own feet multiple times, I’m acutely aware of the laws of unintended consequence and very reluctant to build something thats not thoroughly considered.
When we focalise on a problem we forget the big picture and break things; passing around promissory notes seemed like a great idea at the time of invention - until we externalised all costs onto the planet and got caught in a progress trap… same could be said for our attempts at regulating cobra numbers in India 
When it comes to software, unintended consequences can be incredibly dangerous. The obvious reference is Cambridge analytica and Facebook hijacking elections and our dopamine receptors. The less obvious example was our accidental adoption of the permissions paradigm (rather than capabilities) - which is literally down to the compression of a spreadsheet… this cost us trillions of dollars in sys admins alone and a huge mess; never mind a that the tools we adopted have been pathologically shaping humanity for the last 50 years. This was an unimaginably HUGE setback and came down to a seemingly innocuous decision on a subject/object relationship which had dire emergent effects.
How
From my (naive) understanding it’s about designing from a declarative perspective which means being explicit and generalising to the highest degrees your able. We do this in natural language Tuples (ahhh magic number three!), which are domain specific to create explicit logical outlines of what one is trying to convey. This is also known as Hoare logic.
The formulation is context, event, outcome (feels like a reframe of REA accounting!). This might look like the following
As I:
I want:
So that:
or the more popular formulation
Given:
When:
Then:
My feeling is that this framework may be good for creating Holochain validation rules down the line but I’m too green in both camps to make that assertion with any degree of certainty.
Sign off
I’ve used both versions for a proposals/agreements design here and but have no prior experience designing this way bar philosophical acrobatics and logic formulation… thus I have no idea if I’m doing it right so upfront warnings: #NotGospel #HereBeDragons #Cobras