A Story scenario records its starting data, supplied inputs, expected answers, and expected changes to state. Business owners and delivery teams can review the same examples that the tester uses.
Business specifications by example
Test business actions against agreed scenarios and review the results before promotion.
Make correctness concrete
Run the relevant scope
Test one Story, a Use Case, or a selected subtree against the chosen source and execution target. Compare the observed results with the expectations and inspect structured differences.
The report makes changed behavior visible across that scope. Use it to assess a proposed data, model, or implementation change before accepting it.
Require evidence before promotion
A destination branch can require conformance checks before a proposed change is merged. The decision concerns the tested state; changing that state requires another check.
Executable Use Cases connects actions to business outcomes. Composable Business provides the authoring context. Version control keeps the proposal and its review together.
Developer reference
Technical details
Executable BDD contract
Given fixtures establish graph state; When invokes a Story; Then asserts typed result rows, post-execution graph state or both. Output-only assertions cannot detect an unintended write.
Comparison respects RDF datatypes. Captures bind generated values for later expectations; wildcards leave selected values unconstrained. Chained scenarios carry captures and execution state forward.
Verdict and publication
A run pins specification definitions and execution target, grouping verdicts by Story/Use Case. Execution errors and assertion failures are distinct outcomes. Required conformance can gate a proposed merge. Scoped runs supply impact evidence; this contract does not imply automatic continuous reruns for every upstream dependency edit.