▐▛███▜▌ Claude Code v2.1.138 ▝▜█████▛▘ Sonnet 4.6 · Claude Max ▘▘ ▝▝ /Users/Akasha/Development/ontoref ❯ dime qué tiene que ver este contendip con este proyecto /Users/Akasha/Development/ontoref/assets/presentation/docs/Steal_This_Deck.pd f ⏺ Voy a leer el PDF para ver qué contiene. Read 1 file (ctrl+o to expand) ⏺ Voy a leer las páginas restantes antes de responder. Read 1 file (ctrl+o to expand) ⏺ La conexión es directa y profunda. Este deck es esencialmente el argumento teórico externo que justifica por qué ontoref existe. Lo que Talisman argumenta en KGC 2026: ▎ AI needs knowledge infrastructure — ontologies, typed relations, provenance ▎ — to work reliably. Data infrastructure (lakes, vectors, ETL) doesn't ▎ produce knowledge. You cannot skip layers. Lo que ontoref implementa: Exactamente eso, pero scopeado a proyectos de software en lugar de organizaciones empresariales. Las correspondencias específicas son precisas: Deck (org/enterprise): Controlled vocabularies Ontoref (proyecto de software): ontology/schemas/*.ncl — contratos NCL tipados ──────────────────────────────────────── Deck (org/enterprise): Ontologies — formal commitments Ontoref (proyecto de software): .ontology/core.ncl — nodos Practice/Concept con edges ──────────────────────────────────────── Deck (org/enterprise): Knowledge graphs — live, queryable Ontoref (proyecto de software): DAG-formalized knowledge, ontoref graph, describe ──────────────────────────────────────── Deck (org/enterprise): Governance — forever, not a project Ontoref (proyecto de software): reflection/, ADRs, migraciones, state.ncl FSM ──────────────────────────────────────── Deck (org/enterprise): "Memory is knowledge" Ontoref (proyecto de software): .coder/ sessions, Q&A persistence (ADR-003) El punto de slide 12 — "MCP and A2A are transport. Not semantics." — es particularmente relevante: ontoref tiene una superficie MCP (crates/ontoref-daemon/src/mcp/) que expone precisamente la capa semántica que el protocolo de transporte no puede proveer por sí solo. Es la diferencia que Talisman identifica. El punto de slide "The Productivity Paradox" — AI generates volume without a knowledge backbone — es exactamente el problema que el Agent Entry-Point Protocol de ontoref resuelve: sin describe capabilities, un agente como yo opera sobre correlación estadística, no sobre conocimiento estructurado del proyecto. ¿Por qué está en assets/presentation/? Probablemente es referencia para una presentación propia de ontoref — el argumento de por qué proyectos de software necesitan este tipo de infraestructura de conocimiento para que los agentes AI trabajen sobre ellos con fiabilidad. ✻ Sautéed for 1m 21s ❯ lo acabamos de recibir y no sabemos muy bien qué hacer, si es que debemos o tenemos que hacer algo al respecto ? ⏺ Honestamente, no tienes que hacer nada en el codebase — no hay ningún gap técnico que este deck revele. Lo que sí tiene valor es entender qué te da este documento como recurso: Si estás construyendo una presentación para ontoref (lo sugiere assets/presentation/), este deck te regala el trabajo de contextualización que normalmente es lo más difícil de una pitch: - Ya no tienes que convencer a la audiencia de que AI necesita infraestructura de conocimiento — Talisman lo hace con datos (KGC 2026, benchmarks citados, investigación peer-reviewed) - Puedes entrar directamente a: "Ese problema existe también en proyectos de software. Ontoref es la infraestructura de conocimiento para que los agentes AI trabajen sobre tu proyecto con fiabilidad, no con correlación estadística" - El slide 12 ("MCP are transport, not semantics") es especialmente útil: ontoref tiene superficie MCP + capa ontológica — exactamente el gap que ella identifica El único movimiento concreto que consideraría es guardarlo como referencia citeable en assets/presentation/docs/ (ya está), y si construyes slides, abrir con el contexto que ella establece antes de entrar a qué hace ontoref. Lo que no haría: incorporar su terminología al codebase, cambiar la ontología, ni crear documentos de alineación. El código ya hace lo que el deck describe — es validación externa, no instrucción de diseño. ✻ Sautéed for 31s ※ recap: Reviewing a KGC 2026 presentation about knowledge infrastructure for AI. No action needed — the PDF is external validation for ontoref's pitch, already saved in assets/presentation/docs/. (disable recaps in /config) ❯ puedes extraer del doc las partes relevantes que pueden servir para ontoref en posts, slides, presentacione e intro ⏺ Voy a leer las últimas páginas que me faltan antes de compilar. Read 1 file (ctrl+o to expand) ⏺ Aquí está la extracción organizada por uso: --- Framing / Intro hooks Para abrir cualquier presentación de ontoref: ▎ "AI is a knowledge tool. Not a data tool. That breaks every assumption ▎ underneath many AI strategies." ▎ — Talisman, KGC 2026 Adaptado a ontoref: los agentes AI que trabajan sobre tu repositorio operan sobre correlación estadística si no hay infraestructura de conocimiento. Ontoref es esa infraestructura, pero para proyectos de software. ▎ "Agentic AI is not a model upgrade away. It is a shared language, from which ▎ to act." Este cierre del deck es el mejor hook de intro para ontoref: un modelo más grande no sabe qué es tu proyecto, qué decisiones tomaste, ni en qué estado está. Eso requiere conocimiento estructurado, no un token window mayor. --- Datos citable para el problema Todos con fuente verificable — útiles en posts y slides sin necesitar justificación propia: Dato: 89% de empresas reportan cero impacto de productividad de AI en 3 años Fuente: NBER, Feb 2026, n=5.937 execs ──────────────────────────────────────── Dato: Developers experimentados fueron 19% más lentos con herramientas AI Fuente: METR RCT, 2025 ──────────────────────────────────────── Dato: Ganancia neta semanal del trabajador AI-promedio: −14 minutos Fuente: Foxit/Sapio, March 2026 ──────────────────────────────────────── Dato: 1.7× más issues en PRs escritos por AI Fuente: CodeRabbit, 2025 ──────────────────────────────────────── Dato: 46% del código en GitHub escrito por Copilot Fuente: Octoverse 2025 El argumento que emerge: AI is not saving time. It is generating volume. Without a knowledge backbone, its only measurable output is noise. --- El argumento central — para slides y posts El stack de conocimiento (Talisman lo llama "knowledge infrastructure"): 1. Controlled vocabularies — términos con significado único y autoritativo 2. Taxonomies — organización jerárquica 3. Thesauri — equivalencias, relaciones cruzadas 4. Ontologies — compromisos formales: clases, propiedades, constraints 5. Knowledge graphs — live, queryable, governable ▎ "You cannot skip layers. You cannot start at five and reverse-engineer to ▎ one." Ontoref implementa este stack para proyectos de software: - Schemas NCL → vocabularios controlados - .ontology/core.ncl → nodos Practice/Concept con edges tipados - DAG-formalized knowledge → el knowledge graph - ADRs + migrations + state.ncl → governance --- El argumento de precisión — para posts técnicos ▎ "The accuracy gap is not closed by a bigger model. It is closed by a defined ▎ schema, an ontology, and a validated query." Con datos: - 16% → 72% en question-answering sobre SQL enterprise con ontology checks (Allemang & Sequeda, data.world AI Lab, 2024) - 3.4× GraphRAG vs vector RAG en 43 queries enterprise (Diffbot KG-LM Benchmark, 2023) - Vector RAG colapsa a 0% past 5 entities per query. KG-grounded retrieval sostiene. ▎ "Defining your terms is the cheapest accuracy and cost lever in the LLM ▎ stack." Ontoref es exactamente esto: ontoref describe y el sistema Q&A (ADR-003) son el vocabulario controlado que reduce el espacio de alucinación cuando un agente trabaja sobre el proyecto. --- El argumento de MCP — crítico para el posicionamiento técnico ▎ "MCP and A2A are transport. Not semantics. They move bytes between ▎ endpoints. They do not establish shared meaning." ▎ ▎ "Two agents connected by MCP exchange text bytes. They do not truly share ▎ context." Ontoref cierra este gap: tiene superficie MCP (ontoref-daemon/src/mcp/) encima de una capa ontológica. El protocolo mueve bytes; ontoref provee el significado que hace que esos bytes sean conocimiento, no texto. Esto es diferenciación directa respecto a "simplemente exponer tu repo por MCP". --- El argumento cultural — para posts de opinión ▎ "The industry is optimized to ship solutions, not to own problems." ┌─────────────────────────────┬────────────────────────────────┐ │ Celebrado │ Huérfano │ ├─────────────────────────────┼────────────────────────────────┤ │ Launching new platforms │ Maintaining existing platforms │ ├─────────────────────────────┼────────────────────────────────┤ │ AI-generated content │ Taxonomy work │ ├─────────────────────────────┼────────────────────────────────┤ │ Ontologies built on the fly │ Domain expertise │ └─────────────────────────────┴────────────────────────────────┘ ▎ "Knowledge work IS the maintenance. Yet it keeps getting cut." Ontoref formaliza exactamente lo que siempre se corta: las decisiones arquitectónicas (ADRs), el estado del proyecto (state.ncl), la memoria operacional (.coder/). Lo hace queryable y machine-readable para que no dependa de que alguien lo recuerde. --- El close — para cualquier formato ▎ "The organizations that close the perception/reality gap first won't be the ▎ ones with the best models. They'll be the ones who finally did the work." Adaptado: los proyectos donde los agentes AI trabajan mejor no son los que tienen el modelo más grande. Son los que tienen conocimiento estructurado sobre sí mismos. --- Nota de atribución Todo esto es de Jessica Talisman (KGC 2026, "Stop Betting, Start Building"). Al usar cualquiera de estos puntos en público, citar la fuente — es un argumento de autoridad que refuerza, no debilita, la posición de ontoref. ✻ Baked for 1m 21s ❯ guarda esto en assets/presentation/docs como referencia Listed 1 directory (ctrl+o to expand) ⏺ Write(assets/presentation/docs/talisman-steal-this-deck-extractions.md) ⎿  Wrote 118 lines to assets/presentation/docs/talisman-steal-this-deck-extractions.md 2 # Extractions — Steal This Deck (Talisman, KGC 2026) 3 Source: Jessica Talisman, "Stop Betting, Start Building", Knowled ge Graph Conference 2026. 4 Newsletter: Intentional Arrangement (Substack). Received: 9 May 2 026. 5 Full deck: `Steal_This_Deck.pdf` 6 7 --- 8 9 ## Framing / Intro hooks … +153 lines (ctrl+o to expand) ⏺ Guardado en assets/presentation/docs/talisman-steal-this-deck-extractions.md, junto al PDF original. ✻ Churned for 1m 16s ❯ pero ontoref son dos coxistencias de ontologia y reflection Ella tiene un enfoque más de la semántica ontologica y menos de la operaciona que es el Yang pero sin el Yin de reflection son buenas intenciones/deseos, etc ? ⏺ Exacto. Es la crítica más precisa que se le puede hacer al argumento de Talisman, y es exactamente lo que diferencia ontoref. Lo que ella describe es infraestructura de conocimiento como artefacto de construcción — vocabularios, ontologías, knowledge graphs. El problema que identifica (governance "forever, not a project") lo nombra pero no lo resuelve. Su stack termina en "Govern" como un sexto paso, sin mecanismo interno. La pregunta que no responde: ¿quién vigila que la ontología no derive respecto al sistema real? ¿Quién detecta cuando una decisión arquitectónica invalida un nodo del grafo? ¿Quién propaga los cambios a los consumidores? Sin ese cierre operacional, la ontología más rigurosa acaba siendo exactamente lo que describes — buenas intenciones formalizadas. Archaeology, no infrastructure. Ontoref es las dos mitades: Ontology (Yin — lo que ES) Reflection (Yang — lo que DEVIENE) ────────────────────────────── ────────────────────────────────── .ontology/core.ncl reflection/modes/*.ncl Nodos, edges, constraints DAGs ejecutables, pasos reportables Compromisos formales Operaciones que cambian estado state.ncl (fotografía) state.ncl FSM (transición activa) ADRs (decisión tomada) migrations/ (propagación al ecosistema) describe project sync diff --docs (detección de deriva) Sin Reflection, la ontología cristaliza. Describe lo que el proyecto quería ser en el momento en que se escribió. Sin Ontology, Reflection es ejecución sin verdad — sabe qué hacer pero no qué es. La tensión nombrada en core.ncl — "Ontology vs Reflection: both must coexist without one dominating" — es precisamente esto. Talisman articula bien el Yin. Ontoref es la respuesta al Yang que su framework no provee. Vale la pena añadir esto a las extracciones — es el argumento diferenciador central para cualquier presentación frente a audiencias que ya conocen el mundo KG/semantic web. ¿Lo agrego al documento? ✻ Cooked for 47s ❯ sip Por qué los DAGs se vienen usando desde hace mucho tiempo y no veo que haya la perspectiva de ontoref includo see montan DAgs para los run-books, cd/ci, compiladores ? ⏺ Es la pregunta correcta. Y la respuesta tiene capas. Por qué los DAGs son ubicuos En todos los usos que mencionas — CI/CD, compiladores, runbooks, Airflow, dbt, Bazel — el DAG es un modelo de ejecución. Las aristas significan "esto antes que aquello". El grafo describe cómo se computa, no qué es lo que se computa. Es una herramienta de ordenación topológica. CI/CD: test → build → deploy Compiler: parse → typecheck → codegen → link Runbook: check_health → drain → restart → verify Todos inerts. El grafo no sabe qué es el proyecto, no tiene semántica sobre sus propias aristas. --- Lo que ontoref hace diferente Son dos usos de DAGs que no coexisten en ningún otro sitio: DAG ontológico — aristas con tipo semántico: Practice "ncl-schemas" --implements--> Principle "type-safety" Practice "ncl-schemas" --enforces--> Constraint "zero-runtime-deps" Practice "ncl-schemas" --enables--> Capability "agent-queryable-state" Practice "ncl-schemas" --tension--> Practice "adoption-friction" No es "esto antes que aquello". Es conocimiento — compromisos formales sobre qué ES el proyecto y cómo se relacionan sus conceptos. El equivalente sería un compilador que sabe por qué existe y qué trade-offs tomó. DAG de reflexión — aristas con contrato ejecutable + restricción de actor: step "validate-state" (actor: any) --> step "run-mode" (actor: developer) step "run-mode" (actor: developer) --> step "report" (actor: agent|developer) No es solo ejecución. El DAG es validado como contrato antes de ejecutarse, registra su propio progreso, y sabe quién puede hacer qué. --- El gap que nadie ha cerrado El mundo de knowledge graphs (Talisman, W3C, RDF/OWL) aplica este tipo de semántica a dominios empresariales — productos, clientes, transacciones. Nunca al proyecto de software mismo. El mundo de herramientas de software (GitHub, Jira, Linear, CI/CD) trata el conocimiento del proyecto como documentos no tipados — wikis, tickets, READMEs. Usa DAGs para ejecución, nunca para representación de conocimiento. Knowledge Graph world: semántica sobre el dominio del negocio Software tooling world: DAGs sobre la ejecución del software ontoref: semántica sobre el proyecto de software en sí mismo --- La pieza que lo hace no-trivial La parte que no existe en ningún otro sitio es que los dos DAGs se hablan: - El DAG ontológico dice qué es el proyecto (prácticas, principios, constraints activos) - El DAG de reflexión opera sobre ese estado — detecta deriva, ejecuta modos, registra transiciones - Las migraciones propagan cambios del DAG ontológico a proyectos consumidores Sin esa conexión, tienes una ontología bonita que nadie mantiene (buenas intenciones) o tienes runbooks sin semántica (ejecución ciega). El Yang sin Yin, o el Yin sin Yang. --- Por qué no había emergido antes Tres condicionantes que ahora se alinean: 1. Agentes AI — que necesitan consumir conocimiento estructurado del proyecto, no texto libre. Antes no había consumidor que lo requiriera. 2. NCL/Nickel — un lenguaje de configuración con contratos y tipos que permite expresar ontología sin un triplestore externo. RDF/OWL requería infraestructura pesada. 3. La escala correcta — Knowledge Graphs empresariales son proyectos de años. Ontoref opera a escala de repositorio, con adopción incremental y sin enforcement. ✻ Cooked for 1m 38s ❯ pero hay valores importantes cuando se introducen detalles como el tipo de almacenamiento, el uso modos federados, la gestión via CLI/UI/MCP/GRAPHQL y luego consumir usando jj y radicle ⏺ Ahí está el salto cualitativo que separa ontoref de cualquier otro enfoque. Lo que añade cada capa: Almacenamiento tipado y soberano El enterprise knowledge graph (el mundo de Talisman) asume un triplestore central mantenido por un equipo dedicado. Ontoref invierte eso: el conocimiento vive con el proyecto, en NCL versionado junto al código. La elección de almacenamiento no es un detalle de implementación — es una declaración de soberanía. Nadie puede quitarte tu ontología porque está en tu repo. Modos federados Esto es lo que ningún sistema de knowledge graph tiene: proyectos que se describen a sí mismos Y pueden ser descubiertos y consultados por otros proyectos. No es un grafo central al que todos apuntan — es una red de proyectos auto-descritos que pueden exponer su conocimiento entre ellos. Ecosistema-level visibility sin un intermediario. proyecto-A consulta: ¿qué proyectos implementan "auth-pattern-X"? proyecto-B, proyecto-C responden desde sus propias ontologías sin un servidor central que lo sepa todo NATS (ya feature-gated en el daemon) es exactamente el fabric para esto. CLI + UI + MCP + GraphQL Cuatro superficies que no son redundantes — responden a cuatro tipos de consumidor: ┌───────────────┬───────────────────────────────────────────────────┐ │ Superficie │ Consumidor │ ├───────────────┼───────────────────────────────────────────────────┤ │ CLI (Nushell) │ Desarrollador en terminal, scripts, CI │ ├───────────────┼───────────────────────────────────────────────────┤ │ UI (axum) │ Managers, revisión visual, onboarding │ ├───────────────┼───────────────────────────────────────────────────┤ │ MCP │ Agentes AI — la razón de existir de ontoref │ ├───────────────┼───────────────────────────────────────────────────┤ │ GraphQL │ Herramientas externas, dashboards, queries ad-hoc │ └───────────────┴───────────────────────────────────────────────────┘ GraphQL sobre el DAG ontológico es especialmente potente: SPARQL es el estándar semántico pero requiere expertise. GraphQL es lo que todo el mundo sabe escribir. Reduces la barrera de consumo sin sacrificar la estructura. jj + Radicle como capa de transporte Aquí es donde se cierra el argumento de soberanía: - jj (Jujutsu): modelo de VCS donde cada working copy es siempre un commit. Alinea perfectamente con ontoref — no hay "estado sucio", cada momento del proyecto es capturable. El operation log de jj es análogo al tracking de sesiones de reflection. - Radicle: P2P, local-first, sin GitHub. Si tu código es soberano, tu conocimiento sobre ese código también lo es. Radicle como transport hace que la federación de ontoref no dependa de ninguna plataforma centralizada. --- El cuadro completo que diferencia ontoref: Enterprise KG (Talisman): Ontoref: ───────────────────────── ────────────────────────────────── Triplestore central NCL distribuido, por repo Equipo dedicado El proyecto se mantiene a sí mismo GitHub/GitLab jj + Radicle (soberano, P2P) API SPARQL interna CLI + UI + MCP + GraphQL Un grafo global Federación de proyectos auto-descritos Knowledge como infraestructura Knowledge como parte del proyecto La conexión con Yin/Yang: El almacenamiento soberano + federación + multi-superficie es el Yang operacional que hace que el Yin ontológico sea accionable a escala de ecosistema. Sin esto, incluso la ontología más rigurosa es local y mortal — muere cuando el equipo cambia o cuando la plataforma desaparece. Con esto, el conocimiento del proyecto sobrevive al equipo, se propaga sin intermediarios, y puede ser consumido por cualquier agente o herramienta que hable cualquiera de las cuatro superficies. --- ¿Quieres que capture esto también en el documento de referencia de assets/presentation/docs/? ✻ Sautéed for 58s ❯ estamos con ontoref no sólo en gestión de proyectos, también en infrawstructura y en lo personal ⏺ Eso cambia el scope fundamental. Ya no es una herramienta de gestión de proyectos — es un protocolo de auto-conocimiento para cualquier sistema con identidad e intención. Los tres dominios comparten la misma estructura profunda: Ontology (Yin) Reflection (Yang) ───────────────────── ────────────────────────── Proyecto Qué ES el software Qué DEVIENE — ADRs, modos, principios, prácticas migraciones, deriva de docs Infra Qué ES el sistema Qué DEVIENE — provisioning, servicios, deps, drift detection, remediation, constraints, topología runbooks como DAGs ejecutables Personal Quién ERES Quién DEVIENS — decisiones con valores, roles, consecuencias duraderas, hábitos, principios vitales revisiones, deriva de intención Lo que diferencia a los tres no es la arquitectura — es el sujeto que se describe a sí mismo. --- Infra — lo que añade: Infraestructura ya usa DAGs (Terraform, Pulumi, Ansible) pero todos inerts: describen cómo se provisiona, no por qué existe así. Ontoref sobre infra captura las tensiones reales: Servicio "auth" --tension--> Principio "stateless" porque necesita session state pero el principio dice no Constraint "zero-downtime" --enforces--> Práctica "blue-green" y eso está en el ADR-infra-003, no en el Terraform jj + Radicle + NATS federation = GitOps soberano donde cada entorno (dev, staging, prod) se describe a sí mismo y puede ser consultado desde el proyecto que lo consume. Personal — lo que añade: Es el dominio más radical. La misma pregunta que ontoref hace a un proyecto — ¿qué eres, qué tensiones activas tienes, en qué estado estás respecto a donde quieres estar? — es exactamente la pregunta que el conocimiento personal estructurado necesita responder. No un segundo cerebro de notas. Un grafo de compromisos. Valor "profundidad" --tension--> Rol "padre" porque el tiempo es finito y los dos lo demandan Decisión "dejar empresa X" --constraint--> Futuro laboral con el mismo peso que un ADR arquitectónico Estado "aprendiendo Rust" --blocker--> "contribuir a ontoref-core" FSM personal, no lista de tareas --- La convergencia que lo hace coherente: Los tres dominios son instancias del mismo protocolo porque los tres tienen: - Identidad — qué son, qué principios los definen - Tensiones activas — trade-offs que no se resuelven, se gestionan - Decisiones con consecuencias duraderas — el equivalente de ADRs - Estado observable — dónde están vs. dónde quieren estar - Deriva — la distancia entre intención y realidad que crece con el tiempo - Operaciones — los modos que reducen esa deriva Y todos se benefician del mismo stack: almacenamiento soberano, federación, multi-superficie, jj/Radicle. --- Lo que esto significa para el posicionamiento: Talisman habla de knowledge infrastructure para organizaciones. Ontoref es knowledge infrastructure desde abajo — desde el individuo hasta el proyecto hasta la infraestructura que ejecuta ese proyecto. Sin vendor, sin plataforma central, sin equipo dedicado de ontólogos. El sujeto más pequeño que puede adoptar ontoref es una persona. El más grande es un ecosistema de proyectos federados. ¿Guardamos esto también como referencia? ✻ Cogitated for 52s ❯ guarda todos también ⏺ Write(assets/presentation/docs/ontoref-yin-yang-diferenciacion.md) ⎿  Wrote 67 lines to assets/presentation/docs/ontoref-yin-yang-diferenciacion.md 2 # Ontoref — Yin/Yang: Lo que Talisman no resuelve 3 Referencia para posts, slides, presentaciones. 4 Contexto: extracción del análisis comparativo con "Steal This De ck" (Talisman, KGC 2026). 5 7 --- 8 ## El gap del argumento de Talisman 9 10 Talisman describe infraestructura de conocimiento como artefacto de construcción — … +77 lines (ctrl+o to expand) ⏺ Write(assets/presentation/docs/ontoref-dags-diferenciacion.md) ⎿  Wrote 107 lines to assets/presentation/docs/ontoref-dags-diferenciacion.md 2 # Ontoref — Por qué los DAGs de ontoref son diferentes 3 Referencia para posts, slides, presentaciones. 4 Contexto: análisis de por qué DAGs son ubicuos pero nadie tiene la perspectiva de ontoref. 5 7 --- 8 ## DAGs son ubicuos — y todos hacen lo mismo 9 10 En CI/CD, compiladores, runbooks, Airflow, dbt, Bazel: el DAG es un **modelo de ejecución**. … +130 lines (ctrl+o to expand) ⏺ Write(assets/presentation/docs/ontoref-scope-proyecto-infra-personal.md) ⎿  Wrote 157 lines to assets/presentation/docs/ontoref-scope-proyecto-infra-personal.md 1 # Ontoref — Scope: Proyecto, Infraestructura, Personal 2 3 Referencia para posts, slides, presentaciones. 4 Contexto: ontoref como protocolo de auto-conocimiento para cualqu ier sistema con identidad e intención, 5 más allá de gestión de proyectos de software. 6 7 --- 8 9 ## La afirmación central … +181 lines (ctrl+o to expand) ❯ ok ⏺ Tres archivos guardados en assets/presentation/docs/: - talisman-steal-this-deck-extractions.md — citas, datos y mapeos del deck de Talisman - ontoref-yin-yang-diferenciacion.md — por qué Talisman no resuelve el lado operacional - ontoref-dags-diferenciacion.md — por qué los DAGs de ontoref son distintos a todos los demás - ontoref-scope-proyecto-infra-personal.md — el scope completo con el stack soberano ✻ Worked for 1m 59s ❯ genera un índice de los docs de presentation Listed 2 directories (ctrl+o to expand) ⏺ Write(assets/presentation/docs/INDEX.md) ⎿  Wrote 56 lines to assets/presentation/docs/INDEX.md 2 # Presentation Docs — Index 3 Material de referencia para posts, slides y presentaciones de on toref. 4 5 --- 6 7 ## Análisis y posicionamiento ontoref 8 9 | Archivo | Contenido | 10 |---|---| … +73 lines (ctrl+o to expand) ⏺ INDEX.md creado en assets/presentation/docs/. Agrupa el material en cuatro bloques: 1. Análisis ontoref — los tres docs de posicionamiento generados hoy 2. Talisman KGC 2026 — deck PDF + extracciones + artículo EN/ES 3. José Celano — ontologías y DAGs 4. Material previo — ontología como filosofía, sprints, notas de voz ✻ Sautéed for 35s ❯ genera un post basado en todo esto ⏺ User answered Claude's questions: ⎿  · ¿En qué idioma quieres el post? → Bilingüe · ¿Cuál es el ángulo principal del post? → Puedes generar 4 posts enficados a cada una de las partes · ¿Para qué plataforma/formato? → me gustaría publicar en 1 y algo en 2 pero el foco no va a allí va en jesusperez.pro/blog y ejemplos de posts están en /Users/Akasha/Development/jpl-website/site/content/blog/{en,es} ⏺ Voy a revisar el formato de los posts existentes antes de escribir. Searched for 2 patterns, read 4 files, listed 3 directories (ctrl+o to expand) ⏺ Tengo todo lo que necesito. Voy a generar los 4 posts en EN + ES en paralelo. ★ Insight ───────────────────────────────────── Los posts existentes usan published: false para borradores y la categoría define css_class. La categoría ontoref ya tiene directorios pero sin contenido — ideal para iniciar la serie. ───────────────────────────────────────────────── ⏺ Write(/Users/Akasha/Development/jpl-website/site/content/blog/en/ontoref/ai-kn owledge-tool-who-keeps-it-alive.md) ⎿  Wrote 97 lines to ../jpl-website/site/content/blog/en/ontoref/ai-knowl edge-tool-who-keeps-it-alive.md 2 # Post metadata 4 title: "AI is a Knowledge Tool. But Who Keeps the Knowledge Aliv 5 slug: "ai-knowledge-tool-who-keeps-it-alive" 6 subtitle: "Talisman is right — and stops exactly where the hard 7 excerpt: "Jessica Talisman's KGC 2026 talk is the clearest artic infrastructure and expect reasoning to emerge. She's right. But her solution — build knowledge infrastructure — stops exactly wh ng?"the hard problem begins: who keeps the knowledge from drifti 9 # Publication info 10 author: "Jesús Pérez" … +151 lines (ctrl+o to expand) ⏺ Write(/Users/Akasha/Development/jpl-website/site/content/blog/es/ontoref/la-ia -herramienta-conocimiento-quien-mantiene-vivo.md) ⎿  Wrote 97 lines to ../jpl-website/site/content/blog/es/ontoref/la-ia-he rramienta-conocimiento-quien-mantiene-vivo.md 2 # Post metadata 3 id: "la-ia-herramienta-conocimiento-quien-mantiene-vivo" tiene vivo el conocimiento?"enta de conocimiento. ¿Pero quién man 5 slug: "la-ia-herramienta-conocimiento-quien-mantiene-vivo" 6 subtitle: "Talisman tiene razón — y se detiene exactamente donde 7 excerpt: "La charla de Jessica Talisman en KGC 2026 es la articul ación más clara de por qué fallan las estrategias de AI: las orga erja el razonamiento. Tiene razón. Pero su solución — construir i nfraestructura de conocimiento — se detiene exactamente donde emp ieza el problema difícil: ¿quién evita qu … +162 lines (ctrl+o to expand) ⏺ Write(/Users/Akasha/Development/jpl-website/site/content/blog/en/ontoref/dags- everywhere-none-know-what-they-are.md) ⎿  Wrote 106 lines to ../jpl-website/site/content/blog/en/ontoref/dags-ev erywhere-none-know-what-they-are.md 2 # Post metadata 4 title: "DAGs Are Everywhere. None of Them Know What They Are." 5 slug: "dags-everywhere-none-know-what-they-are" s for execution. Ontoref uses them for knowledge."nbook uses DAG 7 excerpt: "CI/CD pipelines, compilers, runbooks, data orchestrato hem uses DAGs as execution models: this before that, topological sent what the system is, why it exists, or what trade-offs defin e it. That's the gap ontoref fills." 9 # Publication info 10 author: "Jesús Pérez" … +161 lines (ctrl+o to expand) ⏺ Write(/Users/Akasha/Development/jpl-website/site/content/blog/es/ontoref/dags- en-todos-lados-ninguno-sabe-lo-que-es.md) ⎿  Wrote 106 lines to ../jpl-website/site/content/blog/es/ontoref/dags-en -todos-lados-ninguno-sabe-lo-que-es.md 2 # Post metadata 3 id: "dags-en-todos-lados-ninguno-sabe-lo-que-es" 5 slug: "dags-en-todos-lados-ninguno-sabe-lo-que-es"e lo que es." 6 subtitle: "Cada build system, pipeline CI y runbook usa DAGs para 7 excerpt: "Pipelines CI/CD, compiladores, runbooks, orquestadores de datos — todos usan grafos acíclicos dirigidos. Todos sin excep ordenación topológica, resolución de dependencias. Ninguno los us a para representar qué es el sistema, por qué existe, o qué trade 8 -offs lo definen. Ese es el gap que llena ontoref." 9 # Publication i … +167 lines (ctrl+o to expand) ⏺ Write(/Users/Akasha/Development/jpl-website/site/content/blog/en/ontoref/one-p rotocol-three-subjects.md) ⎿  Wrote 122 lines to ../jpl-website/site/content/blog/en/ontoref/one-pro tocol-three-subjects.md 2 # Post metadata 4 title: "One Protocol, Three Subjects" 5 slug: "one-protocol-three-subjects" structure, and yourself"tion applies to your project, your infra 7 excerpt: "Ontoref started as a protocol for software project sel , reflection DAG for what BECOMES — applies without modification changes. The question is identical: what are you, what tensions define you, where are you versus where you intend to be?" 9 # Publication info 10 author: "Jesús Pérez" … +177 lines (ctrl+o to expand) ⏺ Write(/Users/Akasha/Development/jpl-website/site/content/blog/es/ontoref/un-pr otocolo-tres-sujetos.md) ⎿  Wrote 122 lines to ../jpl-website/site/content/blog/es/ontoref/un-prot ocolo-tres-sujetos.md 2 # Post metadata 4 title: "Un protocolo, tres sujetos" 5 slug: "un-protocolo-tres-sujetos" ctura, y a ti mismo"pregunta aplica a tu proyecto, tu infraestru 7 excerpt: "Ontoref comenzó como un protocolo para el auto-conocim lógico para lo que ES, DAG de reflexión para lo que DEVIENE — ap os. El sujeto cambia. La pregunta es idéntica: ¿qué eres, qué te nsiones te definen, dónde estás versus dónde pretendes estar?" 9 # Publication info 10 author: "Jesús Pérez" … +182 lines (ctrl+o to expand) ⏺ Write(/Users/Akasha/Development/jpl-website/site/content/blog/en/ontoref/your- ontology-should-live-with-your-code.md) ⎿  Wrote 106 lines to ../jpl-website/site/content/blog/en/ontoref/your-on tology-should-live-with-your-code.md 2 # Post metadata 4 title: "Your Ontology Should Live With Your Code" 5 slug: "your-ontology-should-live-with-your-code" ure without a home isn't infrastructure at all"wledge infrastruct 7 excerpt: "Enterprise knowledge graphs live in a triplestore maint hanges, the budget gets cut, or the vendor pivots, the knowledge -first knowledge that lives alongside its subject, versioned, que ryable across four surfaces, and federated without a central brok 8 er." 9 # Publication i … +176 lines (ctrl+o to expand) ⏺ Write(/Users/Akasha/Development/jpl-website/site/content/blog/es/ontoref/tu-on tologia-deberia-vivir-con-tu-codigo.md) ⎿  Wrote 106 lines to ../jpl-website/site/content/blog/es/ontoref/tu-onto logia-deberia-vivir-con-tu-codigo.md 2 # Post metadata 3 id: "tu-ontologia-deberia-vivir-con-tu-codigo" 5 slug: "tu-ontologia-deberia-vivir-con-tu-codigo"" 6 subtitle: "Soberanía, federación, y por qué la infraestructura de conocimiento sin hogar no es infraestructura" mantenido por un equipo dedicado en la plataforma de un vendor. Cuando el equipo cambia, el presupuesto se recorta, o el vendor p o: conocimiento soberano y local-first que vive junto a su sujeto , versionado, consultable a través de cuatro superficies, y feder ado sin un broker cent … +186 lines (ctrl+o to expand) ⏺ 8 archivos generados. Resumen de la serie: --- Post 1 — El Yang faltante - EN: en/ontoref/ai-knowledge-tool-who-keeps-it-alive.md - ES: es/ontoref/la-ia-herramienta-conocimiento-quien-mantiene-vivo.md - Argumento: Talisman tiene razón en el diagnóstico, pero governance sin loop operacional es aspiración. Ontoref es las dos mitades. Post 2 — DAGs como conocimiento - EN: en/ontoref/dags-everywhere-none-know-what-they-are.md - ES: es/ontoref/dags-en-todos-lados-ninguno-sabe-lo-que-es.md - Argumento: todos usan DAGs para ejecución, nadie para conocimiento. El doble DAG de ontoref y por qué no existía antes. Post 3 — Los tres sujetos - EN: en/ontoref/one-protocol-three-subjects.md - ES: es/ontoref/un-protocolo-tres-sujetos.md - Argumento: proyecto + infra + personal comparten la misma pregunta estructural y el mismo stack. Post 4 — Soberanía - EN: en/ontoref/your-ontology-should-live-with-your-code.md - ES: es/ontoref/tu-ontologia-deberia-vivir-con-tu-codigo.md - Argumento: jj + Radicle + NATS + cuatro superficies. El knowledge graph que vive con el código es genuinamente tuyo. Todos marcados published: false — borradores listos para revisar antes de publicar. ✻ Sautéed for 8m 22s