Check FSMA 204 Readiness

Documentation Index

Fetch the complete documentation index at: https://docs.closient.com/llms.txt

Use this file to discover all available pages before exploring further.

​

When to use

• A brand owner needs to know “are we FSMA 204-compliant for batch X?” before the Jan 20, 2026 enforcement date — and afterward, every day.
• Before issuing a recall, audit which lots have enough KDE coverage to construct the FDA Sortable Spreadsheet export.
• A 3PL onboarding a new shipper needs to gap-analyze their KDE posture before contracting.
• Continuous-readiness dashboards.

​

Auth

​

Flow

​

Step 1 — Resolve GTINs to lots

GET /epcis/api/2.0/events?MATCH_anyEPC=https%3A%2F%2Fid.gs1.org%2F01%2F{gtin14}

​

Step 2 — Audit CTE coverage per lot

GET /epcis/api/2.0/events?MATCH_epc=https%3A%2F%2Fid.gs1.org%2F01%2F{gtin14}%2F10%2F{lot}

​

Step 3 — Audit KDE completeness per CTE

​

Step 4 — Compose a readiness score

score = (cte_coverage_pct + kde_coverage_pct) / 2

• cte_coverage_pct = (CTEs observed for the lot ∩ CTEs required for the food category) / required.
• kde_coverage_pct = (KDE fields populated across captured CTEs) / expected KDE fields across those CTE types.

​

Required inputs

• gtin — GTIN-8 / 12 / 13 / 14 (server zero-pads shorter forms).
• lot (when scoping to a specific batch).

​

Optional inputs

• food_category — to pick the correct CTE checklist. Closient infers this from Product.product_category when it’s set.
• date_range — bound the audit to a recent window (e.g. last 365 days of shipments).

​

Output

[
  {
    "gtin": "00614141123456",
    "lot": "LOT-2026-042",
    "food_category": "leafy_greens",
    "cte_coverage_pct": 0.83,
    "kde_coverage_pct": 0.71,
    "score": 0.77,
    "missing_ctes": ["COOLING"],
    "missing_kdes": {
      "HARVEST": ["growing_area"],
      "INITIAL_PACK": ["reference_document"]
    },
    "links": {
      "capture_missing": "https://www.closient.com/compliance/lots/<lot_short_id>/capture",
      "fda_export": "/epcis/api/2.0/traceability/lots/<lot_short_id>/fda-export"
    }
  }
]

​

Guidance for agents

• Run the audit on the materialized CTE table, not raw events, where you can. The CriticalTrackingEvent model (see apps.epcis.models) is the authoritative source of CTE rows — EPCIS events that didn’t produce a CTE (because the bizStep isn’t FSMA-relevant) are noise for this audit. The /traceability/lots/{lot_id}/fda-export endpoint already does this filtering; reading its 202-pending response tells you which CTEs exist for the lot.
• Don’t conflate “lot exists” with “lot is ready”. A lot with zero EPCIS events is 0.0 readiness, not “no data”. The product exists in the catalog; FSMA 204 requires CTEs.
• Lock-state matters. Once a ProductLot has been used in a CTE, its LOCKED_FIELDS (lot code, harvest dates, expiration) are immutable. Don’t propose a fix that requires editing those fields — instead, the agent should surface a “capture a corrective event with the missing KDE in ILMD” workflow (calls capture-epcis-event with the right bizStep + ilmd block).
• Audit BY ORGANIZATION’s role in the chain. A brand owner who only packs (not harvests) is not on the hook for HARVEST KDEs — those belong to the grower upstream. The CTE checklist in Step 2 is conditional on the org’s role; for a packer-only, only INITIAL_PACK + SHIP are owed.
• Surface the fix path, not just the gap. A missing growing_area KDE on a HARVEST event is fixable by capturing a corrective bizStep=harvesting event with the right cbvmda:growing_area — hand the agent the exact endpoint and JSON shape it needs.
• Don’t recompute on every page render. When the dedicated endpoint ships, it will cache the per-(GTIN, lot) score for a short TTL. Until then, audits cost ≥ 2 EPCIS queries per lot — batch them.

​

Known gaps (planned)

• No dedicated readiness endpoint. The /compliance/api/v1/products/{gtin}/fsma204-readiness endpoint called out in the ticket scope does NOT exist today. Filed as a follow-up: a real endpoint that walks CTE + KDE coverage and emits the structured shape above, with a 60s server-side cache. Until then, agents must compose the audit from GET /epcis/api/2.0/events queries as described above.
• No food-category-aware CTE checklist on the server. The expected-CTE-by-FTL-category table lives in this skill doc rather than as a server-side rule. When the readiness endpoint ships, the checklist will move to the server and the skill will reference it by URL.
• No bulk-GTIN readiness scan. Agents auditing dozens of GTINs have to fan out queries. A bulk endpoint (POST /compliance/api/v1/fsma204-readiness/scan taking a GTIN list) is planned for the FSMA dashboard refactor.
• Trading-partner KDE coverage is not enforced. The audit assumes SHIP/RECEIVE CTEs already have a resolved TradingPartner destination; if the event captured but the partner GLN couldn’t be resolved, the CTE row exists with trading_partner=NULL and is silently 100% on the KDE rubric. A separate “trading-partner resolution” health check is filed.
• No historical-snapshot scoring. The audit is point-in-time (current state of the ledger). FSMA 204 § 1.1455(c) responses require historical snapshots (“what KDEs did you have on date X”), which is reconstructable from the immutable event ledger but not yet surfaced as a first-class query.

​

Related skills

• capture-epcis-event — the corrective-action surface; agents capture missing-KDE events to close gaps surfaced by this audit.
• query-epcis-events — the underlying read used by this audit until the dedicated endpoint ships.
• manage-recall — pre-recall sanity check; only issue recalls on lots whose readiness score is high enough to compose a defensible FDA Sortable Spreadsheet.
• check-recalls — consumer side of recalls; orthogonal to readiness but reads the same CTE ledger.