Skip to content
Product Walkthrough

The FDA gives you 24 hours.
Here's how the response works.

A step-by-step walkthrough of an illustrative FDA records-request scenario, from messy supplier data to a hash-manifested response package anyone can re-check.

  • 24-hour deadline
  • Hash-manifested package
  • Blocking defects surfaced
  1. T+0:00

    FDA request arrives

    The FDA sends a records request under 21 CFR 1.1455: provide all traceability records for the implicated lots, from farm to retail, within 24 hours.

    This is an illustrative scenario. Under §1.1455(c), the FDA can request records for products on the Food Traceability List, and you must produce a sortable electronic spreadsheet within 24 hours. Real timing varies by completeness of upstream supplier data.

  2. T+0:02

    Request case created in RegEngine

    An operator creates a Request Case, scoping the affected lots, products, and facilities. RegEngine identifies the in-scope traceability events across the affected suppliers and facilities.

    The system searches canonical records by lot code, product, and facility reference. Events from different suppliers and source systems are already normalized into a common schema.

  3. T+0:05

    Data quality gaps surface

    The rules engine evaluates each in-scope event against the FSMA 204 validation rules and separates passes, warnings, and blocking defects.

  4. Blocking defects found

    Missing required KDE: cooling_date
    Identity conflict between two supplier name variants at or above the match threshold, unresolved
    Invalid unit_of_measure: "bushels" not in FSMA standard units

    Export build is blocked until defects are resolved or waived

  5. T+0:15

    Exception cases created

    Each blocking defect becomes an Exception Case with severity, owner assignment, and remediation guidance. The operator sees exactly what needs fixing and why.

    Exception cases track resolution status, signoffs, and waiver history. Nothing gets swept under the rug: every decision is recorded in the audit trail.

  6. T+1:00

    Operator resolves defects

    The cooling_date is recovered from the supplier ERP and added. The identity conflict is merged (confirmed same entity). The invalid unit is corrected from "bushels" to "cases" with a documented reason.

    Each resolution is signed by the operator and timestamped. The rules engine re-evaluates affected events automatically. Stale evaluations are detected and re-run.

  7. T+1:30

    All defects resolved, submission unblocked

    The blocking defect check runs again: 0 blocking defects remain. The package can now be assembled.

    RegEngine checks 7 blocker categories: critical rule failures, unresolved exceptions, unevaluated events, missing signoffs, identity ambiguity, stale evaluations, and deadline monitoring.

  8. T+1:35

    FDA response package assembled

    The operator clicks "Assemble Package." RegEngine generates an immutable, SHA-256 hashed package containing the in-scope records, rule evaluations, exception resolutions, and a manifest listing each file's hash.

    PackageImmutable once assembled
    SHA-256 manifestIncluded with the package
    FormatFDA 21 CFR 1.1455 sortable spreadsheet + EPCIS 2.0 JSON-LD (Preview)
  9. T+1:40

    Package submitted to FDA

    The package is submitted with a recorded submission method, recipient, and timestamp. The request case moves to "submitted" status.

    The SHA-256 manifest lets the FDA or your auditor check that the package files still match the manifest packaged with them. The verify_chain.py script can independently re-run that check. It is a self-consistency check, not a signature: the manifest is not signed, so it does not by itself establish who produced the package. Downstream message-bus signature verification is rolling out and not yet strict-mode by default.

You cannot submit if:

RegEngine surfaces these checks at package assembly time. Rule enforcement is configurable per workflow. In production today, rule failures are recorded as exceptions and surfaced in the dashboard rather than blocking ingest.

Required KDEs are missing

cooling_date, reference_document, tlc_source_reference

Identity conflicts are unresolved

Supplier name matches >=85% but not confirmed

Events have not been evaluated

Newly ingested records not yet run through rules engine

Required signoffs are missing

QA manager approval not recorded

Evaluations are stale

Event amended after last rule evaluation

Deadline has been breached

Response window expired (24 hours from request)

You can proceed if:

Non-critical warnings remain, issues have been waived with documented reason and approver, or all blocking defects are resolved.

This is what RegEngine does.

It takes messy, inconsistent supplier data and turns it into an FDA-oriented sortable records-on-request workflow for operator review. Nothing more. Nothing less.

Become a Founding Design PartnerSee Security Details

See the underlying transformation step by step at /proof/transformation.