NEM — network entity management

Layers of feeds are joined by names, and names are the least reliable thing in any dataset. The same location is written three ways, the same organisation appears under an acronym and a full title, and the same event is described in two languages by two sources.

NEM is the layer that resolves that. It maintains one record per thing across five types — person, organisation, object, location and event — with an identifier that survives however any single source chooses to phrase it.

• Person — individuals referenced across sources.
• Organisation — entities that act, respond or are affected.
• Object — infrastructure, facilities and assets.
• Location — administrative areas, coordinates and named places.
• Event — something that happened, at a place and a time.

Resolution happens as data is ingested rather than as a clean-up afterwards. Names are checked against the existing graph before a new entity is created, and a match is merged into the canonical record rather than left standing beside it.

The canonical identifier is what the rest of the platform uses. Because every relation points at that identifier, a link made from one source is readable from another, and a query about an entity returns what all of them know.

• Canonical identifiers — one identifier per entity, used everywhere.
• Matching before ingestion — names checked before a record is created.
• Soft merge — a duplicate is folded in, and its history is kept.
• Deduplication — the same subject arriving from different feeds stays one record.

An entity on its own is a row; the value is in how entities connect. Relations carry the meaning between them — an organisation operating at a location, an event occurring near a place, a person associated with an organisation — and those relations are what a query traverses.

The graph can also be read by proximity. Given a place and a radius, the platform returns the entities inside it, which is how a single event becomes a list of what is around it rather than a point on a map.

• Traversal — follow the relations out from any entity.
• Proximity — entities inside a radius of a place or an event.
• Perspectives — the same graph read by type, so the question asked shapes the view.
• Browsing — an entity with its relations and the sources behind it.

A dot on a map becomes an entity; an entity becomes a question you can ask.

Locations get their own treatment, because a place name in prose is ambiguous in ways a coordinate is not. A mention in an article is resolved against the platform's canonical administrative areas and countries, so that a city name maps to the actual region rather than to a new entity carrying the name.

Where a name cannot be resolved, it stays unresolved and is marked as such. A guessed location would be worse than an empty one: it would look like knowledge, and it would be relied on.

• Canonical areas — administrative geography as the reference set.
• Fuzzy matching — near-spellings and alternate forms are considered.
• Countries and places — external names resolved against reference lists.
• Unresolved — an entry that cannot be placed says so.

NEM is what makes the rest of the platform's sentences possible. An alert rule with a spatial constraint is evaluated against a location entity; a layer's events link to the places and organisations around them; a situation report can name what it is describing; and the assistant answers questions about an entity rather than returning the rows that mention its name.

It is also the reason two sources can be compared at all. When both are expressed against the same identifiers, agreeing and disagreeing are readable; when they are not, every comparison begins with a manual reconciliation.

• Rules — spatial constraints are expressed against real locations.
• Reports — summarised events name the entities they concern.
• Assistant — questions are asked about people and places, not about strings.
• Layers — the same location is the same geometry across every feed.

Resolution is deliberately conservative. A missed match leaves two records that can be merged later; a wrong merge corrupts both, and the corruption is hard to see because the resulting record looks complete. Where the evidence is thin, the platform prefers two records to one false identity.

The graph also only knows what it has been told. An entity no source mentions is not in it, an entity mentioned once has one source behind it, and the record says so — the graph's confidence is the confidence of its sources, and it is presented that way.