82a358f18d
ontoref-derive: #[onto_mcp_tool] attribute macro registers MCP tool unit-structs in
the catalog at link time via inventory::submit!; annotated item is emitted unchanged,
ToolBase/AsyncTool impls stay on the struct. All 34 tools migrated from manual wiring
(net +5: ontoref_list_projects, ontoref_search, ontoref_describe,
ontoref_list_ontology_extensions, ontoref_get_ontology_extension).
validate modes (ADR-018): reads level_hierarchy from workflow.ncl and checks every
.ncl mode for level declared, strategy declared, delegate chain coherent, compose
extends valid. mode resolve <id> shows which hierarchy level handles a mode and why.
--self-test generates synthetic fixtures in a temp dir for CI smoke-testing.
validate run-cargo: two-step Cargo.toml resolution — workspace layout first
(crates/<check.crate>/Cargo.toml), single-crate fallback by package name or repo
basename. Lets the same ADR constraint shape apply to workspace and single-crate repos.
ontology/schemas/manifest.ncl: registry_topology_type contract — multi-registry
coordination, push targets, participant scopes, per-namespace capability.
reflection/requirements/base.ncl: oras ≥1.2.0, cosign ≥2.0.0, sops ≥3.9.0, age
≥1.1.0, restic declared as Hard/Soft requirements with version_min, check_cmd, and
install_hint (ADR-017 toolchain surface).
ADR-019: per-file recipient routing for tenant isolation without multi-vault. Schema
additions: sops.recipient_groups + sops.recipient_rules in ontoref-project.ncl.
secrets-bootstrap generates .sops.yaml from project.ncl in declarative mode. Three
new secrets-audit checks: recipient-routing-coherent, recipient-routing-coverage,
no-multi-vault. Adoption templates: single-team/, multi-tenant/, agent-first/.
Integration templates: domain-producer/, mode-producer/, mode-consumer/.
UI: project_picker surfaces registry badge (⟳ participant) and vault badge
(⛁ vault_id · N, green=declarative / amber=legacy) per project card. Expanded panel
adds collapsible Registry section with namespace, endpoint, and push/pull capability.
manage.html gains Runtime Services card — MCP and GraphQL toggleable without restart
via HTMX POST /ui/manage/services/{service}/toggle.
describe.nu: capabilities JSON includes registry_topology and vault_state per project.
sync.nu: drift check extended to detect //! absence on newly registered crates.
qa.ncl: six entries — credential-vault-best-practice (layered data-flow diagram),
credential-vault-templates (paths A/B/C), credential-vault-troubleshooting (15 named
errors), integration-what-and-why (ADR-042 OCI federation), integration-how-to-implement,
integration-troubleshooting.
on+re: core.ncl + manifest.ncl updated to reflect OCI, MCP, and mode-hierarchy nodes.
Deleted stale presentation assets (2026-02 slides + voice notes).
862 lines
40 KiB
Text
862 lines
40 KiB
Text
▐▛███▜▌ 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
|