Summary

  • The official API presents agenda item 9131 as LACNIC 46 Wrap-Up, classifies it under the LACNIC46 taxonomy and schedules it for 22 October 2026. Its record title, slug and a second event binding still identify LACNIC 45.
  • The current English agenda response contains 62 records. All 62 use the canonical LACNIC46 taxonomy; 61 also use its ID in the redundant ACF event field. Item 9131 is the one exception, pointing there to LACNIC45.
  • Homepage object 8993 has the current LACNIC46 title, slug, taxonomy and Mendoza body, but its ACF event string says LACNIC 39. The checked sources prove conflicting machine fields, not a wrong rendered page or harm to a participant.

The closing item belongs to two editions

The last twenty minutes of the current LACNIC 46 agenda expose the problem cleanly. Agenda item 9131 is scheduled from 17:40 to 18:00 on 22 October 2026. Its English presentation title is LACNIC 46 Wrap-Up. The Spanish field says Cierre LACNIC 46; the Brazilian Portuguese field says Encerramento LACNIC 46.

Those are not the only identities on the object.

Field on item 9131 Stored value Edition named
Localized English title LACNIC 46 Wrap-Up LACNIC 46
Canonical our_events taxonomy ID 310, LACNIC46 LACNIC 46
Top-level record title LACNIC 45 Cierre LACNIC 45
Top-level slug lacnic-45-cierre-2 LACNIC 45
ACF event binding ID 250, LACNIC45 LACNIC 45

The embedded taxonomy confirms that ID 310 is named LACNIC46. The official record for term 250 is named LACNIC45 and carries a Mexico City country field. The same agenda object is therefore current at its canonical-classification and presentation layers, but one edition old in its record title, slug and redundant event relationship.

This is not a claim that the closing session is actually part of LACNIC 45. The date, localized title and canonical taxonomy all place it in LACNIC 46. It is a claim about referential integrity: a consumer can ask the same public object which edition it belongs to and obtain different answers depending on the field chosen.

One exception in a 62-record response

The disagreement is measurable. The English agenda collection returned through the translated LACNIC46 term contained 62 records when captured on 5 September 2026.

All 62 records had the canonical top-level our_events value [310]. In the ACF event array, 61 also pointed to [310]. One pointed to [250]. That one was item 9131.

The denominator matters because it keeps the finding small. This is not evidence that the agenda is generally corrupted. Nor does one outlier make the other 61 records perfect: the check covered two event selectors in one response, not every field or system. It establishes a bounded exception that can be reproduced without speculation.

The record is not newly exposed by a September programme update. Item 9131 shows the same creation and modification timestamp, 24 July 2026 at 17:25:28 in the API's local time format. Several other agenda items were modified in early September, but their recency cannot be assigned to this outlier.

The homepage carries a different old edition

The current homepage query returns object 8993. Its top-level title is LACNIC46, its slug is lacnic46, and its canonical taxonomy is again ID 310. The body identifies LACNIC 46 / LACNOG 2026 at Hilton Mendoza in Mendoza, Argentina, from 19 to 22 October. Yet the ACF event string says LACNIC 39.

That does not make the whole homepage an old LACNIC 39 page. Most of the object's visible content and classification identify the current edition. It shows instead that a stale mirror can survive inside an otherwise current object.

The event terms add another caution. The canonical LACNIC46 term 310 retains Buenos Aires, Argentina in its country field and leaves start and finish blank, while the homepage body says Mendoza and gives the October dates. The English translation term 312 is also named LACNIC46, but exposes only sparse translation fields. Current event attributes are distributed rather than resolved in one self-sufficient record.

The public agenda HTML returned a client-rendered shell with the page title LACNIC 46. It did not contain server-rendered session rows. A browser reached a tab with the same title, but a locked workstation prevented a visual or accessibility read of the rendered row. The evidence therefore stops at the API and shell. It does not establish that a reader was shown LACNIC 45, that search indexed the stale slug, or that an export followed the wrong relationship.

Which field wins depends on the consumer

A frontend can classify an item by our_events and label it with info_en.title; that combination would show the current edition. A script can instead group records by acf.event, or build a URL from the top-level slug; that combination would carry the older one. These are possible selection rules, not findings about LACNIC's actual applications.

The distinction matters because clean presentation is not proof of clean identity. A current screen can be assembled from the right fields while an archive, migration, feed or later code change selects another field. Conversely, conflicting source fields do not prove that any current consumer has failed.

The useful control should therefore test the record before it reaches a particular presentation. It should know which field is canonical, which fields are localized labels, which are deprecated mirrors and which old values are intentional aliases.

Build an edition map before cleaning the fields

LACNIC does not need a large governance system to repair this. It needs one canonical event-identity map for each edition. The map can bind the series and edition number; canonical and translated term IDs; content record IDs and types; localized presentation titles; operative dates and location; public slug; and any superseded alias.

A validator can then ask a narrow question: does every active classification field resolve to the same edition? If a current LACNIC 46 record points to term 250 or says LACNIC 39 in an active event field, the build or editorial workflow should flag it. If lacnic-45-cierre-2 must remain for an old link, it should be labelled as a historical alias or redirected, not left to compete with the current identity.

Correction history matters. Silently changing every old string would make the surface neater but could erase why the mismatch existed and break an address somebody has retained. A versioned correction can record the old value, the canonical replacement, the field's role, the effective time and the redirect or alias decision.

This keeps the common rule thin. The canonical edition and its relationships are shared. Spanish, English and Portuguese presentation titles remain local. Future clients do not have to infer authority from field position, and historical links do not have to be destroyed to make the current record coherent.

Sources