SPEC-PRD-PRO · v0.14
2 July 2026
Owner: Platform team

Products — product requirements

A RiverSync device is one model in a product family, and the model determines the shape of the telemetry the device emits. This PRD makes device → product → telemetry structure an explicit, catalogued chain — and, for the nevera line, extends it to a configure-to-order reality: a unit is a chassis populated with modules under compatibility and capacity rules, and its configuration grows over its life. It consolidates the product-and-telemetry-taxonomy requirements that span Pipeline (quote lines), Portal & Field (devices) and the Devices domain.

1The chain in one paragraph

RiverSync products are organized into families (each with a product class), and each family holds one or more models. The model is a catalog entity — every device and every quote line references it, so a device's product identity is unambiguous. The frigo and koelkast lines are fixed-configuration models. The nevera line is different: a model names only the chassis (30U or 40U form factor), and each unit is configured from a catalog of controller and cooling modules under compatibility and capacity rules — so a device records its installed module loadout, not just a model, and that loadout grows over the unit's life. Separately, the fleet emits telemetry in several distinct shapes; the platform keeps a telemetry-schema registry, every model declares the schema family it speaks, and each device is classified to exactly one schema family + version as ground truth. The data model names these ProductFamily · ProductModel · TelemetrySchemaFamily · DeviceSchemaAssignment, owned by the Devices service (SVC-DVC).

2One product, several surfaces

The product model is curated in the catalog, configured and sold on a quote, attached to a device at provisioning, read on the device, expanded in the field, and resolved to a telemetry schema by classification. Each app touches the same catalog and the same configuration rules.

App	What it does with the product
Admin	Curates the catalog — families, classes, models, the module catalog and its configuration rules, and the telemetry-schema registry are RiverSync-managed reference data (PRO-1/2/3, PRO-8/9, LIF-4)
Pipeline	Sold as a configured quote — a nevera line is a chassis plus a valid module loadout, each item referencing a catalog SKU, never free text (PRO-2, PRO-7); rules are enforced before a quote can be issued (PRO-9)
Portal	The device reads its model + class and its installed loadout; capacity headroom and telemetry render in the shape its classified schema declares (PRO-4, PRO-10/11)
Field	The engineer sees the device's model and loadout on a visit, and adds or swaps modules as demand grows (the pay-as-you-grow visit); classification needs-review surfaces to RiverSync users (PRO-5, PRO-10)

3Comparing the three families

The catalog holds three product families, and they differ along two independent axes. The first — and the deepest — is configuration: frigo and koelkast are fixed sealed enclosures (§5), while nevera is configure-to-order and field-expandable (§6). This is the divide that shapes everything downstream — how a unit is quoted, what a device record carries, how it is serviced, and how much telemetry it emits. The second axis separates the two edge lines from each other: the compressor — frigo runs a fixed-speed screw, koelkast an inverter variable-speed that modulates cooling to live load (PRO-13). nevera's cooling is modular and multi-compressor, master-synchronised across its installed modules (PRO-11).

Read the table as a decision aid: choose the family by how the site's heat load behaves and grows, then choose the model within it (§2, §5, §6). Every claim below traces to a PRO requirement (§7).

Dimension
Class	edge micro data center		modular micro data center
Configuration	fixed · sealed enclosure (PRO-12)		configure-to-order · module loadout (PRO-7)
Compressor	fixed-speed screw	inverter variable-speed	master inverter + inverter / fixed modules
Models	Frigo 20 · 30	Koelkast 20 · 30	nevera-30 · nevera-40
Cooling	2,500 / 3,500 W	2,500 / 3,500 W	2,500 W base → 5,000 / 7,500 W
Field expansion	none — capacity is fixed at purchase		pay-as-you-grow · add / swap modules (PRO-10)
Controllers	single integrated controller		multi-controller — CM1V master + slaves (PRO-11)
Redundancy	— (single unit)		N+1 (30U) · N+2 (40U)
Telemetry schema	refrigeration family · single controller (PRO-14)		refrigeration family · N controllers (PRO-11)
Device record	model + serial		model + serial + installed loadout + headroom
Service visit	screw-compressor service (PRO-15)	inverter service (PRO-15)	service + expansion visits (PRO-10)

Where each family wins

frigo is the simplest and lowest-cost line to buy, model and operate. The fixed-speed screw compressor and sealed single-capacity enclosure mean a device carries only model + serial — no loadout, no headroom, no expansion visits (PRO-12). It is the right choice for a steady, well-known heat load where constant cooling output and mechanical simplicity matter more than part-load efficiency.

koelkast keeps frigo's fixed-configuration simplicity but replaces the screw with an inverter variable-speed compressor that modulates cooling to the live load (PRO-13). At part load it draws less power, cycles less and runs quieter — the energy-efficient edge choice for sites whose load varies through the day, at the same 20U / 30U capacity points as frigo.

nevera is the only scale-up line. It starts on a 2,500 W base module and grows in the field to 5,000 W (30U) or 7,500 W (40U) as demand rises — pay-as-you-grow, no upfront over-provisioning (PRO-7, PRO-10) — and its multi-module design carries N+1 / N+2 redundancy the sealed edge units cannot. It is the choice where capacity is uncertain, will grow, or needs redundancy; the cost is a richer device record and configuration rules the edge lines don't need (PRO-8/9).

4The product family badge — canonical identity

Each family carries an identity badge the way each app carries its pill and each agreement its tier chip. The badge draws what the requirements state: the family axis is the compressor (PRO-13) and nevera's identity is modularity (PRO-7/10) — one glyph idiom, the shared cabinet silhouette with the family's capability mark inside, on a frozen family hue. The chassis mirrors the maintenance-tier chip: flat solid plaque, 2px corner, hairline inner rim. Icon concept, chassis and hue were each explored and settled (v0.7–0.9); PRO-17 makes the badge mandatory wherever a family is named. Assets: apps/account/rs-family.css · rs-family.js. Hover any badge for its capability tooltip.

Badge	Glyph — what it encodes	Hue · token	Code
	Flat line in the cabinet — constant output of the fixed-speed screw compressor (PRO-13)	Steel blue · --fam-frigo	FR
	Modulating wave — the inverter varies compressor speed to the live load (PRO-13)	Inverter teal · --fam-koelkast	KK
	Module bays + grow mark — configure-to-order chassis that expands in the field (PRO-7, PRO-10)	Modular violet · --fam-nevera	NV

Anatomy & variants

Default chip = plaque + label. The compact chip serves dense tables and mobile rows; the icon-only plaque serves the tightest surfaces (the tooltip carries the name). The hover tooltip states the family's facts — class, compressor / cooling, models, capacity — so the badge is the one-stop answer to “what is this device?”.

Usage rules. The badge appears wherever a family is named — fleet tables, device heads, quote lines, covered-device lists; icon-only on the tightest surfaces. The hue is identity, never status — health stays on the status badge next to it. Both themes ship in the tokens; never restyle locally. Candidate to upstream to DS v2 as tokens/family.css alongside the tier chips.

5The edge micro data center lines — frigo & koelkast

frigo (“refrigerator”, Italian/Spanish) and koelkast (“refrigerator”, Dutch) are RiverSync's two edge micro data center lines — the established, fixed-configuration counterpoint to nevera. Each is a single sealed enclosure with a fixed cooling capacity set by its model: there is no module bay, no controller/cooling catalog and no field expansion. The two families share the edge class and the same capacity points; what distinguishes them is the compressor: frigo uses a fixed-speed screw compressor, koelkast uses an inverter variable-speed compressor that modulates cooling to load. Each line ships in two models — 20 and 30, where the number is the usable rack height (20U / 30U) with its paired capacity.

Only the 2nd-generation models are supported on the online platform (PRO-16): Frigo 20 / 30 and Koelkast 20 / 30. The 1st-generation capacity-named units (frigo 2500 / 3500, koelkast 4500 / 5500) are legacy and are not supported here — they do not onboard, classify or appear in the sellable catalog. No datasheet was provided for the 2nd-generation lines — spec-pending cells await one.

Model	Frigo 20	Frigo 30	Koelkast 20	Koelkast 30
Family	frigo	frigo	koelkast	koelkast
Generation	2nd generation — supported on the platform
Class	edge micro data center · fixed configuration
Compressor	fixed-speed screw		inverter variable-speed
Cooling capacity	2,500 W	3,500 W	2,500 W	3,500 W
Usable rack	20U	30U	20U	30U
Configuration	sealed, single-capacity — no module loadout, no field expansion
Controllers	single integrated controller per unit (contrast nevera multi-controller)
Telemetry schema	refrigeration family (the established 60-field shape)
Dimensions · weight · power	— spec pending (datasheet)

Frigo and Koelkast are capacity-paired — a 20 is 2,500 W / 20U and a 30 is 3,500 W / 30U in either family — so the choice between the lines is driven by the compressor behaviour (fixed-speed screw vs. load-modulating inverter), not by capacity. Because the configuration is fixed, a device record needs only its model + serial — no module loadout, no capacity-headroom tracking, no expansion visits. This is the simplification that makes the modular nevera record (§6, PRO-7…11) the exception rather than the rule, and it keeps the established fleet cheap to model.

What the refrigeration schema exposes. The established shape carries the readings the Portal renders on its device-detail multi-metric stack (PTL-1, SPEC-UIX-DEV §7.1): return-air · supply-air · ambient-air temperature, relative humidity, power draw and cooling COP, plus the enclosure's front · back · side door state (open/close) — a door held open past its 5-min threshold escalates to a door-open alarm. Nevera adds PUE, battery and bus voltage on top. The exact per-family field set lives in the telemetry-schema registry (PRO-3/6), not this table.

6The nevera modular platform

nevera ("refrigerator" in Catalan) is RiverSync's modular micro data center line. Unlike the fixed frigo / koelkast units, a nevera is a scale-up platform: it ships with a base cooling module and expands in the field as IT heat load grows — "pay as you grow", no need to invest up front for future capacity. The catalog must therefore model, beneath the model, a configurable product: a chassis, a module catalog, and the rules that bind them.

Two model axes only — the chassis form factor (30U / 40U usable rack). Everything else is configuration. Source: nevera datasheet v3.0 (2025-06-30); the system cooling maxima are the RiverSync-confirmed figures — 5,000 W (nevera-30) / 7,500 W (nevera-40), which supersede the datasheet spec-sheet table.

Chassis envelope	nevera-30 (30U)	nevera-40 (40U)
Form factor	19″ rack · 30U usable	19″ rack · 40U usable
Cooling capacity — base	2,500 W	2,500 W
Cooling capacity — max	5,000 W	7,500 W
Redundancy class	N+1	N+2
Max cooling modules	2	3
Max inverter modules	2	2
Drainage	Evaporative	Dry-up
Airflow · control · cloud	Front-back · touch screen · customer portal	Front-back · touch screen · customer portal
Dimensions (W×D×H)	785 × 1580 × 1600 mm	785 × 1580 × 2050 mm
Weight — empty / full	240 / 320 kg	300 / 420 kg

Every cooling module carries its own controller; one master controller (CM1V) synchronizes the slave controllers so the system actively balances cooling to live demand. A unit is therefore valid only as a set of modules within the chassis envelope — the module catalog & configuration rules below are what make a quote or a provisioning record legitimate.

§6 nevera modular platform · continued

Module catalog & configuration rules — nevera only

This subsection applies to the modular nevera platform only. frigo and koelkast (§5) are fixed-configuration and have no modules. Two module kinds, each a serial-tracked, priced catalog entity. SKU codes (CM1V, 2500V, …) are manufacturer identifiers — retained verbatim, not contractions to expand.

Controller modules

SKU	Role	Compressors	Rack	Weight
CM1V	Master	1× inverter	30U or 40U	15.2 kg
CS1V	Slave	1× inverter	30U or 40U	11.2 kg
CS1F	Slave	1× fixed	30U or 40U	4 kg
CS2F	Slave	2× fixed	40U only	8 kg
CSVF	Slave	1× inverter + 1× fixed	40U only	15.2 kg

Cooling modules

SKU	Compressor	Capacity	Coils E / C	Max power	Weight
3500V	Inverter	3,500 W · 12,000 BTU	6R / 2R	1,725 W	35 kg
2500V	Inverter	2,500 W · 9,000 BTU	6R / 2R	1,204 W	33 kg
3500F	Fixed	3,500 W · 12,000 BTU	6R / 2R	1,656 W	41 kg
2500F	Fixed	2,500 W · 9,000 BTU	6R / 2R	1,154 W	39 kg
2000F	Fixed	2,000 W · 7,000 BTU	4R / 1R	751 W	37 kg
1500F	Fixed	1,500 W · 5,000 BTU	4R / 1R	581 W	37 kg

All cooling modules: R134 refrigerant; shared module bay 425 × 307 × 89 mm. "V" = inverter compressor, "F" = fixed.

Configuration tiers (what each chassis ships and accepts)

Slot	Tier	nevera-30 (30U)	nevera-40 (40U)
Controller	Included	CM1V	CM1V
	Optional	CS1V · CS1F	CS1V · CS1F · CS2F · CSVF
Cooling	Included	2500V	2500V
	Upgrade	3500V	3500V
	Optional	2500V · 3500V · 2500F · 2000F · 1500F	2500V · 3500V · 2500F · 2000F · 1500F

7Requirements

8Model impact — alignment to do

PRO-7…11 introduce configurability that the current data model does not yet carry. Flagged here so the ERD / domain cascade is explicit; proposed entities below await their catalog turn.

Where	Change needed
ERD SPEC-ERD-PRO	New entities: ProductModule (catalog SKU, kind = controller \| cooling, attributes) · ConfigurationRule (per-chassis ceilings, redundancy, rack constraints) · DeviceModuleLoadout (the installed-module records on a Device, serial-tracked, time-bounded for swaps). Relate ProductModel (chassis) → allowed modules; add capacity-headroom derivation. ⚠ pending
Domain SVC-DVC	Devices service owns the module catalog and loadout; /products exposes modules + rules; a loadout change emits a past-tense event (device.loadout-changed) the audit trail consumes. ⚠ pending
Pipeline SPEC-APP-PIP	A quote line for nevera is a configured line (chassis + modules) validated against PRO-9 before issue; expansion quotes reference an existing device's loadout (PRO-10).
Field SPEC-APP-FLD	The pay-as-you-grow install/expansion visit records loadout changes against the device (PRO-10).
Prototypes	The canonical family badge (§4, PRO-17) is propagated to all six apps: Portal (FamilyChip · device cards, detail, device lines), Field (FamMark · visits, plans), Pipeline (leads, opportunity variants), Partners (devices, deals, quotes, closed, funnel, reseller/distribution scopes), Account (partner detail devices, provisioning) and Admin (shared ticket/schedule engine) — all composing apps/account/rs-family.js, never a local chip. Done.

9Open questions

• 1st-generation devices in demo data. The Field app demo data (apps/field/field-data.js) still lists 1st-generation capacity-named units (frigo 2500 / 3500, koelkast 4500 / 5500) with FIL-35 / FIL-55 filters. Per PRO-16 these are unsupported on the platform — refresh the demo fleet to 2nd-generation Frigo / Koelkast 20 / 30. ⚠ (PRO-16)
• 2nd-generation datasheets. No spec sheet was provided for the supported lines, so dimensions, weight, power draw, airflow and refrigerant are spec-pending (§5). Obtain them to bring the envelope to nevera parity. (PRO-12)
• Legacy cutover. How are existing 1st-generation units handled at onboarding — hard-rejected, or shown as “unsupported, upgrade required”? And is there a trade-in / replacement path to a 2nd-generation model? (PRO-16)
• Inverter telemetry fields. Does koelkast's variable-speed modulation need named refrigeration-schema fields (compressor Hz / duty) that frigo leaves null, or is it captured in existing fields? Confirm before the registry encodes it. (PRO-14)
• System max vs module sum. The confirmed system maxima (5,000 W / 7,500 W) sit below the arithmetic sum of the largest cooling modules (e.g. 3 × 3,500 W on a 40U); the capacity envelope (PRO-9) is the binding cap. Confirm how the 3,500 W modules are limited in a full multi-module config — derated, count-capped, or simply not combinable to the theoretical max. ⚠ (PRO-9)
• Module entities — when does the ERD cascade land? PRO-7…11 are stated as requirements but the catalog still models only ProductModel. Schedule the SPEC-ERD-PRO / SVC-DVC change (§8) — until then a nevera's loadout is requirement-only, not modeled. ⚠ (PRO-7, PRO-8)
• Configured-quote authority. Are module SKUs and configuration rules curated solely in Admin, or can a Pipeline deal propose a not-yet-catalogued combination for RiverSync to confirm? (PRO-9)
• Loadout history granularity. Does Portal need the full module-swap timeline per device (each add/swap, by whom, on which visit), or only the current loadout + capacity headroom? (PRO-10)
• Class beyond the three lines. frigo · koelkast · nevera are the lines today; does the class need to be an open catalog for future product lines, or a fixed enum?
• Schema discovery loop. When the quarantine bucket reveals a new repeating shape, who promotes it to a registered family — an automatic proposal to needs-review, or a manual Admin action? (PRO-5)
• Telemetry retention. What is the per-family retention horizon for the time-series store, and is it tier- or tenant-configurable? (PRO-6, PTL-1 ⚠)

10Revision history

Version	Date	Changes
0.14	2 Jul 2026	Comparison section repositioned to §3. The cross-family comparison (added v0.13) moved ahead of the product-line sections — new order: chain · surfaces · comparison · family badge · edge lines · nevera. Sections renumbered: family badge §4 · edge lines §5 · nevera §6 (Requirements §7 · Model impact §8 · Open questions §9 · Revision history §10 unchanged); internal cross-references updated. No requirement change.
0.13	2 Jul 2026	Family comparison section added (§6). New cross-family comparison of frigo · koelkast · nevera — the two differentiating axes (fixed vs modular configuration; fixed-speed screw vs inverter compressor), a dimension-by-dimension comparison table and a “where each family wins” advantages summary, all tracing to PRO-7…15. Sections renumbered: Requirements §7 · Model impact §8 · Open questions §9 · Revision history §10; the stale §4→nevera cross-reference corrected to §5. No requirement change.
0.12	2 Jul 2026	Refrigeration reading set documented (§4). Added the readings the established schema exposes — return / supply / ambient air, humidity, power, cooling COP and per-door (front · back · side) door state — as the set the Portal renders on the device-detail multi-metric stack (PTL-1, SPEC-UIX-DEV §7.1). Aligns the product doc with the stack prototype; exact fields remain in the schema registry (PRO-3/6). No requirement change.
0.11	2 Jul 2026	PRO-17 enforced platform-wide. The family badge now renders on every family/model surface across all six app prototypes — Portal · Field · Pipeline · Partners · Account · Admin (§7 Prototypes row) — via RSFAM.iconFor()/chip() and the React wrappers; rs-family.js gained iconFor(text) and a non-anchored fromModel. Cross-references landed in SPEC-APP-PTL v0.19 (§1 family table wears the badge; PTL-6 cites PRO-17); the badge mandate is recorded in the project + subtree working notes. No requirement change.
0.10	2 Jul 2026	Family badge promoted to §3 and streamlined. The badge definition moves ahead of the product-line sections (order: chain · surfaces · badge · edge lines · nevera · requirements) and now states only the chosen design — the settled exploration panels (v0.7–0.9) are folded into the prose. Sections renumbered: edge lines §4 · nevera §5 · requirements §6; two stale Model-impact references corrected to §7. Older revision entries reference the pre-move numbering. No requirement change (PRO-17 unchanged).
0.9	2 Jul 2026	Hue settled — dedicated --fam-* product hues are final. The §6 hue exploration is closed: the chart-ramp-derived and monochrome-neutral alternates removed after review. With icon (v0.7), chassis (v0.8) and hue now settled, the family badge definition is complete. No requirement change (PRO-17 unchanged).
0.8	2 Jul 2026	Chassis settled — the tier-idiom plaque chip is final. The §6 chassis exploration is closed: the tinted-chip alternate removed from the spec after review; the --tint variant dropped from rs-family.css/.js. Canonical variants remain default · compact · icon-only. No requirement change (PRO-17 unchanged).
0.7	2 Jul 2026	Icon concept settled — capability mark on the shared cabinet is final. The §6 icon exploration is closed: alternates B (bare capability glyph) and C (letterform monogram) removed from the spec after review; their glyph sets dropped from rs-family.js. Chassis and hue explorations remain recorded with their chosen directions. No requirement change (PRO-17 unchanged).
0.6	2 Jul 2026	Canonical product family badge (§6 added, PRO-17). Defines the family identity badge: capability-axis glyphs on the shared cabinet silhouette (frigo flat line · koelkast modulating wave · nevera module bays + grow mark), dedicated --fam-* hues, tier-chip chassis with compact / icon-only variants and a capability tooltip. Icon-concept, chassis and hue explorations recorded with the chosen direction. Assets apps/account/rs-family.css/.js; propagated to the Portal · Field · Pipeline · Partners prototypes (generic thermometer / snowflake / server icons retired). Master §6 in lockstep (SPEC-PRD v0.36).
0.1	27 Jun 2026	First draft — consolidates the product & telemetry-taxonomy requirements (PRO-1…6) from master SPEC-PRD §6 into their own cross-cutting PRD, alongside Federation and Maintenance.
0.5	27 Jun 2026	nevera confirmed cooling maxima. System cooling max set to the RiverSync-confirmed figures — nevera-30 5,000 W (30U usable) · nevera-40 7,500 W (40U usable) — superseding the datasheet spec-sheet table (7,000 / 10,500 W); resolves the v0.2 spec-sheet-vs-marketing open question. Chassis table, PRO-9 capacity envelope and §4 source note updated; new open question logs the system-max-vs-module-sum reconciliation. Master §6 in lockstep (SPEC-PRD v0.31).
0.4	27 Jun 2026	Generation correction — frigo & koelkast 2nd-gen model (PRO-13/14/15 revised, PRO-16 added). The supported models are the 2nd-generation Frigo 20 / 30 and Koelkast 20 / 30 (number = usable rack U: 20U·2,500 W, 30U·3,500 W); the family axis is the compressor (frigo fixed-speed screw · koelkast inverter variable-speed), not a capacity band. The 1st-generation capacity-named units (2500/3500/4500/5500) are legacy & unsupported online (PRO-16). Reverts the v0.3 capacity-naming; restores Frigo/Koelkast 20/30 as canonical across PRO-2 and the ERD catalog. Field demo-data refresh logged §8. Master §6 updated in lockstep (SPEC-PRD v0.30).
0.3	27 Jun 2026	frigo & koelkast documented (PRO-12…15). Added §3 the edge micro data center lines — both fixed-configuration sealed enclosures, capacity-named models (frigo 2500 / 3500, koelkast 4500 / 5500), refrigeration schema, model-banded service. PRO-2 amended to capacity naming; the legacy -20 / -30 codes are superseded (reconciliation logged §8). No datasheet for these lines — envelope cells marked spec-pending. Master §6 updated in lockstep (SPEC-PRD v0.29).
0.2	27 Jun 2026	nevera modular product model (PRO-7…11), from datasheet v3.0. Adds §3 the nevera modular platform (chassis envelope), §4 module catalog (5 controller + 6 cooling SKUs) & configuration rules, and §6 model-impact / ERD-domain cascade. PRO-2 amended — nevera model = chassis form factor; configuration sits beneath it. Master §6 updated in lockstep (SPEC-PRD v0.28); the SPEC-ERD-PRO / SVC-DVC module-entity cascade is logged ⚠ pending. Flagged the spec-sheet vs marketing capacity discrepancy.