GPSR Compliance Templates & Validation

Paid pluginsize Midea, not a commitment

Indicative price, not an offer: €19.99-39.99/mo per vertical, or €49.99/mo for all verticals — owns the per-country, per-category obligation

Generated from docs/plan/paid/gpsr-compliance-templates-validation/PLAN.md in the project's planning notes, which are not part of the public repository. Nothing described below is implemented — it is the written plan for it.

An idea, not a commitment. It has a written plan but no place in the build order and no date. What is committed.

This plan takes over all or part of GPSR product safety and traceability fields, an entry merged into it.

Paid — commercial track · Catalogue & product data · size M Status: planned, not built.

Paid extension that provides GPSR templates, category-specific checklists, and automated validation for product safety metadata. Maintains expert-curated GPSR rules per product category (optics, automotive, food, electronics, toys) and per country, validates that a product’s stored metadata matches its category’s mandatory fields, and generates compliance audit reports. Merchants pay per vertical or for all verticals; this is where AstroBaaS owns the per-country obligation.

The problem

GPSR compliance requirements vary dramatically by category (optics need Rx rules, automotive need crash specs, food need allergen disclaimers). A merchant selling across categories cannot build category-specific checklists or validate product data without expert help, risking regulatory fines and delisting.

What it does

• Define GPSR templates per category (optics, automotive, food, electronics, toys, other) with mandatory fields, optional fields, and validation rules
• Store per-country rule overrides (e.g., importer required in EU, not in non-EU)
• Validate product safety metadata against its assigned category’s template, returning pass/fail + list of missing mandatory fields
• Batch validation: scan all products, report how many pass, how many fail, and which fail and why
• Generate compliance audit report (CSV/PDF) showing product name, SKU, category, validation status, and gaps
• Assign product to GPSR category in admin UI (dropdown, default ‘other’)
• Webhook on product change: re-validate against template, warn merchant if newly non-compliant
• Dashboard widget: ‘23 of 450 products non-compliant; review optics category (15 gaps)’
• Per-merchant country setting: filter templates and validation rules to that country’s laws
• Export compliance data with audit trail (who assigned category, when, validation status history)
• Category templates are read-only for merchants; AstroBaaS maintains them via plugin or admin panel
• Email alert when a product becomes non-compliant or a template rule updates

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Regulatory consulting — templates are baseline; merchant remains responsible for accuracy and completeness
• Automatic remediation — the system alerts and reports; merchant must fix the product data
• Integration with national regulatory databases — that requires per-country credentials and ongoing sync
• Physical inspection or lab testing — core validates stored data structure only, not whether optics actually have the Rx they claim

Data model

New entities: gpsr_category (name, description, mandatory_fields: string[], optional_fields: string[]), gpsr_rule (category, country_code, field_name, rule_type, rule_value, is_mandatory: boolean), product.gpsr_category (string, foreign key to category.id). New fields on product if using the extended schema: gpsr_last_validated_at (timestamp), gpsr_validation_status (‘pass’ | ‘fail’ | ‘unknown’), gpsr_missing_fields (string[]). No migration required for existing products (they default to category=‘other’, status=‘unknown’).

API

• GET /gpsr/categories — list all GPSR categories and their mandatory/optional fields
• GET /gpsr/categories/:category_id/rules?country_code=DE — get validation rules for a category+country
• POST /gpsr/validate/product/:id — validate a single product, return status + gaps
• POST /gpsr/validate/batch — validate all products, return pass/fail counts and failed product list
• PUT /products/:id — accept gpsr_category assignment
• GET /gpsr/compliance-report — generate audit report (CSV or PDF), optionally filtered by category or validation status
• POST /gpsr/rules — create/update a GPSR rule (admin only, or paid-plugin owner)
• GET /gpsr/audit-log — compliance changes over time (category assignments, validation results)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Admin panel gains ‘GPSR Compliance’ section with: (1) Category selector in product edit, (2) Compliance dashboard showing pass/fail counts per category, (3) Batch validation button (‘Revalidate all products’), (4) Compliance report builder (download as CSV/PDF), (5) Category template viewer (read-only), (6) Webhook settings for re-validation on product change. A merchant can filter products by validation status and export the non-compliant list.

The seam — why this is paid

Paid tier owns the templates, the rules, the validation logic, and the audit reporting. Core owns the product.gpsr_category field and the underlying product-update webhooks that trigger re-validation. The seam is the webhook: core emits ‘product.updated’; the paid plugin subscribes and runs validation. A merchant without the paid tier can manually assign categories and call the public product API, but gets no templates, validation, or alerts.

a paid pack owns the per-country obligation — we maintain GPSR templates per category (optics, automotive, food, etc.), validate merchant product data, and provide audit trails.

Dependencies

• gpsr-product-safety-metadata (core tier must exist; this builds on it)
• product-management (extends product model)
• webhook-system (to trigger re-validation on product updates)
• plugin-system with hooks (paid tier runs as a plugin)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A product assigned to category=‘optics’ with no prescription_type field fails validation against the optics template with gap=‘prescription_type_required’
• A product in category=‘food’ in country=‘US’ is validated differently than the same product in country=‘FR’ (templates are per-country)
• POST /gpsr/validate/batch returns { pass: 450, fail: 23, failed_products: […] } with details on each failure
• Changing a product’s category from ‘automotive’ to ‘food’ triggers re-validation and updates gpsr_validation_status
• A compliance report for ‘optics’ category shows only optics products, sorted by validation status
• Merchant without the paid plugin can still assign a category and see validation status ‘unknown’ (no validation runs)
• Updating a GPSR rule (e.g., making importer_name mandatory in EU) re-validates all affected products in that country
• An email alert is sent when a previously-compliant product becomes non-compliant after a rule update

Risks

Rule updates can suddenly mark many products non-compliant; a poorly-timed rule change (e.g., right before a merchant’s busy season) causes support load. Templates are maintained by AstroBaaS; if a template is wrong or outdated, merchants following it will still fail actual compliance. Validation reports are advisory; a merchant may ignore them and sell non-compliant products, exposing both merchant and AstroBaaS to liability if an issue surfaces.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and CONTRIBUTING.md for how to work on this repository.