Streams as Product Lifecycles
How Products Move Through Time, Change, and Accountability
Products do not exist as static constructs. From the moment a product is conceived until it is retired, it moves through a sequence of states, decisions, and outcomes. These movements form the product lifecycle, and within a digital, product-centric architecture this lifecycle is expressed through streams. Streams are not arbitrary data flows; they are the structured, time-ordered expressions of how a product lives, changes, and remains accountable over time.
Streams as Temporal Structure
A stream represents the ordered progression of events and actions within a single product. It captures how intent becomes execution and how execution becomes record. Unlike generic process flows that can be reused across contexts, a stream is always bound to exactly one product. It exists because the product exists and has no meaning outside that product boundary.
This strict binding is intentional. It ensures that every action, decision, or output can be interpreted in relation to the product that authorised it. In this sense, streams provide the temporal dimension of a product: they show what happened, when it happened, and under which authority.
Lifecycle Over Process
Traditional systems often model processes as reusable, cross-cutting workflows. While efficient on paper, this approach obscures accountability. When processes are shared across products, it becomes unclear which rules applied, which participants were involved, or why a particular outcome occurred.
Streams reverse this logic. They model the lifecycle of a product, not a generic process. Each stream step corresponds to a lifecycle state such as initiation, assessment, decision, execution, review, or termination. The same conceptual step in another product is represented by a different stream, because the meaning, rules, and consequences differ.
This design makes products traceable and recoverable. When questions arise, the answer is not hidden in a system-wide process log but visible in the product’s own stream.
One Product, One or More Streams
A product may have one or multiple streams, depending on its nature. A simple product may follow a single, linear stream from start to finish. More complex products may contain parallel or conditional streams—for example, a main execution stream and a review or exception stream.
Crucially, streams do not relate to each other directly. Their only shared reference is the product to which they belong. This prevents hidden dependencies and ensures that the lifecycle remains intelligible. Coordination happens at the product level, where rules and meaning are defined, not between streams themselves.
Streams as Carriers of Change
Change is inevitable. Regulations evolve, circumstances shift, and products must adapt. Streams allow products to change without losing history. Each stream step records not only the outcome but also the context in which it occurred: the applicable rules, the responsible actors, and the information used.
This makes it possible to distinguish between:
- what was correct at the time,
- what has changed since,
- and how those changes affect future actions.
Streams therefore support learning and improvement. They make evolution visible and manageable rather than disruptive.
Automation Within Boundaries
Streams are where automation operates. Tasks may be executed by humans, systems, or AI agents, but always within the constraints defined by the product. Because streams are structured and contextual, automated actions remain explainable. Every automated step can be traced back to a product rule, a lifecycle state, and an authorised transition.
This is essential for trust. Automation that cannot be explained undermines legitimacy. Streams ensure that automation remains a servant of the product, not its replacement.
Streams as the Memory of a Product
Ultimately, streams form the memory of a product. They tell its story from creation to completion. They allow participants to understand how value was delivered, why decisions were made, and how obligations were fulfilled.
By treating streams as product lifecycles rather than generic workflows, organisations gain clarity, resilience, and control. Products remain coherent over time, even as they move, change, and evolve.