Metodología de extracción

Motor PDF (Sección I). Extrae texto plano con pdfplumber y aplica una batería de reglas regex + heurísticas tipadas para identificar: CIF (con validación de letra de control oficial AEAT), razón social, tipo de acto (constituciones, nombramientos, ceses, ampliaciones, fusiones, concursales, disoluciones, escisiones) y personas involucradas con su cargo normalizado.

Motor XML (Sección II). Procesa los anuncios legales estructurados directamente desde el XML oficial, donde los campos ya están etiquetados con schemas del BOE. Mucho más fiable que el PDF cuando está disponible.

Validador cruzado. Cuando un acto aparece en ambas fuentes, se comparan los campos extraídos. Discrepancias se loguean para auditoría manual semanal. Precisión actual medida en muestra estadística: >98% CIF, >96% razón social, >92% tipo de acto.

Latencia objetivo: <100 ms para búsqueda, <200 ms para ficha de empresa, <300 ms para grafos persona. Medidas reales mejores en la mayoría de los casos por cache hit ratio CF + LiteSpeed > 90%.

Stack productivo: PHP 8.3 + SQLite (lectura-only para datos derivados pesados como facts BORME) + JSON estáticos para hot path + Cloudflare CDN + LiteSpeed cache + OPcache. Cero MySQL/Postgres.

Deploy atómico: nuevas versiones del dataset se suben con nombre temporal, se renombran atómicamente en producción tras smoke tests pasados → cero downtime, rollback en segundos si algo falla post-flight.

Tres estrategias de matching

1. Matching por identificador único (CIF / LEI) — fiabilidad alta. Cuando la fuente publica el CIF o el código LEI (Legal Entity Identifier), la asociación es directa y verificable.
2. Matching por slug canónico — fiabilidad media-alta. El slug se construye por normalización de la razón social. Funciona bien para empresas con denominaciones distintivas.
3. Matching por nombre fuzzy — fiabilidad media. Como último recurso, comparación textual normalizada. Resultados se filtran por volumen mínimo de actos (≥5 actos BORME) para descartar coincidencias falsas con empresas inactivas.

Limitaciones conocidas del matching

Reconocemos abiertamente las siguientes limitaciones técnicas:

• Homonimia parcial: dos empresas con denominaciones similares en distintas provincias pueden generar ambigüedad. Mitigación: priorizamos la entidad con mayor volumen de actos publicados.
• Empresas extranjeras sin CIF español: cobertura más débil porque sólo aparecen si tienen LEI o relación matriz/filial documentada con entidad española.
• Empresas extintas o disueltas: pueden seguir apareciendo en menciones históricas. Se reflejan tal como están publicadas en la fuente original. Recomendamos verificar el estado actual en el Registro Mercantil competente.
• Cambios de denominación social: si una empresa se ha renombrado, las menciones anteriores pueden quedar en una ficha distinta hasta que el match cruzado se actualice.
• Matching binario, no probabilístico: una relación cross-fuente actualmente se establece como match = sí / no, sin scoring de confianza por relación. En el roadmap está la migración a un modelo de confianza por claim / evidencia (ver sección Roadmap técnico).

Cómo corregir un matching erróneo

Si detecta que una mención está mal asociada a su empresa (o a otra empresa), puede notificarlo en el canal de rectificación. Plazo de respuesta: 48-72 horas hábiles. Indique en el correo el slug afectado y la mención concreta.

OpenMercantil publica un Indicador documental (anteriormente denominado "Trust Score") en algunas fichas de empresa. Es una estimación algorítmica orientativa basada exclusivamente en señales documentales públicas:

• Antigüedad registral y continuidad de actos BORME
• Depósito de cuentas anuales
• Capital social declarado y evolución
• Propiedad industrial (marcas, patentes registradas)
• Presencia en registros sectoriales oficiales (CNMV, AESA, etc.)
• Sanciones administrativas publicadas (sentido negativo)
• Concursos de acreedores publicados (sentido negativo)

Coincidencias en listas internacionales

Cuando una empresa coincide con una entrada en listas internacionales (OpenSanctions, ICIJ Offshore Leaks, etc.), OpenMercantil lo refleja pero con disclaimers explícitos en la ficha:

• Una coincidencia puede deberse a homonimia (mismo nombre, distinta entidad).
• Una coincidencia puede deberse a coincidencia parcial de denominación.
• Una coincidencia no implica per se infracción: hay que verificar la naturaleza del registro y el contexto en la fuente original.
• Para validez jurídica, consultar la fuente oficial enlazada en cada hallazgo.

Algoritmo completo y ponderaciones del Indicador documental disponibles en /trust-score.

Por qué este modelo

Inicialmente, OpenMercantil indexaba los datos en tablas-por-fuente (sanctions_aepd_companies, cnmc_sanctions, sanciones_aepd, etc.). Esto funcionaba pero limitaba la auditoría: no había un identificador único por afirmación ni un historial de versiones.

Migramos progresivamente a un modelo unificado donde cada afirmación se representa como una tupla auditable.

Esquema del modelo

claims_evidence (
  id                       PK
  entity_type              'company' | 'person' | 'org'
  entity_slug              FK a /empresa/{slug} o /persona/{slug}
  entity_name              denormalized para display
  claim_id                 UUID único
  predicate                e.g. 'sanctioned_by_aepd', 'awarded_contract'
  value                    string normalizado
  value_extra              JSON adicional opcional
  source_name              'AEPD', 'BORME', 'CNMV', ...
  source_url               URL oficial
  source_publication_date  YYYY-MM-DD
  observed_at              cuándo lo observó OpenMercantil
  confidence               'high' | 'medium' | 'low' | 'experimental'
  raw_text_hash            sha256 del texto fuente
  parser_version           ej. 'aepd-v2.1'
  normalized_value         post-normalización OpenMercantil
  interpretation           'official' | 'derived' | 'inferred'
  status                   'active' | 'superseded' | 'corrected' | 'disputed'
)

Beneficios

• Trazabilidad completa: cada dato responde a "qué fuente lo respalda, cuándo se publicó, cuándo lo observamos, qué confianza tiene".
• Versionado: las correcciones generan un nuevo claim con status=superseded en el viejo.
• Confidence scoring real: matching fuzzy con score < 0.85 se marca confidence='low' explícito.
• Auditabilidad: el raw_text_hash permite detectar cambios en la fuente original.
• Reproceso: cambios en el parser quedan trazados con parser_version.

Estado actual

Tabla claims_evidence creada en BD standalone artifacts/claims_evidence.sqlite con seeding inicial de 3 ejemplos AEPD para validar el esquema. Helpers PHP disponibles:

• openmercantil_get_company_claims($slug, $predicate, $limit)
• openmercantil_get_claims_stats()

Roadmap de migración (incremental, sin breaking):

1. Fase 1 — POC con sanciones AEPD (3 ejemplos seeded).
2. Fase 2 — Migración completa AEPD (todas las sanciones).
3. Fase 3 — Sanciones CNMC + ESMA + AEAT morosos.
4. Fase 4 — Contratación pública PLACSP + TED EU.
5. Fase 5 — Subvenciones BDNS + CORDIS.
6. Fase 6 — Marcas/Patentes OEPM + EUIPO + EPO/WIPO.
7. Fase 7+ — Resto fuentes (gradualmente).

Durante el período migratorio, los datos legacy seguirán visibles desde sus tablas originales. El frontend mostrará indicadores cuando un dato proceda del modelo nuevo vs legacy.