Context, Action, Outcome
A structured format for describing product behaviour. Precise enough to be unambiguous, plain enough for anyone on the team to read — without the machine-oriented syntax of BDD.
Context/Action/Outcome is the format every scenario in a Specsight specification uses. It has exactly three elements: a Context (the starting situation), an Action (what the user or system does), and an Outcome (what the product does in response). Together, they describe one specific behaviour in a way that's both precise and readable.
It's structurally similar to Given-When-Then from Behaviour-Driven Development, but with one critical difference: it's written for humans, not test runners. No syntax to learn, no step definitions to wire up, no test harness to integrate with. A PM can read it. A customer success manager can read it. A stakeholder can read it.
The format matters because it makes surgical updates possible. When a release changes how one edge case is handled, only that scenario needs to update — the rest of the spec stays accurate. A wall of prose has no natural update boundary; a structured scenario does.
Example
Related Terms
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a living product specification.
A software development practice where behaviour is described in a structured format (typically Gherkin) that can be read by stakeholders and executed as automated tests.
A structured syntax for describing software behaviour, centred on Given-When-Then clauses. Designed to map directly to automated test steps.
Further Reading
See it in practice
The Specsight demo shows real scenarios, features, and a complete living product spec — generated from an actual codebase.