Architecture
How RegEngine is built
Service topology, data flow from ingest to export, tenant isolation model, and infrastructure posture. This page is written for IT reviewers and security teams evaluating RegEngine for procurement.
System flow at a glance
The core path keeps customer-owned source data, authenticated request context, PostgreSQL tenant controls, and export review boundaries visually separate. Optional processors sit outside the default core path unless they are enabled or configured for a workspace.
Source systems
ERP, WMS, and supplier data sent as CSV uploads or JSON events API calls
Customer-owned data quality
App and API edge
Next.js app, authenticated routes, and mediated API traffic
Session and request context
Ingestion service
FastAPI validation, mapping, coverage and completeness checking, and workflow orchestration
Server-side tenant context
Tenant database
PostgreSQL records, RLS policies, append-oriented evidence handling
Core data isolation layer
Evidence exports
FDA-oriented spreadsheets, EPCIS (Preview) and CSV packages, and manifests where configured
Customer review and archive
Service topology
This page describes the current service topology and intended control boundaries. Exact infrastructure details can vary by deployment and environment.
Current deployment posture uses a server-rendered React app with edge caching and proxy-based API routing so browser traffic is mediated before it reaches backend services.
Single consolidated Python service for CTE ingestion, JSON events API validation, CSV parsing, compliance coverage and completeness checking, exports, and alert generation. The services directories are code-organization boundaries, not separate default deploys.
Current database posture uses PostgreSQL tenant-scoping controls, append-oriented audit protections, and managed connection pooling.
Default active application/database hosting is US-based where configured. CDN, edge, AI, and object-storage processing locations vary by provider and executed DPA.
Data flow: ingest to export
The current product posture aims for a consistent five-stage pipeline from ingest to export, with integrity controls applied after validation.
CTE events arrive via CSV upload or the JSON events API. Both paths run validation synchronously and persist before coverage checks. EPCIS 2.0 is in Preview.
Raw event data is mapped to FSMA CTE/KDE structures. Lot codes, GLNs, and facility identities may be standardized, with exceptions or missing KDEs surfaced for review.
Validated events are SHA-256 hashed and chain-linked at ingest, scoped per tenant. Commit means accepted records are appended after checks you configure; this is not a certification. Independent verification of exported bundles is offered at /verify. Default deployments use PostgreSQL-backed task processing rather than a managed message bus.
The compliance engine produces an advisory coverage and completeness checklist across six weighted dimensions: export-checklist completeness, KDE completeness, CTE coverage, chain integrity, obligation coverage, and FTL product-list overlap. This is not a readiness score, not a badge, not an FDA or buyer decision. FTL overlap is list-membership, not a covered-person determination. Per-dimension maturity varies; rule enforcement is opt-in per workflow and is advisory in production today.
Compliance records may be exported in one or more supported formats such as EPCIS 2.0 (Preview), FDA-oriented spreadsheets, or CSV, depending on the enabled workflow.
Tenant isolation model
Isolation is intended to be enforced as close to the data layer as possible rather than depending solely on application logic.
PostgreSQL row-level policies and authenticated tenant context are designed and tested to restrict reads on core PostgreSQL-backed paths. Identity-resolution and graph-layer hardening is in progress; details available under NDA.
Integrity records are designed to remain tenant-scoped so one customer workspace does not depend on another customer's evidence chain.
API credentials and tenant context are intended to be scoped per customer workspace, with server-side mediation preferred over trusting raw client context.
Compliance records are append-oriented after ingest; in-place mutation is not the supported path. Audit-chain coverage across review and admin surfaces is being expanded.
Infrastructure controls
Need more detail? The security page covers RLS testing, hash verification, and audit trail posture.
Verify supported evidence export bundles yourself: drop a supported bundle into /verify.