SINFI 4.0 and network nodes: one boolean for cyber vulnerability, one for early warning

Until now Italy’s national network cadastre wanted to know where the cable runs and what it is threaded through. With version 4.0 it starts asking which amplifier sits in the node, how it is powered, and whether anything is watching it. That changes the nature of the datum, not its detail. And it comes with a caveat almost nobody will quote.

Adopted does not mean settled

Version 4.0 was adopted by AgID determination no. 129/2026 of 14 July, published on the transparency portal on the 15th and announced on the 20th. For line segments the changes are presented as changes, full stop: we went through them yesterday.

For nodes, not so. In the “Report on the changes in specification v.4.0”, the preamble to class ND_COM — node of the telecommunications and cabling network, 070702 — closes with one sentence: “Before proceeding with the integrations, the proposals described must be agreed with the stakeholders” (our translation).

Correction, 17 September 2026. That sentence describes the stage before adoption, and we took it for the state of play: that was wrong, and we are correcting it here rather than leaving it on the page. In the specification adopted on 14 July, the attributes ND_COM_AMP (07070206) and ND_COM_SOR (07070207) carry the letter P, which the document defines as follows: «i costrutti discriminati dalla lettera “P”, rappresentano contenuti informativi minimi, quindi obbligatori per l’implementazione del SINFI» — constructs marked with the letter “P” are minimum information content, and therefore mandatory for implementing SINFI. These are not proposals to be agreed: they are mandatory minimum content. Everything that follows should be read as an obligation, and the parts of this article that said otherwise have been rewritten against the adopted text rather than against the proposal document.

The node, and the node that does not exist

There are three integrations to ND_COM: vertical position (the same domain as line segments, underwater included), type, and specific characteristics expressed as data types.

The type domain — which already lists chambers, joints, telephone exchanges, radio base stations, cross-connection cabinets, FTTCab/CNO, building optical distributors and satellite land stations — gains 15 landing node (between submarine and terrestrial segments) and 16 subsea branching unit. The first is the point where a submarine backbone becomes a terrestrial network, and the most concentrated point of risk on the whole route.

Then there is 89 fictitious, a “node serving the graph connection of nodes (used for amplifiers and monitoring or surveillance systems, detailed as data types)”. Translated: an amplifier is not a node in the topological sense, but it needs one to sit in the cadastre’s graph, so the model invents it. It is a modeller’s detail, and it tells designers something: the cadastre’s representation does not match yours, and the conversion must be designed, not improvised at submission time.

“Cyber vulnerability”: yes or no

Data type ND_COM_AMP describes the amplifier with three attributes. Type: EDFA, Raman, SOA, other — the vocabulary of ITU-T G.662 on optical amplifiers. Power supply: direct current, alternating current, power over Ethernet, remote powering, solar panels or batteries, other. And then AMP_VUL, “cyber vulnerability”, cardinality [0..1], type Boolean.

A boolean. True or false.

Three questions to bring to the consultation. Who answers: the network operator, whoever commissioned the equipment, the manufacturer? Against what: a published security advisory, a firmware version, an internal assessment? As at what date: because equipment that is “not vulnerable” in July stops being so the day an advisory lands, with nothing touched on site.

A binary field on a property that changes over time is a photograph that ages. If the field stays — and it can, provided it is useful — it needs a written rule for completing it: reference, assessment date, the party who signs it. Without those three things the column fills up with “false” out of caution and informs nobody. With them it becomes a datum. That difference is decided now, not at the first submission.

Monitoring is not preventing

The second data type is ND_COM_SOR, monitoring or surveillance systems. The capabilities that can be declared, cardinality [0..*]: fault detection, intrusion or tampering detection, environmental monitoring, signal quality analysis, other. The second matters to anyone with unattended closures and cabinets along the route.

Then SOR_EW, early warning: another boolean, defined by the document as a “preventive alerting function that flags anomalies or potential faults before a service interruption occurs”.

Declaring it costs a tick. Demonstrating it is another matter. An alarm fires once the threshold has been crossed: the service is already down. A pre-alarm means seeing the drift while the service is running — so a measurement that does not stop the traffic but runs alongside it, on another wavelength — and a history to compare it against. Anyone ticking “true” without either is declaring an intention.

Electricity networks are not a separate chapter

On the electricity side the same warning applies. For class TR_ELE (line segment, 070301) the proposal document described a domain in which two different entries carried the same code 04, “segment serving public lighting” and “segment serving traffic signals and similar”. Those two entries are not in the adopted specification: the TR_ELE_TY domain has been pruned, and anyone who mapped a record layout onto those codes by reading the report would now hold two values that no longer exist. The second observation we made at the time, about repeated mnemonics, falls with them: in the adopted text TR_ELE_STA and TR_ELE_PRO each appear exactly once. That is why a record layout is written against the adopted text and never against the document that preceded it.

In class ND_ELE (node of the electricity network, 070302) the attribute “type of connected user” (ND_ELE_UTE, 07030203) carries the P and the domain opens into a tree: domestic, industrial by size class, agricultural — with an entry for “precision agriculture” — public buildings, and urban services. The entries “mixed” and “firefighting”, announced by the proposal document, do not appear in the adopted specification. The last branch shows the direction of travel: public lighting, traffic signals, electric vehicle charging points, video surveillance, sensors and IoT devices — with the stated aim of supporting integration with the other urban service management systems.

One point that looked like a contradiction at the time is resolved by reading the adopted text: the cardinality is still [0..*] in 4.0, because the obligation lies in the letter P, not in the cardinality. And the domain does not belong to the electricity class: it is the shared “type of user” domain, referenced by seven different node classes, from water mains to gas to telecommunications. Only the electricity one carries the P; the other six stay optional, but the domain beneath them has been rewritten all the same.

Why it matters to anyone laying fibre: a cadastre that records loads and services, not just conduits, is the map you consult before digging in a shared duct or coordinating works with the electricity distributor.

What to do now

Check what you have already filed against the adopted text, not against the report that announces it. For nodes we are past proposal stage: amplifier and monitoring systems are minimum content, and an archive validated before July may hold values the domain no longer allows.
Start collecting the data on active equipment now: amplifier type, power supply, presence and capabilities of the monitoring system. These are the data nobody holds in exportable form — they sit in test records, emails, and the memory of whoever commissioned the equipment.
Write the rule for completing the booleans before completing them: against which reference, as at what date, signed by whom.
Design the conversion towards node 89: decide how your equipment becomes graph nodes, and keep the identifier tying the two representations together.
On the electricity side, survey the connected user node by node: it is a datum you collect once and update, not one you reconstruct afterwards.

The point.

The cadastre is ceasing to be a map and becoming an inventory of state. It is only fed if the datum is born structured where it is born: in the chamber, the cabinet, the test record. Documenting a network is not an end-of-works formality: it is a collection designed beforehand. That is how we work — measurement, certification and as-built documentation set up so that submission is an export.

Do you need to decide which fields to add to your as-built before the data model closes? Talk to an engineer.