What the system follows and what it lacks

What it requires. An identifier of the form NLDM000574590532: country per ISO 3166-1, sex, twelve digits of the national number. With the breed code in front, nineteen characters.

What we have. Assembly and parsing in both country notations, a reference list of thirty-two countries, the country and the number in the country of origin held on the animal. An imported animal counts from its country of origin, not from ours. The number is never invented: no data, no number.

What comes next. The breed code field exists in the reference list and is wired into the exchange; whether it is filled in is shown by the check:breed-codes run, and the code is put in by a person who knows the breeds. Separately, a validation rule for “the number does not match its parts” is needed: a discrepancy between the stored number and the one assembled from the parts would go unnoticed today.

What it requires. The fifteen-digit decimal representation of the transponder code; the first three digits are the ISO 3166-1 country code or the manufacturer code.

What we have. A check of the form: length, digits, plausibility of the first three. A manufacturer code of 900 and above is recognised separately and not passed off as a country. A tag leaves for exchange only once it has passed the check.

What comes next. The texts of the standards have not been bought — the check is written from secondary sources. Around 100–150 CHF, the only expense in the whole international plan.

What it requires. From 1 March 2026, submitting information about breeding animals on the forms of the register is mandatory, with the assigned identifiers loaded back.

What we have. All twenty templates of the register: export and reverse import. The headers are matched line by line against the real files of the register. Every exported field has a way in — by hand or by upload.

What it requires. An open specification for exchanging animal data: JSON schemas, REST, shared vocabularies. Apache 2.0 licence; no formal certification exists.

What we have. 14 collections served at the addresses of the specification (animals, test-day-results, parturitions, inseminations, type-classifications, weights, breeding-values, arrivals, departures, deaths, pregnancy-checks, milking-visits, daily-milking-averages, diagnoses). POST is accepted on 7 of them, with a repeated submission recognised by the pair “source + its record id” — otherwise a dropped connection would duplicate the record. Rejections come back as icarErrorResource; a batch answers with icarBatchResult line by line. What is served is validated against the real JSON schemas of the adewg/ICAR repository, not against our own copy of the enumerations. The exchange is documented in the general interface description, in the “Exchange” section.

What comes next. Both exchange styles of the standard work: selection by location, and set-based exchange with a change feed, an opaque continuation token and recognition of deleted records. Eleven resources out of some fifty are carried — exactly what the book keeps; health, feeding and group events are not in the book itself yet. Animals, conformation scoring, breeding values and movements are closed for writing deliberately, not by omission: registering an animal and transferring rights are statements the Association answers for before the breeder, and they go through an application with review; each of them is answered with 405 and an explanation in words.

What it requires. The interface described by a machine-readable specification, not by prose alone.

What we have. An OpenAPI description, a documentation page and a run that checks the description against the code. The ICAR ADE exchange is described there as a section of its own: an integrator who opens the documentation learns about the standard interface without studying ours.

What it requires. Aligning the exchange model with the UN business requirements specifications for livestock traceability.

What we have. Nothing.

What comes next. This starts not with the work but with finding the documents themselves: the BRS texts could not be located in the review of open sources.

What it requires. The rules for recording production, verifying parentage, scoring conformation and computing genetic evaluations that recording organisations on five continents work by.

What we have. Analysed section by section: what each one requires and how it is done. Not a single section is covered in full, and that is the state of things, not caution in wording.

What comes next. 16 gaps across 9 sections — all of them written out on a separate page.

What it requires. Twelve mandatory microsatellite loci, at least two hundred SNPs from the ISAG set, the TOP/AB notation, computation of exclusion probabilities.

What we have. The twelve mandatory STR loci, the verification methods and the verdicts.

What comes next. There is no SNP panel, no TOP/AB notation, and exclusion probabilities are not computed. What is stored is the result of the test, not the genotype: we cannot re-check it ourselves, and cannot hand it to another laboratory either.

What it requires. Registration rules: five generations of pedigree with production data, a flag for a non-Holstein ancestor, the recessive codes Mulefoot, BLAD, CVM and DUMPS, colour codes, embryo documentation.

What we have. None of the above.

What comes next. The largest piece of subject-matter work in the plan, and the most useful: this is what makes a herd book different from a database of cows.

What it requires. The structure of the 200/300/301 files, computation of effective daughter contributions, validation tests of the genetic trend by methods I–III.

What we have. Nothing.

What comes next. Trend validation is needed regardless of taking part in international evaluation: without it a slow drift of the base looks like genetic progress, and the substitution cannot be spotted.

What it requires. Bringing the national evaluations of different countries onto a common scale.

What we have. The index of the book is our own computation on a borrowed comparison base, and the caption beside it says so directly.

What comes next. Requires ICAR membership and a validated national evaluation in a single countrywide base. The membership form contains a declaration of compliance with OFAC and FATF rules, and ICAR checks it before admission.

Not up to us. ICAR and Interbull: membership and a validated national evaluation

What it requires. The only industry certification of herd book keeping and data processing in the world, with an on-site audit.

What we have. We do not have it, and cannot have it without membership.

What comes next. Open to ICAR members only. The analysis is in the document on the mark and membership.

Not up to us. ICAR: certification is open to members only

What it requires. Mutual recognition of Holstein cattle registration in Europe.

What we have. The Russian Holstein association was a member of EHRC and was suspended by a decision of 12 July 2022. No public announcement of that suspension being lifted has been found for 2023–2026.

What comes next. The first step costs nothing: a letter to the secretary general asking about the current status. Until it is answered, discussing international recognition is pointless.

Not up to us. EHRC and WHFF: the suspension is lifted by a decision of those organisations

What it requires. Traceability requirements: preventing duplicate identifiers, the list of events, linking identifiers on import and export, backup copies, confidentiality.

What we have. Part of the requirements is met in fact — the change log, access rights, events with dates — but no mapping against the text of the code has been made.

What comes next. The work is mostly documentary: a table of “requirement → implementation”. There are two items of real work — checks for duplicate identifiers, and the linking of numbers on import.

What it requires. Integrated multi-purpose animal recording systems and breeding strategies — as an architectural reference.

What we have. Nothing.

What comes next. A document, not code. A day of work.

What it requires. National reporting on animal genetic resources.

What we have. Not our area: it is the state that reports, not the developer of the system. Russia does not keep this reporting and does not populate DAD-IS.

Not up to us. the state: reporting to DAD-IS is done by the country, not by the developer

What it requires. Accessibility of the interface for people with limited sight, hearing and motor control.

What we have. Particulars: the language is marked up on the pages and on the switcher buttons, the logo and the navigations have labels, links are distinguishable by more than colour. No systematic run against the criteria has been made.

What comes next. A run against the criteria, an accessibility statement with an honest list of the limitations — large tables and graphical pedigrees are problematic by nature — and automatic checking of whatever can be automated.

What it requires. The software quality model as the language of technical specifications and acceptance.

What we have. The register of runs maps onto the model almost entirely, but the mapping has not been written down. Certification against 25010 essentially does not exist.

What comes next. A document mapping the eight quality characteristics onto what we have.

What it requires. Reference lists, codes and exchange schemas under CC0 1.0; aggregated statistics and catalogue metadata under CC BY 4.0. Architecture following the FAIR principles.

What we have. Nothing.

What comes next. An open data page with the reference lists in JSON and CSV, a licence file beside each of them, and a licence note in the interface response. It depends on the decision of the Association on what to open.

Not up to us. a decision of the Association on which reference lists to open

What it requires. An information security management system with an external audit.

What we have. Nothing formal.

What comes next. Implementation under GOST R ISO/IEC 27001-2021, the Russian adoption of the standard, with an audit by a Russian company. Internationally recognised certification is not available directly: Rosaccreditation, the Russian national accreditation service, is not a signatory to the mutual recognition arrangement for management systems.

Not up to us. an accredited auditor: certification is issued by a certification body, not by the developer

What it requires. Inclusion in the register under the class “software for sector-specific tasks in agriculture”. It opens access to state procurement and exempts the product from VAT.

What we have. No application has been filed.

What comes next. Preparation has to start early because of the two-operating-systems rule: for sector-specific application software it applies from 1 June 2027.

Not up to us. the Ministry of Digital Development: inclusion in the register is a decision of the ministry on the application of the rights holder

What it requires. Requirements for the development process: code analysis, vulnerability management, testing.

What we have. Part of the practices is followed in fact; no conformity assessment has been carried out.

What comes next. This is the language of FSTEC and of the Ministry of Digital Development, and the foundation of trusted software status.

Not up to us. a conformity assessment body: the practices can be followed, but conformity can only be confirmed from outside

What it requires. Testing of milk meters and samplers, certification of identification devices, accreditation of milk and DNA analysis laboratories.

What we have. Not our area. The book accepts the results of such devices and laboratories, but does not certify them and makes no claim to.

Not up to us. certification bodies for devices and accreditation bodies for laboratories