jesus/ontoref
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ontoref/assets/presentation/docs/2026-04-24-234910-me-planteo-estas-dos-propuestas-para-un-open-spac.txt
Jesús Pérez 82a358f18d
Some checks failed
Nickel Type Check / Nickel Type Checking (push) Has been cancelled
Details
Rust CI / Security Audit (push) Has been cancelled
Details
Rust CI / Check + Test + Lint (push) Has been cancelled
Details
feat: #[onto_mcp_tool] catalog, OCI credential vault layer, validate ADR-018 mode hierarchy 
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).
2026-05-12 04:46:15 +01:00

4668 lines
No EOL
292 KiB
Text
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

╭─── Claude Code v2.1.119 ─────────────────────────────────────────────────────╮
│ │ Recent activity │
│ Welcome back Jesús! │ No recent activity │
│ │ ─────────────────────── │
│ ▐▛███▜▌ │ What's new │
│ ▝▜█████▛▘ │ `/config` settings (th… │
│ ▘▘ ▝▝ │ Added `prUrlTemplate` … │
│ Sonnet 4.6 · Claude Max · jpl@jesusperez.pro's │ Added `CLAUDE_CODE_HID… │
│ Organization │ /release-notes for more │
│ /…/Akasha/Development/ontoref/assets/presentation │ │
╰──────────────────────────────────────────────────────────────────────────────╯
❯ me planteo estas dos propuestas para un open space y quiero unas slides sobre
ontologia y reflection como conceptos base del proyecto ontoref
es para Desarrolladores, puntos base para tener en cuenta
Dos propuestas
▎ "Ontología en mis proyectos: para que la IA sepa lo que no sabe y yo me
aclare"
Tesis: La ontología no es para la IA. Es para ti. La IA se beneficia como
efecto secundario.
Puntos clave:
- Sin modelo explícito, tus proyectos viven en tu cabeza — y lo que vive
solo en tu cabeza no se
puede validar.
- Formalizar invariantes, tensiones y estado actual te fuerza a saber qué
es verdad ahora mismo.
- La IA consume ese modelo y deja de inventarse contexto — opera sobre lo
que tú ya clarificaste.
- El valor real: el proceso de escribir la ontología es donde te aclaras
tú, no la IA.
Para el debate:
- ¿No es suficiente con un buen README?
- ¿Qué diferencia una ontología de una lista de decisiones?
- ¿Quién mantiene esto actualizado cuando el proyecto cambia rápido?
más que ver con ontref
▎ "Apocalipsis: la IA gestiona tu infra, ¿sabes lo que está pasando?"
Tesis: La IA puede declarar tu infra. No puede entenderla por ti.
Puntos clave:
- Declarativo != comprensión. Describes el estado deseado, no el por qué.
- La IA opera sobre forma, no sobre significado. Genera YAML correcto para
el problema equivocado.
- Sin ontología de tu infra — qué son las cosas, cómo se relacionan, qué no
puede romperse — no
tienes control, tienes ilusión de control.
- Cuando falla a las 2am, el Terraform generado no te dice qué asumió.
Para el debate:
- ¿Es diferente a copiar Stack Overflow?
- ¿Dónde está el mínimo de comprensión necesario?
- ¿Las plataformas internas resuelven esto o lo esconden?
más que ver con /Users/Akasha/project-provisioning/provisioning/
La idea es generar las slides en
/Users/Akasha/Development/ontoref/assets/presentation/
siguiendo el patrón actual de slides.md que puedes sobreescribir
⏺ Voy a leer los archivos existentes de presentación para entender el patrón.
Read 1 file, listed 1 directory (ctrl+o to expand)
⏺ Tengo el patrón claro — Slidev dark, español, componentes Vue, speaker notes.
Voy a escribir las slides ahora.
★ Insight ─────────────────────────────────────
El archivo usa Slidev con v-click para animaciones incrementales y el patrón
box-highlight border-l-4 como elemento visual recurrente. Las speaker notes en
<!-- --> son parte del contrato de presentación — no decoración. El flujo
narrativo real va del problema a la tesis, no al revés.
─────────────────────────────────────────────────
⏺ Write(slides.md)
⎿  Added 443 lines, removed 846 lines
1 ---
2 theme: default
3 -title: Ontology and Reflection
3 +title: Ontología y Reflection — lo que la IA no puede entender
+por ti
4 titleTemplate: '%s - OntoRef'
5 layout: cover
6 -keywords: Nickel,Nushell,Ontology,Reflection,StratumIOps
6 +keywords: Ontología,Reflection,IA,Infraestructura,OntoRef,Nushe
+ll,Nickel
7 download: true
8 -exportFilename: OntoRef
8 +exportFilename: ontoref-openspace
9 monaco: true
10 remoteAssets: true
11 selectable: true
...
27 class: 'justify-center flex flex-cols'
28 ---
29
30 -<h1 class="font-medium">Ontology & Reflection</h1>
30 +<h1 class="font-medium text-3xl leading-tight">La IA gestiona t
+u infra.<br><span class="text-orange-400">¿Sabes lo que está pa
+sando?</span></h1>
31
32 -<h2 class="flex justify-center mt-5 font-medium text-orange-400
-">
33 - <img class="-mt-2 h-32" src="/ontoref-text.svg">
34 -</h2>
35 -
36 -<div class="flex justify-center mt-3 text-gray-400 text-lg ital
-ic">
37 - Typing the invisible. Verifying the obvious. Sealing what mat
-ters.
32 +<div class="flex justify-center mt-6 text-gray-400 text-lg ital
+ic">
33 + Ontología y Reflection como base de un proyecto que se entien
+de a sí mismo.
34 </div>
35
40 -<div class="flex justify-center">
41 - <img class="mt-8 w-40" src="/jesusperez_w.svg">
36 +<div class="flex justify-center mt-8">
37 + <img class="w-40" src="/jesusperez_w.svg">
38 </div>
39
44 -<div class="flex justify-center">
45 - <img class="mt-8 w-40" src="/ontoref_img.svg">
46 -</div>
47 -
40 <style scoped>
41 h1, h2, p { z-index: 10; }
42 </style>
...
44 <Footer />
45
46 <!--
55 -Open with silence. Let the subtitle land.
56 -This talk is not about tools — it is about the epistemic contr
-act between code and understanding.
47 +Abrir con pausa. El título es una pregunta directa.
48 +No es retórica — la mayoría no sabe. Y el punto es exactamente
+ ese.
49 +Esta charla no es sobre herramientas. Es sobre qué pasa cuando
+ externalizas comprensión.
50 -->
51
52 ---
60 -layout: two-cols
53 +layout: default
54 ---
55
63 -# ¿Qué estamos resolviendo?
56 +# El problema no es la herramienta
57
58 +<div class="grid grid-cols-2 gap-8 mt-4">
59 +
60 <div>
61
67 -**Los problemas**
62 +**Lo que la IA hace bien**
63
64 <div class="mt-3 space-y-3">
65
66 <div class="flex items-start gap-2">
72 - <span class="text-red-500 font-bold text-sm mt-1">🔴</span>
73 - <div><span class="text-gray-200 font-semibold">Epistemic dri
-ft</span><br><span class="text-gray-400 text-sm">El código hac
-e X, el equipo cree que hace Y.<br> Silencioso. Acumulativo.</
-span></div>
67 + <span class="text-green-400 font-bold text-sm mt-1">✓</span>
68 + <div class="text-gray-300 text-sm">Genera YAML correcto sint
+ácticamente</div>
69 </div>
70
71 <div class="flex items-start gap-2">
77 - <span class="text-red-500 font-bold text-sm mt-1">🔴</span>
78 - <div><span class="text-gray-200 font-semibold">Multi-actor c
-ollision</span><br><span class="text-gray-400 text-sm">Humano
-+ agente IA escriben al mismo fichero,<br> sin coordinación.</
-span></div>
72 + <span class="text-green-400 font-bold text-sm mt-1">✓</span>
73 + <div class="text-gray-300 text-sm">Completa Terraform que nu
+nca rompe el plan</div>
74 </div>
75
76 <div class="flex items-start gap-2">
82 - <span class="text-orange-400 font-bold text-sm mt-1">🟠</spa
-n>
83 - <div><span class="text-gray-200 font-semibold">Decision amne
-sia</span><br><span class="text-gray-400 text-sm">¿Por qué se
-tomó esta decisión? ¿Quién la autorizó?</span></div>
77 + <span class="text-green-400 font-bold text-sm mt-1">✓</span>
78 + <div class="text-gray-300 text-sm">Rellena gaps de configura
+ción con defaults razonables</div>
79 </div>
80
81 <div class="flex items-start gap-2">
87 - <span class="text-orange-400 font-bold text-sm mt-1">🟠</spa
-n>
88 - <div><span class="text-gray-200 font-semibold">Config schizo
-phrenia</span><br><span class="text-gray-400 text-sm">Staging
-funciona, prod no. ¿Qué campo cambió y cuándo?</span></div>
82 + <span class="text-green-400 font-bold text-sm mt-1">✓</span>
83 + <div class="text-gray-300 text-sm">Traduce intención en form
+a declarativa</div>
84 </div>
85
86 </div>
87
88 </div>
89
95 -::right::
96 -
90 <div>
91
92 +<v-click>
93 +
94 +**Lo que la IA no puede hacer**
95 +
96 +<div class="mt-3 space-y-3">
97 +
98 <div class="flex items-start gap-2">
100 - <span class="text-orange-400 font-bold text-sm mt-1">🟠</spa
-n>
101 - <div><span class="text-gray-200 font-semibold">Docs como art
-efactos muertos</span><br><span class="text-gray-400 text-sm">
-Escritas una vez, olvidadas, nunca actualizadas.</span></div>
99 + <span class="text-red-400 font-bold text-sm mt-1">✗</span>
100 + <div class="text-gray-300 text-sm">Saber <em>por qué</em> es
+e servicio no puede escalar a N réplicas</div>
101 </div>
102
104 -<div class="flex items-start gap-2 mt-2">
105 - <span class="text-yellow-400 font-bold text-sm mt-1">🟡</spa
-n>
106 - <div><span class="text-gray-200 font-semibold">Agent con ceg
-uera</span><br><span class="text-gray-400 text-sm">Los agentes
- IA empiezan sin contexto,<br> violan invariantes establecidas
-.</span></div>
103 +<div class="flex items-start gap-2">
104 + <span class="text-red-400 font-bold text-sm mt-1">✗</span>
105 + <div class="text-gray-300 text-sm">Conocer la tensión que ex
+iste entre latencia y consistencia en <em>tu</em> sistema</div
+>
106 </div>
107
109 -<v-click>
108 +<div class="flex items-start gap-2">
109 + <span class="text-red-400 font-bold text-sm mt-1">✗</span>
110 + <div class="text-gray-300 text-sm">Recordar la decisión que
+tomaste en diciembre y por qué descartaste la alternativa</div
+>
111 +</div>
112
111 -<div class="mt-2 text-xs text-gray-400 space-y-2 font-mono">
113 +<div class="flex items-start gap-2">
114 + <span class="text-red-400 font-bold text-sm mt-1">✗</span>
115 + <div class="text-gray-300 text-sm">Entender qué no puede rom
+perse sin coordinación entre equipos</div>
116 +</div>
117
113 -**Ejemplo: desincronización real**
118 +</div>
119
115 -```bash
116 -# Documentación (2024-01)
117 -config.max_retries = 3
120 +</v-click>
121
119 -# Código actual (después de cambio sin registrar)
120 -config.max_retries = 7
122 +<v-click>
123
122 -# Equipo cree que está usando 3 ✗
123 -# Sistema usa 7 silenciosamente ✓
124 -# Nadie sabe cuándo cambió ni por qué
125 -```
126 -
124 +<div class="mt-6 border-l-4 border-orange-500 pl-4 text-sm tex
+t-gray-300">
125 + Declarativo ≠ comprensión.<br>
126 + Describes el estado deseado, no el <em>por qué</em>.
127 </div>
128
129 </v-click>
130
131 </div>
132
133 +</div>
134 +
135 <Footer />
136
137 <!--
136 -Pause after each severity badge. The audience will recognize t
-hese — they have lived this.
137 -Goal is recognition, not education. Ask silently: "how many of
- these are in your project right now?"
138 +La IA genera forma correcta para el problema equivocado.
139 +El YAML válido es el problema mínimo. El problema real es que
+nadie sabe qué asumió.
140 -->
141
142 ---
143 layout: default
144 ---
145
144 -# El coste de ignorarlo
146 +# Las 2am — cuando el Terraform no habla
147
148 <div class="grid grid-cols-2 gap-8 mt-4">
149
150 <div>
151
150 -<div class="box-highlight mt-2 font-mono text-xs">
152 +**Lo que ves cuando falla**
153
154 +<div class="mt-3 font-mono text-xs text-gray-300">
155 +
156 ```text
153 -Deuda técnica → arreglable
154 -Deuda epistémica → sistémica
155 -Deuda de confianza → letal
157 +Error: Error creating Instance:
158 + googleapi: Error 400: Invalid value
159 + for field 'resource.machineType'
160 +
161 +# El plan pasó. El apply falló.
162 +# ¿Qué asumió el agente?
163 +# ¿Qué región eligió? ¿Por qué ese tipo?
164 +# ¿Hay una restricción de org que no sabía?
165 ```
166
167 </div>
168
169 <v-click>
170
162 -<div class="mt-4 space-y-5 text-xs text-gray-300">
171 +<div class="mt-4 font-mono text-xs text-gray-400">
172
164 -<div class="border-l-2 border-red-500 pl-2">
165 - <div class="font-semibold text-red-300">Técnica</div>
166 - <div class="text-gray-400">Refactoriza, reescribe, corrige.<
-/div>
167 - <div class="text-gray-500 text-xs">1-3 sprints</div>
168 -</div>
173 +```yaml
174 +# Lo que generó la IA (hace 6 semanas)
175 +resource "google_compute_instance" "api" {
176 + machine_type = "e2-medium" # "razonable"
177 + zone = "us-central1-a" # "por defecto"
178 +}
179
170 -<div class="border-l-2 border-orange-500 pl-2">
171 - <div class="font-semibold text-orange-300">Epistémica</div>
172 - <div class="text-gray-400">Acumula silenciosamente. No sabes
- dónde.</div>
173 - <div class="text-gray-500 text-xs">Crece cada semana</div>
174 -</div>
180 +# Lo que tu política de org requiere
181 +# → solo europe-west1, solo n2-standard-*
182 +# → la IA no lo sabía porque tú tampoco lo escribiste
183 +```
184
176 -<div class="border-l-2 border-yellow-600 pl-2">
177 - <div class="font-semibold text-yellow-300">Confianza</div>
178 - <div class="text-gray-400">Se disuelve cuando se descubre el
- drift.</div>
179 - <div class="text-gray-500 text-xs">Imposible reparar rápido<
-/div>
185 </div>
186
182 -</div>
183 -
187 </v-click>
188
189 </div>
...
192
193 <v-click>
194
192 -<div class="mt-2 text-gray-300">
195 +**El patrón que se repite**
196
194 -**Escenario: 6 meses de ignorar**
197 +<div class="mt-3 space-y-3 text-sm">
198
196 -<div class="mt-3 font-mono text-xs space-y-2 text-gray-400">
199 +<div class="border-l-2 border-red-500 pl-3">
200 + <div class="text-red-300 font-semibold">Sin modelo explícito
+</div>
201 + <div class="text-gray-400">La IA inventa contexto plausible.
+ Tú asumes que sabe. Falla en prod.</div>
202 +</div>
203
198 -```yaml
199 -Mes 1: "Solo refactorizar esto"
200 -Mes 2: "Documentación está desactualizada"
201 -Mes 3: "¿Por qué prod falla y staging no?"
202 -Mes 4: "Nadie sabe quién cambió qué"
203 -Mes 5: Pánico. Rollback arriesgado.
204 -Mes 6: Equipo rechaza cambios nuevos.
205 - "No confiamos sin entender"
206 -```
204 +<div class="border-l-2 border-orange-500 pl-3">
205 + <div class="text-orange-300 font-semibold">Con Stack Overflo
+w</div>
206 + <div class="text-gray-400">Copias código sin entender el sup
+uesto. Al menos tú lo buscaste.</div>
207 +</div>
208
209 +<div class="border-l-2 border-yellow-500 pl-3">
210 + <div class="text-yellow-300 font-semibold">Con la IA</div>
211 + <div class="text-gray-400">El agente genera con confianza. L
+a confianza es contagiosa. El error también.</div>
212 </div>
213
214 </div>
...
217
218 <v-click>
219
216 -<div class="mt-8 text-gray-300 text-base leading-7 border-l-4
-border-orange-500 pl-4">
217 - Estos problemas no tienen solución técnica.<br>
218 - Tienen solución de <em>arquitectura</em>.
220 +<div class="mt-6 text-base font-semibold text-gray-200 border-
+l-4 border-orange-500 pl-4">
221 + La diferencia con Stack Overflow:<br>
222 + <span class="text-gray-400 font-normal text-sm">Al menos ahí
+ buscabas activamente.<br>Con la IA, delegas también la búsque
+da.</span>
223 </div>
224
225 </v-click>
...
228
229 </div>
230
231 +<Footer />
232 +
233 +<!--
234 +Este slide es el que el público siente. Todos tienen una histo
+ria de "la IA lo generó y pareció bien".
235 +La pregunta es: ¿cuándo lo descubriste? ¿Staging? ¿Prod? ¿6 me
+ses después?
236 +-->
237 +
238 ---
239 layout: default
240 ---
241
231 -<h1 class="-mt-5"> Verdad y operación — dos fuerzas que deben
-coexistir </h1>
242 +# Tu proyecto vive en tu cabeza
243
244 <div class="grid grid-cols-2 gap-8 mt-4">
245
235 -<div class="border-l-4 border-blue-500 pl-4">
246 +<div>
247
237 -**Yin — la capa formal**
248 +**Lo que vive solo en tu cabeza**
249
239 -*Lo que debe ser verdad*
240 -
250 <div class="mt-3 space-y-2 text-sm text-gray-300">
251
243 -- **Nickel schemas** → corrección estructural<br> en tiempo de
- definición
244 -- **ADR constraints** → "esto nunca puede violarse"
245 -- **Config seals** → estados sellados, verificables con sha256
246 -- **Ontology invariants** → lo que no puede cambiar <br> sin u
-n nuevo ADR
247 -- **Hashes matemáticos** → prueba de qué fue sellado<br> y cuá
-ndo
252 +<div class="flex items-start gap-2">
253 + <span class="text-orange-400 text-sm mt-1">→</span>
254 + <div>Por qué este servicio no puede tener más de 3 réplicas<
+/div>
255 +</div>
256
257 +<div class="flex items-start gap-2">
258 + <span class="text-orange-400 text-sm mt-1">→</span>
259 + <div>Qué pasó cuando intentamos escalar en enero y por qué f
+allamos</div>
260 </div>
261
262 +<div class="flex items-start gap-2">
263 + <span class="text-orange-400 text-sm mt-1">→</span>
264 + <div>La tensión entre el equipo de plataforma y el de produc
+to sobre quién controla el networking</div>
265 </div>
266
253 -<div class="border-l-4 border-orange-500 pl-4">
254 -
255 -**Yang — la capa operacional**
256 -
257 -*Cómo las cosas se mueven y cambian*
258 -
259 -<div class="-mt-2 space-y-2 text-sm text-gray-300">
260 -
261 -- **Nu commands** → transformación estructurada de datos
262 -- **Actors** (human/agent/CI) → mismo protocolo,<br> distintas
- capacidades
263 -- **Register flow** → captura cambios,<br> los enruta al artef
-acto correcto
264 -- **Mode definitions** → secuencias de operaciones<br> con ver
-ificación
265 -- **Pre-commit hooks** → sincronización forzada <br>en el mome
-nto del commit
266 -
267 +<div class="flex items-start gap-2">
268 + <span class="text-orange-400 text-sm mt-1">→</span>
269 + <div>Qué alternativa se rechazó y por qué</div>
270 </div>
271
272 +<div class="flex items-start gap-2">
273 + <span class="text-orange-400 text-sm mt-1">→</span>
274 + <div>Qué invariante no puede violarse sin romper el acuerdo
+con el equipo de seguridad</div>
275 </div>
276
277 </div>
278
279 <v-click>
280
275 -<div class="mt-1 border border-gray-700 rounded p-4 bg-gray-90
-0 text-sm text-gray-300 font-mono leading-7">
276 -
277 -```text
278 -Yang sin Yin = fluido pero caótico. Cualquier cosa puede cam
-biar. Nada es verificable.
279 -Yin sin Yang = correcto pero inútil. Schemas perfectos sin op
-eraciones = documentación muerta.
280 -```
281 -
282 -<div class="text-orange-400 text-center mt-2 font-sans font-se
-mibold">El sistema vive en la coexistencia.</div>
283 -
281 +<div class="mt-5 border-l-4 border-red-500 pl-4 text-sm text-g
+ray-400">
282 + Lo que vive solo en tu cabeza <strong class="text-red-300">n
+o se puede validar</strong>.<br>
283 + No puede consultarlo un agente. No puede consultarlo un comp
+añero nuevo.<br>
284 + No puedes consultarlo tú mismo en 6 meses.
285 </div>
286
287 </v-click>
288
288 -<Footer />
289 +</div>
290
290 -<!--
291 -The Yin/Yang is not metaphor for aesthetics — it is the archit
-ectural duality.
292 -Pure formal layer without operation is a museum. Pure operatio
-n without formal layer is controlled chaos.
293 -Hold the tension statement at the end. It is the thesis.
294 --->
291 +<div>
292
296 ----
297 -layout: center
298 ----
293 +<v-click>
294
300 -# Los ingredientes
295 +**La trampa del README**
296
302 -<div class="mt-2 space-y-3">
297 +<div class="mt-3 font-mono text-xs text-gray-400">
298
304 -<div class="border-l-4 border-blue-400 pl-4 py-2 bg-gray-900 r
-ounded-r">
305 - <div class="text-blue-300 font-mono font-semibold text-sm">C
-APA DECLARATIVA &nbsp;·&nbsp; Nickel</div>
306 - <div class="text-gray-400 text-sm mt-1"><code>.ontology/</co
-de> &nbsp;·&nbsp; <code>adrs/</code> &nbsp;·&nbsp; <code>refle
-ction/schemas/</code> &nbsp;·&nbsp; <code>reflection/configs/<
-/code></div>
307 - <div class="text-gray-500 text-xs mt-1">Tipos fuertes, contr
-atos, enums. Falla en definición, no en runtime.</div>
308 -</div>
299 +```markdown
300 +# Mi Proyecto
301
310 -<div class="border-l-4 border-orange-400 pl-4 py-2 bg-gray-900
- rounded-r">
311 - <div class="text-orange-300 font-mono font-semibold text-sm"
->CAPA OPERACIONAL &nbsp;·&nbsp; Nushell</div>
312 - <div class="text-gray-400 text-sm mt-1"><code>adr</code> &nb
-sp;·&nbsp; <code>register</code> &nbsp;·&nbsp; <code>config</c
-ode> &nbsp;·&nbsp; <code>backlog</code> &nbsp;·&nbsp; <code>fo
-rms</code> &nbsp;·&nbsp; <code>prereqs</code></div>
313 - <div class="text-gray-500 text-xs mt-1">Pipelines tipadas so
-bre datos estructurados. No streams de texto.</div>
314 -</div>
302 +Este servicio hace X. Está desplegado en GCP.
303 +Usa Terraform. Tiene 3 entornos: dev, staging, prod.
304
316 -<div class="border-l-4 border-green-400 pl-4 py-2 bg-gray-900
-rounded-r">
317 - <div class="text-green-300 font-mono font-semibold text-sm">
-PUNTO DE ENTRADA &nbsp;·&nbsp; Bash → Nu</div>
318 - <div class="text-gray-400 text-sm mt-1"><code>stratum.sh</co
-de> &nbsp;·&nbsp; actor detection &nbsp;·&nbsp; locking &nbsp;
-·&nbsp; <code>NICKEL_IMPORT_PATH</code></div>
319 - <div class="text-gray-500 text-xs mt-1">Un único entry point
-. Detecta actor, adquiere lock, despacha al módulo Nu correcto
-.</div>
320 -</div>
305 +## Arquitectura
306 +Ver diagrama (desactualizado desde marzo).
307
322 -<div class="border-l-4 border-purple-400 pl-4 py-2 bg-gray-900
- rounded-r">
323 - <div class="text-purple-300 font-mono font-semibold text-sm"
->GRAFO DE CONOCIMIENTO &nbsp;·&nbsp; Ontología + ADRs</div>
324 - <div class="text-gray-400 text-sm mt-1">nodes &nbsp;·&nbsp;
-invariants &nbsp;·&nbsp; gates &nbsp;·&nbsp; dimensions &nbsp;
-·&nbsp; states</div>
325 - <div class="text-gray-500 text-xs mt-1">El sistema sabe qué
-sabe. Actor-agnostic. Machine-queryable.</div>
326 -</div>
308 +## Decisiones
309 +- Elegimos PostgreSQL porque MySQL no nos gustaba.
310 +- Usamos gRPC internamente.
311 +```
312
328 -<div class="border-l-4 border-yellow-400 pl-4 py-2 bg-gray-900
- rounded-r">
329 - <div class="text-yellow-300 font-mono font-semibold text-sm"
->ESTADOS SELLADOS &nbsp;·&nbsp; Config + Historia</div>
330 - <div class="text-gray-400 text-sm mt-1">profiles &nbsp;·&nbs
-p; sha256 seals &nbsp;·&nbsp; audit trail &nbsp;·&nbsp; rollba
-ck</div>
331 - <div class="text-gray-500 text-xs mt-1">Inmutabilidad verifi
-cable. Drift detection. Trazabilidad completa ADR/PR/bug.</div
->
313 </div>
314
334 -</div>
315 +<div class="mt-4 space-y-2 text-sm text-gray-400">
316
336 -<Footer />
337 -
338 -<!--
339 -This is the map, not the territory. Each layer will get its ow
-n slide.
340 -Point bottom-up: sealed states give you history; the graph giv
-es you meaning; the entry point gives you discipline.
341 --->
342 -
343 ----
344 -layout: default
345 ----
346 -
347 -# Nickel — configuración con tipos, sin runtime
348 -
349 -<div class="grid grid-cols-2 gap-8 mt-4">
350 -
351 -<div>
352 -
353 -**Qué es Nickel**
354 -
355 -<div class="text-sm text-gray-300 space-y-1 mt-2">
356 -
357 -- Lenguaje de configuración con tipos fuertes (de Tweag)
358 -- Puramente declarativo: sin efectos secundarios, sin loops, s
-in runtime
359 -- Superset de JSON: JSON válido es Nickel válido
360 -- Imports: <small>`let s = import "schema.ncl" in`</small>
361 -- Contratos: `field | TypeName` — verificado al merge
362 -- Enums tipados: <small>`[| 'Proposed, 'Accepted, 'Superseded
-|]`</small>
363 -- Registros abiertos/cerrados: <br> <small>`{ _: String }` vs
-`{ field | String }`</small>
364 -- `nickel export file.ncl` → JSON estable pipelines Nu
365 -
317 +<div class="flex items-start gap-2">
318 + <span class="text-red-400 text-sm">✗</span>
319 + <div>No dice qué no puede cambiar</div>
320 </div>
321
368 -<div class="mt-4 text-lg text-gray-500 border-l-2 border-orang
-e-500 pl-3 italic">
369 - El sistema de tipos <em>es</em> la documentación.
322 +<div class="flex items-start gap-2">
323 + <span class="text-red-400 text-sm">✗</span>
324 + <div>No captura las alternativas rechazadas ni el por qué</d
+iv>
325 </div>
326
327 +<div class="flex items-start gap-2">
328 + <span class="text-red-400 text-sm">✗</span>
329 + <div>No es consultable ni verificable — es prosa</div>
330 </div>
331
374 -<div>
375 -
376 -**Por qué no alternativas**
377 -
378 -<div class="font-mono text-xs text-gray-400 -mt-4 space-y-1">
379 -
380 -```text
381 -YAML → sin tipos, whitespace-sensitive,
382 - coerciones implícitas
383 -TOML → sin tipos ≥ primitivos, sin imports
384 -JSON → sin comentarios, sin imports, sin tipos
385 -HCL → efectos secundarios, no es config pura
386 -CUE → similar pero peor historia de imports
387 -KCL → tipos + validación, pero vendedor
388 - lenguaje opaco
389 -```
390 -
332 +<div class="flex items-start gap-2">
333 + <span class="text-red-400 text-sm">✗</span>
334 + <div>No refleja el estado actual — refleja el estado de cuan
+do se escribió</div>
335 </div>
336
393 -<div class="mt-i2 text-lg text-gray-300 font-semibold">Por qué
- aquí específicamente</div>
394 -
395 -<div class="text-xs text-gray-400 mt-1 space-y-1">
396 -
397 -- ADR constraints necesitan typecheck, no validación manual
398 -- Perfiles de config deben fallar en definición, no en runtime
399 -- `nickel export` produce JSON estable para consumo Nu
400 -
337 </div>
338
403 -<v-click>
404 -
405 -<div class="mt-1 font-mono text-xs">
406 -
407 -```bash
408 -# YAML: silently accepts garbage
409 -actor: developr # typo, accepted
410 -# Nickel: rejected at typecheck
411 -{ actor | [| 'developer, 'agent, 'ci |] = "developr" }
412 -# ^^^^^^^^^
413 -# error: tag not in enum type
414 -```
415 -
416 -</div>
417 -
339 </v-click>
340
341 </div>
...
345 <Footer />
346
347 <!--
427 -The before/after example is the punchline. Let it sit.
428 -"The type system IS the documentation" — this is the core Nick
-el thesis. Not a feature, the philosophy.
348 +La pregunta clave que lanzar al público: ¿cuándo fue la última
+ vez que actualizaste tu README?
349 +Un README es documentación. Una ontología es un modelo vivo de
+l sistema.
350 -->
351
352 ---
432 -layout: default
353 +layout: center
354 ---
355
435 -# Nushell — datos estructurados, no streams de texto
356 +# La tesis
357
437 -<div class="grid grid-cols-2 gap-8 mt-4">
358 +<div class="mt-8 text-center space-y-6">
359
439 -<div>
360 +<div class="text-3xl font-semibold text-gray-100">
361 + La ontología no es para la IA.
362 +</div>
363
441 -**Shell tradicional: texto opaco**
442 -
443 -<div class="mt-2 font-mono text-xs">
444 -
445 -```bash
446 -# Bash: parsear texto, error-prone
447 -grep 'severity' adrs/adr-001.json |\
448 - python3 -c "import sys,json; ..."
449 -```
450 -
364 +<div class="text-3xl font-semibold text-orange-400">
365 + Es para ti.
366 </div>
367
368 <v-click>
369
455 -<div class="mt-4 text-sm font-semibold text-gray-200">Nushell:
- records nativos</div>
456 -
457 -<div class="mt-2 font-mono text-xs">
458 -
459 -```nu
460 -nickel export adrs/adr-001.ncl
461 - | from json
462 - | get constraints
463 - | where severity == "Hard"
464 - | select id claim
465 -```
466 -
370 +<div class="mt-8 text-lg text-gray-400 max-w-2xl mx-auto leadi
+ng-8">
371 + Formalizar invariantes, tensiones y estado actual<br>
372 + te fuerza a saber qué es verdad <em>ahora mismo</em>.
373 </div>
374
469 -<div class="mt-3 font-mono text-xs text-gray-500">
375 +</v-click>
376
471 -```text
472 -╭───┬────────────┬──────────────────────────────╮
473 -│ # │ id │ claim │
474 -├───┼────────────┼──────────────────────────────┤
475 -│ 0 │ adr-001-c1 │ nickel export must succeed… │
476 -│ 1 │ adr-001-c2 │ schema is sole source of… │
477 -╰───┴────────────┴──────────────────────────────╯
478 -```
377 +<v-click>
378
379 +<div class="mt-6 text-lg text-gray-400 max-w-2xl mx-auto leadi
+ng-8">
380 + La IA se beneficia como efecto secundario.<br>
381 + Opera sobre lo que <em>tú ya clarificaste</em>.
382 </div>
383
384 </v-click>
385
484 -</div>
485 -
486 -<div>
487 -
386 <v-click>
387
490 -**Nickel → Nu → Bash — tres capas, tres roles**
491 -
492 -<div class="mt-3 space-y-3 text-sm">
493 -
494 -<div class="box-highlight border-l-4 border-blue-500 pl-3 py-2
-">
495 - <div class="font-semibold text-blue-300">Nickel exporta JSON
- tipado</div>
496 - <div class="text-gray-400 text-xs">Nunca strings mágicos. Co
-ntratos en la definición, no en runtime.</div>
388 +<div class="mt-8 text-base text-gray-500 max-w-2xl mx-auto bor
+der-t border-gray-700 pt-6">
389 + El valor real: el proceso de <strong class="text-gray-300">e
+scribir la ontología</strong><br>
390 + es donde te aclaras tú, no la IA.
391 </div>
392
499 -<div class="box-highlight border-l-4 border-orange-400 pl-3 py
--2">
500 - <div class="font-semibold text-orange-300">Nu consume estruc
-turas</div>
501 - <div class="text-gray-400 text-xs">Tables, records, pipeline
-s. Filter, sort, merge — sin awk ni sed.</div>
502 -</div>
503 -
504 -<div class="box-highlight border-l-4 border-gray-500 pl-3 py-2
-">
505 - <div class="font-semibold text-gray-300">Bash orquesta proce
-sos</div>
506 - <div class="text-gray-400 text-xs">Locking, signals, exec. S
-olo lo que bash hace de forma nativa.</div>
507 -</div>
508 -
509 -</div>
510 -
511 -<div class="mt-4 font-mono text-xs">
512 -
513 -```nu
514 -# Constraints Hard del sistema completo
515 -glob "adrs/adr-*.ncl"
516 -| each { |f| nickel export $f | complete | get stdout }
517 -| each { from json }
518 -| where status == "Accepted"
519 -| get constraints | flatten
520 -| where severity == "Hard"
521 -```
522 -
523 -</div>
524 -
393 </v-click>
394
395 </div>
396
529 -</div>
530 -
397 <Footer />
398
399 <!--
534 -Nu is not "better bash". It is a different semantic layer.
535 -Text pipelines are broken by design — structured pipelines are
- the fix.
536 -Nickel/Nu/Bash: each covers what the others cannot. The divisi
-on is deliberate.
400 +Pausa larga después del primer par de líneas. Dejar que aterri
+ce.
401 +La gente espera que digas "la IA necesita contexto". La invers
+ión es el punto.
402 -->
403
404 ---
405 layout: default
406 ---
407
543 -# DAGs y FSMs — grafos acíclicos y máquinas de estado
408 +# Ontología ≠ lista de decisiones
409
410 <div class="grid grid-cols-2 gap-8 mt-4">
411
412 <div>
413
549 -**FSM: ciclo de vida de un ADR**
414 +**Una lista de decisiones**
415
551 -<div class="mt-3 font-mono text-xs">
416 +<div class="mt-3 font-mono text-xs text-gray-400">
417
418 ```text
554 - ┌──────────┐ adr accept ┌──────────┐
555 - │ Proposed │ ───────────▶ │ Accepted │
556 - └──────────┘ └──────────┘
557 - │ new ADR
558 - │ supersedes
559 - ▼
560 - ┌────────────┐
561 - │ Superseded │
562 - └────────────┘
419 +- Elegimos Kubernetes
420 +- Usamos Helm para despliegues
421 +- PostgreSQL como base de datos primaria
422 +- gRPC entre servicios internos
423 +- OAuth2 para autenticación externa
424 ```
425
426 </div>
427
567 -<div class="mt-3 text-sm text-gray-300">Transiciones typecheck
--enforced en Nickel:</div>
568 -
569 -<div class="font-mono text-xs mt-1">
570 -
571 -```text
572 -status | [| 'Proposed, 'Accepted, 'Superseded |]
573 -superseded_by | String | default = ""
574 -```
575 -
428 +<div class="mt-4 text-sm text-gray-500">
429 +Captura el <em>qué</em>. No captura el <em>por qué</em>,<br>
430 +las alternativas rechazadas, ni las consecuencias.
431 </div>
432
578 -<v-click>
579 -
580 -<div class="mt-4 text-xs text-gray-400">
581 -Las transiciones inválidas no existen <br>
582 -— el tipo las elimina del espacio de posibilidades.<br>
583 -Un ADR no puede volver a Proposed.<br>
584 -Superseded no puede tener constraints activas.
433 </div>
434
587 -</v-click>
588 -
589 -</div>
590 -
435 <div>
436
593 -**DAG: ontología como grafo de dependencias**
437 +<v-click>
438
595 -<div class="mt-3 font-mono text-xs text-gray-300">
439 +**Una ontología**
440
597 -```text
598 -invariante: backend-agnostic-core
599 - └─ tensión: nickel-as-canonical-schema
600 - └─ gate: nickel-primacy-gate [activa]
601 - └─ protege: nickel-integration-depth
441 +<div class="mt-3 space-y-2 text-sm">
442
603 -invariante: zero-external-runtime-core
604 - └─ gate: core-dependency-gate [activa]
605 - └─ protege: backend-agnostic-core
606 -```
443 +<div class="border-l-4 border-blue-400 pl-3 py-1 bg-gray-900 r
+ounded-r">
444 + <div class="text-blue-300 font-mono text-xs font-semibold">I
+NVARIANTES</div>
445 + <div class="text-gray-400 text-xs">Lo que no puede cambiar s
+in decisión explícita y coordinación</div>
446 +</div>
447
448 +<div class="border-l-4 border-orange-400 pl-3 py-1 bg-gray-900
+ rounded-r">
449 + <div class="text-orange-300 font-mono text-xs font-semibold"
+>TENSIONES ACTIVAS</div>
450 + <div class="text-gray-400 text-xs">Trade-offs que aún no se
+han resuelto — viven en el sistema ahora mismo</div>
451 </div>
452
610 -<v-click>
453 +<div class="border-l-4 border-purple-400 pl-3 py-1 bg-gray-900
+ rounded-r">
454 + <div class="text-purple-300 font-mono text-xs font-semibold"
+>ESTADO ACTUAL → DESEADO</div>
455 + <div class="text-gray-400 text-xs">Dimensiones de madurez. D
+ónde estás, dónde quieres estar, qué te bloquea</div>
456 +</div>
457
612 -<div class="mt-4 text-sm font-semibold text-gray-200">Por qué
-importa la aciclicidad</div>
458 +<div class="border-l-4 border-green-400 pl-3 py-1 bg-gray-900
+rounded-r">
459 + <div class="text-green-300 font-mono text-xs font-semibold">
+GATES ACTIVAS</div>
460 + <div class="text-gray-400 text-xs">Condiciones que deben cum
+plirse antes de cruzar una frontera arquitectural</div>
461 +</div>
462
614 -<div class="mt-2 space-y-1 text-sm text-gray-400">
615 -<div>→ Un invariante no puede depender de sí mismo</div>
616 -<div>→ Las gates protegen nodos hoja, no ciclos</div>
617 -<div>→ El rollback es determinista: sin ambigüedad de orden</d
-iv>
463 </div>
464
620 -<div class="mt-3 font-mono text-xs">
465 +</v-click>
466
622 -```nu
623 -# Invariantes activos
624 -nickel export .ontology/core.ncl
625 -| from json | get nodos
626 -| where invariante == true
627 -| select id descripcion
628 -```
467 +<v-click>
468
469 +<div class="mt-4 text-sm text-gray-300">
470 + Es un grafo consultable. No prosa.<br>
471 + <span class="text-gray-500 text-xs">La IA puede leerlo. Tu C
+I puede verificarlo. Tú puedes razonarlo.</span>
472 </div>
473
474 </v-click>
...
480 <Footer />
481
482 <!--
641 -State machines are architecture, not documentation.
642 -The ADR FSM has 3 states and 2 transitions — that simplicity i
-s the power.
643 -The ontology DAG is the dependency graph of semantic constrain
-ts, not a diagram.
483 +La diferencia no es el nivel de detalle — es la estructura.
484 +Un grafo tiene propiedades que la prosa no tiene: es consultab
+le, verificable, traversable.
485 -->
486
487 ---
488 layout: default
489 ---
490
650 -# La Ontología Operacional — el grafo operacional
491 +# Ontoref — tres archivos, tres preguntas
492
652 -<div class="grid grid-cols-2 gap-8 mt-4">
493 +<div class="grid grid-cols-3 gap-5 mt-6">
494
654 -<div>
495 +<div class="border border-gray-700 rounded p-4 bg-gray-900">
496
656 -**`core.ncl` — lo que no puede cambiar**
497 +<div class="text-blue-300 font-mono font-semibold text-sm mb-3
+">core.ncl</div>
498 +<div class="text-orange-400 text-xs mb-3 italic">"¿Qué ES este
+ proyecto?"</div>
499
658 -<div class="mt-2 font-mono text-xs">
500 +<div class="font-mono text-xs text-gray-400">
501
502 ```text
661 -# .ontology/core.ncl
662 -{
663 - nodos = [
664 - {
665 - id = "backend-agnostic-core",
666 - invariante = true,
667 - descripcion = "business logic sin deps de UI",
668 - tensiones = ["nickel-as-canonical-schema"],
669 - },
670 - ],
671 - practicas = [...],
672 -}
503 +invariantes:
504 + - backend-agnostic-core
505 + - zero-external-runtime
506 +
507 +tensiones:
508 + - formalization vs adoption-friction
509 + - ontology vs reflection
510 +
511 +prácticas:
512 + - nickel-as-schema-layer
513 + - nushell-as-operator
514 ```
515
516 </div>
517
677 -<div class="mt-3 text-sm text-gray-400">
678 -Tocar un nodo con <code class="text-orange-300">invariante = t
-rue</code> requiere un nuevo ADR. Sin excepción.
518 +<div class="mt-3 text-xs text-gray-600">
519 +Inmutable sin ADR nuevo.
520 </div>
521
522 </div>
523
683 -<div>
524 +<div class="border border-gray-700 rounded p-4 bg-gray-900">
525
685 -**`state.ncl` y `gate.ncl` — dónde estamos**
526 +<div class="text-orange-300 font-mono font-semibold text-sm mb
+-3">state.ncl</div>
527 +<div class="text-orange-400 text-xs mb-3 italic">"¿Dónde ESTAM
+OS?"</div>
528
687 -<v-click>
529 +<div class="font-mono text-xs text-gray-400">
530
689 -<div class="mt-2 font-mono text-xs">
531 +```text
532 +dimensiones:
533 + backend-maturity:
534 + actual: multi-stable
535 + deseado: all-production
536 + bloqueador: missing-nats-tests
537
691 -```nu
692 -nickel export .ontology/state.ncl
693 -| from json | get dimensiones
694 -| select id estado_actual estado_deseado
538 + nickel-depth:
539 + actual: schema-input
540 + deseado: bidirectional
541 + catalizador: export pipeline
542 ```
543
544 </div>
545
699 -<div class="mt-2 font-mono text-xs text-gray-400">
546 +<div class="mt-3 text-xs text-gray-600">
547 +Evoluciona con el proyecto.
548 +</div>
549
701 -```text
702 -backend-maturity multi-stable → all-production
703 -nickel-integration-depth schema-input → bidirectional
704 -```
705 -
550 </div>
551
708 -</v-click>
552 +<div class="border border-gray-700 rounded p-4 bg-gray-900">
553
710 -<v-click>
554 +<div class="text-green-300 font-mono font-semibold text-sm mb-
+3">gate.ncl</div>
555 +<div class="text-orange-400 text-xs mb-3 italic">"¿Cuándo esta
+mos LISTOS?"</div>
556
712 -<div class="mt-4 font-mono text-xs">
557 +<div class="font-mono text-xs text-gray-400">
558
714 -```nu
715 -nickel export .ontology/gate.ncl
716 -| from json | get membranas
717 -| where activa == true
718 -| select id permeabilidad protege
559 +```text
560 +gates:
561 + core-dependency-gate:
562 + activa: true
563 + permeabilidad: Low
564 + protege:
565 + - backend-agnostic-core
566 +
567 + nickel-primacy-gate:
568 + activa: true
569 + permeabilidad: Low
570 + protege:
571 + - nickel-as-schema-layer
572 ```
573
574 </div>
575
723 -<div class="mt-2 font-mono text-xs text-gray-400">
724 -
725 -```text
726 -core-dependency-gate Low [backend-agnostic-core, ...]
727 -nickel-primacy-gate Low [nickel-as-canonical-schema]
728 -```
729 -
576 +<div class="mt-3 text-xs text-gray-600">
577 +Condiciones de cruce.
578 </div>
579
732 -</v-click>
733 -
734 -<div class="mt-3 text-xs text-gray-500">
735 -La ontología no es un diagrama.<br>
736 -Es un grafo consultable que el sistema y los agentes leen.
580 </div>
581
582 </div>
583
584 +<v-click>
585 +
586 +<div class="mt-5 font-mono text-xs text-center text-gray-500">
587 + Nickel tipado · exportable como JSON · consultable desde Nu
+· verificable en CI
588 </div>
589
590 +</v-click>
591 +
592 <Footer />
593
594 <!--
746 -The .ontology/ directory separates three orthogonal concerns i
-n three files:
747 - core.ncl — what the project IS: invariant axioms and struct
-ural tensions.
748 - state.ncl — where it IS vs where it wants to BE.
749 - gate.ncl — when it is READY to cross a boundary.
750 -
751 -reflection/ reads all three and answers self-knowledge queries
-.
752 -This separation allows an agent to understand the project with
-out reading code —
753 -only by consulting the declarative graph.
595 +Tres preguntas, tres responsabilidades. La separación es delib
+erada.
596 +core.ncl responde al SER. state.ncl al DEVENIR. gate.ncl al CR
+UZAR.
597 +Cada uno puede cambiar a ritmos diferentes sin contaminar los
+otros.
598 -->
599
600 ---
601 layout: default
602 ---
603
760 -# Reflection — modos, formas, módulos, perfiles
604 +# Reflection — lo que se CONVIERTE
605
762 -<div class="grid grid-cols-2 gap-8 -mt-5">
606 +<div class="grid grid-cols-2 gap-8 mt-2">
607
608 <div>
609
766 -**Modo: especificación ejecutable**
610 +**Ontología = lo que ES**
611
768 -<div class="mt-1 font-mono text-xs">
769 -
770 -```bash
771 -# reflection/modes/new_service.ncl
772 -{
773 - id = "new_service",
774 - trigger = "When adding a service",
775 - steps = [
776 - {
777 - id = "create-adr",
778 - actor = "developer",
779 - action = "Draft ADR for service boundary",
780 - cmd = "stratum form new_adr",
781 - on_error = { strategy = "abort" },
782 - },
783 - {
784 - id = "seal-config",
785 - actor = "developer",
786 - action = "Apply initial config seal",
787 - cmd = "stratum config apply development",
788 - depends_on = [{ step = "create-adr" }],
789 - on_error = { strategy = "abort" },
790 - },
791 - ],
792 -}
793 -```
794 -
612 +<div class="mt-3 text-sm text-gray-400 space-y-2">
613 +<div>→ Invariantes — verdad estructural</div>
614 +<div>→ Tensiones — trade-offs vivos</div>
615 +<div>→ Estado — dónde estamos ahora</div>
616 </div>
617
797 -</div>
618 +<div class="mt-5 text-sm font-semibold text-gray-200">Reflecti
+on = lo que DEVIENE</div>
619
799 -<div>
800 -
801 -**Forma: entrada estructurada tipada**
802 -
803 -<div class="mt-2 font-mono text-xs">
804 -
805 -```bash
806 -# reflection/forms/register_change.ncl
807 -{
808 - elements = [
809 - { type = "section_header", label = "Change" },
810 - {
811 - type = "text",
812 - id = "title",
813 - label = "Title",
814 - required = true,
815 - },
816 - {
817 - type = "select",
818 - id = "change_type",
819 - options = ["feature","fix","refactor","config"],
820 - },
821 - ]
822 -}
823 -```
824 -
620 +<div class="mt-3 text-sm text-gray-400 space-y-2">
621 +<div>→ Modos operacionales — secuencias con DAG de dependencia
+s</div>
622 +<div>→ ADRs con constraints tipadas — decisiones vivas, no pro
+sa</div>
623 +<div>→ Backlog estructurado — tensiones → tareas</div>
624 +<div>→ Historial de sesiones — quién hizo qué y cuándo</div>
625 </div>
626
627 <v-click>
628
829 -<div class="mt-3 space-y-2 text-sm">
830 -
831 -<div class="box-highlight border-l-4 border-purple-500 pl-3 py
--1">
832 - <div class="font-semibold text-purple-300">Perfil de config
-= estado sellado</div>
833 - <div class="text-gray-400 text-xs"><code>sha256(nickel expor
-t profile.ncl)</code> — drift detection instantánea</div>
629 +<div class="mt-5 border-l-4 border-orange-500 pl-4 text-sm tex
+t-gray-300">
630 + La ontología captura el <em>ser</em>.<br>
631 + La reflection captura el <em>operar sobre ese ser</em>.
632 </div>
633
836 -<div class="text-xs text-gray-400 mt-2">
837 -<code>stratum config verify development</code> → compara hash
-actual con hash sellado
838 -</div>
839 -
840 -</div>
841 -
634 </v-click>
635
636 </div>
637
846 -</div>
847 -
848 -<Footer />
849 -
850 -<!--
851 -Modes are not runbooks. They are typed, versioned, queryable o
-perational specifications.
852 -Forms are the structured capture layer — TypeDialog renders th
-em across CLI/TUI/Web backends.
853 -Config profiles seal the observable state with a cryptographic
- fingerprint.
854 --->
855 -
856 ----
857 -layout: default
858 ----
859 -
860 -# ADRs vivos
861 -## — de documento muerto a constraint machine
862 -
863 -<div class="grid grid-cols-2 gap-8 mt-1">
864 -
638 <div>
639
867 -**Estructura Nickel de un ADR**
640 +<v-click>
641
869 -<div class="-mt-2 font-mono text-xs">
642 +**Un modo como especificación ejecutable**
643
644 +<div class="mt-3 font-mono text-xs">
645 +
646 ```bash
872 -# adrs/adr-001-nickel-as-canonical.ncl
873 -let s = import "adrs/schema.ncl" in
647 +# reflection/modes/new_service.ncl
648 {
875 - id = "adr-001",
876 - title = "Nickel as First-Class Form Definition",
877 - status = "Accepted",
878 - date = "2025-12-01",
879 - constraints = [
649 + id = "new_service",
650 + trigger = "When adding a new service boundary",
651 + steps = [
652 {
881 - id = "adr-001-c1",
882 - severity = "Hard",
883 - claim =
884 - "nickel export must succeed before "
885 - ++ "any user interaction",
653 + id = "draft-adr",
654 + actor = "developer",
655 + action = "Draft ADR for service boundary decision",
656 },
657 + {
658 + id = "verify-invariants",
659 + actor = "agent",
660 + action = "Check no invariant is violated",
661 + depends_on = [{ step = "draft-adr" }],
662 + },
663 + {
664 + id = "seal-config",
665 + actor = "developer",
666 + action = "Apply initial config seal",
667 + depends_on = [{ step = "verify-invariants" }],
668 + },
669 ],
888 - superseded_by = "",
889 -} | s.ADR
670 +}
671 ```
672
673 </div>
674
675 +<div class="mt-2 text-xs text-gray-500">
676 +No es un runbook. Es un grafo acíclico tipado.<br>
677 +La IA lo ejecuta. El sistema lo valida.
678 </div>
679
896 -<div>
897 -
898 -<p class="-mt-2 text-sm font-semibold text-gray-200"> Ciclo de
- vida y consulta </p>
899 -
900 -<div class="-mt-2 font-mono text-xs text-gray-300">
901 -
902 -```text
903 -Proposed ──────▶ Accepted ──────▶ Superseded
904 - │ ▲
905 - │ new ADR │
906 - └──────── superseded_by ────────────┘
907 -```
908 -
909 -</div>
910 -
911 -<v-click>
912 -
913 -<div class="mt-2 text-sm font-semibold text-gray-200">Constrai
-nts Hard activas del sistema</div>
914 -
915 -<div class="mt-2 font-mono text-xs">
916 -
917 -```nu
918 -glob "adrs/adr-*.ncl"
919 -| each { |f|
920 - nickel export $f | complete
921 - | if $in.exit_code == 0 {
922 - $in.stdout | from json
923 - } else { null }
924 - }
925 -| compact
926 -| where status == "Accepted"
927 -| get constraints | flatten
928 -| where severity == "Hard"
929 -| select id claim
930 -```
931 -
932 -</div>
933 -
680 </v-click>
681
936 -<v-click>
937 -
938 -<div class="mt-3 text-xs text-gray-500">
939 -El conjunto activo de constraints es el contrato en vigor — no
- la prosa del ADR.
940 -La prosa explica el porqué. Los constraints enforcan el qué.
682 </div>
683
943 -</v-click>
944 -
684 </div>
685
947 -</div>
948 -
686 <Footer />
687
688 <!--
952 -"Living ADRs" is not a metaphor.
953 -The machine can query them, validate against them, and enforce
- them.
954 -The prose explains why. The constraints enforce what.
689 +La dualidad ontología/reflection es la tensión central de onto
+ref.
690 +No pueden fusionarse — tienen ritmos de cambio diferentes y au
+diencias diferentes.
691 +La reflection sin ontología es procedimiento sin semántica. La
+ ontología sin reflection es diagrama muerto.
692 -->
693
694 ---
695 layout: default
696 ---
697
961 -# Implementación — las partes y cómo encajan
698 +# La IA como actor, no como oráculo
699
700 <div class="grid grid-cols-2 gap-8 mt-4">
701
702 <div>
703
967 -**Stack de archivos operativos**
704 +**Sin ontología formalizada**
705
969 -<div class="mt-2 font-mono text-xs text-gray-300">
706 +<div class="mt-3 font-mono text-xs">
707
708 ```bash
972 -stratum.sh ← entry point, locking, env
973 - └─ reflection/bin/stratum.nu ← dispatcher
974 - ├─ modules/adr.nu ← ADR lifecycle
975 - ├─ modules/register.nu ← CHANGELOG + ontology
976 - ├─ modules/config.nu ← sealed profiles
977 - ├─ modules/backlog.nu ← backlog items
978 - └─ modules/forms.nu ← TypeDialog integrated
709 +# Lo que el agente recibe
710 +"Ayúdame a escalar este servicio"
711
980 -.ontology/ ← queryable truth
981 - ├─ core.ncl ← invariants
982 - ├─ state.ncl ← dimensions
983 - └─ gate.ncl ← active guards
712 +# Lo que el agente asume
713 +- que puede añadir réplicas libremente
714 +- que el estado actual es el deseado
715 +- que no hay restricciones de org
716 +- que la decisión de diciembre es irrelevante
717
985 -adrs/ ← typed decisions
986 -reflection/configs/ ← sealed config history
718 +# Lo que genera
719 +resource "google_compute_instance" {
720 + count = 5 # razonable, ¿no?
721 +}
722 ```
723
724 </div>
...
727
728 <div>
729
995 -**Flujo de escritura protegida**
996 -
730 <v-click>
731
999 -<div class="mt-2 space-y-2 text-sm">
732 +**Con ontología formalizada**
733
1001 -<div class="box-highlight border-l-4 border-gray-600 pl-3 py-
-1">
1002 - <div class="font-semibold text-gray-200">stratum.sh</div>
1003 - <div class="text-gray-400 text-xs">detect actor → acquire l
-ock (mkdir) → delegate → release</div>
1004 -</div>
734 +<div class="mt-3 font-mono text-xs">
735
1006 -<div class="box-highlight border-l-4 border-orange-500 pl-3 p
-y-1">
1007 - <div class="font-semibold text-orange-300">Lock resources</
-div>
1008 - <div class="text-gray-400 text-xs"><code>manifest</code> (c
-onfig apply/rollback) · <code>changelog</code> (register) · <
-code>backlog</code> (done/cancel)</div>
1009 -</div>
736 +```bash
737 +# Lo que el agente recibe (SessionStart hook)
738 +INVARIANT: max-replicas-per-zone = 2
739 +TENSION: scaling vs consistency [unresolved]
740 +CONSTRAINT (adr-003): no horizontal scaling
741 + without explicit capacity review
742 +STATE: backend-maturity = single-stable
743 + → desired: multi-stable
744 + → blocker: capacity-review-pending
745
1011 -<div class="box-highlight border-l-4 border-blue-500 pl-3 py-
-1">
1012 - <div class="font-semibold text-blue-300">Timestamp IDs</div
->
1013 - <div class="text-gray-400 text-xs"><code>cfg-20260309T04520
-6-developer</code> — colisión imposible, sin TOCTOU</div>
1014 -</div>
746 +# Lo que el agente puede hacer
747 +- Preguntar si procede dado el bloqueador
748 +- Generar la config dentro de los límites
749 +- Indicar que el ADR debe revisarse antes
750 +```
751
752 </div>
753
...
755
756 <v-click>
757
1022 -<div class="mt-4 font-mono text-xs text-gray-400">
1023 -
1024 -```bash
1025 -# Advisory lock: mkdir es POSIX-atómico
1026 -mkdir .stratumiops/locks/manifest.lock 2>/dev/null
1027 -echo "$$:developer:$(date -u +%Y%m%dT%H%M%SZ)"
1028 - > .stratumiops/locks/manifest.lock/owner
1029 -```
1030 -
758 +<div class="mt-4 border-l-4 border-green-500 pl-4 text-sm tex
+t-gray-300">
759 + El agente opera sobre lo que tú ya clarificaste.<br>
760 + <span class="text-gray-500 text-xs">Deja de inventarse cont
+exto porque tú dejaste de tenerlo implícito.</span>
761 </div>
762
763 </v-click>
...
769 <Footer />
770
771 <!--
1042 -Implementation is derived from architecture — not the other w
-ay around.
1043 -Every piece exists because a specific problem required it.
1044 -The lock is 4 lines of bash because mkdir is atomic on POSIX.
- No daemon needed.
772 +El SessionStart hook en ontoref inyecta el contexto ontológic
+o al inicio de cada sesión.
773 +El agente no es más inteligente — tiene más información real
+y menos que inventar.
774 +La mejora no es de la IA. Es tuya: formalizaste algo que ante
+s vivía solo en tu cabeza.
775 -->
776
777 ---
778 layout: default
779 ---
780
1051 -# Mecánica y flujo — casos de uso reales
781 +# ¿Quién mantiene esto actualizado?
782
1053 -<div class="grid grid-cols-2 gap-8 mt-4">
783 +<div class="mt-4 text-lg text-gray-400 text-center">La pregun
+ta que siempre sale.</div>
784
785 +<div class="grid grid-cols-2 gap-8 mt-6">
786 +
787 <div>
788
1057 -**Flujo: registrar un cambio**
789 +**El problema real con el README**
790
1059 -<div class="mt-2 text-xs space-y-1">
791 +<div class="mt-3 space-y-2 text-sm text-gray-400">
792
1061 -<div class="flex items-start gap-2 mt-1">
1062 - <span class="text-orange-400 font-mono font-bold">①</span>
1063 - <div><code>stratum register</code> → forma TypeDialog inter
-activa</div>
1064 -</div>
1065 -
793 <div class="flex items-start gap-2">
1067 - <span class="text-orange-400 font-mono font-bold">②</span>
1068 - <div>Clasificar: tipo de cambio, impacto, ADR relacionado</
-div>
794 + <span class="text-red-400">✗</span>
795 + <div>Nadie tiene incentivo para actualizarlo — no está en e
+l path crítico</div>
796 </div>
797
798 <div class="flex items-start gap-2">
1072 - <span class="text-orange-400 font-mono font-bold">③</span>
1073 - <div>Artefacto: entrada CHANGELOG + stub ADR si aplica</div
->
799 + <span class="text-red-400">✗</span>
800 + <div>No hay señal de cuando está desactualizado</div>
801 </div>
802
803 <div class="flex items-start gap-2">
1077 - <span class="text-orange-400 font-mono font-bold">④</span>
1078 - <div>Verificar: <code>nickel typecheck</code> debe pasar</d
-iv>
804 + <span class="text-red-400">✗</span>
805 + <div>Actualizar requiere fricción de escritura libre</div>
806 </div>
807
808 <div class="flex items-start gap-2">
1082 - <span class="text-orange-400 font-mono font-bold">⑤</span>
1083 - <div>Sellar si afecta config: <code>stratum config apply</c
-ode></div>
809 + <span class="text-red-400">✗</span>
810 + <div>No hay verificación — puede divergir silenciosamente</
+div>
811 </div>
812
813 </div>
814
1088 -<v-click>
1089 -
1090 -<div class="mt-4 text-sm font-semibold text-gray-200">Detecci
-ón de drift</div>
1091 -
1092 -<div class="mt-2 font-mono text-xs">
1093 -
1094 -```nu
1095 -stratum config apply production --adr adr-006 --pr 42
1096 -# Meses después:
1097 -stratum config verify production
1098 -# → ✓ verified a3f7c12d8b4e9f01...
1099 -# → ✗ DRIFT DETECTED stored vs current hash
1100 -```
1101 -
815 </div>
816
1104 -</v-click>
1105 -
1106 -</div>
1107 -
817 <div>
818
1110 -**Rollback verificado**
1111 -
819 <v-click>
820
1114 -<div class="mt-2 font-mono text-xs">
821 +**El diseño de ontoref**
822
1116 -```nu
1117 -stratum config history production
823 +<div class="mt-3 space-y-2 text-sm">
824
1119 -stratum config rollback production \
1120 - cfg-20260301T120000-developer \
1121 - --adr adr-007 \
1122 - --note "revert breaking change"
1123 -```
1124 -
825 +<div class="border-l-4 border-blue-400 pl-3 py-1 bg-gray-900
+rounded-r">
826 + <div class="text-blue-300 font-semibold text-xs">Pre-commit
+ como sincronización forzada</div>
827 + <div class="text-gray-400 text-xs"><code>nickel typecheck</
+code> en cada commit — la capa declarativa nunca queda rota</
+div>
828 </div>
829
1127 -</v-click>
1128 -
1129 -<v-click>
1130 -
1131 -<div class="mt-3 text-xs text-gray-400 space-y-1">
1132 -<div>→ <code>snapshot_hash</code> verifica integridad antes d
-e restaurar</div>
1133 -<div>→ Rollback genera nuevo sello — la historia es append-on
-ly</div>
1134 -<div>→ Trazabilidad completa: ADR + PR + bug en cada sello</d
-iv>
830 +<div class="border-l-4 border-orange-400 pl-3 py-1 bg-gray-90
+0 rounded-r">
831 + <div class="text-orange-300 font-semibold text-xs">Modos co
+mo procedimientos obligatorios</div>
832 + <div class="text-gray-400 text-xs">Añadir un servicio ejecu
+ta el modo — el ADR se escribe como parte del proceso</div>
833 </div>
834
1137 -<div class="mt-4 font-mono text-xs text-gray-500">
1138 -
1139 -```text
1140 -cfg-20260301T120000-developer (original)
1141 - └─ cfg-20260309T045206-agent (change)
1142 - └─ cfg-20260309T120000-developer (rollback)
1143 -```
1144 -
835 +<div class="border-l-4 border-purple-400 pl-3 py-1 bg-gray-90
+0 rounded-r">
836 + <div class="text-purple-300 font-semibold text-xs">Drift de
+tection</div>
837 + <div class="text-gray-400 text-xs"><code>sha256(nickel expo
+rt)</code> — sabes cuándo el estado sellado difiere del actua
+l</div>
838 </div>
839
1147 -</v-click>
1148 -
840 +<div class="border-l-4 border-green-400 pl-3 py-1 bg-gray-900
+ rounded-r">
841 + <div class="text-green-300 font-semibold text-xs">ADRs como
+ constraints, no prosa</div>
842 + <div class="text-gray-400 text-xs">El constraint es machine
+-readable — el CI puede verificarlo, no solo leerlo</div>
843 </div>
844
845 </div>
846
1153 -<Footer />
1154 -
1155 -<!--
1156 -Walk through a real scenario. The audience needs to see the f
-low, not just the components.
1157 -Drift detection is the killer feature: no guessing what chang
-ed in production.
1158 --->
1159 -
1160 ----
1161 -layout: default
1162 ----
1163 -
1164 -# Integración en proyectos — onboarding al ecosistema
1165 -
1166 -<div class="grid grid-cols-2 gap-8 mt-4">
1167 -
1168 -<div>
1169 -
1170 -**Lo que un proyecto necesita**
1171 -
1172 -<div class="mt-2 font-mono text-xs text-gray-300">
1173 -
1174 -```bash
1175 -proyecto/
1176 - .ontology/
1177 - core.ncl ← invariants del proyecto
1178 - state.ncl ← dimensiones de madurez
1179 - gate.ncl ← guards activos
1180 - adrs/
1181 - schema.ncl
1182 - reflection.ncl
1183 - adr-001-*.ncl ← ADR fundacional
1184 - reflection/
1185 - forms/ ← TypeDialog forms
1186 - modes/ ← operational modes
1187 - configs/ ← sealed profiles
1188 - modules/ ← Nu modules
1189 - bin/stratum.nu
1190 - stratum.sh
1191 -```
1192 -
1193 -</div>
1194 -
1195 -</div>
1196 -
1197 -<div>
1198 -
1199 -**Inicialización**
1200 -
1201 -<v-click>
1202 -
1203 -<div class="mt-2 text-xs space-y-2">
1204 -
1205 -<div class="box-highlight border-l-4 border-green-500 pl-3 py
--1">
1206 - <div class="font-semibold text-green-300">Comando de onboar
-ding</div>
1207 - <div class="font-mono text-gray-400 text-xs mt-1"><code>/on
-board-project</code> → genera <code>.ontology/ <br></code> +
-ADR fundacional</div>
1208 -</div>
1209 -
1210 -<div class="box-highlight border-l-4 border-blue-500 pl-3 py-
-1">
1211 - <div class="font-semibold text-blue-300">Primer ADR obligat
-orio</div>
1212 - <div class="text-gray-400 text-xs">Define las invariantes —
- qué no puede cambiar sin ADR nuevo</div>
1213 -</div>
1214 -
1215 -<div class="box-highlight border-l-4 border-orange-400 pl-3 p
-y-1">
1216 - <div class="font-semibold text-orange-300">Pre-commit como
-sincronización</div>
1217 - <div class="text-gray-400 text-xs"><code>nickel typecheck</
-code> en cada commit<br> — la capa declarativa nunca queda ro
-ta</div>
1218 -</div>
1219 -
1220 -</div>
1221 -
847 </v-click>
848
849 <v-click>
850
1226 -<div class="mt-4 font-mono text-xs">
1227 -
1228 -```bash
1229 -./stratum.sh check
1230 -# ✓ nushell 0.110.0
1231 -# ✓ nickel 1.9.0
1232 -# ✓ .ontology/core.ncl exportable
1233 -# ✓ adrs/adr-001 Accepted
1234 -# ✗ no sealed config profiles yet
1235 -```
1236 -
851 +<div class="mt-4 text-xs text-gray-500 border-l-2 border-gray
+-700 pl-3">
852 + La ontología se mantiene porque es el path.<br>
853 + No porque alguien sea disciplinado.
854 </div>
855
856 </v-click>
...
862 <Footer />
863
864 <!--
1248 -Onboarding is a contract, not a tutorial.
1249 -The system tells the project what it needs via `stratum check
-`.
1250 -The foundational ADR is the project's semantic constitution.
865 +Esta es la objeción más honesta del público. Abrazarla, no es
+quivarla.
866 +La respuesta no es "la gente debería ser más disciplinada".
867 +La respuesta es: el sistema lo hace obligatorio, no opcional.
868 -->
869
870 ---
871 layout: default
872 ---
873
1257 -# Integración con Claude Code & Uso concurrente
874 +# Para el debate
875
1259 -<div class="grid grid-cols-2 gap-8 mt-4">
876 +<div class="grid grid-cols-2 gap-8 mt-6">
877
878 <div>
879
1263 -**SessionStart: contexto automático**
880 +**Propuesta 1 — Ontología**
881
1265 -<div class="mt-2 text-xs text-gray-300">
1266 -<code>stratum-session-start.sh</code> se ejecuta al inicio de
- cada sesión:
882 +<div class="mt-4 space-y-4">
883 +
884 +<div class="border border-gray-700 rounded p-3 bg-gray-900">
885 + <div class="text-orange-300 text-sm font-semibold">¿No es s
+uficiente con un buen README?</div>
886 + <div class="text-gray-500 text-xs mt-1">¿Cuándo fue la últi
+ma vez que el tuyo estaba al día?</div>
887 </div>
888
1269 -<div class="mt-2 font-mono text-xs">
889 +<div class="border border-gray-700 rounded p-3 bg-gray-900">
890 + <div class="text-orange-300 text-sm font-semibold">¿Qué dif
+erencia una ontología de una lista de decisiones?</div>
891 + <div class="text-gray-500 text-xs mt-1">Estructura, consult
+abilidad, verificabilidad.</div>
892 +</div>
893
1271 -```bash
1272 -=== STRATUM CONTEXT: typedialog ===
894 +<div class="border border-gray-700 rounded p-3 bg-gray-900">
895 + <div class="text-orange-300 text-sm font-semibold">¿Quién m
+antiene esto cuando el proyecto cambia rápido?</div>
896 + <div class="text-gray-500 text-xs mt-1">El diseño lo hace o
+bligatorio, no opcional.</div>
897 +</div>
898
1274 -ADRS
1275 - adr-001 [Accepted] Nickel as First-Class Form...
1276 - adr-002 [Accepted] NCL element order from position
1277 -
1278 -HARD CONSTRAINTS
1279 - adr-001-c1 nickel export must succeed before...
1280 - adr-002-c1 web/tui must render headers interleaved
1281 -
1282 -STATE
1283 - backend-maturity: multi-stable → all-production
1284 -
1285 -ACTIVE GATES
1286 - nickel-primacy-gate [Low] Protects: nickel-as-...
1287 -
1288 -=== END STRATUM CONTEXT ===
1289 -```
1290 -
899 </div>
900
901 </div>
902
903 <div>
904
1297 -**Uso concurrente: humano + agente IA**
905 +**Propuesta 2 — Infra + IA**
906
1299 -<v-click>
907 +<div class="mt-4 space-y-4">
908
1301 -<div class="mt-4 space-y-4 text-sm">
1302 -
1303 -<div class="box-highlight border-l-4 border-blue-500 pl-3 py-
-1">
1304 - <div class="font-semibold text-blue-300">IDs timestamp con
-actor</div>
1305 - <div class="font-mono text-gray-400 text-xs">cfg-20260309T0
-45206-developer<br>cfg-20260309T045207-agent</div>
1306 - <div class="text-gray-400 text-xs">Sin coordinador. Sin TOC
-TOU. Trazabilidad por actor.</div>
909 +<div class="border border-gray-700 rounded p-3 bg-gray-900">
910 + <div class="text-orange-300 text-sm font-semibold">¿Es dife
+rente a copiar Stack Overflow?</div>
911 + <div class="text-gray-500 text-xs mt-1">En SO buscabas. Con
+ la IA, delegas también la búsqueda.</div>
912 </div>
913
1309 -<div class="box-highlight border-l-4 border-orange-400 pl-3 p
-y-1">
1310 - <div class="font-semibold text-orange-300">Advisory locks (
-mkdir)</div>
1311 - <div class="text-gray-400 text-xs">Serializa escrituras en
-manifest/changelog/backlog. Stale detection por PID.</div>
914 +<div class="border border-gray-700 rounded p-3 bg-gray-900">
915 + <div class="text-orange-300 text-sm font-semibold">¿Dónde e
+stá el mínimo de comprensión necesario?</div>
916 + <div class="text-gray-500 text-xs mt-1">Saber qué no puede
+romperse. Sin eso, no tienes control.</div>
917 </div>
918
1314 -<div class="box-highlight border-l-4 border-gray-600 pl-3 py-
-1">
1315 - <div class="font-semibold text-gray-300">Actor-agnostic pro
-tocol</div>
1316 - <div class="text-gray-400 text-xs">El sistema no distingue
-humano de agente. El protocolo enforcea igual para ambos.</di
-v>
919 +<div class="border border-gray-700 rounded p-3 bg-gray-900">
920 + <div class="text-orange-300 text-sm font-semibold">¿Las pla
+taformas internas resuelven esto o lo esconden?</div>
921 + <div class="text-gray-500 text-xs mt-1">Una plataforma sin
+ontología solo mueve la ignorancia un nivel arriba.</div>
922 </div>
923
924 </div>
925
1321 -</v-click>
1322 -
1323 -<v-click>
1324 -
1325 -<div class="mt-8 text-sm text-gray-500">
1326 -Worktrees aíslan el working-tree (branches diferentes).<br>
1327 -Locking serializa escrituras sobre el mismo árbol.<br>
1328 -Son complementarios, no alternativos.
926 </div>
927
1331 -</v-click>
1332 -
928 </div>
929
1335 -</div>
1336 -
930 <Footer />
931
932 <!--
1340 -AI agents are first-class actors in this system. The protocol
- does not distinguish — it enforces.
1341 -The session hook means Claude starts informed, not blind.
1342 -Concurrent use without a central coordinator is the scaling p
-roperty that makes this practical.
933 +Open space: las mejores respuestas vendrán del público.
934 +Tu rol aquí es provocar, no resolver. Lanza las preguntas y d
+eja el silencio.
935 -->
936
937 ---
...
942
943 <div class="standalone-slide text-shadow-lg text-xl">
944
1353 -# Ontology & Reflection
945 +<div class="text-3xl font-semibold text-gray-100 mb-2">
946 + La IA puede declarar tu infra.
947 +</div>
948
1355 -<div class="meters-final -mt-3 mb-7">
1356 - <span class="text-green-400">✓ Typed</span>
1357 - <span class="text-green-400">✓ Verified</span>
1358 - <span class="text-green-400">✓ Sealed</span>
1359 - <span class="text-green-400">✓ Decided</span>
949 +<div class="text-3xl font-semibold text-orange-400 mb-8">
950 + No puede entenderla por ti.
951 </div>
952
1362 -<div class="text-2xl leading-11 text-gray-200">
1363 -El código y el entendimiento del código deben converger.<br>
1364 -Los <em>ADRs</em> y la <em>ontología</em> son el contrato ent
-re ambos.<br>
1365 -La <em>reflection</em> es la operación sobre ese contrato.
953 +<v-click>
954 +
955 +<div class="text-xl text-gray-300 leading-10 max-w-2xl mx-aut
+o">
956 + La ontología es el modelo que te fuerza a saber qué es verd
+ad ahora.<br>
957 + La reflection es la operación sobre ese modelo.<br>
958 + La IA es el actor que opera <em>sobre lo que ya clarificast
+e</em>.
959 </div>
960
1368 -<div class="text-4xl leading-12 text-gray-200 my-5">
1369 -Gracias. ¿Preguntas?
961 +</v-click>
962 +
963 +<v-click>
964 +
965 +<div class="mt-10 text-2xl text-gray-200">
966 + Gracias. ¿Preguntas?
967 </div>
968
1372 -<small>jesusperez.pro · ontoref.dev </small>
969 +<small class="mt-4 block text-gray-500">jesusperez.pro · onto
+ref.dev</small>
970
971 +</v-click>
972 +
973 </div>
974
975 <style>
1377 -.meters-final {
1378 - display: inline-flex;
1379 - gap: 2rem;
1380 - font-size: 1.4rem;
1381 - font-family: monospace;
976 +.standalone-slide {
977 + text-align: center;
978 }
979 </style>
980
981 <Footer />
982
983 <!--
1388 -Direct eye contact. Slow delivery.
1389 -The three green checks are the promise: typed, verified, seal
-ed. If those three hold, the system holds.
984 +Cierre lento. Las tres líneas son la síntesis completa.
985 +No terminar con "ontoref es la solución" — terminar con la in
+versión cognitiva.
986 +El punto no es adoptar ontoref. El punto es tomar posesión de
+ tu propio modelo.
987 -->
⏺ ★ Insight ─────────────────────────────────────
Las slides fusionan las dos propuestas en una narrativa única: propuesta 2
(infra + IA) establece el problema, propuesta 1 (ontología como
auto-clarificación) es la respuesta. El slide final invierte la expectativa —
no "ontoref es la herramienta", sino "la mejora es tuya, no de la IA". El
slide de debate mantiene ambas líneas separadas para que en el open space el
facilitador pueda elegir qué hilo tirar.
─────────────────────────────────────────────────
11 slides en total siguiendo el patrón Slidev exacto del archivo original:
┌─────┬──────────────────────────┬────────────────────────────────────────┐
│ # │ Slide │ Función narrativa │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 1 │ Cover │ Pregunta provocadora — combina ambas │
│ │ │ propuestas │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 2 │ El problema no es la │ IA hace forma correcta, no significado │
│ │ herramienta │ │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 3 │ Las 2am │ Caso concreto de Terraform sin │
│ │ │ contexto │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 4 │ Tu proyecto vive en tu │ Transición al argumento de ontología │
│ │ cabeza │ │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 5 │ La tesis │ Inversión central — ontología es para │
│ │ │ ti │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 6 │ Ontología ≠ lista de │ Diferencia estructural vs prosa │
│ │ decisiones │ │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 7 │ Ontoref — tres archivos │ core.ncl, state.ncl, gate.ncl como │
│ │ │ modelo concreto │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 8 │ Reflection — lo que se │ Dualidad ontología/reflection │
│ │ CONVIERTE │ │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 9 │ La IA como actor, no │ SessionStart hook — antes/después │
│ │ oráculo │ │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 10 │ ¿Quién mantiene esto? │ La objeción más honesta + respuesta de │
│ │ │ diseño │
├─────┼──────────────────────────┼────────────────────────────────────────┤
│ 11 │ Debate + Cierre │ Preguntas abiertas organizadas por │
│ │ │ propuesta │
└─────┴──────────────────────────┴────────────────────────────────────────┘
✻ Baked for 2m 58s
※ recap: Created open space slides in slides.md covering ontology and reflection as ontoref base concepts, blending both proposals into one narrative arc. No next action pending — slides are complete and ready to preview. (disable recaps in /config)
❯ en la ontología filosófca exiten los universales, ¿ son los invariantes un
equivalente de los mismos ?
⏺ No exactamente — la correspondencia es más fina que eso.
Los universales responden a: ¿qué comparten múltiples particulares que los
hace del mismo tipo? Son propiedades abstractas que se instancian en varios
individuos: "rojez", "humanidad". El debate clásico (realismo platónico vs
nominalismo) gira en torno a si existen independientemente de sus instancias.
Los invariantes en ontoref son otra cosa: son propiedades esenciales de un
singular — el proyecto como entidad. No preguntan qué comparten múltiples
proyectos; preguntan qué no puede cambiar en este proyecto sin que deje de ser
este proyecto.
La analogía filosófica más precisa no es el universal — es la distinción
aristotélica entre propiedades esenciales y accidentales. Un invariante dice:
si esto cambia, el proyecto ha cambiado de naturaleza, no solo de estado.
Kripke lo formalizó mejor: ciertas propiedades son rígidas — no contingentes
en ningún mundo posible dado un individuo.
Donde sí hay resonancia con los universales: ambos capturan lo que no varía a
través del cambio — el universal a través de la instanciación, el invariante a
través de la evolución temporal. La familia semántica es la misma aunque el
eje difiera.
Y hay otra diferencia de fondo: los universales platónicos existen
independientemente de que alguien los declare. Los invariantes de ontoref son
hechos institucionales en el sentido de Searle — son verdad porque los
arquitectos del proyecto los declararon como tales y los formalizaron. Son
constructivistas, no metafísicamente realistas. Eso los hace más frágiles
(requieren mantenimiento activo) pero también más honestos sobre su
naturaleza.
Las tensiones de ontoref tienen otro pedigree — se acercan más a la dialéctica
hegeliana: trade-offs que no se resuelven, solo se gestionan.
✻ Crunched for 33s
❯ relaciona los elementos básicos de la filosófica con respecto a la que usa el
model operacional en software y compara sus autores y orígenes
⏺ Esta es una genealogía real. La tabla primero, luego los matices que no caben
en ella.
---
Tabla comparativa
Concepto filosófico: Universales
Autor / Origen: Platón (428-348 aC) — República, Parménides
Equivalente operacional: Tipos / Schemas
Implementación en ontoref: Contratos Nickel — String, [| 'Accepted, 'Proposed
|]
────────────────────────────────────────
Concepto filosófico: Esencia / Accidente
Autor / Origen: Aristóteles (384-322 aC) — Metafísica
Equivalente operacional: Invariante / Estado mutable
Implementación en ontoref: invariante = true en core.ncl vs dimensiones en
state.ncl
────────────────────────────────────────
Concepto filosófico: Potencia / Acto
Autor / Origen: Aristóteles — Metafísica IX
Equivalente operacional: Estado actual → deseado + Gates
Implementación en ontoref: current_state / desired_state / gate.ncl
────────────────────────────────────────
Concepto filosófico: Categorías
Autor / Origen: Aristóteles — Categorías
Equivalente operacional: Tipos de nodo ontológico
Implementación en ontoref: invariants, tensions, practices, dimensions, gates
────────────────────────────────────────
Concepto filosófico: Sustancia primera / segunda
Autor / Origen: Aristóteles — Categorías
Equivalente operacional: Instancia / Tipo
Implementación en ontoref: Proyecto concreto vs schema de proyecto
────────────────────────────────────────
Concepto filosófico: Identidad a través del tiempo
Autor / Origen: Locke (Ensayo, 1689), Parfit (Reasons, 1984)
Equivalente operacional: Versioning + ADR lifecycle
Implementación en ontoref: status = Superseded, superseded_by — identidad que
evoluciona formalmente
────────────────────────────────────────
Concepto filosófico: Dialéctica
Autor / Origen: Hegel (1770-1831) — Fenomenología del Espíritu
Equivalente operacional: Tensiones activas
Implementación en ontoref: tensions en core.ncl — sin síntesis, gestionadas
────────────────────────────────────────
Concepto filosófico: Logos como tensión de opuestos
Autor / Origen: Heráclito (535-475 aC)
Equivalente operacional: Tensión irreducible
Implementación en ontoref: La dualidad ontología/reflection como tensión
constitutiva
────────────────────────────────────────
Concepto filosófico: Mundos posibles
Autor / Origen: Leibniz (1646-1716) + Kripke (Naming, 1980)
Equivalente operacional: FSM — transiciones permitidas
Implementación en ontoref: ADRs como restricciones de accesibilidad entre
estados
────────────────────────────────────────
Concepto filosófico: Propiedades esenciales rígidas
Autor / Origen: Kripke — Naming and Necessity (1980)
Equivalente operacional: Invariantes como necesidad, no contingencia
Implementación en ontoref: Un invariante es verdad en todos los estados
posibles del proyecto
────────────────────────────────────────
Concepto filosófico: Límites del lenguaje = límites del mundo
Autor / Origen: Wittgenstein — Tractatus (1921)
Equivalente operacional: Schema como frontera de lo expresable
Implementación en ontoref: Lo que no tipea en Nickel no puede existir en el
sistema
────────────────────────────────────────
Concepto filosófico: Juegos de lenguaje
Autor / Origen: Wittgenstein — Investigaciones (1953)
Equivalente operacional: Modos operacionales
Implementación en ontoref: Un modo define las reglas del juego para un
contexto
operacional
────────────────────────────────────────
Concepto filosófico: Verdad como correspondencia
Autor / Origen: Tarski (1933) — El concepto de verdad
Equivalente operacional: Typecheck / validación
Implementación en ontoref: nickel export como verificación de correspondencia
con el schema
────────────────────────────────────────
Concepto filosófico: Hechos institucionales
Autor / Origen: Searle — La construcción de la realidad social (1995)
Equivalente operacional: ADRs como decisiones declaradas
Implementación en ontoref: Un ADR es verdad porque el equipo lo declaró y
formalizó — no metafísicamente
────────────────────────────────────────
Concepto filosófico: Ontología formal vs regional
Autor / Origen: Husserl — Ideas I (1913)
Equivalente operacional: Schema (formal) vs ontología del proyecto (regional)
Implementación en ontoref: adrs/schema.ncl vs .ontology/core.ncl
────────────────────────────────────────
Concepto filosófico: Proceso vs sustancia
Autor / Origen: Whitehead — Process and Reality (1929)
Equivalente operacional: Ontología (ser) vs Reflection (devenir)
Implementación en ontoref: La dualidad estructural del protocolo
────────────────────────────────────────
Concepto filosófico: Realismo estructural
Autor / Origen: Ladyman & Ross — Every Thing Must Go (2007)
Equivalente operacional: Grafo como lo real, no las entidades
Implementación en ontoref: El DAG captura relaciones; los nodos son
secundarios
────────────────────────────────────────
Concepto filosófico: Lógica de predicados
Autor / Origen: Frege (1879) — Begriffsschrift
Equivalente operacional: Queries sobre el grafo
Implementación en ontoref: where severity == "Hard" | select id claim
---
Los mapeos no triviales
Aristóteles es el arquitecto base. La esencia/accidente es exactamente
invariante/estado-mutable. La potencia/acto es exactamente
current_state/desired_state con la gate como umbral de actualización. Que esto
haya tardado 2.300 años en aparecer en software de forma explícita es
indicativo de cuánto tiempo estuvo implícito.
Whitehead vs Aristóteles es la tensión interna del protocolo. Aristóteles ve
la realidad como sustancias con propiedades. Whitehead la ve como procesos: no
hay cosas, hay eventos. Ontoref vive en esa grieta — la ontología es
aristotélica (qué ES el proyecto), la reflection es whiteheadiana (cómo
DEVIENE). La decisión de mantenerlos como capas separadas es un reconocimiento
implícito de que ninguno basta solo.
Kripke resuelve algo que Aristóteles dejó ambiguo. Aristóteles distingue
esencial de accidental pero no formaliza la modalidad. Kripke dice: una
propiedad esencial es rígida — verdad en todos los mundos posibles accesibles
desde el individuo. Los invariantes de ontoref son exactamente esto: no pueden
ser falsos en ningún estado posible del proyecto sin que el proyecto deje de
ser ese proyecto. Los ADRs que los cambian no violan los invariantes — crean
un nuevo individuo.
Searle es el que más se ignora y más aplica. Un ADR no captura una verdad
metafísica sobre el proyecto — es un hecho institucional. Es verdad porque el
equipo colectivamente lo declaró y comprometió. Exactamente como "este papel
es dinero" o "este jugador está fuera de juego". Sin el acto declarativo, la
constraint no existe. Esto tiene una implicación práctica: si el equipo no
cree en el ADR, no hay constraint real — hay teatro.
Wittgenstein en dos fases distintas. El Tractatus da el fundamento del schema:
los límites de lo tipable son los límites de lo que el sistema puede
representar. Las Investigaciones dan el fundamento de los modos: el
significado de una operación es su uso dentro de un juego de lenguaje — el
modo new_service no describe, prescribe una forma de vida operacional dentro
del proyecto.
La ausencia notable: Heidegger. El ser-en-el-mundo como condición de
posibilidad de cualquier ontología explícita no aparece en ningún modelo de
software operacional. Lo que Heidegger llamaría el trasfondo pre-temático — el
contexto que no se puede formalizar porque es la condición de posibilidad de
la formalización — es exactamente lo que los READMEs intentan capturar y
fracasan. Ontoref no lo resuelve tampoco. Lo que sí hace es reducir la
superficie de ese trasfondo haciendo explícito lo que puede serlo.
✻ Cooked for 1m 2s
❯ genera un pdf con estas dos últimas preguntas en un PDF y añade info sobre
quíen creo la ontología operacional, por qué y dónde se usa actualmente
⏺ Primero verifico qué herramientas de conversión tengo disponibles.
⏺ Bash(which pandoc && pandoc --version | head -1; which wkhtmltopdf; which
weasyprint; which typst)
⎿  /usr/local/bin/pandoc
pandoc 3.7.0.2
/opt/homebrew/bin/weasyprint
/opt/homebrew/bin/typst
⏺ Tengo pandoc y typst. Usaré typst — produce mejor output para contenido
académico/filosófico. Escribo el documento y compilo.
⏺ Write(ontologia-filosofia-software.typ)
⎿  Wrote 360 lines to ontologia-filosofia-software.typ
2 title: "Ontología filosófica y modelo operacional en software"
,
3 author: "Jesús Pérez Lorenzo",
4 )
5
7 paper: "a4",
8 margin: (top: 2.5cm, bottom: 2.5cm, left: 2.8cm, right: 2.8cm)
,
9 numbering: "1",
10 number-align: right,
… +536 lines (ctrl+o to expand)
❯ escribe el pdf tambien !!!
⏺ Bash(cd /Users/Akasha/Development/ontoref/assets/presentation && typst compile
ontologia-filosofia-software.typ ontologia-filosofia-software.pdf 2>&1)
⎿  (No output)
Listed 1 directory (ctrl+o to expand)
⏺ PDF generado en assets/presentation/ontologia-filosofia-software.pdf (179K).
Contiene tres secciones:
1. Universales e invariantes — la correspondencia no es directa: los
invariantes son propiedades esenciales de un singular (Aristóteles → Kripke)
con estatus de hechos institucionales (Searle), no universales en sentido
platónico ni aristotélico.
2. Tabla comparativa completa — 17 filas con concepto, autor/obra/fecha,
equivalente operacional e implementación concreta en ontoref.
3. Genealogía de la ontología operacional en software:
┌────────────────┬────────────────────────────────────────────┬───────────┐
│ Figura │ Contribución │ Año │
├────────────────┼────────────────────────────────────────────┼───────────┤
│ McCarthy │ Representación explícita del conocimiento, │ 1958–1969 │
│ │ situational calculus │ │
├────────────────┼────────────────────────────────────────────┼───────────┤
│ Minsky │ Frames — primera estructura análoga a la │ 1974 │
│ │ sustancia aristotélica │ │
├────────────────┼────────────────────────────────────────────┼───────────┤
│ Lenat │ Cyc — 600K conceptos, el proyecto más │ 1984 │
│ │ ambicioso │ │
├────────────────┼────────────────────────────────────────────┼───────────┤
│ Gruber │ Definición canónica: "especificación de │ 1993 │
│ (Stanford) │ una conceptualización" │ │
├────────────────┼────────────────────────────────────────────┼───────────┤
│ Guarino │ Ontología formal en sistemas de │ 1990s │
│ (ISTC-CNR) │ información, FOIS │ │
├────────────────┼────────────────────────────────────────────┼───────────┤
│ Berners-Lee et │ Web Semántica, RDF, OWL, SPARQL │ 2001 │
│ al. │ │ │
├────────────────┼────────────────────────────────────────────┼───────────┤
│ Google │ Knowledge Graph — ontología operacional a │ 2012 │
│ │ escala de producción │ │
└────────────────┴────────────────────────────────────────────┴───────────┘
Uso actual: biomedicina (Gene Ontology, SNOMED CT, ICD-11), grafos
empresariales (Wikidata, schema.org), manufactura (ISO 15926, BIM/IFC),
agentes IA — y la frontera actual: ontologías del propio proyecto de software
como modelo auto-descriptivo consultable.
El .typ fuente queda en el mismo directorio para ediciones futuras.
✻ Brewed for 3m 16s
※ recap: Generated slides for the open space talk (slides.md) and a philosophical PDF comparing ontology concepts to ontoref's operational model. No pending actions unless you want to review or present either file. (disable recaps in /config)
❯ Qué relación tiene la ontología la filosófica y la operacional con el
taoismo, yin/yang ?
⏺ La relación es más profunda que una metáfora. Hay correspondencias
estructurales genuinas, pero también diferencias que el Taoísmo ilumina mejor
que la tradición occidental.
---
Lo que el Taoísmo ve que la ontología occidental no ve
La ontología occidental desde Parménides privilegia el ser sobre el no-ser, la
presencia sobre la ausencia, la identidad sobre la diferencia. Toda la
tradición aristotélica-escolástica-analítica trabaja desde ahí.
El Taoísmo invierte la pregunta. El Tao (道) es previo a la distinción
ser/no-ser. El primer capítulo del Tao Te Ching:
▎ 道可道，非常道。名可名，非常名。
▎ El Tao que puede nombrarse no es el Tao eterno. El nombre que puede
▎ pronunciarse no es el nombre eterno.
Lo que no puede formalizarse no es una limitación — es la condición de
posibilidad de todo lo que sí puede formalizarse. La ontología operacional que
puede expresarse completamente en un schema no captura la realidad
operacional completa. Heidegger llegó al mismo lugar por otro camino — el
trasfondo pre-temático que hace posible cualquier acto de comprensión
explícita.
---
Yin-Yang — no oposición sino polaridad constitutiva
La confusión más común: yin y yang no son contrarios sino complementarios que
se definen mutuamente. Propiedades clave:
- Cada polo contiene una semilla del opuesto — el punto pequeño dentro de cada
mitad del símbolo
- El exceso de un polo genera su contrario (極則反 — la extremidad se
invierte)
- La tensión entre ellos nunca se resuelve — solo se gestiona dinámicamente
- Uno no existe sin el otro — yin sin yang es vacío inerte, yang sin yin es
movimiento sin forma
Esto es estructuralmente distinto de la dialéctica hegeliana, que busca
síntesis — resolver la contradicción en una unidad superior. El yin-yang no
resuelve. La tensión es constitutiva, permanente.
---
Correspondencias con la ontología filosófica
Concepto taoísta: Tao (道) — el principio previo a toda distinción
Autor / Texto: Laozi, Tao Te Ching (~6-4 aC)
Equivalente occidental más cercano: Ser de Heidegger — previo a los entes
Diferencia clave: El Tao es innombrable; el Ser heideggeriano puede pensarse
aunque no definirse
────────────────────────────────────────
Concepto taoísta: Yin/Yang — dualidad que no se resuelve
Autor / Texto: Tradición Zhou (~1100 aC), sistematizada en I Ching
Equivalente occidental más cercano: Heráclito — logos como tensión de opuestos
Diferencia clave: Heráclito es el único occidental pre-moderno equivalente
────────────────────────────────────────
Concepto taoísta: Wu wei (無為) — acción sin forzar
Autor / Texto: Laozi, Tao Te Ching
Equivalente occidental más cercano: Aristóteles — acto que fluye de la esencia
Diferencia clave: Wu wei no tiene equivalente exacto en Occidente
────────────────────────────────────────
Concepto taoísta: Ji (機) — el momento exacto de transformación
Autor / Texto: Zhuangzi, Zhuangzi (~4 aC)
Equivalente occidental más cercano: Kripke — accesibilidad entre mundos
posibles
Diferencia clave: Ji es cualitativo y contextual; Kripke es lógico-formal
────────────────────────────────────────
Concepto taoísta: Wu ji → Tai ji — de lo indiferenciado a la polaridad
Autor / Texto: Cosmología taoísta, Zhou Dunyi (1017-1073)
Equivalente occidental más cercano: Hegel — de lo abstracto a lo concreto
Diferencia clave: Hegel sintetiza; el taoísmo mantiene la polaridad
────────────────────────────────────────
Concepto taoísta: Relatividad perspectival
Autor / Texto: Zhuangzi — la perspectiva de la rana del pozo
Equivalente occidental más cercano: Wittgenstein tardío — juegos de lenguaje
Diferencia clave: Zhuangzi va más lejos: toda ontología es perspectival
Heráclito es el occidental más cercano. Su logos como tensión dinámica de
opuestos — "el camino hacia arriba y hacia abajo son el mismo" — es
estructuralmente idéntico al yin-yang. Hegel lo notó. La diferencia: Heráclito
vive en la tensión; Hegel la usa como palanca hacia la síntesis.
---
Correspondencias con la ontología operacional en software
Aquí es donde se pone interesante. La ontología OWL-estilo (Gruber, Web
Semántica) es fundamentalmente clasificatoria — jerarquías de tipos, herencia,
subsunción. Aristotélica en su hueso.
El modelo operacional de ontoref es estructuralmente más cercano al Taoísmo:
1. Yin/Yang ↔ Ontología / Reflection
La dualidad ya está en el diseño del protocolo:
- Ontología (core.ncl): lo que ES — invariantes, estructura, ser. Yang — la
capa formal, dura, definida.
- Reflection: lo que DEVIENE — operaciones, modos, movimiento. Yin — la capa
fluida, procesual.
Y como en el símbolo: cada una contiene una semilla de la otra. La ontología
describe estados futuros (desired_state) — contiene movimiento. La reflection
puede actualizar la ontología vía ADRs — contiene forma. Separarlas es
necesario porque tienen ritmos distintos; fundirlas sería colapsar el yin en
el yang.
2. Wu wei ↔ "No enforcement"
Uno de los invariantes del protocolo: coherencia voluntaria que emerge de la
adopción justificada, sin mecanismo de enforcement.
Esto es wu wei aplicado a diseño de sistemas. No impones — creas las
condiciones para que el alineamiento emerja naturalmente. Un sistema de tipos
fuertes fuerza. Una ontología operacional orienta. La diferencia es
exactamente la diferencia entre imponer el Tao y fluir con él.
3. Tensiones ↔ Yin-Yang permanente
Las tensiones en un modelo operacional ("formalización vs. fricción de
adopción", "ontología vs. reflection") son explícitamente irresolubles. No se
busca síntesis — se gestionan.
Esto es taoísta, no hegeliano. Si eliminas la tensión entre formalización y
adopción — maximizando uno — el sistema muere. O es un schema perfecto que
nadie adopta, o es caos que todos adoptan pero nadie puede razonar sobre. La
tensión viva entre los polos es la que sostiene el sistema.
4. Gates ↔ Ji (機) — el momento de transformación
El concepto taoísta de ji es el punto de inflexión donde el potencial se
actualiza — no un estado sino el umbral entre estados. Dinámico, cualitativo,
contextual.
Las gates en ontoref son exactamente esto. No son checkboxes — son condiciones
que marcan el momento en que un estado puede transformarse en otro. La gate
activa no dice "puedes cruzar cuando X sea verdad" sino "este es el umbral que
separa lo que eres de lo que puedes devenir".
5. Wu ji → Tai ji ↔ Schema formal → Ontología regional
La cosmología taoísta describe el origen como Wu ji (無極) — el vacío
indiferenciado previo a cualquier distinción — que da lugar a Tai ji (太極) —
la polaridad primordial yin/yang.
Husserl hizo la misma distinción: ontología formal (estructuras lógicas puras,
previas a cualquier dominio) vs. ontología regional (conceptos de un dominio
específico). El schema.ncl es el Wu ji — la estructura vacía que puede
instanciarse en cualquier proyecto. El .ontology/core.ncl de un proyecto
concreto es el Tai ji — la polaridad específica de ese mundo.
---
Lo que el Taoísmo revela que la tradición occidental pierde
La crítica taoísta a OWL y las ontologías clasificatorias:
Los sistemas como OWL intentan eliminar la ambigüedad mediante clasificación
precisa. El Tao Te Ching advierte: cuanto más preciso el nombre, más excluyes.
La realidad vive en el espacio entre las categorías, no en las categorías
mismas.
Esto explica por qué las ontologías biomédicas — las más maduras del campo —
sufren continuamente con casos límite, dependencia del contexto y la necesidad
de múltiples ejes de clasificación simultáneos. La vista taoísta diría:
estáis intentando resolver una tensión irresolvable. La precisión y la
cobertura son yin y yang — solo se gestionan.
Zhuangzi y el límite de toda ontología:
Zhuangzi va más lejos que Laozi. Toda distinción ontológica es perspectival —
la perspectiva de la rana en el pozo que no puede imaginar el mar. Esto no
lleva al nihilismo sino a la apropiada contextualidad: la ontología correcta
para un proyecto no es la más formalmente precisa sino la que el equipo puede
sostener y evolucionar.
Gruber llegó intuitivamente a lo mismo en su definición de 1993: una ontología
no es una captura de la realidad — es "una especificación de una
conceptualización". Un punto de vista compartido, no una verdad metafísica.
Eso es profundamente zhuangziano sin saberlo.
---
La síntesis imposible — y por qué eso es correcto
No hay síntesis entre el modelo ontológico occidental (jerarquías de tipos,
ser definido, identidad estable) y el Taoísmo (proceso, polaridad
irresolvable, Tao innombrable). Y no debería haberla.
Lo que el Taoísmo aporta a la ontología operacional en software no es una
alternativa — es una corrección de actitud. La tentación del ingeniero es
resolver las tensiones, eliminar la ambigüedad, llevar el sistema a un estado
estable final. El Taoísmo dice: ese estado final no existe. El yin-yang vivo —
la tensión gestionada — es el sistema funcionando correctamente, no el
sistema esperando ser completado.
Un modelo operacional que no tiene tensiones activas no es un modelo maduro.
Es un modelo muerto.
✻ Sautéed for 1m 42s
❯ Y cómo se llega a los DAG y su función en la ontología operacional
⏺ La genealogía es larga y viene de tres tradiciones que convergen. Vale la pena
recorrerla completa porque cada una aporta algo distinto.
---
1. El problema que fuerza el grafo
Antes del grafo hay un problema: ¿cómo representar conocimiento estructurado
de forma que se pueda razonar sobre él?
La prosa no sirve — no es consultable ni verificable. Las listas planas
pierden las relaciones. Las jerarquías de árbol pierden los nodos con
múltiples padres. El grafo emerge como la estructura mínima que captura
relaciones arbitrarias entre conceptos.
Pero el grafo general tiene un problema: puede tener ciclos. Y los ciclos en
ontología son epistemológicamente problemáticos.
---
2. Por qué la aciclicidad — el problema de la justificación circular
Esto viene de dos tradiciones independientes que llegan al mismo resultado:
Aristóteles (384-322 aC) — Analíticos Posteriores: una definición válida
procede de género más diferencia específica. El género es más general que lo
definido — la jerarquía es estrictamente descendente. Si A se define en
términos de B y B en términos de A, ninguno está definido. La justificación
circular es un defecto lógico, no una propiedad tolerable.
Russell (1901) — la paradoja del conjunto de todos los conjuntos que no se
contienen a sí mismos. La solución que Russell y Whitehead desarrollan en
Principia Mathematica (1910) es la teoría de tipos: los tipos forman una
jerarquía estricta — un tipo de nivel N solo puede contener o referirse a
tipos de nivel N-1 o inferior. Esto es estructuralmente un DAG. La aciclicidad
no es una restricción arbitraria — es la solución formal al colapso por
autorreferencia.
Tarski (1933) — verdad como correspondencia entre proposiciones y estructuras.
Las estructuras que usa son relaciones sobre dominios — grafos. La teoría de
modelos formaliza esto.
La convergencia: en lógica, ontología formal y teoría de tipos, la aciclicidad
es el requisito de que las definiciones sean bien fundadas. No puede haber
descenso infinito ni circularidad.
---
3. La entrada en inteligencia artificial — redes semánticas
Collins & Quillian (1969) — "Retrieval time from semantic memory", Cognitive
Psychology.
Primera implementación computacional de un grafo de conocimiento. Nodos =
conceptos, aristas = relaciones (is-a, has-property). La jerarquía is-a es
inherentemente un DAG — si "perro es-un animal" y "animal es-un ser-vivo", la
subsunción es transitiva y acíclica.
Collins y Quillian usaron esto para modelar cómo los humanos recuperamos
información semántica. El experimento: verificar "¿un canario puede respirar?"
tarda más que "¿un canario puede cantar?" porque hay que recorrer más niveles
del DAG. La estructura del grafo predice tiempos de reacción — el
conocimiento humano tiene topología.
Minsky (1974) — frames. Ya discutido, pero la herencia entre frames crea un
DAG. Un frame puede tener múltiples padres (herencia múltiple) — eso descarta
el árbol y exige el grafo. Pero los ciclos de herencia son patológicos — un
frame no puede ser su propio ancestro.
KL-ONE (Brachman & Schmolze, 1985) — el primer sistema formal de Description
Logic. La relación de subsunción entre conceptos forma un DAG. Este trabajo es
el antecedente directo de OWL. La contribución clave: separar la taxonomía
(qué es-un qué) del esquema (qué propiedades tiene qué). Dos DAGs superpuestos
sobre el mismo dominio.
---
4. La formalización de la causalidad como DAG — Pearl
Judea Pearl (1988, 2000) — Causality: Models, Reasoning, and Inference.
Pearl formalizó algo que hasta entonces era intuitivo: la causalidad es
acíclica porque la causalidad es temporal. Si A causa B, B ocurre después de
A. Si B también causara A, tendríamos una contradicción temporal — B ocurre
antes de A y después de A simultáneamente.
Los Bayesian Networks de Pearl son DAGs donde las aristas representan
relaciones causales y los nodos son variables aleatorias. La estructura del
DAG codifica las independencias condicionales del sistema — qué variables son
relevantes para predecir qué otras.
Esto añade algo que las redes semánticas no tenían: dirección con significado
causal, no solo jerárquico. La arista no solo dice "A depende de B" — dice "B
influye sobre A en esta dirección y no al revés".
Para la ontología operacional esto es crucial. Las dependencias entre
invariantes, tensiones, prácticas y gates no son solo jerárquicas — son
cuasi-causales. Un invariante justifica una tensión; una tensión motiva una
práctica; una práctica activa una gate. La dirección importa y no puede
invertirse.
---
5. El DAG en ingeniería — Make, Git, build systems
Paralelo al trabajo académico, los DAGs aparecen en ingeniería por necesidad
práctica:
Make (Feldman, 1976) — el primer build system formal. Las reglas de
compilación forman un DAG: el ejecutable depende de los objetos, los objetos
dependen de los fuentes. Make recorre el DAG en orden topológico — compilar
solo lo que cambió, en el orden correcto. Un ciclo en las dependencias es un
error explícito.
PERT charts (1958, US Navy — programa Polaris) — planificación de proyectos
como DAG de tareas. Las aristas son dependencias temporales. El camino crítico
es el camino más largo en el DAG — determina la duración mínima del proyecto.
Primer uso masivo de DAGs en gestión.
Git (Torvalds, 2005) — el historial de commits es un DAG. Cada commit apunta a
sus padres; los merges crean nodos con múltiples padres; las branches
divergen. La propiedad clave: no puede existir un commit que sea su propio
ancestro. La historia es irreversible — el tiempo es un DAG.
---
6. La función del DAG en ontología operacional
Cuando llega a la ontología operacional, el DAG hace cuatro cosas que ninguna
otra estructura hace juntas:
① Traversal determinista para consultas de impacto
Si cambias un nodo, el DAG define exactamente qué nodos son alcanzables desde
él (descendientes) y qué nodos lo alcanzan (ancestros). Esto es análisis de
impacto: "si modifico este invariante, ¿qué tensiones, prácticas y gates se
ven afectadas?"
En un grafo cíclico esto es indecidible — el cierre transitivo de un nodo en
un grafo cíclico puede ser todo el grafo.
② Orden topológico para ejecución
Los modos operacionales en ontoref son DAGs de pasos con depends_on. El
ordenamiento topológico del DAG da el orden de ejecución válido — sin
necesidad de un scheduler externo. Si el paso B depende del paso A, A siempre
precede a B en cualquier topological sort.
③ Justificación bien fundada — sin circularidad epistémica
En el debate epistemológico clásico, el fundacionalismo dice que el
conocimiento descansa en fundamentos no circulares — como un árbol o DAG con
nodos raíz. El coherentismo dice que el conocimiento es una red de creencias
mutuamente sustentadas — puede ser cíclico.
La ontología operacional es fundacionalista por diseño. Los invariantes son
los nodos raíz — se justifican por decisión arquitectural explícita (ADR), no
por otros nodos del grafo. Las tensiones dependen de los invariantes; las
prácticas dependen de las tensiones; las gates dependen de las prácticas. La
justificación fluye en una dirección.
Un ciclo en ese grafo significaría: "este invariante existe porque esta
práctica existe, y esta práctica existe porque este invariante existe". Eso no
es arquitectura — es dogma circular.
④ Rollback con orden definido
Si necesitas deshacer cambios, el DAG da el orden inverso. En un grafo
cíclico, no hay orden inverso bien definido.
---
7. La tensión con el Taoísmo — DAG vs. ciclo
Aquí está el punto más interesante, conectando con la conversación anterior.
El DAG es yang en su estructura: direccional, jerárquico, asimétrico,
irreversible. Codifica la flecha del tiempo — las causas preceden a los
efectos, las definiciones preceden a lo definido.
El yin-yang taoísta es cíclico: yin genera yang, yang genera yin. Las
estaciones, el día y la noche, vida y muerte — todo retorna. El Tao es el
ciclo eterno.
Esto genera una tensión real en la ontología operacional:
DAG Yin-Yang
───────────────────────── ──────────────────────────
Irreversible Cíclico
Asimétrico Simétrico en transformación
El pasado no depende El pasado se convierte
del futuro en futuro
Fundacionalista Coherentista
La resolución que ontoref hace implícitamente — sin nombrarlo — es separar dos
temporalidades:
- Sincrónica (snapshot): el DAG es válido dentro de un momento dado. La
ontología en t₀ es un DAG acíclico.
- Diacrónica (evolución): la secuencia de snapshots puede tener patrones
cíclicos. Lo que era tensión puede convertirse en invariante; lo que era
práctica puede ser abandonado y redescubierto.
El DAG captura la estructura del ser en un momento. El yin-yang captura el
proceso de transformación a través del tiempo. Son complementarios, no
contradictorios — exactamente como ontología y reflection son complementarios.
Dicho de otra manera: el contenido es un DAG; la evolución es un ciclo. El I
Ching — el libro de los cambios — es un sistema para razonar sobre las
transformaciones de un estado a otro. Los 64 hexagramas son estados (nodos);
las transformaciones entre ellos son las aristas. El sistema completo es... un
grafo. No un DAG — un grafo con ciclos, porque la realidad vuelve.
---
Síntesis
┌───────────────────────┬─────────────────────────────────────────────────┐
│ Origen │ Contribución al DAG en ontología operacional │
├───────────────────────┼─────────────────────────────────────────────────┤
│ Aristóteles (384 aC) │ Definición bien fundada — jerarquía sin │
│ │ circularidad │
├───────────────────────┼─────────────────────────────────────────────────┤
│ Russell/Whitehead │ Teoría de tipos — aciclicidad como solución al │
│ (1910) │ colapso por autorreferencia │
├───────────────────────┼─────────────────────────────────────────────────┤
│ Collins & Quillian │ Primera red semántica computacional — is-a como │
│ (1969) │ DAG │
├───────────────────────┼─────────────────────────────────────────────────┤
│ Minsky (1974) │ Frames con herencia múltiple — DAG sobre árbol │
├───────────────────────┼─────────────────────────────────────────────────┤
│ Brachman/Schmolze │ Description Logic — subsunción formal como DAG │
│ (1985) │ │
├───────────────────────┼─────────────────────────────────────────────────┤
│ Pearl (1988) │ Causalidad como DAG — dirección con significado │
│ │ temporal │
├───────────────────────┼─────────────────────────────────────────────────┤
│ Feldman/Make (1976) │ Dependencias de build como DAG — orden │
│ │ topológico práctico │
├───────────────────────┼─────────────────────────────────────────────────┤
│ Torvalds/Git (2005) │ Historia como DAG — irreversibilidad del tiempo │
│ │ en VCS │
└───────────────────────┴─────────────────────────────────────────────────┘
Lo que el DAG aporta que ninguna otra estructura da: razonamiento sobre
dependencias con garantía de terminación y justificación no circular. Es el
mínimo estructural para que una ontología pueda responder "¿qué afecta a qué?"
sin entrar en bucle infinito.
Y la tensión con el Taoísmo no es un defecto — es la tensión constitutiva
entre estructura y proceso, entre el instante formalizados y el tiempo que
fluye. El DAG captura el yang del sistema. El ciclo de ADRs, versiones y
transformaciones captura el yin.
✻ Brewed for 1m 56s
❯ ¿ tal vez quieras incluir algo como material relevante y añadir alguna
refencia y perpectiva ?
⏺ Voy a leer el archivo typst actual y añadir las dos nuevas secciones más la
bibliografía.
Read 1 file (ctrl+o to expand)
⎿  Interrupted · What should Claude do instead?
❯ continua
⏺ Update(ontologia-filosofia-software.typ)
⎿  Added 323 lines
358 La ontología operacional en software no es una importación rec
iente de la filosofía — es una convergencia que lleva setenta
años ocurriendo, desde los frames de Minsky hasta los grafos d
e conocimiento de Google. Lo que ha cambiado con la proliferac
ión de agentes de IA es la urgencia: cuando un agente puede mo
dificar código, infraestructura o configuración de forma autón
oma, la ausencia de un modelo explícito del proyecto no es una
deuda técnica. Es una pérdida de control.
359
360 La ontología no es la solución a ese problema. Es el nombre de
l problema que hay que resolver.
361 +
362 +#pagebreak()
363 +
364 +// ─── 4. TAOÍSMO Y ONTOLOGÍA OPERACIONAL ────────────────────
+────────────────
365 +
366 += Taoísmo, Yin-Yang y ontología operacional
367 +
368 +== Lo que la tradición occidental no vio
369 +
370 +La ontología occidental desde Parménides privilegia el *ser* s
+obre el *no-ser*, la *presencia* sobre la *ausencia*, la *iden
+tidad* sobre la *diferencia*. Toda la tradición aristotélica-e
+scolástica-analítica trabaja desde ese punto de partida.
371 +
372 +El Taoísmo invierte la pregunta. El Tao (道) es previo a la di
+stinción ser/no-ser. El primer capítulo del _Tao Te Ching_ (La
+ozi, ~siglo VI-IV aC):
373 +
374 +#align(center)[
375 + #text(style: "italic")[
376 + 道可道，非常道。名可名，非常名。\
377 + El Tao que puede nombrarse no es el Tao eterno.\
378 + El nombre que puede pronunciarse no es el nombre eterno.
379 + ]
380 +]
381 +
382 +Lo que no puede formalizarse no es una limitación del modelo —
+ es la condición de posibilidad de todo lo que sí puede formal
+izarse. La ontología operacional que puede expresarse completa
+mente en un schema no captura la realidad operacional completa
+. Heidegger llegó al mismo lugar por camino diferente: el *tra
+sfondo pre-temático* que hace posible cualquier acto de compre
+nsión explícita es precisamente lo que escapa a la formalizaci
+ón.
383 +
384 +== Yin-Yang — polaridad constitutiva, no oposición
385 +
386 +La confusión más frecuente: yin y yang no son *contrarios* sin
+o *complementarios que se definen mutuamente*. Las propiedades
+ estructurales del par son:
387 +
388 +- Cada polo *contiene una semilla del opuesto* — representada
+por el punto de color contrario en el símbolo
389 +- El exceso de un polo *genera su contrario* (極則反 — la extr
+emidad se invierte)
390 +- La tensión entre ellos *nunca se resuelve* en síntesis — sol
+o se gestiona dinámicamente
391 +- Uno *no existe sin el otro* — yin sin yang es vacío inerte,
+yang sin yin es movimiento sin forma
392 +
393 +Esto es estructuralmente distinto de la dialéctica hegeliana,
+que busca síntesis — resolver la contradicción en una unidad s
+uperior. El yin-yang no resuelve. La tensión es constitutiva,
+permanente. Hegel usa la contradicción como *palanca*; el Taoí
+smo la habita como *condición*.
394 +
395 +Heráclito (535-475 aC) es el occidental más cercano: su logos
+como tensión dinámica de opuestos — "el camino hacia arriba y
+hacia abajo son el mismo" — es estructuralmente idéntico al yi
+n-yang. La diferencia: Heráclito vive en la tensión, Hegel la
+usa para superarla.
396 +
397 +== Correspondencias con el modelo operacional
398 +
399 +#table(
400 + columns: (1.4fr, 1.3fr, 1.8fr, 1.8fr),
401 + inset: 7pt,
402 + fill: (col, row) => if row == 0 { rgb("#c04000") } else if c
+alc.odd(row) { rgb("#fdf6f0") } else { white },
403 + table.header(
404 + text(fill: white, weight: "bold")[Concepto taoísta],
405 + text(fill: white, weight: "bold")[Texto / Época],
406 + text(fill: white, weight: "bold")[Equivalente occidental m
+ás cercano],
407 + text(fill: white, weight: "bold")[Correspondencia operacio
+nal],
408 + ),
409 + [*Tao* (道) — principio previo a toda distinción],
410 + [Laozi, _Tao Te Ching_ \ (~6-4 aC)],
411 + [Ser de Heidegger — previo a los entes],
412 + [Trasfondo pre-temático que ningún schema captura completame
+nte],
413 +
414 + [*Yin / Yang* — polaridad que no se resuelve],
415 + [Tradición Zhou (~1100 aC) \ sistematizada en _I Ching_],
416 + [Heráclito — logos como tensión de opuestos],
417 + [Ontología (ser) / Reflection (devenir) — capas que se neces
+itan mutuamente],
418 +
419 + [*Wu wei* (無為) — acción sin forzar],
420 + [Laozi, _Tao Te Ching_],
421 + [Sin equivalente exacto en Occidente],
422 + ["No enforcement" — coherencia que emerge de adopción justif
+icada, no impuesta],
423 +
424 + [*Ji* (機) — el momento exacto de transformación],
425 + [Zhuangzi, _Zhuangzi_ \ (~4 aC)],
426 + [Kripke — mundos posibles accesibles],
427 + [Gates — umbral cualitativo entre estados, no condición bina
+ria],
428 +
429 + [*Wu ji → Tai ji* — de lo indiferenciado a la polaridad],
430 + [Zhou Dunyi (1017-1073) \ _Taijitu shuo_],
431 + [Husserl — ontología formal vs. regional],
432 + [schema.ncl (vacío universal) → core.ncl (polaridad concreta
+ del proyecto)],
433 +
434 + [*Relatividad perspectival*],
435 + [Zhuangzi — la rana del pozo],
436 + [Wittgenstein tardío — juegos de lenguaje],
437 + [Toda ontología es una conceptualización, no una captura de
+la realidad (Gruber)],
438 +)
439 +
440 +== Las cuatro correspondencias profundas
441 +
442 +*Yin/Yang ↔ Ontología/Reflection.* La dualidad ya está en el d
+iseño del protocolo. La ontología (core.ncl) captura lo que ES
+ — invariantes, estructura, ser; capa yang: formal, dura, defi
+nida. La reflection captura lo que DEVIENE — operaciones, modo
+s, movimiento; capa yin: fluida, procesual. Como en el símbolo
+: cada una contiene una semilla de la otra. La ontología descr
+ibe estados *futuros* (desired_state) — contiene movimiento. L
+a reflection puede *actualizar* la ontología vía ADRs — contie
+ne forma. Separarlas es necesario porque tienen ritmos de camb
+io distintos; fundirlas colapsaría el yin en el yang.
443 +
444 +*Wu wei ↔ "No enforcement".* Uno de los invariantes del protoc
+olo: coherencia voluntaria que emerge de la adopción justifica
+da, sin mecanismo de enforcement. Esto es wu wei aplicado a di
+seño de sistemas. No impones — creas las condiciones para que
+el alineamiento emerja naturalmente. Un sistema de tipos fuert
+es fuerza; una ontología operacional orienta. La diferencia es
+ exactamente la diferencia entre imponer el Tao y fluir con él
+.
445 +
446 +*Tensiones ↔ Yin-Yang permanente.* Las tensiones en un modelo
+operacional ("formalización vs. fricción de adopción", "ontolo
+gía vs. reflection") son explícitamente irresolubles. No se bu
+sca síntesis — se gestionan. Si eliminas la tensión entre form
+alización y adopción maximizando uno de los polos, el sistema
+muere: o es un schema perfecto que nadie adopta, o es caos ope
+racional que todos adoptan pero nadie puede razonar sobre él.
447 +
448 +*Gates ↔ Ji (機).* El concepto taoísta de ji es el punto de in
+flexión donde el potencial se actualiza — no un estado sino el
+ umbral entre estados. Dinámico, cualitativo, contextual. Las
+gates en el modelo operacional son exactamente esto: no checkb
+oxes — son condiciones que marcan el momento en que un estado
+puede transformarse en otro.
449 +
450 +== La crítica taoísta a la ontología clasificatoria
451 +
452 +Los sistemas como OWL intentan eliminar la ambigüedad mediante
+ clasificación precisa. El _Tao Te Ching_ advierte: cuanto más
+ preciso el nombre, más excluyes. La realidad vive en el espac
+io *entre* las categorías, no en las categorías mismas.
453 +
454 +Esto explica por qué las ontologías biomédicas — las más madur
+as del campo — sufren continuamente con casos límite, dependen
+cia del contexto y la necesidad de múltiples ejes de clasifica
+ción simultáneos. La vista taoísta diría: estáis intentando re
+solver una tensión constitutiva. La precisión y la cobertura s
+on yin y yang — no se resuelven, se equilibran.
455 +
456 +Zhuangzi va más lejos que Laozi. Toda distinción ontológica es
+ perspectival. Esto no lleva al nihilismo sino a la *apropiada
+ contextualidad*: la ontología correcta para un proyecto no es
+ la más formalmente precisa sino la que el equipo puede sosten
+er y evolucionar. Gruber llegó al mismo lugar en 1993 sin sabe
+rlo: una ontología es "una especificación de una conceptualiza
+ción" — un punto de vista compartido, no una verdad metafísica
+.
457 +
458 +#pagebreak()
459 +
460 +// ─── 5. DAGs ───────────────────────────────────────────────
+─────────────────
461 +
462 += DAGs — genealogía y función en ontología operacional
463 +
464 +== El problema que fuerza el grafo
465 +
466 +Antes del grafo hay un problema: ¿cómo representar conocimient
+o estructurado de forma que se pueda razonar sobre él? La pros
+a no es consultable ni verificable. Las listas planas pierden
+las relaciones. Las jerarquías de árbol pierden los nodos con
+múltiples padres. El grafo emerge como la estructura mínima qu
+e captura relaciones arbitrarias entre conceptos.
467 +
468 +Pero el grafo general tiene un problema: puede tener ciclos. Y
+ los ciclos en ontología son epistemológicamente problemáticos
+.
469 +
470 +== Por qué la aciclicidad — el problema de la justificación ci
+rcular
471 +
472 +Dos tradiciones independientes llegan al mismo resultado:
473 +
474 +*Aristóteles* (_Analíticos Posteriores_): una definición válid
+a procede de género más diferencia específica. El género es má
+s general que lo definido — la jerarquía es estrictamente desc
+endente. Si A se define en términos de B y B en términos de A,
+ ninguno está definido. La justificación circular es un defect
+o lógico.
475 +
476 +*Russell* (1901): la paradoja del conjunto de todos los conjun
+tos que no se contienen a sí mismos. La solución en _Principia
+ Mathematica_ (1910, con Whitehead) es la *teoría de tipos*: l
+os tipos forman una jerarquía estricta — un tipo de nivel N so
+lo puede referirse a tipos de nivel N-1 o inferior. Esto es es
+tructuralmente un DAG. La aciclicidad no es una restricción ar
+bitraria — es la solución formal al colapso por autorreferenci
+a.
477 +
478 +La convergencia: en lógica, ontología formal y teoría de tipos
+, la aciclicidad es el requisito de que las definiciones sean
+*bien fundadas*. No puede haber descenso infinito ni circulari
+dad.
479 +
480 +== Línea genealógica
481 +
482 +#table(
483 + columns: (0.8fr, 2fr, 2.5fr),
484 + inset: 7pt,
485 + fill: (col, row) => if row == 0 { rgb("#c04000") } else if c
+alc.odd(row) { rgb("#fdf6f0") } else { white },
486 + table.header(
487 + text(fill: white, weight: "bold")[Año],
488 + text(fill: white, weight: "bold")[Autor / Hito],
489 + text(fill: white, weight: "bold")[Contribución al DAG en o
+ntología],
490 + ),
491 + [384-322 aC],
492 + [Aristóteles — _Analíticos Posteriores_],
493 + [Definición bien fundada: jerarquía sin circularidad. Género
+ → diferencia → especie.],
494 +
495 + [1879],
496 + [Frege — _Begriffsschrift_],
497 + [Lógica de predicados: relaciones formales entre conceptos.
+Base para representar grafos de conocimiento.],
498 +
499 + [1901-1910],
500 + [Russell & Whitehead — _Principia Mathematica_],
501 + [Teoría de tipos como DAG: aciclicidad como solución al cola
+pso por autorreferencia.],
502 +
503 + [1933],
504 + [Tarski — "El concepto de verdad"],
505 + [Verdad como correspondencia entre proposiciones y estructur
+as (grafos). Base de la validación formal.],
506 +
507 + [1958],
508 + [US Navy — PERT charts (programa Polaris)],
509 + [DAG para planificación de proyectos: camino crítico como re
+corrido del grafo de dependencias temporales.],
510 +
511 + [1969],
512 + [Collins & Quillian — "Retrieval time from semantic memory"]
+,
513 + [Primera red semántica computacional: is-a como DAG. La topo
+logía del grafo predice tiempos de reacción humanos.],
514 +
515 + [1974],
516 + [Minsky — "A Framework for Representing Knowledge"],
517 + [Frames con herencia múltiple: DAG sobre árbol. Primer siste
+ma con nodos de múltiples padres.],
518 +
519 + [1976],
520 + [Feldman — Make],
521 + [Build system como DAG de dependencias. Orden topológico par
+a compilación incremental. Ciclos = error explícito.],
522 +
523 + [1985],
524 + [Brachman & Schmolze — KL-ONE],
525 + [Description Logic: subsunción formal como DAG. Antecedente
+directo de OWL.],
526 +
527 + [1988],
528 + [Pearl — _Probabilistic Reasoning in Intelligent Systems_],
529 + [Causalidad como DAG: la asimetría temporal hace la causalid
+ad inherentemente acíclica.],
530 +
531 + [2000],
532 + [Pearl — _Causality_],
533 + [Do-calculus: intervención como operación sobre el DAG causa
+l. Separación entre correlación y causa.],
534 +
535 + [2001],
536 + [Berners-Lee et al. — Web Semántica],
537 + [RDF/OWL: grafos de conocimiento como estándar industrial. D
+AG de subsunción en jerarquías de clases.],
538 +
539 + [2005],
540 + [Torvalds — Git],
541 + [Historia de commits como DAG: irreversibilidad del tiempo e
+n control de versiones. Merges = nodos con múltiples padres.],
542 +)
543 +
544 +== Las cuatro funciones del DAG en ontología operacional
545 +
546 +*① Traversal determinista para análisis de impacto.* Si cambia
+s un nodo, el DAG define exactamente qué nodos son alcanzables
+ desde él (descendientes) y qué nodos lo alcanzan (ancestros).
+ Esto es análisis de impacto: "si modifico este invariante, ¿q
+ué tensiones, prácticas y gates se ven afectadas?" En un grafo
+ cíclico esto es indecidible — el cierre transitivo de un nodo
+ puede ser todo el grafo.
547 +
548 +*② Orden topológico para ejecución.* Los modos operacionales s
+on DAGs de pasos con dependencias. El ordenamiento topológico
+da el orden de ejecución válido sin necesidad de un scheduler
+externo. Si el paso B depende del paso A, A siempre precede a
+B en cualquier topological sort.
549 +
550 +*③ Justificación bien fundada — sin circularidad epistémica.*
+El debate clásico en epistemología enfrenta fundacionalismo (e
+l conocimiento descansa en fundamentos no circulares — DAG con
+ nodos raíz) contra coherentismo (red de creencias mutuamente
+sustentadas — puede ser cíclica). La ontología operacional es
+fundacionalista por diseño: los invariantes son nodos raíz jus
+tificados por ADR explícito, no por otros nodos del grafo. Un
+ciclo significaría: "este invariante existe porque esta prácti
+ca existe, y esta práctica existe porque este invariante exist
+e" — dogma circular, no arquitectura.
551 +
552 +*④ Rollback con orden definido.* Deshacer cambios requiere un
+orden inverso bien definido. En un grafo cíclico no existe ese
+ orden. El DAG garantiza que el rollback siempre tiene una sec
+uencia válida.
553 +
554 +== La tensión con el Taoísmo — DAG vs. ciclo
555 +
556 +El DAG es *yang* en su estructura: direccional, jerárquico, as
+imétrico, irreversible. Codifica la flecha del tiempo — las ca
+usas preceden a los efectos, las definiciones preceden a lo de
+finido.
557 +
558 +El yin-yang taoísta es *cíclico*: yin genera yang, yang genera
+ yin. Las estaciones, el día y la noche, vida y muerte — todo
+retorna.
559 +
560 +La resolución está en separar dos temporalidades:
561 +
562 +- *Sincrónica* (snapshot): el DAG es válido dentro de un momen
+to dado. La ontología en $t_0$ es un grafo acíclico.
563 +- *Diacrónica* (evolución): la secuencia de snapshots puede te
+ner patrones cíclicos. Lo que era tensión puede convertirse en
+ invariante; lo que era práctica puede ser abandonado y redesc
+ubierto.
564 +
565 +El DAG captura la *estructura del ser en un momento*. El ciclo
+ taoísta captura el *proceso de transformación a través del ti
+empo*. Son complementarios, no contradictorios — exactamente c
+omo ontología y reflection son complementarios en el protocolo
+. El *I Ching* — el libro de los cambios — es un sistema para
+razonar sobre las transformaciones de un estado a otro: 64 hex
+agramas como estados (nodos), transformaciones entre ellos com
+o aristas. El sistema completo es un grafo. No un DAG — un gra
+fo con ciclos, porque la realidad vuelve.
566 +
567 +#pagebreak()
568 +
569 +// ─── 6. REFERENCIAS ────────────────────────────────────────
+─────────────────
570 +
571 += Referencias y lecturas recomendadas
572 +
573 +== Filosofía clásica y ontología
574 +
575 +#set par(first-line-indent: 0em)
576 +
577 +*Aristóteles.* _Metafísica_. Traducción de Tomás Calvo Martíne
+z. Madrid: Gredos, 1994. [~330 aC] \
578 +#text(fill: rgb("#666666"), size: 9.5pt)[El libro fundamental
+para la distinción esencia/accidente, potencia/acto y las cate
+gorías. El libro IX sobre potencia es la base del modelo estad
+o-actual/estado-deseado.]
579 +
580 +*Aristóteles.* _Analíticos Posteriores_. Traducción de Miguel
+Candel Sanmartín. Madrid: Gredos, 1988. [~350 aC] \
581 +#text(fill: rgb("#666666"), size: 9.5pt)[Formaliza el requisit
+o de definiciones bien fundadas — antecedente directo de la ac
+iclicidad en DAGs.]
582 +
583 +*Laozi.* _Tao Te Ching_. Traducción y comentarios de Stephen M
+itchell. Nueva York: Harper Perennial, 1992. [~siglo VI-IV aC]
+ \
584 +#text(fill: rgb("#666666"), size: 9.5pt)[Texto fundacional del
+ Taoísmo. Los primeros y últimos capítulos son los más relevan
+tes para la relación con ontología operacional.]
585 +
586 +*Zhuangzi.* _Zhuangzi: The Complete Writings_. Traducción de B
+rook Ziporyn. Indianapolis: Hackett, 2020. [~siglo IV aC] \
587 +#text(fill: rgb("#666666"), size: 9.5pt)[Especialmente los cap
+ítulos internos (1-7). La relatividad perspectival de Zhuangzi
+ como crítica de toda ontología clasificatoria.]
588 +
589 +*Frege, G.* _Begriffsschrift_. Halle: Nebert, 1879. \
590 +#text(fill: rgb("#666666"), size: 9.5pt)[Primera formulación d
+e la lógica de predicados. El antecedente formal de toda repre
+sentación de conocimiento estructurado.]
591 +
592 +*Russell, B. & Whitehead, A.N.* _Principia Mathematica_. Cambr
+idge: Cambridge University Press, 1910-1913. \
593 +#text(fill: rgb("#666666"), size: 9.5pt)[La teoría de tipos co
+mo DAG para evitar la autorreferencia circular. El capítulo in
+troductorio explica el principio del círculo vicioso.]
594 +
595 +*Wittgenstein, L.* _Tractatus Logico-Philosophicus_. Londres:
+Kegan Paul, 1922. \
596 +#text(fill: rgb("#666666"), size: 9.5pt)["Los límites de mi le
+nguaje son los límites de mi mundo." El fundamento de por qué
+el schema Nickel define la frontera de lo representable en el
+sistema.]
597 +
598 +*Wittgenstein, L.* _Investigaciones filosóficas_. Oxford: Blac
+kwell, 1953. \
599 +#text(fill: rgb("#666666"), size: 9.5pt)[Juegos de lenguaje co
+mo práctica. El significado como uso — los modos operacionales
+ como juegos de lenguaje de un proyecto.]
600 +
601 +*Hegel, G.W.F.* _Fenomenología del Espíritu_. Traducción de Ma
+nuel Jiménez Redondo. Valencia: Pre-Textos, 2006. [1807] \
602 +#text(fill: rgb("#666666"), size: 9.5pt)[Dialéctica tesis-antí
+tesis-síntesis. Contrástese con el yin-yang: la diferencia ent
+re síntesis y tensión gestionada permanentemente.]
603 +
604 +*Husserl, E.* _Ideas relativas a una fenomenología pura y una
+filosofía fenomenológica_. México: FCE, 1993. [1913] \
605 +#text(fill: rgb("#666666"), size: 9.5pt)[La distinción ontolog
+ía formal/regional — estructura vacía universal vs. conceptos
+de dominio específico.]
606 +
607 +*Whitehead, A.N.* _Process and Reality_. Nueva York: Free Pres
+s, 1978. [1929] \
608 +#text(fill: rgb("#666666"), size: 9.5pt)[La realidad como proc
+eso, no sustancia. El fundamento filosófico de la capa reflect
+ion como devenir distinto del ser ontológico.]
609 +
610 +*Kripke, S.* _Naming and Necessity_. Cambridge: Harvard Univer
+sity Press, 1980. \
611 +#text(fill: rgb("#666666"), size: 9.5pt)[Propiedades esenciale
+s rígidas y semántica de mundos posibles. El fundamento modal
+de los invariantes operacionales.]
612 +
613 +*Searle, J.* _The Construction of Social Reality_. Nueva York:
+ Free Press, 1995. \
614 +#text(fill: rgb("#666666"), size: 9.5pt)[Hechos institucionale
+s como fundamento de las decisiones declaradas. El ADR como ac
+to de habla colectivo que crea realidad operacional.]
615 +
616 +*Parfit, D.* _Reasons and Persons_. Oxford: Oxford University
+Press, 1984. \
617 +#text(fill: rgb("#666666"), size: 9.5pt)[Identidad a través de
+l tiempo. La pregunta "¿es el mismo proyecto?" cuando sus inva
+riantes cambian vía ADR.]
618 +
619 +*Ladyman, J. & Ross, D.* _Every Thing Must Go: Metaphysics Nat
+uralized_. Oxford: Oxford University Press, 2007. \
620 +#text(fill: rgb("#666666"), size: 9.5pt)[Realismo estructural:
+ las relaciones son más reales que las entidades. El DAG como
+estructura fundamental, los nodos como secundarios.]
621 +
622 +*Quine, W.V.O.* "On What There Is." _Review of Metaphysics_, 2
+(5), 1948. \
623 +#text(fill: rgb("#666666"), size: 9.5pt)[El concepto de compro
+miso ontológico: toda teoría asume la existencia de ciertas en
+tidades. Todo schema asume una ontología aunque no lo declare.
+]
624 +
625 +*Tarski, A.* "The Concept of Truth in Formalized Languages." E
+n _Logic, Semantics, Metamathematics_. Oxford: Clarendon Press
+, 1956. [1933] \
626 +#text(fill: rgb("#666666"), size: 9.5pt)[Verdad como correspon
+dencia. El fundamento de la validación formal — nickel typeche
+ck como verificación tarsquiana.]
627 +
628 +== Inteligencia artificial y representación del conocimiento
629 +
630 +*Minsky, M.* "A Framework for Representing Knowledge." MIT AI
+Lab Memo 306, 1974. \
631 +#text(fill: rgb("#666666"), size: 9.5pt)[Los frames como prime
+ra estructura computacional análoga a la sustancia aristotélic
+a con propiedades heredables.]
632 +
633 +*Collins, A.M. & Quillian, M.R.* "Retrieval time from semantic
+ memory." _Journal of Verbal Learning and Verbal Behavior_, 8(
+2), 240-247, 1969. \
634 +#text(fill: rgb("#666666"), size: 9.5pt)[Primera red semántica
+ computacional. Demuestra que la topología del grafo de conoci
+miento predice el comportamiento cognitivo.]
635 +
636 +*Brachman, R.J. & Schmolze, J.G.* "An overview of the KL-ONE k
+nowledge representation system." _Cognitive Science_, 9(2), 17
+1-216, 1985. \
637 +#text(fill: rgb("#666666"), size: 9.5pt)[Description Logic: la
+ subsunción como relación formal que genera el DAG de concepto
+s. Antecedente teórico de OWL.]
638 +
639 +*Gruber, T.* "A translation approach to portable ontology spec
+ifications." _Knowledge Acquisition_, 5(2), 199-220, 1993. \
640 +#text(fill: rgb("#666666"), size: 9.5pt)[La definición canónic
+a: ontología como especificación de una conceptualización. Ref
+erencia obligatoria para cualquier trabajo en ontología de sof
+tware.]
641 +
642 +*Lenat, D.B. & Guha, R.V.* _Building Large Knowledge-Based Sys
+tems: Representation and Inference in the Cyc Project_. Readin
+g: Addison-Wesley, 1990. \
643 +#text(fill: rgb("#666666"), size: 9.5pt)[El proyecto más ambic
+ioso de ontología operacional. Sus fracasos son tan informativ
+os como sus logros.]
644 +
645 +*Pearl, J.* _Probabilistic Reasoning in Intelligent Systems_.
+San Mateo: Morgan Kaufmann, 1988. \
646 +#text(fill: rgb("#666666"), size: 9.5pt)[Bayesian networks com
+o DAGs causales. La formalización de por qué la causalidad es
+inherentemente acíclica.]
647 +
648 +*Pearl, J.* _Causality: Models, Reasoning, and Inference_. Cam
+bridge: Cambridge University Press, 2000. \
649 +#text(fill: rgb("#666666"), size: 9.5pt)[El do-calculus. Disti
+nción entre correlación y causa como operaciones sobre el DAG.
+ Segunda edición (2009) incluye el modelo causal completo.]
650 +
651 +*Guarino, N. (ed.)* _Formal Ontology in Information Systems_.
+Amsterdam: IOS Press, 1998. \
652 +#text(fill: rgb("#666666"), size: 9.5pt)[Actas de FOIS'98. La
+conferencia fundacional del campo. Especialmente el artículo i
+ntroductorio de Guarino sobre ontología formal vs. de dominio.
+]
653 +
654 +*Berners-Lee, T., Hendler, J. & Lassila, O.* "The Semantic Web
+." _Scientific American_, 284(5), 34-43, 2001. \
655 +#text(fill: rgb("#666666"), size: 9.5pt)[El artículo que popul
+arizó las ontologías en ingeniería de software. La visión de l
+a web como grafo de conocimiento estructurado.]
656 +
657 +== Ingeniería de software y praxis
658 +
659 +*Nygard, M.* "Documenting Architecture Decisions." Cognitect B
+log, 2011. Disponible en: cognitect.com/blog \
660 +#text(fill: rgb("#666666"), size: 9.5pt)[La propuesta original
+ de ADRs como documentación ligera de decisiones. El precursor
+ directo de los ADRs con constraints tipadas.]
661 +
662 +*Brown, S.* _Software Architecture for Developers_. Leanpub, 2
+014. \
663 +#text(fill: rgb("#666666"), size: 9.5pt)[El modelo C4 como alt
+ernativa a los diagramas UML. Introduce la idea de múltiples n
+iveles de abstracción para describir un sistema.]
664 +
665 +*Hohpe, G. & Woolf, B.* _Enterprise Integration Patterns_. Bos
+ton: Addison-Wesley, 2003. \
666 +#text(fill: rgb("#666666"), size: 9.5pt)[Patrones como vocabul
+ario compartido — la idea de que nombrar los patrones operacio
+nales es un acto ontológico.]
667 +
668 +== Perspectivas adicionales
669 +
670 +*Zhou Dunyi.* _Taijitu shuo_ (Explicación del Diagrama del Sup
+remo Último). [1017-1073] \
671 +#text(fill: rgb("#666666"), size: 9.5pt)[La cosmología taoísta
+ sistematizada: wu ji → tai ji → yin-yang. La transición de lo
+ indiferenciado a la polaridad como modelo de emergencia estru
+ctural.]
672 +
673 +*Heidegger, M.* _Ser y Tiempo_. Traducción de Jorge Eduardo Ri
+vera. Santiago: Editorial Universitaria, 1997. [1927] \
674 +#text(fill: rgb("#666666"), size: 9.5pt)[El trasfondo pre-temá
+tico que ninguna ontología captura completamente. La ausencia
+notable en todos los modelos operacionales de software.]
675 +
676 +*Heráclito.* _Fragmentos_. Edición de Rodolfo Mondolfo. Buenos
+ Aires: Losada, 2007. [~500 aC] \
677 +#text(fill: rgb("#666666"), size: 9.5pt)[El único pensador pre
+socrático estructuralmente equivalente al yin-yang. El fragmen
+to DK22B60 — "el camino hacia arriba y hacia abajo son el mism
+o" — es el punto de partida.]
678 +
679 +*Bateson, G.* _Steps to an Ecology of Mind_. Nueva York: Balla
+ntine, 1972. \
680 +#text(fill: rgb("#666666"), size: 9.5pt)[La diferencia que hac
+e una diferencia. Epistemología sistémica que conecta Taoísmo,
+ cibernética y representación del conocimiento. Perspectiva po
+co citada en CS pero fundamentalmente relevante.]
681 +
682 +*Winograd, T. & Flores, F.* _Understanding Computers and Cogni
+tion_. Norwood: Ablex, 1986. \
683 +#text(fill: rgb("#666666"), size: 9.5pt)[La crítica más influy
+ente a la IA simbólica desde Heidegger. Argumenta que el trasf
+ondo de comprensión no puede formalizarse — límite de toda ont
+ología operacional.]
⏺ Bash(typst compile ontologia-filosofia-software.typ
ontologia-filosofia-software.pdf 2>&1)
⎿  (No output)
⏺ Bash(ls -lh /Users/Akasha/Development/ontoref/assets/presentation/ontologia-fi
losofia-software.pdf && typst query --field value
ontologia-filosofia-software.typ "<sy…)
⎿  -rw-r--r--@ 1 jesusperezlorenzo admin 321K Apr 24 22:46 /Users/Akas
ha/Development/ontoref/assets/presentation/ontologia-filosofia-softwar
e.pdf
… +2 lines (ctrl+o to expand)
⏺ PDF actualizado — 20 páginas, 321K. Lo que se añadió:
Sección 4 — Taoísmo, Yin-Yang y ontología operacional
- Por qué el Taoísmo ve lo que la tradición occidental no ve (el trasfondo
pre-temático que ningún schema captura)
- La distinción estructural entre yin-yang y dialéctica hegeliana — polaridad
permanente vs. síntesis
- Tabla comparativa: Tao, Wu wei, Ji, Wu ji/Tai ji, relatividad perspectival ↔
equivalentes occidentales y operacionales
- Las cuatro correspondencias profundas con el modelo de ontoref
- La crítica taoísta a la ontología OWL-clasificatoria
Sección 5 — DAGs: genealogía y función
- El problema que fuerza el grafo y por qué la aciclicidad no es arbitraria
- Tabla genealógica: Aristóteles (384 aC) → Git (2005), con contribución de
cada autor al DAG en ontología
- Las cuatro funciones del DAG: traversal determinista, orden topológico,
justificación bien fundada, rollback ordenado
- La tensión DAG/ciclo taoísta — resolución por separación
sincrónico/diacrónico
Sección 6 — Referencias (29 entradas anotadas)
- Filosofía clásica: Aristóteles, Laozi, Zhuangzi, Frege, Russell,
Wittgenstein, Hegel, Husserl, Whitehead, Kripke, Searle, Parfit, Ladyman,
Quine, Tarski
- IA y representación del conocimiento: Minsky, Collins/Quillian,
Brachman/Schmolze, Gruber, Lenat, Pearl, Guarino, Berners-Lee
- Ingeniería de software: Nygard, Brown, Hohpe/Woolf
- Perspectivas adicionales: Zhou Dunyi, Heidegger, Heráclito, Bateson,
Winograd/Flores
✻ Baked for 3m 4s
※ recap: Generating a philosophical PDF on ontology, Taoism, DAGs and their software parallels. The expanded document with new sections and 29 annotated references compiled successfully to 20 pages at assets/presentation/ontologia-filosofia-software.pdf. (disable recaps in /config)
❯ ¿ En todo esto tiene algún sentido la física cuántica y la computación
cuántica ?
⏺ Sí, pero hay que separar dónde la conexión es genuina de dónde es metáfora
seductora.
---
Donde la física cuántica es genuinamente relevante — ontología filosófica
El golpe más profundo: Aristóteles estaba equivocado en el nivel fundamental.
La ontología aristotélica asume que las sustancias tienen propiedades
definidas. La mecánica cuántica demuestra que, en el nivel fundamental, las
propiedades no son definidas hasta que se miden. Un electrón no tiene posición
— la posición emerge del acto de medición. Esto no es ignorancia del
observador sobre una propiedad preexistente — el teorema de Kochen-Specker
(1967) lo prueba formalmente: es imposible asignar valores definidos a todos
los observables cuánticos simultáneamente, incluso antes de la medición. La
indeterminación es ontológica, no epistémica.
El suelo sobre el que se construyeron 2.300 años de ontología occidental se
mueve.
---
Las tres conexiones genuinas
1. Complementariedad de Bohr ↔ Yin-Yang y la dualidad Ontología/Reflection
Niels Bohr (1885-1962) formuló el principio de complementariedad: onda y
partícula son dos descripciones mutuamente excluyentes pero igualmente
necesarias del mismo fenómeno. No puedes observar ambas simultáneamente — el
aparato de medición determina qué aspecto revelas.
Esto es estructuralmente idéntico al yin-yang. Bohr lo sabía — adoptó el
símbolo taoísta como parte de su escudo de armas cuando fue ennoblecido en
1947. La inscripción: Contraria sunt complementa — los contrarios son
complementarios.
La dualidad ontología/reflection del modelo operacional tiene la misma
estructura: no puedes capturar el ser y el devenir en una única
representación. El "aparato de medición" — qué preguntas haces al sistema —
determina qué aspecto revelas. La capa que uses (core.ncl o los modos de
reflection) determina qué aspecto del proyecto ves. Ninguna es más verdadera —
son complementarias.
2. Contextualidad cuántica ↔ Ontología perspectival
El teorema de Kochen-Specker (1967) prueba algo más radical que la
incertidumbre de Heisenberg: el resultado de medir un observable cuántico
depende de qué otros observables se miden simultáneamente. Las propiedades son
contextuales — no existen independientemente del contexto de medición.
Esto conecta con tres tradiciones de nuestra discusión:
- Zhuangzi: toda distinción ontológica es perspectival — la rana del pozo no
puede imaginar el mar
- Wittgenstein tardío: el significado depende del juego de lenguaje — del
contexto de uso
- Gruber: una ontología es una conceptualización, no una captura de la
realidad
La contextualidad cuántica convierte esto de posición filosófica a hecho
físico. Las propiedades no están en las cosas — emergen de la interacción
entre la cosa y el sistema de observación.
Para la ontología operacional: el "estado" de un proyecto es siempre relativo
al actor y al contexto de consulta. Un agente IA y un desarrollador humano
consultando el mismo core.ncl están haciendo mediciones con aparatos
distintos. Lo que ven es complementario, no idéntico.
3. El problema del observador ↔ El trasfondo que no puede formalizarse
En mecánica cuántica, la medición colapsa la función de onda — el observador
es parte del sistema. No hay view from nowhere (Thomas Nagel, 1986). Todo
conocimiento es conocimiento desde una posición.
Esto es exactamente lo que Heidegger llamó el trasfondo pre-temático — la
condición de posibilidad de cualquier formalización que ella misma no puede
ser formalizada. Y lo que el Tao Te Ching afirma en su primer verso: el Tao
que puede nombrarse no es el Tao eterno.
La mecánica cuántica convierte esto en física: el acto de observar constituye
lo observado. La ontología operacional que crees que describes objetivamente
está siendo constituida por el acto de escribirla.
---
La interpretación más relevante — Mecánica Cuántica Relacional (Rovelli, 1996)
Carlo Rovelli propuso en 1996 una interpretación de la mecánica cuántica
directamente pertinente a esta conversación: no existen estados absolutos —
solo estados relativos a otros sistemas. El estado de una partícula no es una
propiedad intrínseca — es una propiedad relacional respecto al sistema con el
que interactúa.
Esto es la ontología más radical posible: no hay propiedades, solo relaciones.
Ladyman y Ross (que ya aparecen en nuestra tabla) llegaron al mismo lugar
desde la filosofía de la física: realismo estructural — las estructuras
relacionales son lo real, las entidades son secundarias.
Para el modelo operacional: el "estado" de un proyecto (current_state en
state.ncl) no es una propiedad intrínseca del proyecto — es una propiedad
relacional respecto al actor que consulta, los objetivos que se persiguen, el
momento en el ciclo de vida. Dos actores con marcos de referencia distintos
pueden tener mediciones del estado coherentes pero distintas. No hay
contradicción — hay contextualidad relacional.
---
La computación cuántica — honestidad sobre sus límites aquí
La computación cuántica tiene relevancia limitada para la ontología
operacional en software hoy. Las razones son prácticas, no filosóficas:
┌────────────────┬────────────────────────────────────────────────────────┐
│ Aspecto │ Situación real │
├────────────────┼────────────────────────────────────────────────────────┤
│ Tamaño de los │ Los grafos de ontología de proyecto son pequeños │
│ grafos │ (decenas a centenas de nodos). La ventaja cuántica │
│ │ aparece a escala masiva. │
├────────────────┼────────────────────────────────────────────────────────┤
│ Algoritmos │ Grover (búsqueda no estructurada: O(√N)) y Shor │
│ relevantes │ (factorización) no mapean a consultas típicas sobre │
│ │ ontologías de proyecto. │
├────────────────┼────────────────────────────────────────────────────────┤
│ │ Los sistemas cuánticos son extremadamente frágiles — │
│ Decoherencia │ cualquier interacción con el entorno colapsa la │
│ │ superposición. El uso práctico requiere aislamiento │
│ │ que contradice la operación continua. │
├────────────────┼────────────────────────────────────────────────────────┤
│ Estado del │ Los computadores cuánticos actuales (2026) tienen │
│ arte │ decenas a cientos de qubits con alta tasa de error. │
│ │ Los problemas de ontología no son el caso de uso. │
└────────────────┴────────────────────────────────────────────────────────┘
Donde sí hay investigación activa y filosóficamente interesante:
Redes semánticas cuánticas — representar relaciones entre conceptos con
amplitudes de probabilidad en lugar de valores booleanos. Un concepto no es o
no es subclase de otro — lo es con cierta amplitud. Esto captura algo que las
ontologías OWL pierden: el conocimiento humano no es binario, es gradual y
contextual.
Bayesian networks cuánticas — Pearl formalizó la causalidad como DAG con
probabilidades condicionales clásicas. La extensión cuántica reemplaza las
probabilidades por amplitudes complejas, permitiendo modelar correlaciones
causales sin explicación clásica. Relevante para sistemas donde las
dependencias entre componentes exhiben comportamiento emergente no reducible a
sus partes.
Quantum knowledge graphs — investigación emergente (2020-presente) sobre
representar grafos de conocimiento en espacios de Hilbert. La similitud entre
dos conceptos se convierte en producto interno de vectores de estado. Esto es
la base matemática de los embeddings en modelos de lenguaje — los LLMs ya
están haciendo algo cuántico-adjacent sin saberlo.
---
La conexión más profunda — y menos obvia
Los Large Language Models operan en espacios vectoriales de alta dimensión
donde el significado es relacional y contextual. Esto no es metáfora cuántica
— es la misma matemática de espacios de Hilbert que usa la mecánica cuántica,
aplicada a representación semántica.
La ontología operacional (core.ncl, invariantes, tensiones) es, en este
contexto, una base en ese espacio — un conjunto de vectores ortogonales que
fijan el marco de referencia en el que el agente opera. Sin esa base, el
agente opera en un espacio de alta dimensión sin orientación — genera texto
coherente localmente pero sin anclaje semántico al proyecto concreto.
Inyectar el contexto ontológico al inicio de una sesión de agente es, en la
geometría de estos modelos, fijar el marco de referencia antes de que el
agente empiece a computar. Es, literalmente, una operación de cambio de base
en el espacio de representación.
---
Síntesis honesta
Dominio: Física cuántica → ontología filosófica
Relevancia: Alta y genuina
Por qué: Kochen-Specker destruye el Aristóteles ingenuo; complementariedad
formaliza el yin-yang; Rovelli formaliza la ontología relacional
────────────────────────────────────────
Dominio: Física cuántica → ontología operacional en software
Relevancia: Media, principalmente filosófica
Por qué: Contextualidad y relacionalidad son principios de diseño, no solo
metáforas
────────────────────────────────────────
Dominio: Computación cuántica → ontología operacional hoy
Relevancia: Baja, prácticamente nula
Por qué: Escala incorrecta, algoritmos que no mapean, hardware inmaduro
────────────────────────────────────────
Dominio: Matemáticas cuánticas → LLMs y agentes
Relevancia: Alta y directa
Por qué: Espacios de Hilbert, productos internos, bases ortogonales — es la
misma geometría
La física cuántica importa aquí no porque vayamos a correr ontologías en
computadores cuánticos — sino porque demuestra que las asunciones ontológicas
sobre las que construimos el pensamiento clásico (propiedades definidas,
estados absolutos, observador separado del sistema) son físicamente
incorrectas en el nivel fundamental.
Eso no invalida la ontología operacional — la valida en otro sentido: si ni la
realidad física tiene propiedades absolutas independientes del contexto de
observación, menos las tendrá un proyecto de software. La ontología
operacional es contextual, relacional y perspectival por diseño correcto, no
por limitación.
✻ Sautéed for 1m 48s
❯ por qué entonces es relevante la ontología operaciona y la reflection con los
DAG en desarrollo de software e infraestructuras digitales
⏺ La respuesta honesta requiere separar tres planos: qué problema existe, qué
aporta cada capa, y por qué ahora más que nunca.
---
El problema real — no es técnico, es epistémico
El software moderno tiene un déficit estructural que no se resuelve con
mejores herramientas:
La complejidad ha superado la capacidad de comprensión individual. Un sistema
de microservicios en Kubernetes con Terraform, pipelines de CI/CD, múltiples
equipos y agentes de IA trabajando en paralelo no cabe en la cabeza de ninguna
persona. Nunca cabió — pero durante años pudimos fingir que sí.
Lo que resulta de eso no es ignorancia puntual — es deriva epistémica
sistémica:
Lo que el sistema hace ≠ Lo que el equipo cree que hace
Lo que la infra tiene desplegado ≠ Lo que Terraform declara
Lo que el ADR decidió ≠ Lo que el código implementa
Lo que el agente asume ≠ Lo que el contexto real requiere
Cada una de esas brechas es silenciosa, acumulativa, y solo se descubre cuando
falla en producción.
---
Por qué la ontología operacional — específicamente
Una ontología operacional no documenta el sistema. Es el modelo del sistema
que el propio sistema puede leer.
La diferencia no es de grado — es de naturaleza:
┌──────────────────────────┬──────────────────────────────────────────────┐
│ Documentación │ Ontología operacional │
│ tradicional │ │
├──────────────────────────┼──────────────────────────────────────────────┤
│ Prosa — no consultable │ Grafo tipado — consultable con queries │
├──────────────────────────┼──────────────────────────────────────────────┤
│ Estática — se │ Verificada en cada commit (typecheck) │
│ desactualiza │ │
├──────────────────────────┼──────────────────────────────────────────────┤
│ Describe lo que hubo │ Formaliza lo que ES y lo que debe ser │
├──────────────────────────┼──────────────────────────────────────────────┤
│ Solo legible por humanos │ Legible por humanos, agentes, CI │
├──────────────────────────┼──────────────────────────────────────────────┤
│ Captura el qué │ Captura el qué, el por qué, el no puede │
│ │ cambiar │
└──────────────────────────┴──────────────────────────────────────────────┘
Lo que la ontología operacional hace en software e infra que nada más hace:
① Formaliza lo que no puede romperse. Los invariantes no son comentarios — son
constraints tipadas que el sistema verifica. Cuando alguien o algo intenta
violarlos, falla antes del runtime, no después.
② Captura las tensiones activas como ciudadanos de primera clase. "Coste vs.
disponibilidad", "velocidad de despliegue vs. estabilidad" — estos trade-offs
viven en la ontología, no en la cabeza de quien lleva más tiempo en el equipo.
Cuando ese alguien se va, los trade-offs permanecen.
③ Separa el ser del devenir. Lo que el proyecto es (core.ncl) tiene ritmo de
cambio diferente a lo que el proyecto opera (reflection). Fusionarlos — como
hace cualquier README o wiki — produce documentación que siempre está
desactualizada en la mitad más importante.
④ Da al agente de IA el contexto que no puede inferir del código. Un agente
puede leer todo el código de un sistema y no saber que hay un acuerdo con el
equipo de seguridad que impide escalar horizontalmente cierto servicio, o que
la decisión de usar gRPC interno fue consecuencia de una tensión específica
con latencia que no está en ningún archivo. La ontología operacional hace eso
explícito y machine-readable.
---
Por qué los DAGs — específicamente
Los DAGs no son una elección estética. Son la única estructura que garantiza
cuatro propiedades simultáneamente:
① Análisis de impacto decidible. Antes de cambiar un invariante, una práctica,
o un nodo de infra — recorre el DAG y sabes exactamente qué se ve afectado.
En prosa o grafo cíclico esto no es computable de forma general.
Concreto: en Terraform, el grafo de recursos es un DAG. terraform plan recorre
ese grafo para determinar qué debe crearse, modificarse o destruirse en qué
orden. Eso funciona porque el grafo es acíclico. Si hubiera ciclos, el plan
sería indecidible.
② Orden topológico para ejecución fiable. Cualquier operación con dependencias
— despliegue, migración, rollback, onboarding — tiene un orden correcto. El
DAG lo da sin necesidad de un coordinador central. Este es el principio detrás
de Make (1976), Bazel, Gradle, y cualquier build system no trivial.
③ Justificación sin circularidad. Si el invariante A existe porque la práctica
B lo requiere, y la práctica B existe porque el invariante A lo define —
tienes dogma, no arquitectura. El DAG hace esa circularidad visible e
inaceptable. Fuerza que cada nodo tenga justificación bien fundada.
④ Rollback determinista. El inverso topológico del DAG es siempre computable.
Cualquier operación es reversible en orden definido. Sin DAG, el rollback es
un proceso manual, frágil y que depende de que alguien recuerde el orden
correcto.
---
Por qué la reflection — específicamente
La ontología captura el ser. Pero los sistemas de software no solo son —
operan. La reflection es la capa que hace la ontología ejecutable:
Modos como DAGs operacionales. Un procedimiento sin DAG es una lista de pasos
que alguien puede ejecutar en cualquier orden, saltar, o ignorar. Un modo como
DAG tiene dependencias explícitas — el sistema puede verificar que se ejecutó
correctamente antes de avanzar. Esto es la diferencia entre un runbook y una
especificación ejecutable.
ADRs con constraints tipadas. Una decisión sin constraints es prosa. Una
decisión con constraints tipadas es un contrato que el CI puede verificar en
cada commit. La pregunta "¿estamos violando alguna decisión arquitectural?"
pasa de ser reflexión manual a ser una comprobación automática.
Historial como append-only. La reflection registra qué operaciones ocurrieron,
quién las ejecutó, cuándo, con qué contexto. Eso no es logging — es la
historia del devenir del proyecto, trazable y consultable. Cuando algo falla a
las 2am, la pregunta "¿qué cambió y quién lo autorizó?" tiene respuesta en el
grafo de history, no en Slack.
Detección de drift. La diferencia entre el estado sellado (lo que declaraste
que era verdad en t₀) y el estado actual (lo que realmente hay desplegado) es
medible si y solo si formalizaste el estado sellado. Sin eso, la pregunta "¿ha
derivado esto?" no tiene respuesta objetiva.
---
Por qué ahora — la convergencia de tres presiones
Estos conceptos no son nuevos. Lo nuevo es que tres presiones convergen
simultáneamente y hacen la ausencia del modelo operacional costosa de una
forma que antes era tolerable:
Presión 1: Los sistemas son demasiado complejos para modelos mentales.
Un monolito de 2005 podía vivir en la cabeza de dos personas. Un sistema
cloud-native de 2026 con 40 microservicios, múltiples regiones, pipelines de
despliegue automatizados y SLOs por servicio no cabe en ninguna cabeza. El
modelo mental individual ha dejado de ser suficiente como mecanismo de
coordinación.
Presión 2: Los agentes de IA tienen acceso de escritura.
Hasta hace muy poco, una herramienta de IA que generaba código incorrecto
producía texto que un humano revisaba antes de ejecutar. Hoy los agentes
pueden abrir PRs, modificar configuración, ejecutar Terraform, y desplegar. El
ciclo humano-en-el-loop se está comprimiendo. Un agente que opera sin
contexto ontológico en ese entorno no es un asistente — es un actor autónomo
con comprensión incompleta del sistema que modifica.
La ontología operacional es el mecanismo por el cual el agente opera sobre lo
que tú ya clarificaste en lugar de inventar el contexto que le falta.
Presión 3: Los equipos son multi-actor y distribuidos.
Humanos en zonas horarias distintas, agentes de IA con distintos contextos de
sesión, pipelines de CI ejecutando en paralelo — todos escribiendo sobre el
mismo sistema sin un coordinador central. Sin un protocolo compartido y
machine-readable para "qué puede cambiarse, bajo qué condiciones, con qué
justificación", la coordinación depende de que todo el mundo lea el mismo
Confluence actualizado. Eso nunca funcionó.
---
El punto de convergencia
Lo que la ontología operacional + reflection + DAGs aportan en conjunto es
algo que ninguna de sus partes aporta sola:
Un sistema que sabe lo que es, puede verificar que sigue siendo lo que dice
ser, y puede comunicarlo a cualquier actor — humano, agente, o CI — de forma
estructurada y sin ambigüedad.
Eso no es documentación. Es un modelo operacional vivo.
La ausencia de ese modelo no es un problema de disciplina del equipo — es una
propiedad emergente de sistemas complejos operados sin representación
explícita. El drift, la amnesia de decisiones, la ilusión de control en
infraestructura declarativa — no son fallos de las personas. Son consecuencias
inevitables de operar un sistema complejo sin un modelo del propio sistema.
La ontología operacional es la respuesta a la pregunta: ¿qué estructura mínima
necesita un sistema para conocerse a sí mismo de forma que ese conocimiento
pueda ser usado, verificado y compartido?
✻ Cooked for 1m 27s
※ recap: Explorando la genealogía filosófica y científica de la ontología operacional en software. El siguiente paso es generar el PDF actualizado con las secciones de Taoísmo, DAGs y referencias.
❯ quiero incluir las últimas cuestione y respuestas en los docuemntos con las
referecias que puedes completar al final
⏺ Voy a leer el final del documento para hacer la inserción correcta.
Read 1 file (ctrl+o to expand)
⏺ Ahora hago la edición — inserto las dos nuevas secciones antes de referencias
y amplío la bibliografía al final.
⏺ Update(ontologia-filosofia-software.typ)
⎿  Added 213 lines, removed 1 line
566
567 #pagebreak()
568
569 -// ─── 6. REFERENCIAS ────────────────────────────────────────
-─────────────────
569 +// ─── 6. FÍSICA CUÁNTICA ────────────────────────────────────
+─────────────────
570
571 += Física cuántica, computación cuántica y ontología operaciona
+l
572 +
573 +== El golpe más profundo — Aristóteles estaba equivocado en el
+ nivel fundamental
574 +
575 +La ontología aristotélica asume que las sustancias tienen prop
+iedades definidas. La mecánica cuántica demuestra que, en el n
+ivel fundamental, las propiedades no son definidas hasta que s
+e miden. Un electrón no *tiene* posición — la posición emerge
+del acto de medición.
576 +
577 +Esto no es ignorancia del observador sobre una propiedad preex
+istente. El *teorema de Kochen-Specker* (1967) lo prueba forma
+lmente: es imposible asignar valores definidos a todos los obs
+ervables cuánticos simultáneamente, incluso antes de la medici
+ón. La indeterminación es *ontológica*, no epistémica. El suel
+o sobre el que se construyeron 2.300 años de ontología occiden
+tal se mueve.
578 +
579 +== Las tres conexiones genuinas
580 +
581 +=== Complementariedad de Bohr ↔ Yin-Yang y la dualidad Ontolog
+ía/Reflection
582 +
583 +Niels Bohr (1885-1962) formuló el *principio de complementarie
+dad*: onda y partícula son dos descripciones mutuamente excluy
+entes pero igualmente necesarias del mismo fenómeno. No puedes
+ observar ambas simultáneamente — el aparato de medición deter
+mina qué aspecto revelas.
584 +
585 +Bohr lo conectó explícitamente con el Taoísmo: cuando fue enno
+blecido en 1947 adoptó el símbolo yin-yang como parte de su es
+cudo de armas con la inscripción _Contraria sunt complementa_
+— los contrarios son complementarios.
586 +
587 +La dualidad ontología/reflection del modelo operacional tiene
+la misma estructura. El "aparato de medición" — qué preguntas
+haces al sistema — determina qué aspecto revelas. La capa que
+uses (core.ncl o los modos de reflection) determina qué ves. N
+inguna es más verdadera — son complementarias.
588 +
589 +=== Contextualidad cuántica ↔ Ontología perspectival
590 +
591 +El teorema de Kochen-Specker prueba algo más radical que la in
+certidumbre de Heisenberg: el resultado de medir un observable
+ cuántico depende de *qué otros observables se miden simultáne
+amente*. Las propiedades son *contextuales* — no existen indep
+endientemente del contexto de medición.
592 +
593 +Esto convierte en hecho físico lo que tres tradiciones de esta
+ discusión habían sostenido filosóficamente:
594 +
595 +- *Zhuangzi*: toda distinción ontológica es perspectival
596 +- *Wittgenstein tardío*: el significado depende del juego de l
+enguaje
597 +- *Gruber*: una ontología es una especificación de una concept
+ualización, no una captura de la realidad
598 +
599 +Para la ontología operacional: el "estado" de un proyecto es s
+iempre relativo al actor y al contexto de consulta. Un agente
+de IA y un desarrollador humano consultando el mismo core.ncl
+están haciendo mediciones con aparatos distintos. Lo que ven e
+s complementario, no idéntico.
600 +
601 +=== El problema del observador ↔ El trasfondo que no puede for
+malizarse
602 +
603 +En mecánica cuántica, la medición colapsa la función de onda —
+ el observador es parte del sistema. No hay _view from nowhere
+_ (Nagel, 1986). Todo conocimiento es conocimiento *desde* una
+ posición.
604 +
605 +Esto es exactamente lo que Heidegger llamó el trasfondo pre-te
+mático — la condición de posibilidad de cualquier formalizació
+n que ella misma no puede ser formalizada. Y lo que el _Tao Te
+ Ching_ afirma: el Tao que puede nombrarse no es el Tao eterno
+.
606 +
607 +La ontología operacional que crees que describes objetivamente
+ está siendo constituida por el acto de escribirla. Esto no es
+ un defecto del modelo — es un límite estructural de toda repr
+esentación.
608 +
609 +== La interpretación más relevante — Mecánica Cuántica Relacio
+nal
610 +
611 +Carlo Rovelli propuso en 1996 (_Relational Quantum Mechanics_,
+ International Journal of Theoretical Physics) que no existen
+estados absolutos — solo estados *relativos a otros sistemas*.
+ El estado de una partícula no es una propiedad intrínseca — e
+s una propiedad relacional respecto al sistema con el que inte
+ractúa.
612 +
613 +Esto es la ontología más radical posible y conecta directament
+e con Ladyman y Ross (realismo estructural): no hay propiedade
+s, solo relaciones. Lo real son las estructuras relacionales,
+no las entidades.
614 +
615 +Para el modelo operacional: el "estado" de un proyecto (curren
+t_state en state.ncl) no es una propiedad intrínseca del proye
+cto — es relacional respecto al actor que consulta, los objeti
+vos perseguidos, el momento del ciclo de vida. Dos actores con
+ marcos de referencia distintos pueden tener mediciones del es
+tado coherentes pero distintas. No hay contradicción — hay con
+textualidad relacional.
616 +
617 +== La computación cuántica — honestidad sobre sus límites
618 +
619 +#table(
620 + columns: (1.5fr, 2fr, 2fr),
621 + inset: 7pt,
622 + fill: (col, row) => if row == 0 { rgb("#c04000") } else if c
+alc.odd(row) { rgb("#fdf6f0") } else { white },
623 + table.header(
624 + text(fill: white, weight: "bold")[Aspecto],
625 + text(fill: white, weight: "bold")[Situación real (2026)],
626 + text(fill: white, weight: "bold")[Relevancia para ontologí
+a operacional],
627 + ),
628 + [Tamaño de grafos],
629 + [La ventaja cuántica aparece a escala masiva],
630 + [Los grafos de ontología de proyecto son pequeños — sin vent
+aja cuántica],
631 +
632 + [Algoritmos relevantes],
633 + [Grover: O(√N) búsqueda. Shor: factorización polinómica],
634 + [No mapean a consultas típicas sobre ontologías de proyecto]
+,
635 +
636 + [Decoherencia],
637 + [Cualquier interacción colapsa la superposición],
638 + [El uso práctico requiere aislamiento que contradice operaci
+ón continua],
639 +
640 + [Redes semánticas cuánticas],
641 + [Investigación activa — relaciones con amplitudes de probabi
+lidad],
642 + [Captura gradualidad que OWL binario pierde — relevante a me
+diano plazo],
643 +
644 + [Bayesian networks cuánticas],
645 + [Extensión de Pearl con amplitudes complejas],
646 + [Modelar dependencias con comportamiento emergente no reduci
+ble],
647 +
648 + [LLMs y espacios de Hilbert],
649 + [Los embeddings son productos internos en espacio vectorial
+de alta dimensión],
650 + [Directamente relevante: la misma matemática cuántica, aplic
+ada a semántica],
651 +)
652 +
653 +== La conexión no obvia — LLMs como geometría cuántica aplicad
+a
654 +
655 +Los Large Language Models operan en espacios vectoriales de al
+ta dimensión donde el significado es relacional y contextual.
+No es metáfora cuántica — es la misma matemática de espacios d
+e Hilbert que usa la mecánica cuántica, aplicada a representac
+ión semántica.
656 +
657 +La ontología operacional (core.ncl, invariantes, tensiones) es
+, en este contexto, una *base* en ese espacio — un conjunto de
+ vectores que fijan el marco de referencia en el que el agente
+ opera. Inyectar el contexto ontológico al inicio de una sesió
+n es, en la geometría de estos modelos, fijar el marco de refe
+rencia antes de que el agente empiece a computar.
658 +
659 +La física cuántica importa aquí no porque vayamos a correr ont
+ologías en computadores cuánticos — sino porque demuestra que
+las asunciones ontológicas clásicas (propiedades definidas, es
+tados absolutos, observador separado del sistema) son físicame
+nte incorrectas en el nivel fundamental. La ontología operacio
+nal es contextual, relacional y perspectival *por diseño corre
+cto*, no por limitación.
660 +
661 +#pagebreak()
662 +
663 +// ─── 7. RELEVANCIA EN SOFTWARE E INFRA ─────────────────────
+─────────────────
664 +
665 += Por qué es relevante en software e infraestructuras digitale
+s
666 +
667 +== El problema real no es técnico — es epistémico
668 +
669 +El software moderno tiene un déficit estructural que no se res
+uelve con mejores herramientas:
670 +
671 +#align(center)[
672 + #block(
673 + fill: rgb("#1a1a1a"),
674 + radius: 4pt,
675 + inset: 12pt,
676 + width: 90%,
677 + )[
678 + #set text(font: "New Computer Modern Mono", size: 9pt, fil
+l: rgb("#cccccc"))
679 + Lo que el sistema hace ≠ Lo que el equipo cree
+que hace \
680 + Lo que la infra tiene desplegado ≠ Lo que Terraform decla
+ra \
681 + Lo que el ADR decidió ≠ Lo que el código imple
+menta \
682 + Lo que el agente asume ≠ Lo que el contexto rea
+l requiere
683 + ]
684 +]
685 +
686 +Cada una de esas brechas es silenciosa, acumulativa, y solo se
+ descubre cuando falla en producción. No son fallos de las per
+sonas — son consecuencias inevitables de operar un sistema com
+plejo sin un modelo del propio sistema.
687 +
688 +== Lo que la ontología operacional hace que nada más hace
689 +
690 +#table(
691 + columns: (1.5fr, 1.5fr),
692 + inset: 7pt,
693 + fill: (col, row) => if row == 0 { rgb("#c04000") } else if c
+alc.odd(row) { rgb("#fdf6f0") } else { white },
694 + table.header(
695 + text(fill: white, weight: "bold")[Documentación tradiciona
+l],
696 + text(fill: white, weight: "bold")[Ontología operacional],
697 + ),
698 + [Prosa — no consultable],
699 + [Grafo tipado — consultable con queries estructuradas],
700 +
701 + [Estática — se desactualiza sin señal],
702 + [Verificada en cada commit mediante typecheck],
703 +
704 + [Describe lo que hubo],
705 + [Formaliza lo que ES y lo que debe ser],
706 +
707 + [Solo legible por humanos],
708 + [Legible por humanos, agentes de IA y pipelines de CI],
709 +
710 + [Captura el qué],
711 + [Captura el qué, el por qué, y lo que no puede cambiar],
712 +
713 + [Nadie la actualiza bajo presión],
714 + [El proceso la actualiza — es el path, no documentación para
+lela],
715 +)
716 +
717 +*Formaliza lo que no puede romperse.* Los invariantes no son c
+omentarios — son constraints tipadas que el sistema verifica a
+ntes del runtime, no después.
718 +
719 +*Captura las tensiones activas.* "Coste vs. disponibilidad", "
+velocidad de despliegue vs. estabilidad" viven en la ontología
+, no en la cabeza del miembro más veterano del equipo. Cuando
+ese alguien se va, los trade-offs permanecen.
720 +
721 +*Da al agente de IA el contexto que no puede inferir del códig
+o.* Un agente puede leer todo el código de un sistema y no sab
+er que hay un acuerdo que impide escalar horizontalmente ciert
+o servicio, o que la decisión de usar gRPC interno fue consecu
+encia de una tensión específica de latencia que no está en nin
+gún archivo. La ontología operacional hace eso explícito y mac
+hine-readable.
722 +
723 +== Por qué los DAGs — especificidad técnica
724 +
725 +Los DAGs no son una elección estética. Son la única estructura
+ que garantiza cuatro propiedades simultáneamente en sistemas
+operacionales:
726 +
727 +*Análisis de impacto decidible.* Antes de cambiar un invariant
+e o un nodo de infra — recorre el DAG y sabes exactamente qué
+se ve afectado. Concreto: en Terraform, el grafo de recursos e
+s un DAG. `terraform plan` recorre ese grafo para determinar q
+ué debe crearse, modificarse o destruirse en qué orden. Si hub
+iera ciclos, el plan sería indecidible.
728 +
729 +*Orden topológico para ejecución fiable.* Cualquier operación
+con dependencias — despliegue, migración, rollback, onboarding
+ — tiene un orden correcto. El DAG lo da sin necesidad de un c
+oordinador central. Este es el principio detrás de Make (1976)
+, Bazel, Gradle, y cualquier build system no trivial.
730 +
731 +*Justificación sin circularidad.* Si el invariante A existe po
+rque la práctica B lo requiere, y la práctica B existe porque
+el invariante A lo define — tienes dogma, no arquitectura. El
+DAG hace esa circularidad visible e inaceptable.
732 +
733 +*Rollback determinista.* El inverso topológico del DAG es siem
+pre computable. Sin DAG, el rollback es un proceso manual que
+depende de que alguien recuerde el orden correcto.
734 +
735 +== Por qué la reflection — la ontología sin operación es un mu
+seo
736 +
737 +La ontología captura el *ser*. Pero los sistemas de software n
+o solo son — *operan*. La reflection es la capa que hace la on
+tología ejecutable:
738 +
739 +*Modos como DAGs operacionales.* Un procedimiento sin DAG es u
+na lista de pasos que alguien puede ejecutar en cualquier orde
+n, saltar, o ignorar. Un modo como DAG tiene dependencias expl
+ícitas — el sistema puede verificar que se ejecutó correctamen
+te antes de avanzar.
740 +
741 +*ADRs con constraints tipadas.* Una decisión sin constraints e
+s prosa. Con constraints tipadas es un contrato que el CI pued
+e verificar en cada commit. La pregunta "¿estamos violando alg
+una decisión arquitectural?" pasa de ser reflexión manual a se
+r comprobación automática.
742 +
743 +*Detección de drift.* La diferencia entre el estado sellado (l
+o que declaraste que era verdad) y el estado actual (lo que re
+almente hay desplegado) es medible si y solo si formalizaste e
+l estado sellado. Sin eso, la pregunta "¿ha derivado esto?" no
+ tiene respuesta objetiva.
744 +
745 +== Las tres presiones que hacen esto urgente ahora
746 +
747 +Estos conceptos no son nuevos. Lo nuevo es que tres presiones
+convergen simultáneamente haciendo que la ausencia del modelo
+operacional sea costosa de una forma que antes era tolerable:
748 +
749 +*Presión 1: Los sistemas superan la capacidad de comprensión i
+ndividual.* Un monolito de 2005 podía vivir en la cabeza de do
+s personas. Un sistema cloud-native de 2026 con decenas de mic
+roservicios, múltiples regiones, pipelines automatizados y SLO
+s por servicio no cabe en ninguna cabeza. El modelo mental ind
+ividual ha dejado de ser suficiente como mecanismo de coordina
+ción.
750 +
751 +*Presión 2: Los agentes de IA tienen acceso de escritura.* Has
+ta hace poco, una herramienta de IA que generaba código incorr
+ecto producía texto que un humano revisaba antes de ejecutar.
+Hoy los agentes pueden abrir PRs, modificar configuración, eje
+cutar Terraform, y desplegar. El ciclo humano-en-el-loop se co
+mprime. Un agente sin contexto ontológico en ese entorno no es
+ un asistente — es un actor autónomo con comprensión incomplet
+a del sistema que modifica.
752 +
753 +*Presión 3: Los equipos son multi-actor y distribuidos.* Human
+os en zonas horarias distintas, agentes de IA con distintos co
+ntextos de sesión, pipelines de CI ejecutando en paralelo — to
+dos escribiendo sobre el mismo sistema sin coordinador central
+. Sin un protocolo compartido y machine-readable para "qué pue
+de cambiarse, bajo qué condiciones, con qué justificación", la
+ coordinación depende de que todo el mundo lea el mismo Conflu
+ence actualizado. Eso nunca funcionó.
754 +
755 +== La síntesis
756 +
757 +Lo que la ontología operacional, reflection y DAGs aportan en
+conjunto es algo que ninguna de sus partes aporta sola:
758 +
759 +#align(center)[
760 + #block(
761 + stroke: rgb("#c04000") + 1pt,
762 + radius: 4pt,
763 + inset: 14pt,
764 + width: 88%,
765 + )[
766 + #set text(size: 11pt)
767 + Un sistema que sabe lo que es, puede verificar que sigue s
+iendo \
768 + lo que dice ser, y puede comunicarlo a cualquier actor — h
+umano, \
769 + agente o CI — de forma estructurada y sin ambigüedad.
770 + ]
771 +]
772 +
773 +Eso no es documentación. Es un modelo operacional vivo.
774 +
775 +La ausencia de ese modelo no es un problema de disciplina del
+equipo. Es una propiedad emergente de sistemas complejos opera
+dos sin representación explícita. El drift, la amnesia de deci
+siones, la ilusión de control en infraestructura declarativa —
+ no son fallos de las personas. Son consecuencias inevitables.
776 +
777 +La ontología operacional es la respuesta a la pregunta: *¿qué
+estructura mínima necesita un sistema para conocerse a sí mism
+o de forma que ese conocimiento pueda ser usado, verificado y
+compartido?*
778 +
779 +#pagebreak()
780 +
781 +// ─── 8. REFERENCIAS ────────────────────────────────────────
+─────────────────
782 +
783 = Referencias y lecturas recomendadas
784
785 == Filosofía clásica y ontología
⏺ Ahora añado las referencias de física cuántica e ingeniería de software al
final de la bibliografía.
⏺ Update(ontologia-filosofia-software.typ)
⎿  Added 68 lines
892 #text(fill: rgb("#666666"), size: 9.5pt)[La diferencia que hac
e una diferencia. Epistemología sistémica que conecta Taoísmo,
cibernética y representación del conocimiento. Perspectiva po
co citada en CS pero fundamentalmente relevante.]
893
894 *Winograd, T. & Flores, F.* _Understanding Computers and Cogni
tion_. Norwood: Ablex, 1986. \
895 +#text(fill: rgb("#666666"), size: 9.5pt)[La crítica más influy
+ente a la IA simbólica desde Heidegger. Argumenta que el trasf
+ondo de comprensión no puede formalizarse — límite estructural
+ de toda ontología operacional.]
896 +
897 +== Física cuántica y fundamentos
898 +
899 +*Bohr, N.* "Can Quantum-Mechanical Description of Physical Rea
+lity Be Considered Complete?" _Physical Review_, 48, 696-702,
+1935. \
900 +#text(fill: rgb("#666666"), size: 9.5pt)[La respuesta de Bohr
+al artículo EPR de Einstein-Podolsky-Rosen. Formula el princip
+io de complementariedad como posición filosófica irrenunciable
+.]
901 +
902 +*Bohr, N.* "Discussion with Einstein on Epistemological Proble
+ms in Atomic Physics." En Schilpp (ed.), _Albert Einstein: Phi
+losopher-Scientist_. Evanston: Library of Living Philosophers,
+ 1949. \
903 +#text(fill: rgb("#666666"), size: 9.5pt)[El debate más importa
+nte de la física del siglo XX sobre interpretación cuántica. B
+ohr y Einstein representan dos ontologías irreconciliables.]
904 +
905 +*Heisenberg, W.* _Physics and Philosophy: The Revolution in Mo
+dern Science_. Nueva York: Harper & Row, 1958. \
906 +#text(fill: rgb("#666666"), size: 9.5pt)[La reflexión filosófi
+ca más accesible de uno de los fundadores. El capítulo sobre e
+l papel del lenguaje en física cuántica conecta directamente c
+on Wittgenstein.]
907 +
908 +*Schrödinger, E.* "Die gegenwärtige Situation in der Quantenme
+chanik." _Naturwissenschaften_, 23(48-49-50), 1935. \
909 +#text(fill: rgb("#666666"), size: 9.5pt)[El artículo del gato.
+ Introduce el concepto de entrelazamiento (_Verschränkung_) y
+demuestra que la superposición cuántica no puede interpretarse
+ clásicamente.]
910 +
911 +*Kochen, S. & Specker, E.P.* "The Problem of Hidden Variables
+in Quantum Mechanics." _Journal of Mathematics and Mechanics_,
+ 17(1), 59-87, 1967. \
912 +#text(fill: rgb("#666666"), size: 9.5pt)[Prueba formal de que
+es imposible asignar valores definidos a todos los observables
+ cuánticos simultáneamente. La contextualidad como hecho matem
+ático, no filosófico.]
913 +
914 +*Bell, J.S.* _Speakable and Unspeakable in Quantum Mechanics_.
+ Cambridge: Cambridge University Press, 1987. \
915 +#text(fill: rgb("#666666"), size: 9.5pt)[Colección de ensayos
+del autor del teorema de Bell (1964). El capítulo "Against mea
+surement" es una crítica filosófica fundamental al vocabulario
+ de la física cuántica.]
916 +
917 +*Aspect, A., Grangier, P. & Roger, G.* "Experimental Realizati
+on of Einstein-Podolsky-Rosen-Bohm Gedankenexperiment." _Physi
+cal Review Letters_, 49(2), 91-94, 1982. \
918 +#text(fill: rgb("#666666"), size: 9.5pt)[La confirmación exper
+imental de que las desigualdades de Bell se violan. Prueba que
+ la naturaleza es no-local — no hay variables ocultas locales.
+]
919 +
920 +*Everett, H.* "Relative State Formulation of Quantum Mechanics
+." _Reviews of Modern Physics_, 29(3), 454-462, 1957. \
921 +#text(fill: rgb("#666666"), size: 9.5pt)[La interpretación de
+muchos mundos. Relevante porque ofrece una ontología donde tod
+os los estados posibles son reales — el antípoda de la ontolog
+ía operacional que colapsa posibilidades en decisiones.]
922 +
923 +*Rovelli, C.* "Relational Quantum Mechanics." _International J
+ournal of Theoretical Physics_, 35(8), 1637-1678, 1996. \
924 +#text(fill: rgb("#666666"), size: 9.5pt)[No existen estados ab
+solutos — solo estados relativos a otros sistemas. La ontologí
+a más radical de la lista y la más relevante para entender por
+ qué el estado de un proyecto es siempre relacional.]
925 +
926 +*Rovelli, C.* _Helgoland_. Milano: Adelphi, 2020. \
927 +#text(fill: rgb("#666666"), size: 9.5pt)[La versión divulgativ
+a de la mecánica cuántica relacional. Accesible y filosóficame
+nte riguroso. El capítulo sobre relaciones y el budismo es rel
+evante para la conexión con el Taoísmo.]
928 +
929 +*Nagel, T.* _The View from Nowhere_. Oxford: Oxford University
+ Press, 1986. \
930 +#text(fill: rgb("#666666"), size: 9.5pt)[El argumento de que t
+oda objetividad requiere un punto de vista. En tensión directa
+ con el problema del observador cuántico y la ontología perspe
+ctival de Zhuangzi.]
931 +
932 +*Nielsen, M.A. & Chuang, I.L.* _Quantum Computation and Quantu
+m Information_. Cambridge: Cambridge University Press, 2000. \
933 +#text(fill: rgb("#666666"), size: 9.5pt)[El texto estándar de
+computación cuántica. Los capítulos 2-3 sobre el formalismo ma
+temático (espacios de Hilbert, operadores, entrelazamiento) so
+n la base para entender la conexión con LLMs.]
934 +
935 +*Deutsch, D.* _The Fabric of Reality_. Londres: Allen Lane, 19
+97. \
936 +#text(fill: rgb("#666666"), size: 9.5pt)[La defensa más ambici
+osa de la interpretación de muchos mundos. El capítulo sobre e
+pistemología cuántica conecta con la cuestión de qué puede con
+ocerse sobre un sistema complejo.]
937 +
938 +== Ingeniería de software e infraestructura
939 +
940 +*Evans, E.* _Domain-Driven Design: Tackling Complexity in the
+Heart of Software_. Boston: Addison-Wesley, 2003. \
941 +#text(fill: rgb("#666666"), size: 9.5pt)[El lenguaje ubicuo co
+mo ontología operacional informal. El bounded context es estru
+cturalmente equivalente a una ontología regional de Husserl ap
+licada a dominios de negocio.]
942 +
943 +*Kleppmann, M.* _Designing Data-Intensive Applications_. Sebas
+topol: O'Reilly, 2017. \
944 +#text(fill: rgb("#666666"), size: 9.5pt)[El capítulo sobre mod
+elos de datos es el más relevante: la elección de modelo (rela
+cional, documental, grafo) es una decisión ontológica — define
+ qué relaciones pueden existir.]
945 +
946 +*Morris, K.* _Infrastructure as Code_. Sebastopol: O'Reilly, 2
+016. \
947 +#text(fill: rgb("#666666"), size: 9.5pt)[Formaliza la declarat
+ividad en infraestructura. El capítulo sobre principios hace e
+xplícita la distinción entre estado deseado y estado actual —
+el núcleo del modelo state.ncl.]
948 +
949 +*Humble, J. & Farley, D.* _Continuous Delivery_. Boston: Addis
+on-Wesley, 2010. \
950 +#text(fill: rgb("#666666"), size: 9.5pt)[El pipeline de despli
+egue como DAG de verificaciones. La idea de que cada etapa del
+ pipeline es un gate que el sistema debe cruzar formalmente.]
951 +
952 +*Kim, G., Humble, J., Debois, P. & Willis, J.* _The DevOps Han
+dbook_. Portland: IT Revolution Press, 2016. \
953 +#text(fill: rgb("#666666"), size: 9.5pt)[El flujo de trabajo D
+evOps como protocolo operacional. La sección sobre feedback lo
+ops es estructuralmente equivalente al ciclo ontología/reflect
+ion.]
954 +
955 +*Dehghani, Z.* "How to Move Beyond a Monolithic Data Lake to a
+ Distributed Data Mesh." Martin Fowler Blog, 2019. \
956 +#text(fill: rgb("#666666"), size: 9.5pt)[Data mesh como ontolo
+gía operacional distribuida para datos. Cada dominio es respon
+sable de su propia ontología de datos — la aplicación más cerc
+ana al modelo ontoref en infraestructura de datos.]
957 +
958 +*Fowler, M.* "Who Needs an Architect?" _IEEE Software_, 20(5),
+ 11-13, 2003. \
959 +#text(fill: rgb("#666666"), size: 9.5pt)[Define arquitectura c
+omo "las decisiones que son difíciles de cambiar" — equivalent
+e exacto de los invariantes en ontología operacional.]
960 +
961 +*Richardson, C.* _Microservices Patterns_. Shelter Island: Man
+ning, 2018. \
962 +#text(fill: rgb("#666666"), size: 9.5pt)[El patrón Saga como D
+AG de transacciones distribuidas. Cada paso del saga tiene dep
+ends_on implícito — el DAG operacional aplicado a consistencia
+ eventual.]
963 #text(fill: rgb("#666666"), size: 9.5pt)[La crítica más influy
ente a la IA simbólica desde Heidegger. Argumenta que el trasf
ondo de comprensión no puede formalizarse — límite de toda ont
ología operacional.]
⏺ Bash(typst compile ontologia-filosofia-software.typ
ontologia-filosofia-software.pdf 2>&1)
⎿  warning: unknown font family: new computer modern mono
┌─ ontologia-filosofia-software.typ:678:20
│
… +3 lines (ctrl+o to expand)
⏺ Update(ontologia-filosofia-software.typ)
⎿  Added 1 line, removed 1 line
675 inset: 12pt,
676 width: 90%,
677 )[
678 - #set text(font: "New Computer Modern Mono", size: 9pt, fil
-l: rgb("#cccccc"))
678 + #set text(font: "Courier New", size: 9pt, fill: rgb("#cccc
+cc"))
679 Lo que el sistema hace ≠ Lo que el equipo cree
que hace \
680 Lo que la infra tiene desplegado ≠ Lo que Terraform decla
ra \
681 Lo que el ADR decidió ≠ Lo que el código imple
menta \
⏺ Bash(typst compile ontologia-filosofia-software.typ
ontologia-filosofia-software.pdf 2>&1 && echo "OK" && ls -lh
ontologia-filosofia-software.pdf && echo "pages: $(p…)
⎿  OK
-rw-r--r--@ 1 jesusperezlorenzo admin 440K Apr 24 23:47 ontologia-f
ilosofia-software.pdf
pages: 28
⏺ PDF actualizado — 28 páginas, 440K.
Lo que se añadió:
Sección 6 — Física cuántica y ontología operacional
- El teorema de Kochen-Specker como prueba formal de que Aristóteles falla en
el nivel fundamental
- Tres conexiones genuinas: complementariedad de Bohr ↔ yin-yang/dualidad
ontología-reflection; contextualidad cuántica ↔ perspectivismo (Zhuangzi,
Wittgenstein, Gruber); problema del observador ↔ trasfondo pre-temático
- Mecánica Cuántica Relacional de Rovelli — estados sin propiedades absolutas,
solo relacionales
- Tabla honesta sobre computación cuántica: dónde aplica y dónde no
- La conexión LLMs/espacios de Hilbert — la misma matemática cuántica aplicada
a semántica
Sección 7 — Relevancia en software e infraestructuras
- Las cuatro brechas epistémicas sistémicas (sistema vs. creencia del equipo,
infra vs. Terraform, ADR vs. código, agente vs. contexto real)
- Tabla documentación tradicional vs. ontología operacional
- Por qué los DAGs técnicamente: impacto decidible, orden topológico,
justificación sin circularidad, rollback determinista
- Por qué la reflection: modos ejecutables, ADR constraints en CI, drift
detection
- Las tres presiones convergentes: complejidad supera comprensión individual,
agentes con acceso de escritura, equipos multi-actor distribuidos
Referencias ampliadas — 14 nuevas entradas:
- Física cuántica: Bohr (×2), Heisenberg, Schrödinger, Kochen-Specker, Bell,
Aspect, Everett, Rovelli (×2), Nagel, Nielsen/Chuang, Deutsch
- Ingeniería: Evans (DDD), Kleppmann, Morris (IaC), Humble/Farley, Kim et al.
(DevOps), Dehghani (data mesh), Fowler, Richardson
✻ Worked for 3m 43s
Reference in a new issue View git blame Copy permalink