ontoref/steal_this_deck_session.txt

 ▐▛███▜▌   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