Organisation Product Database | Knowledge Base

Overview

A centralised product data store shared across all users within an organisation. Product records are entered once and made available to every tool in the platform that requires product parameters. This eliminates repeated data entry, ensures consistency across tools and users, and creates a single source of truth for each product in a manufacturer’s or consultant’s portfolio.

User Stories

As a manufacturer with 4 products, I want to upload my product data once and have it available to all my team members across all platform tools so we don’t each re-enter the same parameters. As a consultant, I want to maintain a product database covering all my clients’ products so I can select any product and run a simulation without re-entering parameters each time. As an organisation admin, I want to control who can add, edit, or delete product records so that data integrity is maintained. As a user running a simulation, I want to select a product from the database and have all parameters pre-filled so I can go straight to running the tool. As a user, I want to see the compliance status of each product at a glance so I know which registrations are current and which need attention.

Organisation and Access Model

Organisation definition:

An organisation is created when a user registers with a corporate email domain and activates an organisation account Subsequent users registering with the same email domain are prompted to join the existing organisation Domain-sharing is not automatic: it must be activated by the first user (who becomes the org admin) and accepted by joining users Personal email domains (gmail, outlook, hotmail, yahoo, and similar) are not eligible for domain-based organisation sharing. the developer to implement a blocklist of common personal domains; Alastair to review the list before launch.

Roles within an organisation

Admin: can add/edit/delete product records, manage users, configure organisation settings Editor: can add and edit product records, cannot delete, cannot manage users Viewer: can select products from the database to use in tools, cannot modify records

Consultant model

EnergyAE operates as a consultant managing products on behalf of multiple manufacturer clients The product database should support tagging each product record with a client name so the database can be filtered by client This is a consultant-specific feature; standard manufacturer organisations do not need client tagging

Product Record Structure

Identity fields:

Brand name Model number (primary key for deduplication) Product display name Product category: residential HPWH / commercial HPWH / other Tank volume (litres) Target market: AU / NZ / both Refrigerant type Product status: active / discontinued / in development Client tag (consultant organisations only, nullable)

Performance data

Source: linked 5125.1 report record (from the 5125.1 Analyser feature) or manually entered COP vs ambient temperature: table of data points (minimum 3 points covering low/mid/high ambient) Heating capacity vs ambient temperature: table of data points Power input vs ambient temperature: table of data points These fields auto-populate when a 5125.1 report is linked; manual entry available as fallback

Simulation parameters

Tank characteristics: volume, insulation loss coefficient, node count for simulation HP operating range: minimum and maximum ambient temperature Boost element: power (kW), position, enable/disable Control settings: setpoint, cut-in differential, boost activation conditions These are editable independently of the test report to support modelling of variants

Compliance records (one per scheme registration)

Scheme: VEU / ESS / SRES / NZ (EECA) / other Registration number Registration date Expiry date (if applicable) Registration status: active / expired / pending / not registered Certificate document (attached PDF)

Documents

5125.1 test report PDF (linked from analyser or uploaded directly) Product datasheet Certificate of conformity Scheme registration certificates Other (user-labelled) All documents stored with upload date and uploader name

Metadata

Created by Created at Last modified by Last modified at Record version number

Versioning

When any core parameter field is edited, the system creates a new version of the record rather than overwriting Previous versions are accessible via a version history panel on the product record All simulation runs, MEPS sessions, and 5125.1 analyses reference the specific version of the product record used at the time Users are notified when a product record they have used in a previous session has been updated, with a prompt to re-run if desired Deleting a product record is a soft delete: record is archived, not removed, so historical references remain valid

Integration With Other Platform Tools

This is the core value of the feature. Every tool that currently asks for product parameters should instead offer a product selector as step one.

Performance simulator

“Select product” dropdown at the top of the input form
On selection: all simulation parameters pre-fill from the product record
User can override individual fields for a specific run without modifying the master record
Run is logged against the product ID

MEPS estimation tool

Same pattern: select product, parameters pre-fill, overrides allowed per session “Upload 5125.1 report” route now offers to link the extracted data to an existing product record or create a new one

5125.1 report analyser

After extraction and review, user prompted: “Save to product database?” with option to create new record or update existing Extracted performance data populates the performance data fields

RAG chatbot

User can optionally select a product to provide context: “Answer questions about this product” mode Chatbot can reference the product’s compliance status and registration details when answering scheme-related questions

News feed

If a product has AU registrations, prioritise AU regulatory news If NZ only, prioritise NZ news Based on product market field in the database

Product Database UI

Main view

Card or table view toggle (user preference)
Each product shows: brand, model, tank volume, market, compliance status summary (green/amber/red), last modified date
Filter by: market, category, compliance status, client (consultant orgs), product status
Search by brand or model number
“Add new product” button (editors and admins only)

Product detail page

Tabbed layout: Overview / Performance Data / Simulation Parameters / Compliance / Documents / Version History Edit button opens inline editing for each section “Use in tool” shortcuts: buttons linking directly to each platform tool with this product pre-selected Compliance status section shows a traffic-light summary per scheme with days-to-expiry where applicable

Compliance dashboard (organisation-level view)

Separate view showing all products and their compliance status across all schemes in a matrix Highlights: expired registrations, registrations expiring within 90 days, schemes where no registration exists Exportable as a summary table

Out of Scope (v1)

Automated compliance expiry notifications (email alerts) - v2
API access to product database for external integrations
Public product directory or shared cross-organisation data
Bulk import of multiple products via CSV (v2 - useful for seeding but not critical for launch)
Integration with scheme administrator portals for registration status verification

Data Model (indicative)

organisations table:

org_id org_name email_domain org_type (manufacturer / consultant / other) created_at domain_sharing_active (boolean)

org_users table:

user_id org_id role (admin / editor / viewer) joined_at

products table

product_id org_id current_version model_number brand display_name category tank_volume_l market refrigerant status client_tag (nullable) created_by created_at

product_versions table:

version_id product_id (foreign key) version_number parameter_snapshot (JSON blob of all fields at this version) modified_by modified_at change_summary (auto-generated or user-entered)

product_compliance table:

compliance_id product_id scheme registration_number registration_date expiry_date status certificate_document_id

product_documents table:

document_id product_id document_type filename storage_url uploaded_by uploaded_at

Acceptance Criteria

Open Questions

Should the platform support a manufacturer inviting a consultant (e.g. EnergyAE) to access their product database, without the consultant being a member of the manufacturer’s organisation? This would allow a manufacturer to grant EnergyAE read access to their records. Useful but adds access model complexity - consider for v2. Bulk CSV import for seeding historical product data: not in v1 scope, but Alastair should define the CSV schema now so historical data can be prepared in parallel with the build. What constitutes a “core parameter” change that triggers a new version vs a minor edit (e.g. fixing a typo in the display name) that doesn’t? Define this rule before the developer builds the versioning logic. Should the compliance expiry dashboard be visible to viewer-role users, or editors and admins only? For consultant organisations: should client-tagged products be completely invisible to users without that client tag, or visible to all org users but filterable? Relevant if EnergyAE ever has staff who work on only some clients.