In software systems if a decision isn't recorded as an immutable fact, did it really happen?
To model and build Software Systems that deliver Business Value faster and efficiently the first time
Business Modelling · Spec · Driven Development
RULE 1
Define what happens and how it happens
RULE 2
Specs emerge directly from the business model
RULE 3
Auto-Generate repetition - don’t write it
RULE 4
DRA (Domain Resource Action) · Vertical Slices · Explicit & Decoupled structure
RULE 5
Organise code into Functional Core (for pure functions) + Imperative Shell (for side effects)
Result → A simple working software system with no “lost in translation” errors
From User Action to Business Value
User clicks to submit an order and a "Place Order" action is sent to the system, with the relevant context.
e.g. CustomerID, CartID, ShippingAddressID, PaymentID, etc.
System checks all Business Rules for the Business Action "Place Order".
e.g. "enough stock", "shipping address validity", "payment processed", etc.
A Business Decision is made for the "Place Order" Business Action, based on the result of the Business Rules checks.
e.g. ACCEPT , PENDING or REJECT.
The Unchangeable History and Source of Truth for every Business Decision made by the system.
e.g. The Business Decision for the "Place Order" Business Action would result in an "Order Accepted", "Order Pending", or "Order Rejected" Immutable Business Fact.
An Immutable Business Fact is of Guaranteed Business Value because it enables point-in-time travel to the past, which enables recovery, debugging, compliance, auditability, accountability, and more.
Business Behaviours triggered, e.g. Send User Email, Notify Warehouse, etc.
Business Outcomes, e.g. increase in sales for the current month, quarter, year, etc.
Business Value, e.g. amount paid by the customer, being a returning customer, etc.
From Business Fact to Business Action (The Right Way)
First, we find all the Business Facts for all Business Flows (The How). Facts are the ones of Business Interest, coming from a Business Decision that was made based on Business Rules. For example: "User Registered", "Order Placed", "Order Shipped", etc.
Now that we know the Business Facts, we can map them to their respective Business Decisions, e.g. "Order can be Placed?", "Order can be Shipped?", etc.
Business Rules govern how Business Decisions are made, e.g "Payment confirmed", "Inventory allocated", etc.
Business Actions are Intents (or Requests) with instructions to trigger changes in the Business, e.g. "Register User", "Place Order", "Fulfil Order", etc.
BMSDD forces a crucial distinction: not all system activity is of Business Interest. We only record as a Business Fact data changes that drive Business Behaviours, Outcomes and Value.
Business Fact: A customer's address is updated (Impacts shipping, billing, etc.).
Operational Detail: A user clicked a button 3 times (Just logging/telemetry, no change to the official story).
Since Business Facts are immutable, they intrinsically guarantee they can be Audited for Accountability and Compliance.
Every Business Decision is recorded as an Immutable Business Fact that is linked to a time, an actor, a purpose, with all relevant context for it.
Business Modelling Spec Driven Development aligns strategy, product, and architecture around a single source of truth, the business model.
Ensure software execution faithfully delivers business strategy, reduces risk, and protects long-term business value.
Turns business intent into a clear and validated business model and specification, before development begins.
Build systems from business models and specifications, not from business requirements docs that promote ambiguity and assumptions.
(Business Modelling Spec Driven Development)
Bridging the Gap Between Business & Developers
Validate the flow to sign-off before it's built to eliminate the "lost in translation" errors
Accelerates delivery by enabling parallel workflows and automated prototyping
Decisions made based on Business Rules and recorded as Immutable Business Facts
Derive Business Insights from the Immutable Business Facts History
Auditable and accountable records for all decisions, from Immutable Business Facts
Prevents expensive rework by fixing ambiguities during the modelling phase.
Business Model
Technical Specifications
Immutable Business Facts
Clear specs from the business model mean no more guessing games.
Generate boilerplate code from the spec and focus on the core logic.
A clear, decoupled architecture makes the system easier to understand and modify.
Well-defined specs make it easier for AI assistants to understand the code and help you.
The business model is not tied to any specific technology stack.
Get it right the first time with clear requirements from the start.
Our mission is to fundamentally change the conversation between business and developers. We created the Business Modelling Spec Driven Development (BMSDD) framework to eliminate the costly "lost in translation" errors that plague software projects, ensuring that what gets built is exactly what the business expects and needs.
We believe that a business's core logic is its most valuable asset. By modelling business flows into immutable facts, deriving specifications from those models, and driving development from both, we enable the business and developers to create software systems that are not just robust, scalable, easy to maintain, and add features, but also auditable, accountable, and perfectly aligned with the business's strategic goals.