STREAM rebuild — solution specification

This docs/ set is the outcome-driven solution specification for the STREAM rebuild, called for in ../MANIFEST.md. It is authored from the canonical strategy document (../README.md), which remains the single source of truth for vision, history, and the original product’s mechanisms.

Note on naming: docs/ (this set, the forward-looking rebuild spec) is distinct from ../history/ (the preserved original reference material, including the 2016 manuals under ../history/Doc/). docs/ is intent; history/ is historical reference.

The artifacts

The specification is built in three layers, each grounding the next:

#	Document	Status	Purpose
0	`analysis-progression.md`	Draft	Narrative trail: original product → 2026 market → the flaw → repositioning → problem. Written to be shareable with the original Stream team.
1	`problem-definition.md`	Draft	Who hurts, how, why now, and why existing tools don’t fix it.
2	`solution-definition.md`	Draft	What STREAM does about it, and the shape of the answer. Tech decisions deferred to requirements.
3	`requirements.md`	Draft	Outcome-driven: user scenarios + the outcome requirements they exercise + MVP. Implementation/tech deferred to architecture.
4	`architecture.md`	Draft	The how: mechanisms + four decisions. Transform language decided (TypeScript); persistence, hosting, identity & access pending.

Derived artifacts (cut across the layered set rather than sitting in the chain):

discussion-pack.md — a standalone, plain-English catch-up distilling the set above, written to re-engage the advisors, early testers and prospective customers who took an interest in STREAM a decade+ ago (many haven’t seen it since), and to surface where their perspective would help.
lean-canvas.md — a market-viability lens over the whole set: the nine Lean Canvas blocks, a rough market sizing, and a ranked list of the riskiest assumptions to test (willingness-to-pay, pain acuteness, re-education cost). Problem/solution/customer blocks are drawn from locked decisions; the commercial blocks are flagged ⚠️ as unvalidated leans.

Decisions locked so far

These were settled through analysis (June 2026) and anchor everything below:

Strategic shape: a reconciliation & assurance layer — continuous, reversible, provenance-true identity merge/split plus interpretation skinning. Explicitly not document-extraction (à la DIGATEX) and not a class library (à la Datum360, now Autodesk). Extraction tools and class libraries are inputs, not the product.
Beachhead: Australian water — the tier below the metro majors: regional urban water corporations and council-run utilities (e.g. Victoria’s Coliban Water, Barwon Water, North East Water; NSW’s 89 council Local Water Utilities such as Central Coast and Tamworth Regional; TasWater). Targeting brownfield assets already in service whose own data quality is unknown, not greenfield handover.
- Initial GTM focus — South-East Queensland (warmest near-term access): the SEQ providers, starting with the council-run City of Gold Coast and the distributor-retailers Urban Utilities and Unitywater (with Seqwater as the bulk-water authority above them). Rest of the tier is the expansion path.
Dropped: mid-tier private industrial (examined and set aside — nearer the incumbents’ core, no regulatory forcing function).
Transform & rules language: TypeScript (decided June 2026) — no custom DSL; the old Fluid DSL is retired, with its domain primitives provided as a typed STREAM SDK. (Other architecture decisions — persistence, hosting, identity & access — remain pending; see architecture.md.)