Sistema operativo MUVERA — cómo organizamos el conocimiento
10 ontologías transversales que atraviesan los 10 hubs principales del sitio: audiencias, pains, entregables, métricas, evidencia, objeciones, prompts, datasets, riesgos, formatos. Entity Registry interno y regla de publicación documentada. Curado por Andrés Castrejón.
Esto no es un hub comercial. Es el manifiesto del sistema: cómo decidimos qué se publica, qué se queda en registry interno y por qué el sitio crece por densidad y no por cobertura aspiracional.
Nota editorial
Este hub publica la lógica del sistema, no oferta comercial. Documenta el Entity Registry interno y por qué algunas entidades nunca tendrán URL propia. Las 10 ontologías transversales listadas aquí no se convertirán en 10 hubs públicos — esa es precisamente la regla. Solo 4 hubs nuevos se justifican como expansiones futuras: /entregables/, /como-medimos/ expandido, /problemas/ y /investigacion/niveles-de-evidencia/. El resto vive como metadata operativa.
Macro-ontologías + entidades transversales = sistema completo
El universo MUVERA ya tiene los grandes pilares cerrados. Lo que falta no son más mundos — son las entidades que atraviesan todos esos mundos para que el sistema sea operable, medible y difícil de copiar.
Fórmula del sistema
Macro-ontologías = estructura del universo (10 hubs principales) Entidades transversales = sistema operativo (10 ontologías metadata) URLs = solo lo que tiene intención + evidencia + rol de negocio
Los 10 hubs principales ya cubren la tesis Hipersigno como arquitectura de conocimiento, no solo agencia SEO:
Las 10 ontologías que atraviesan los 10 hubs
Cada una etiquetada con prioridad de expansión: P1 (justifica hub futuro), P2 (justifica sub-rutas), P3 (vive como metadata interna).
Ontología de audiencias y compradores
P3Quién compra cada cosa. Founder/CEO, CMO, Head of Growth, SEO Manager, Ecommerce Manager, CTO, Data Lead, dueño de clínica/ecommerce, director comercial, socio de despacho legal, gerente multi-sucursal, comité de compra B2B.
Uso: Metadata interna para briefs, CTAs y copy por landing. NO hub público.
Ontología de problemas y diagnósticos
P3Dependencia de Ads, caída de tráfico orgánico, canibalización, problemas de indexación, contenido commodity, migración con pérdida, falta de medición, no aparecer en IA, marca mal representada por IA, datos empresariales dispersos, sitio no preparado para agentes.
Uso: Entidades dentro de servicios y soluciones. Hub /problemas/ candidato futuro (P1).
Ontología de entregables
P1Diagnóstico SEO, auditoría técnica/semántica/GEO, AI Visibility Audit, roadmap SEO/GEO/KG, topical map, entity map, mapa de canibalización, brief SEO/GEO, schema roadmap, JSON-LD templates, citation audit, prompt audit, brand accuracy report, RAG readiness audit.
Uso: Hub /entregables/ candidato futuro PRIORITARIO (P1). BOFU directo: 'qué recibo exactamente'.
Ontología de métricas y resultados
P2Revenue orgánico, margen proxy, pipeline orgánico, leads/MQLs/SQLs, ROI SEO, payback period, share of voice orgánico, share of AI Voice, AI referrals, citas en IA, brand accuracy, prompt coverage, revenue/pipeline asistido por IA, URLs indexadas, Core Web Vitals.
Uso: Expandir /como-medimos/ existente como hub (P2). Sub-rutas por métrica clave.
Ontología de evidencia y claims
P2Claim, evidencia, fuente primaria/secundaria, documento oficial, paper, patente, leak, caso de éxito, benchmark, dataset propio, experimento, captura GSC/GA4, dashboard, dato sectorial, autor experto, revisión experta, nivel de evidencia, riesgo de sobreinterpretación.
Uso: Capa que fortalece E-E-A-T y GEO. Página candidata /metodologia/como-validamos-claims (P2).
Ontología de objeciones comerciales
P3SEO tarda mucho, SEO es caro, ya tengo agencia, ya tengo equipo interno, prefiero Ads, no sé si funciona para mi industria, mi sitio está mal hecho, no tengo equipo para implementar, no entiendo GEO, miedo de exponer datos internos.
Uso: Entidades en /precios/, /paquetes/, /diagnostico-seo/, comparativas. Páginas /aprende/ específicas (P3).
Ontología de prompts y preguntas
P2Prompt BOFU/MOFU/TOFU, prompt comparativo, prompt local, prompt ecommerce/B2B, prompt reputacional, prompt de compra/investigación/diagnóstico, query fan-out, synthetic query, prompt coverage, prompt cluster, prompt-to-URL mapping, prompt-to-CTA mapping.
Uso: Cada página GEO declara prompts_objetivo. Sub-rutas en /geo/ (prompt-tracking, prompt-map) candidatas (P2).
Ontología de datasets y benchmarks
P1Dataset, benchmark, radiografía de búsqueda por industria, keyword/SERP/prompt/citation datasets, industry/competitor datasets, search demand, CPC, intent, entity, topical map dataset, market map, share of AI Voice dataset, vertical SEO benchmarks.
Uso: Hub /datasets/ futuro con producto de entrada. Da enlaces, autoridad y demand gen (P1).
Ontología de riesgos / compliance / YMYL
P1YMYL, E-E-A-T, revisión experta, claim médico/legal/financiero, COFEPRIS, publicidad médica/suplementos/alcohol, contenido legal/financiero, privacidad, datos personales, consentimiento, AI safety, prompt injection, hallucination risk, política editorial.
Uso: Frameworks YMYL, servicios de compliance SEO, política editorial IA. Crítico para verticales prioritarias (P1).
Ontología de formatos y activos digitales
P3Landing BOFU, página de servicio/solución/industria/plataforma, framework, guía, glosario, dataset, checklist, plantilla, calculadora, dashboard, reporte, curso, webinar, caso de éxito, experimento, whitepaper, playbook, scorecard, benchmark, API, MCP, notebook.
Uso: Taxonomía interna para /recursos/ futuro (plantillas/checklists/calculadoras/playbooks/benchmarks). P3.
Cada entidad operativa lleva 17 campos
Este registry NO es público — es infraestructura operativa de Hipersigno. Alimenta briefs MUVERA, evita improvisación al crear páginas y permite auditoría editorial. Estructura canónica:
entidad: # nombre canónico
tipo: # audiencia | pain | entregable | métrica | claim |
# objeción | prompt | dataset | riesgo | formato
macrodominio: # SEO | GEO | KG | AK | Ontologías | IC | IA Emp |
# Web Agéntica | Autoridades | Stack | Sistema Op
subdominio: # SEO ecommerce | GEO local | KG B2B | etc.
intencion: # informacional | comercial | navegacional | local
funnel: # TOFU | MOFU | BOFU | retention
audiencia: # founder | CMO | CTO | dueño-clínica | etc.
pain: # dependencia-Ads | canibalización | etc.
servicio_relacionado: # /servicios/auditoria-seo/ | /paquetes/sprint-seo/
entregable_relacionado: # auditoría técnica | topical map | dashboard
kpi_relacionado: # revenue orgánico | pipeline | share-of-AI-voice
cta: # /diagnostico-seo/ | /metodologia/ | /contacto/
url_canonica: # URL si tiene intención + evidencia + CTA
estado: # registry-interno | borrador | activa | retired
indexacion: # index | noindex | backlog
prioridad: # P0 | P1 | P2 | P3
evidencia: # casos, datos, fuentes que respaldan claims
fuentes: # documentos del hub /autoridades/
riesgo: # YMYL | reputacional | compliance | bajoSolo URLs con intención + evidencia + CTA
Esta regla previene el antipatrón típico de cobertura aspiracional: publicar URLs porque "completa el tema" en vez de porque "tiene búsqueda comercial real con evidencia para responder".
✓ Entidad con intención + evidencia + CTA
URL indexable. Plantilla editorial completa. Schema apropiado. Enlazada desde hubs L1 relevantes. Sub de un sistema.
○ Entidad útil pero inmadura
Noindex o backlog. Existe en registry para futura activación. NO se publica con thin content para "tener algo".
○ Entidad sin intención
Solo registry interno. Sirve como metadata para briefs, audiencias y CTAs — nunca tendrá URL pública. Audiencias, formatos y objeciones viven aquí.
Solo 4 hubs nuevos se justifican
De las 10 ontologías transversales, solo 4 merecen hub público propio en el futuro. Cualquier otra propuesta de hub se rechaza por dilución del universo.
/entregables/BOFU directoP1Muy útil para vender sin humo. Baja la ansiedad del comprador respondiendo '¿qué recibo exactamente?' con sub-rutas: /entregables/auditoria-seo/, /topical-map/, /entity-map/, /roadmap-seo/, /dashboard-seo/, /ai-visibility-audit/, /knowledge-graph-roadmap/.
/como-medimos/ (expandir existente)Trust + transparenciaP2Ya existe la página, convertirla en hub con sub-rutas: /como-medimos/revenue-organico/, /pipeline-organico/, /roi-seo/, /share-of-ai-voice/, /brand-accuracy/, /ai-referrals/.
/problemas/Captura pain-basedP3Solo si capturamos búsquedas pain-based explícitas. Sub-rutas: /problemas/caida-de-trafico-organico/, /canibalizacion-seo/, /problemas-de-indexacion/, /dependencia-de-ads/, /no-aparecer-en-ia/.
/investigacion/niveles-de-evidencia/Trust layer + GEOP2No como hub comercial — como trust layer que demuestra rigor. Páginas: /niveles-de-evidencia/, /como-validamos-claims/, /fuentes-primarias-vs-secundarias/.
10 hubs que NO entran al menú principal
Estos 10 hubs aspiracionales típicos de sitios SEO genéricos NO se agregarán. Diluyen el universo MUVERA y crean canibalización innecesaria con hubs existentes.
/personas/ fuera del hub /autoridades//empresas/ fuera del hub /autoridades/ o casos/tendencias//noticias//opiniones//herramientas-externas/ duplicando /stack-tecnologico//marketing-digital//ia/ (ya cubierto por /ia-empresarial/)/automatizacion/ (ya cubierto por /stack-tecnologico/automatizacion-no-code/)/consultoria/ (ya cubierto por /servicios/ y /paquetes/)Orden recomendado para próximas waves
Las últimas 3 ontologías (audiencias, objeciones, formatos) son metadata operativa — no expansion pública. Los primeros 7 son potenciales waves futuras según ROI.
Entregables
BOFU directo, baja ansiedad del comprador, diferencia de humo
Métricas / cómo medimos
Trust + transparencia, fortalece /servicios/ y /paquetes/
Problemas / pains
Captura demanda pain-based, conecta con diagnóstico
Evidencia / claims
Fortalece E-E-A-T y citabilidad por LLMs (GEO)
Prompts GEO
Operacionaliza GEO con prompt-to-URL mapping
Datasets / benchmarks
Da enlaces, autoridad y producto de entrada gratuito
Riesgo / compliance YMYL
Protege marca en verticales sensibles (clínicas, abogados, finanzas)
Audiencias
Metadata para CTAs y copy, no hub público
Objeciones
Material para /aprende/, comparativas, /precios/
Formatos / activos
Taxonomía /recursos/ cuando haya volumen de activos
11 reglas MUVERA del sistema operativo
Reglas que gobiernan el Entity Registry y la decisión de publicación. Sin estas reglas, el sitio se vuelve directorio aspiracional.
Macro-ontologías = estructura del universo. 8 hubs L1 + 2 hubs sistema + /autoridades/ + /stack-tecnologico/ + /sistema-operativo/ ya cubren la tesis. No agregar más pilares al menú principal.
Entidades transversales = sistema operativo. Audiencias, pains, entregables, métricas, claims, objeciones, prompts, datasets, riesgos, formatos viven en Entity Registry interno — no como hubs públicos por defecto.
URLs = solo lo que tiene intención + evidencia + CTA. Sin los tres, va a registry interno o backlog. Entidad sin intención no merece URL.
Una URL = una entidad dominante. Una landing no debe servir a varias audiencias contradictorias ni mezclar entregables de servicios distintos.
Entity Registry es no-negociable. Cada entidad operativa lleva: tipo, macrodominio, subdominio, intención, funnel, audiencia, pain, servicio relacionado, entregable, KPI, CTA, URL canónica, estado, indexación, prioridad, evidencia, fuentes, riesgo.
4 hubs nuevos justificados solamente. /entregables/, /como-medimos/ expandido, /problemas/, /investigacion/niveles-de-evidencia/. El resto se evalúa con criterio MUVERA — no por aspiración de cobertura.
Lo que NO entra al menú principal: /personas/, /empresas/, /tendencias/, /noticias/, /opiniones/, /marketing-digital/, /ia/, /automatizacion/, /consultoria/. Diluyen — ya están cubiertos por hubs existentes.
Cada entidad transversal sirve a 1+ hub L1 técnico. Si una audiencia no compra ninguno de los 8 servicios técnicos, no se documenta. Si un pain no se resuelve con servicios actuales, va a backlog estratégico.
El Entity Registry alimenta briefs, no copy. Genera briefs MUVERA con todos los atributos preseteados — el copy se redacta humano, no autogenerado.
Actualización trimestral del registry. Pains, objeciones, prompts y datasets cambian más rápido que macrodominios. Audiencias y formatos son más estables.
Prioridad real para próximas waves: entregables → métricas → pains → evidencia → prompts → datasets → riesgos. Las últimas 3 (audiencias, objeciones, formatos) son metadata, no expansion.
Preguntas frecuentes sobre el sistema operativo
¿Qué es el hub Sistema Operativo y por qué Hipersigno lo tiene?
Es el manifiesto del sistema operativo MUVERA: cómo organizamos las entidades que atraviesan los 8 hubs L1 técnicos (SEO/GEO/KG/AK/Ontologías/IC/IA/Web Agéntica) + los 2 hubs sistema (Autoridades/Stack Tecnológico). Documenta el Entity Registry interno, las 10 ontologías transversales y la regla de publicación. Sin esto, el sitio se ve como colección de hubs; con esto, se ve como sistema con lógica coherente.
¿Por qué no convertir las 10 ontologías transversales en 10 hubs públicos?
Porque diluye el sistema y rompe la regla MUVERA #1: una URL = una entidad dominante. Audiencias, pains, objeciones y formatos son metadata operativa para briefs y CTAs — no entidades comerciales que merezcan landing dedicada. Hacerlas hubs públicos genera thin content y canibalización. Solo 4 ontologías justifican hubs futuros (entregables, métricas, pains, evidencia), y solo cuando tengan ≥5 entidades con intención clara.
¿Cuál es la regla de publicación?
Entidad sin intención = registry interno. Entidad con intención + evidencia + CTA = URL indexable. Entidad útil pero inmadura = noindex o backlog. Esta regla previene el antipatrón típico de cobertura aspiracional: publicar URLs porque 'completa el tema' en vez de porque 'tiene búsqueda comercial real con evidencia para responder'.
¿Qué es el Entity Registry interno?
Un inventario estructurado YAML donde cada entidad operativa lleva 17 campos: tipo, macrodominio, subdominio, intención, funnel, audiencia, pain, servicio relacionado, entregable, KPI, CTA, URL canónica, estado, indexación, prioridad, evidencia, fuentes, riesgo. Alimenta briefs MUVERA, evita improvisación al crear páginas y permite auditoría editorial. NO es público — es infraestructura operativa de Hipersigno.
¿Cuáles son los 4 hubs nuevos justificados como expansión futura?
Solo cuatro. /entregables/ (BOFU directo, baja ansiedad del comprador con sub-rutas por tipo de entregable). /como-medimos/ expandido (ya existe la página — convertirla en hub con sub-rutas por métrica). /problemas/ (captura demanda pain-based con sub-rutas como /caida-de-trafico-organico/, /canibalizacion-seo/). /investigacion/niveles-de-evidencia/ (trust layer + GEO, demuestra rigor metodológico). Cualquier otro hub propuesto se rechaza por MUVERA #6.
¿Cuál es la prioridad real para próximas waves?
Orden recomendado: 1) Entregables (BOFU), 2) Métricas/como-medimos (transparencia), 3) Problemas/pains (captura), 4) Evidencia/claims (E-E-A-T + GEO), 5) Prompts GEO (operacionaliza), 6) Datasets (autoridad + lead gen), 7) Riesgo/compliance YMYL (protege marca). Las últimas tres ontologías (audiencias, objeciones, formatos) son metadata — no expansion pública.
¿Qué NO se va a expandir en el menú principal?
/personas/ fuera de Autoridades, /empresas/ fuera de Autoridades/casos, /tendencias/, /noticias/, /opiniones/, /herramientas-externas/ duplicando Stack Tecnológico, /marketing-digital/ (genérico), /ia/ (ya en /ia-empresarial/), /automatizacion/ (ya en Stack), /consultoria/ (ya en Servicios/Paquetes). Diluyen el universo MUVERA y crean canibalización innecesaria.
¿Cómo se conecta este hub con los demás?
Es el meta-hub que explica cómo opera el sistema. Cada entidad transversal documentada aquí enlaza a uno o más hubs L1 técnicos donde se aplica. Por ejemplo: la ontología de prompts conecta con /geo/; la de entregables conecta con /servicios/, /paquetes/, /diagnostico-seo/; la de riesgos YMYL conecta con /industrias/clinicas/, /industrias/abogados/, /industrias/finanzas-seguros/. Es el tejido invisible que coordina los 10 hubs principales.
¿Quieres aplicar este sistema a tu empresa?
Este sistema operativo es lo que diferencia a Hipersigno de agencias SEO convencionales: no improvisamos URLs ni copy. Cada página se decide desde un Entity Registry con 17 campos, cada claim se respalda contra autoridades documentadas y cada hub justifica su existencia con métricas de negocio. Si tu empresa quiere operar SEO/GEO/KG así, empieza por un diagnóstico.
Última actualización: 2026-06-11 · Sistema: MUVERA Ontology System v0.1 · Autor: Andrés Castrejón