A note from the founder

There is one part of ENTIA I should have explained earlier.

11,330,391economic identities
51Entia Home launch countries
2,705Knowledge
API · MCPstructured delivery

For months I have sent you rights reservations, telemetry, operator records, hashes and technical questions. I did that because I needed to document, precisely, how automated systems were accessing ENTIA.

But in doing so I think I made a communication mistake: I explained in great detail how your systems reach ENTIA, and almost not at all what ENTIA actually is.

This page is my attempt to correct that.

ENTIA is an economic identity and knowledge infrastructure designed to give machines resolved entities instead of forcing them to reconstruct them from the open web.Identity, provenance, structured knowledge and machine-readable delivery are resolved before the request reaches the model.
Fernando Vilches
01 · Why ENTIA

I did not start by trying to build a data company.

Roughly two years ago I was trying to solve a much smaller problem: how can a machine know, with enough certainty, who is really behind a company?

Finding a website was relatively easy. Resolving that a trading name, a legal entity, a domain, a tax identifier, an address and a registry history belong to the same economic entity was different.

When that certainty was missing, the machine had to infer.

What emerged is not a conventional data business. ENTIA resolves economic identity, provenance and structured knowledge into infrastructure that machines can query directly.

My working hypothesis became simple: where identity can be resolved from evidence, a machine should not have to reconstruct it from fragments.
02 · The infrastructure

That experiment became an infrastructure.

The primary asset is not a collection of pages. It is a resolved layer of economic identity, provenance and structured knowledge that can be projected to humans and delivered directly to machines.

Economic identity11,330,391

Canonical economic entities with identifiers, provenance, temporal state, relationships and corrections.

Knowledge2,705

Published knowledge objects structured for retrieval, grounding and citation.

Machine deliveryAPI · MCP

Programmatic surfaces and structured representations for consuming the resolved layer.

Resolved layercanonical identity · provenance · temporal state · relationships · controlled schemas · change tracking
03 · Example · Repsol

REPSOL SA — a resolved entity, shown in its machine-readable form.

REPSOL SA is a richer illustration of the resolved layer: one canonical economic identity joined to legal identifiers, location, external knowledge identifiers, registry activity, verification metadata and territorial context.

Legal name
VAT / tax identifier
Canonical URL
Country: ES
Sector: energy
City: Madrid
Wikidata: Q174747
BORME activity
↓ RESOLVED CANONICAL ENTITY ↓
REPSOL SAresolved entity
vat_idA78374725
countryES
cityMadrid
sectorenergy
wikidataQ174747
BORME acts1,891

Illustrative ENTIA representation. It shows how a resolved economic identity can be projected to machines with identifiers, verification metadata and contextual fields; it does not imply a commercial relationship with Repsol.

04 · Public projection

The public web is a projection, not the dataset.

When a crawler reaches an ENTIA URL, it reaches a public representation of work already performed upstream.

Public projection

  • canonical URL
  • HTML
  • JSON-LD
  • machine-readable metadata
  • public facts
  • policy signals

Resolved infrastructure

  • resolved entity identity
  • entity relationships
  • economic attributes
  • provenance
  • temporal state
  • validation state
  • structured knowledge
  • canonical identifiers
  • API/MCP delivery
  • controlled schemas
  • change tracking
The public web projection is not the dataset. It is a public projection of a deeper resolved identity infrastructure.

A direct relationship would not simply mean permission to crawl more pages. Crawling retrieves documents. A direct ENTIA relationship can provide resolved entities, controlled schemas, provenance and structured delivery.

05 · What it can solve

What this can solve for a data or AI team

Value depends on the product. The engineering problem is more stable: avoid rebuilding from web fragments an identity that can already be resolved canonically.

Entity resolution

Map names, identifiers, domains, locations and records onto a canonical economic entity.

Economic universes

Define a sector, geography or entity class and keep that population current.

Grounded retrieval

Retrieve entities and knowledge with provenance instead of rediscovering the evidence chain.

Change propagation

Carry status, identifier and relationship changes through a governed layer.

Programmatic delivery

Consume the resolved layer through API, MCP, JSON, JSON-LD or structured export as appropriate.

If you asked me tomorrow for a complete universe of law firms in London, that is exactly the kind of problem I want ENTIA to be able to resolve, maintain and deliver.
06 · Two tracks

Product and governance are two separate tracks

Track A — Product / Data infrastructure

  • Economic identity
  • Entity resolution
  • Knowledge
  • Provenance
  • API
  • MCP
  • Structured delivery
  • Evaluation
  • Data partnership

Track B — Governance / Access

  • Crawler access
  • TDM policy
  • robots.txt
  • machine-readable rights
  • Telemetry
  • Observability
  • Regulatory dossiers
Product and governance are two separate tracks. ENTIA can be evaluated commercially on its own merits, separately from the existing dossiers concerning automated access.
07 · Cross-cutting problem

This is not a problem of one LLM.

When an AI system has to understand a real company, it repeatedly faces the same difficulty: names, legal entities, domains, identifiers, locations and context do not always arrive already reconciled. The problem takes different forms across search, retrieval, agents and models, but the need to resolve the entity correctly is cross-cutting.

Machine access observed across multiple ecosystems

Machine requests observed by ENTIA through 26 September 2026. These are observed operator-family requests; they do not prove training, model incorporation or provider-side use.

Meta
1,014,565
Microsoft
645,683
Apple
463,211
Google
281,995
Amazon
230,797
Anthropic
136,897
OpenAI
30,847
Perplexity
8,121
08 · Observability

Telemetry demonstrates observable access, not internal processing.

ENTIA instruments machine access because it needs to know which surfaces are requested and what is served. That observability is evidence around the infrastructure; it is not the core product.

Machine acquisition

crawler access · retrieval · machine surfaces

PROVIDER-SIDE
PROCESS
NOT OBSERVABLE
AI-origin referrals
Perplexity
17
ChatGPT
13
Copilot
10
Gemini
1

41 AI-origin referrals observed in the complete retrievable window used for this illustration

Referral traffic demonstrates detectable downstream discovery. It does not reveal or prove the internal processing performed by the originating AI provider.

09 · Founder

There is also a personal reason I wanted to send you this.

ENTIA is founder-led. I designed the system and have operated it personally, using coding agents to build and maintain infrastructure that would normally be spread across product, data, engineering and policy teams.

This conversation arrived through an unusual route: the work of understanding and documenting automated access to ENTIA eventually placed part of that record within a European regulatory dialogue that I was invited to contribute to. I did not ask to participate in it. That origin explains how this channel opened; it does not define what ENTIA is or the value of the product.

My objective now is simpler: for ENTIA to be evaluated on the value of infrastructure that already exists. Reconstructing economic identity from the open web requires entity resolution, source deduplication, provenance and freshness maintenance, change control and a durable integration layer. ENTIA compresses that replacement cost into a resolved infrastructure prepared for programmatic delivery.

If we reach a complete bilateral agreement, then from my side the conflict that brought us into this conversation is over. I have no interest in turning the agreement into a public precedent, nor in making its commercial terms or the methodology behind it public.

After twenty-four months of work, what I want is to turn that infrastructure into a productive relationship for both sides: let the right team evaluate whether integrating resolved identity, provenance and structured delivery saves time, engineering effort and errors compared with rebuilding it themselves.

The legal and technical record remains exactly where it was. This page does not replace it. It simply shows the part of ENTIA I had not explained well enough.

Author: Fernando Vilches · Founder, ENTIA
11 · Evaluation protocol

Evaluate ENTIA with a bounded protocol

An evaluation may end in integration, a pilot, a partnership, a licence or no further action. The point is to measure before scaling.

01

Scope

Sector, country/geography and entity class.

02

Sample

A controlled sample of 100, 500 or 1,000 entities, by agreement.

03

Fields

Canonical identity, legal name, economic identifiers, website, location, relationships, provenance, temporal state and Knowledge.

04

Delivery

API, MCP, JSON, JSON-LD or structured export, depending on the use case.

05

Criteria

Entity resolution, coverage, freshness, provenance, consistency, integration complexity and machine usability.

06

Outcome

No further action, technical integration, pilot, data partnership or licensing agreement.