Trust Center

Operational realities

• Source-system fields must be mapped into FSMA CTE and KDE structures.
• Lot codes, GLNs, product IDs, and facility identities have to be normalized.
• Missing KDEs and conflicting facility matches still require human review.
• Cryptographic hashing provides tamper-evidence after ingest, not proof of upstream data entry.

Retention and support boundaries

• Customers should schedule recurring exports and maintain off-platform archives from day one.
• Public support windows are not a substitute for recall-readiness operations.
• Premium escalation and SLA terms are contractual, not implied by public pricing copy.
• Security and diligence materials are a mix of public pages and request/NDA workflows.

Tenant isolation, tamper-evidence posture, disclosure path, and infrastructure controls.

FSMA-first topology, service boundaries, and where RegEngine sits in the stack.

Subscription retention, external archive expectations, and recurring export posture.

Response windows, emergency recall escalation path, and enterprise escalation handling.

US-configured core posture, provider-specific locations, and subprocessor details available on request.

Approved security diligence materials are available under request or NDA when applicable. RegEngine does not currently claim completed third-party penetration testing.

• GS1 EPCIS 2.0 JSON-LD (Preview, industry standard)
• FDA-oriented sortable spreadsheet aligned to 21 CFR 1.1455 where applicable
• CSV with all CTE/KDE fields
• Audit evidence bundle with manifest hashing

• Supported evidence workflows can hash and chain-link accepted events
• Timestamped manifests are generated where the configured export workflow supports them
• Public verification endpoint at /verify
• Legacy Kafka-compatible signing exists for opt-in deployments; the default deployment uses PostgreSQL-backed task processing instead of a managed message bus

• Export cadence can be scoped per deployment
• Archive delivery may use object storage or downloadable bundles
• Manifest hashing is part of the intended export posture
• Monitoring and retry behavior depend on the configured delivery path

• Per-CTE-type required KDE validation (7 CTE types)
• GLN format and GS1 check-digit verification
• Rejects events more than 24 hours in the future or more than 90 days old (configurable)
• Unit of measure validation against FSMA 204 standard units
• Location requirement validation per CTE

• Missing required KDEs trigger event rejection with detailed error messages
• Obligation-gap alerts are surfaced asynchronously; rule enforcement is configurable per deployment and is advisory in production today
• Batch deduplication prevents duplicate CTE submissions
• Rejected events returned with status and actionable error detail

• Per-supplier KDE completeness tracking
• Submission history retained for review
• Specific scoring and alerting features ship per workspace configuration

• Six weighted signals: export readiness (30%), KDE completeness (25%), CTE coverage (15%), chain integrity (10%), obligation coverage (10%), FTL product coverage (10%)
• Calculated from data in the active workspace
• Internal readiness signal, not an FDA endorsement

• FDA Final Rule: Requirements for Additional Traceability Records (21 CFR Part 1, Subpart S)
• Original compliance date: January 20, 2026; FDA has proposed a 30-month extension and Congress directed FDA not to enforce before July 20, 2028
• Food Traceability List (FTL): reviewed against FDA publications current as of April 1, 2026
• FDA Q&A draft guidance: February 2026; FAQ updates reviewed June 2026

• Validation rules are versioned and reference the underlying FDA guidance
• Compliance logic changes are documented in the changelog
• FTL category definitions are reviewed against current FDA publications
• Customers are responsible for confirming their own regulatory interpretation