Beyond Ingredients and Instructions: Why Ajinomatrix Is Building JRF for Recipes?

A recipe can travel as text. Can its meaning travel too?

Recipes move between people remarkably well.

A human cook reading “fold the whipped cream into the chocolate”, “reduce until thickened”, or “bake until done” supplies a great deal of knowledge that the document never formally states. We understand that melted chocolate and whipped cream are intermediate states. We understand that two preparations can happen in parallel. We recognize that a sauce produced halfway through a recipe is now an object that later steps can consume.

Software does not automatically share that understanding.

Two applications can exchange exactly the same recipe text while constructing two different internal representations of what happened.

One may treat “melted chocolate” as another ingredient. Another may recognize it as the result of applying a melting process to chocolate.

One may preserve two parallel preparation branches. Another may flatten them into a misleading sequential list.

And, increasingly importantly, an AI system may encounter information that the source never supplied — time, temperature, equipment, quantities — and be tempted to fill the gaps with plausible values.

The text has travelled.

The recipe’s actual transformation logic may not have.

That is the problem behind JRF — JSON Recipe File, the recipe-file programme now being developed by Ajinomatrix.

Its central proposition is deliberately simple:

The process is the recipe.

From recipe card to transformation process

Most digital recipes still resemble the paper recipe card from which they evolved:

title + ingredients + instructions

That is an excellent human interface.

It is much less satisfactory as a computational interchange model.

Consider a simplified chocolate mousse:

Chocolate → melt → melted chocolate

and, in parallel:

Cream → whip → whipped cream

The two intermediate products then converge:

melted chocolate + whipped cream → fold → mousse mixture → chill → finished mousse

“Melted chocolate”, “whipped cream”, “mousse mixture” and “finished mousse” are not decorative labels. They are identifiable material states produced and consumed by processes.

The two initial operations occur in parallel.

The fold operation has two inputs.

The chilled mousse is the terminal state of the recipe.

A representation capable of expressing that structure preserves considerably more meaning than one carrying only a numbered instruction list.

JRF is being developed around that distinction.

What JRF is — and what it is not yet

JRF — JSON Recipe File is an Ajinomatrix initiative for a portable, human-readable JSON representation of recipes as transformation processes.

The proposed .jrf file is intended to carry information such as:

• ingredients and quantities;

• units;

• preparation and transformation operations;

• time, temperature and other process conditions;

• equipment;

• intermediate material states;

• dependencies and parallel branches;

• final or serving state;

• provenance;

• optional sensory attachments;

• extension information without corrupting the canonical recipe core.

A competent developer should still be able to open the file and read it as ordinary JSON.

Just as importantly, a JRF object should remain meaningful outside a proprietary Ajinomatrix database.

You can find and download our white paper here.

What already exists

There is now a working JRF Preview, implemented as the AJNV4.3 compatibility profile used by Ajinoverse Studio.

The public Studio currently provides browser tools for extracting, viewing, validating, converting, inspecting, comparing and visualizing recipe-process files. Its recipe extractor can take recipe videos or pages and produce .jrf / AJNV4.3 structured output. (⁠Ajinoverse Studio)

What is still being formalized

The richer canonical JRF specification — including stronger provenance, assertion semantics, progressive conformance and evidence handling — remains under development.

That distinction matters.

A working preview profile exists. A finished industry standard does not.

JRF is best described today as an open recipe-file standard initiative under development.

We did not invent the idea that recipes are processes

The idea that a recipe can be represented procedurally is established prior art.

ISA-88, also published internationally through IEC 61512, has long provided structured recipe models for industrial batch processes. It distinguishes general, site, master and control recipes and formalizes procedural structures including procedures, unit procedures, operations and phases. (⁠isa.org)

Food-process research goes further still.

The PO2/TransformON ontology published in npj Science of Food in 2023 models generic transformation processes as sequences of steps with input and output components, observations and results, and applies this architecture to food, biomass and bioproduct engineering. (⁠Nature)

Recipe exchange formats also predate JRF, including Schema.org/Recipe, Cooklang, RecipeMD and historical work explicitly named Open Recipe Format.

So the interesting question is not:

Can somebody invent a structured recipe format?

That question was answered long ago.

Our question is narrower:

Can a lightweight, portable recipe file preserve process and state semantics, source information, uncertainty and interoperability well enough to move reliably between modern food-software systems?

That is what JRF needs to demonstrate.

Why we built millions of recipe records before freezing the specification

It would have been easy to design JRF around ten beautiful demonstration recipes.

It would also have been dangerous.

Real recipes contain:

• incomplete quantities;

• regional units;

• ambiguous instructions;

• implicit intermediates;

• nested preparations;

• parallel processes;

• fermentation and maturation;

• preparation states embedded in ingredient names;

• different languages;

• inconsistent webpages;

• copied and modified variants;

• culturally specific terminology.

A representation that succeeds on a carefully selected chocolate mousse may fail immediately when exposed to several million recipes written by different people in different languages.

So the development programme deliberately built an empirical substrate before freezing the format.

August 2026 corpus snapshot

The current acquisition system has observed approximately:

6.09 million raw recipe records

across:

8,224 domains, 115 detected languages

A separate fusion and deduplication pipeline has identified approximately:

2.71 million unique recipes

with approximately:

1.01 million duplicate records removed

and:

58,828 multi-source cases

in the current snapshot.

The merged corpus is substantially multilingual, including approximately 1.61 million English recipes alongside major French, German, Japanese, Russian, Italian, Spanish, Swedish and Portuguese populations.

But these numbers need an important qualification.

Raw acquisitions are not validated recipes. Unique recipes are not gold-standard annotations. Corpus size is not evidence that JRF itself works.

The corpus is the laboratory in which JRF can now fail honestly.

That is much more useful than a large number presented as proof.

Duplicates may turn out to be some of the most useful data

Deduplication usually sounds like housekeeping.

For JRF it exposes a deeper research problem.

When multiple websites contain identical or near-identical recipes, they can differ in:

• wording;

• quantities;

• substitutions;

• step order;

• omitted details;

• translation;

• localization;

• source attribution.

That gives us an unusually interesting experimental question:

When are two recipe documents different representations of the same underlying culinary process?

Current textual deduplication does not answer that question.

A MinHash similarity score can identify textual proximity. It does not prove that two transformation graphs are semantically equivalent.

But the multi-source population provides data with which that question can eventually be investigated.

No Silent Invention

One principle has become central enough that we believe it deserves a name:

No Silent Invention

Imagine the source says:

“Mix and bake until done.”

A conversion system should not silently transform that into:

180 °C for 25 minutes in a convection oven

simply because those values sound reasonable.

They may be excellent guesses.

They are still guesses.

The rule we want JRF tooling to enforce is:

Unknown means unknown. Missing means missing. Inference must identify itself as inference.

If information is inferred, the inference should be visible.

If information is unsupported, the system should not quietly convert it into apparent fact.

If conversion loses information, that loss should be reported.

This is especially important when language models participate in recipe extraction. Fluent output makes unsupported assertions easy to overlook.

For JRF, an incomplete representation containing explicit unknowns may therefore be scientifically better than a beautifully complete representation containing invented facts.

Toward a Silent Invention Rate

We are consequently investigating an experimental validation metric:

SIR — Silent Invention Rate

Conceptually:

unsupported generated semantic assertions / total generated semantic assertions

Its exact definition is not frozen yet.

But its purpose is important.

Conventional extraction evaluation tends to reward recall: how much information did the system manage to extract?

For a process representation, we also need to ask:

How much did the system claim that the source never justified?

A parser achieving slightly lower recall but virtually no unsupported assertions may be more useful than one producing impressively complete but partially fictional process graphs.

Why we are not converting all 2.7 million recipes yet

Because scale should follow measurement, not precede it.

The next important JRF experiment is deliberately much smaller:

1,000 recipes

The benchmark should be stratified across:

• languages;

• source types;

• recipe complexity;

• ingredient counts;

• process counts;

• intermediate states;

• parallel branches;

• ambiguous quantities;

• timing;

• temperatures;

• equipment;

• poorly structured source material.

A smaller subset can then receive detailed human gold annotation.

The measurements should go beyond simple ingredient recognition.

We want to evaluate:

• ingredient identity;

• quantity and unit extraction;

• preparation state;

• process recognition;

• process ordering;

• input/output relationships;

• intermediate-state reconstruction;

• parallel-process reconstruction;

• final-state detection;

• provenance retention;

• unsupported inference;

• human correction effort.

Only once those failure modes are understood does scaling from 1,000 to 10,000, 100,000 and eventually millions become scientifically useful.

A conformance ladder instead of pretending every source is perfect

Another JRF principle is progressive conformance.

A twenty-year-old recipe file should not become “invalid” simply because it cannot express every element of a future JRF specification.

Instead, the programme is investigating classifications such as:

native current JRF

older compatible representation

convertible without semantic loss

convertible with declared warnings or loss

incompatible without inventing information

The validator can likewise operate at several levels:

1. Is it valid JSON?

2. Does it satisfy the structural schema?

3. Do all process references resolve?

4. Is the recipe semantically coherent?

5. Which JRF/application versions can consume it?

6. What information would be lost through conversion?

That is a more realistic route to interoperability than demanding instant purity.

JRF does not need to own everything

JRF is deliberately not intended to become the ontology of the entire food industry.

Its job is the recipe transformation object.

Other systems can own their own domains.

Within the Ajinomatrix architecture:

JRF represents the recipe and its transformation process.

MP6 represents sensory and perceptual information.

TT-o can carry deeper ingredient-origin, supplier, lot and process-history information.

KG-SRS / SRS-GraphDB provides a broader provenance-aware knowledge substrate.

Ajinoverse provides tools able to produce, inspect, validate and transform those objects.

The important architectural principle is separability.

A .jrf file should not become meaningless simply because an Ajinomatrix server is unavailable.

The file is supposed to be the interchange object.

Provenance is already being tested elsewhere in the architecture

The recipe representation itself has not yet completed its benchmark.

But some of the underlying evidence philosophy is already operating elsewhere.

A recent live Ciqual ingestion into KG-SRS produced a provenance-aware food-composition graph in which observations and measurements remain distinct, multiple measurement methods can coexist, references remain attached to values, and “absence”, “traces” and censored values can retain different semantics.

This matters because the same general discipline is required for recipes:

do not flatten different kinds of evidence into one apparently certain value.

It is supporting infrastructure evidence.

It is not evidence that JRF itself has already passed validation.

That boundary is intentional.

What we can claim today

JRF can presently claim:

• a developed process-centric conceptual model;

• substantial prior-art and standards analysis;

• a working JRF Preview / AJNV4.3 compatibility profile;

• public browser-based recipe-process tools;

• a large multilingual empirical corpus;

• operating acquisition, fusion and deduplication infrastructure;

• a proposed conformance model;

• a benchmark programme;

• a provenance-aware supporting knowledge architecture.

It cannot yet claim:

• formal standards-body recognition;

• industry-wide adoption;

• a frozen JRF v1.0;

• measured parser accuracy at corpus scale;

• automatic semantic equivalence detection;

• perfect recipe understanding;

• unrestricted redistribution rights over the acquired recipe corpus.

Those are not footnotes.

They define the current maturity of the programme.

What will earn JRF v0.2

We want the next meaningful version to be triggered by evidence rather than by writing another document.

The gate is approximately:

source recipe↓

candidate extraction↓

process/state reconstruction↓

.jrf serialization↓

schema + semantic validation↓

provenance verification↓

MP6 attachment or explicit sensory stub↓

KG-SRS projection↓

measured 1,000-recipe benchmark

When that chain works, can be reproduced and has measured failure modes, JRF will have crossed an important threshold.

Until then, remaining in the v0.1.x line is a feature, not a weakness.

A file is useful only if meaning survives the journey

Recipes are already digital.

They live in webpages, videos, AI conversations, databases, mobile applications, formulation systems and professional kitchens.

The remaining question is not whether we can move the words.

We can.

The harder question is:

How much of the actual transformation logic survives when a recipe moves from one computational system to another?

JRF is Ajinomatrix’s attempt to turn that question into something concrete, testable and interoperable.

Not another container for recipe text.

A portable representation of what the recipe says happens.

JRF status — August 2026

JRF Preview: operational through Ajinoverse Studio.

Canonical JRF specification: under development for open publication and independent implementation.

Corpus: approximately 2.71 million unique recipes in the current dated experimental snapshot.

Next evidence gate: stratified 1,000-recipe process-extraction benchmark.

Ajinomatrix welcomes technical review from researchers, food-software developers, culinary technologists, standards specialists and interoperability practitioners interested in testing the model or representative files.

The JRF whitepaper is available for download here.