DEV Community: Hanieh Khanmohamad

Designing a Food Traceability Event Model That Survives Real-World Handoffs

Hanieh Khanmohamad — Tue, 10 Nov 2026 11:42:10 +0000

A dashboard that says “shipment delivered” is not a traceability system. During a food recall, the useful questions are much harder: Which ingredient lots were combined into this finished batch? Where did those transformations happen? Which customers received the affected products?

A system can answer these questions without requiring an elaborate blockchain or a large data platform. What matters first is a trustworthy model of events and relationships.
An event is not a current inventory balance
An inventory table tells you what you believe is in a warehouse now. A traceability event records something that happened to a product or lot at a particular time and location.

The GS1 EPCIS standard describes visibility data using events that help answer what, when, where, and why. EPCIS 2.0 also supports contextual observations such as temperature. In practice, partners need a shared vocabulary as much as they need a shared API.

For a minimal prototype, begin with six event categories:

Created — a production or receipt lot is assigned an identity.
Packed — units are grouped into cases, pallets, or containers.
Shipped — custody moves from a defined location.
Received — another location acknowledges the movement.
Transformed — one or more input lots become one or more output lots.
Disposed — stock leaves the usable chain through destruction or another recorded disposition. These are illustrative application events, not an exhaustive or official list of EPCIS event types or of the FDA's Critical Tracking Events. Start with a small, explicit record Here is an intentionally simplified event. It is not an EPCIS-compliant JSON document. A production integration should adopt the official GS1 data model and controlled vocabularies. { "event_id": "evt-2026-0114", "event_type": "received", "occurred_at": "2026-11-09T08:42:00Z", "lot_id": "LOT-PEAR-204", "product_id": "SKU-PEAR-BOX-10KG", "location_id": "WH-02", "quantity": 125, "unit": "box", "previous_event_id": "evt-2026-0113", "operator_id": "team-03" } The field names are less important than their meanings. Document the unit of measure, the identity of each organization, and the distinction between a product identifier and a particular production lot. If a receiver measures kilograms while a shipper records cases, preserve both measurements and the conversion rule rather than quietly rewriting history. Five implementation decisions that make or break a recall
Keep an append-only audit trail. A corrected quantity should generate a new correction record tied to the earlier event. An update that silently replaces the original record may conceal precisely the discrepancy investigators need to understand. This does not mean the entire application must use event sourcing; the audit history just needs to remain inspectable.
Model transformations as relationships. Suppose flour lots F-17 and F-18 are used in production batch B-55. A scan of the finished batch is not enough. You need explicit edges from both inputs to the output, including measured or estimated quantities. The resulting graph allows a query to move backward toward suppliers or forward toward customers.
Use globally unambiguous identities where necessary. Human-readable names such as “Warehouse 2” are prone to collisions. Keep identifiers stable across organizational boundaries, and map partner-specific codes to a canonical identity with documented ownership.
Treat time and sensors carefully. Store timestamps with offsets or in UTC, preserve the observed local context, and record device identity and calibration metadata for temperature readings. Missing samples are unknown, not evidence that the cold chain remained within limits.
Protect commercially sensitive data. A downstream buyer may need confirmation that a lot passed an inspection; it rarely needs unrelated supplier prices or employee records. Implement field-level permissions and log access to shared records.
A recall drill is a better test than a dashboard demo
Pick a hypothetical finished food lot and ask the application to return the full chain of input lots, processing events, storage locations and customer shipments. Time how long it takes, then reverse the query from an input lot and identify every affected output lot.

Try four failure cases: a scanner working offline, a late data upload, a duplicate receiving record, and a partner using an unexpected unit of measure. A credible system must explain gaps rather than return a confident-looking but incomplete answer.

Useful metrics include time to reconstruct a lot's history, percentage of shipments with complete handoff records, and number of unresolved identity mismatches. “We collected a million events” is not a safety metric.

In the United States, the FDA's Food Traceability Rule also requires specific Key Data Elements (KDEs) around Critical Tracking Events (CTEs) for certain foods. As of November 2026, the agency states that Congress directed it not to enforce the rule before July 20, 2028. A prototype data model should never be mistaken for a compliance assessment: map each relevant legal requirement independently. See the FDA's rule overview.
The problem continues beyond the API
Food traceability is ultimately a cooperation problem. One organization can build a flawless event store and still fail if a carrier, co-packer or retailer cannot match its identifiers or deliver its records during an investigation.

For readers examining the commercial and regional dimensions of food production, distribution and logistics, Mazehnameh provides Persian-language food supply-chain analysis. The technical architecture and the operational reality should inform one another.

Start with one product family and a small set of partners. Rehearse both forward and backward tracing. Add features only after a real gap appears in the drill.
References and further reading

GS1 — What is Electronic Product Code Information Services (EPCIS)?
GS1 — EPCIS 2.0 standard
US FDA — Food Traceability Rule overview Editorial disclosure: This educational article was drafted with generative AI assistance. It contains a simplified illustrative record, not production software or legal compliance advice. Subject-matter review is recommended before implementing its design.

Which Business Tasks Should You Delegate to AI? A Practical 2x2 Decision Matrix

Hanieh Khanmohamad — Sun, 13 Sep 2026 11:57:24 +0000

AI adoption inside companies often fails for a simple reason: managers start with tools instead of decisions.

The useful question is not, “Where can we use AI?” It is, “Which tasks should be delegated to AI, which should stay human-led, and which should use a hybrid model?”

A practical way to answer that is to score work across two dimensions:

Repeatability: How structured, frequent, and rules-based is the task?
Judgment sensitivity: How much context, accountability, empathy, negotiation, or strategic interpretation does the task require?

That creates a simple 2x2 matrix.

1. High repeatability, low judgment: delegate aggressively

These are the strongest candidates for AI automation.

Typical examples include:

formatting recurring reports,
classifying support tickets,
summarizing standard documents,
extracting structured data,
producing first-pass meeting notes,
monitoring predefined metrics,
generating routine variations of internal content.

The management objective here is straightforward: reduce cycle time and free people from mechanical work.

The main risk is not usually “bad strategy.” It is process quality. If inputs are inconsistent, the AI will automate inconsistency faster. Before deployment, standardize the workflow and define exception handling.

2. High repeatability, high judgment: use a human-in-the-loop model

These tasks look automatable because they happen frequently, but the consequences of a wrong decision can be significant.

Examples include:

reviewing customer complaints,
drafting performance feedback,
evaluating sales opportunities,
preparing credit or risk assessments,
screening contracts,
recommending pricing changes.

AI can do valuable preparatory work: summarize evidence, identify patterns, rank alternatives, and flag anomalies. But a human should remain accountable for the final call.

This is where many companies get the biggest productivity gain without creating unnecessary governance risk.

3. Low repeatability, low judgment: assist rather than automate

One-off or occasional tasks may not justify building an automated workflow, but AI can still accelerate them.

Examples include:

brainstorming workshop agendas,
comparing software options,
creating a first draft of a project brief,
summarizing unfamiliar background material,
exploring alternative ways to structure a presentation.

The right mental model is “copilot,” not “autopilot.” The goal is speed of exploration.

4. Low repeatability, high judgment: keep humans in charge

This quadrant contains work where organizational context and accountability matter more than processing speed.

Examples include:

choosing a new market,
handling a major negotiation,
terminating a senior employee,
defining company positioning,
responding to a reputational crisis,
making a large capital allocation decision.

AI may still support the process by stress-testing assumptions, generating scenarios, or exposing blind spots. But delegating ownership of the decision itself is usually the wrong design choice.

Add a third variable: cost of error

The 2x2 matrix becomes more useful when managers add one more question:

What happens if the AI is wrong?

A mistake in an internal meeting summary is very different from a mistake in a regulatory filing or a major customer commitment.

For each candidate task, estimate:

frequency,
time currently consumed,
degree of repeatability,
judgment required,
cost of error,
reversibility of the decision.

High-frequency, repeatable, low-cost-of-error work should move to the front of the AI adoption queue.

A simple implementation process

A manager can operationalize the matrix in five steps.

Step 1: Inventory tasks, not job titles

Do not ask whether a “marketing manager” or “financial analyst” can be automated. Break each role into individual tasks.

Step 2: Score every task

Use a 1–5 scale for repeatability, judgment sensitivity, and cost of error.

Step 3: Pick a narrow pilot

Choose one high-repeatability, low-risk task. Define a baseline for time, quality, and error rate before introducing AI.

Step 4: Measure the result

Compare before and after performance. Productivity without quality control is not a meaningful improvement.

Step 5: Expand only when the process is stable

Once the workflow performs consistently, move to the next task rather than trying to automate an entire department at once.

The management principle behind the matrix

AI strategy should be treated as a portfolio of delegation decisions.

The highest-value organizations will probably not be the ones that automate the most tasks. They will be the ones that draw the clearest boundary between machine leverage and human accountability.

For managers who want a compact version of this framework, ForsatNet has published a practical AI delegation matrix for managers that applies the same logic to business decision-making.

The core rule is simple: automate structure, augment judgment, and keep accountability human.