82a358f18d
ontoref-derive: #[onto_mcp_tool] attribute macro registers MCP tool unit-structs in
the catalog at link time via inventory::submit!; annotated item is emitted unchanged,
ToolBase/AsyncTool impls stay on the struct. All 34 tools migrated from manual wiring
(net +5: ontoref_list_projects, ontoref_search, ontoref_describe,
ontoref_list_ontology_extensions, ontoref_get_ontology_extension).
validate modes (ADR-018): reads level_hierarchy from workflow.ncl and checks every
.ncl mode for level declared, strategy declared, delegate chain coherent, compose
extends valid. mode resolve <id> shows which hierarchy level handles a mode and why.
--self-test generates synthetic fixtures in a temp dir for CI smoke-testing.
validate run-cargo: two-step Cargo.toml resolution — workspace layout first
(crates/<check.crate>/Cargo.toml), single-crate fallback by package name or repo
basename. Lets the same ADR constraint shape apply to workspace and single-crate repos.
ontology/schemas/manifest.ncl: registry_topology_type contract — multi-registry
coordination, push targets, participant scopes, per-namespace capability.
reflection/requirements/base.ncl: oras ≥1.2.0, cosign ≥2.0.0, sops ≥3.9.0, age
≥1.1.0, restic declared as Hard/Soft requirements with version_min, check_cmd, and
install_hint (ADR-017 toolchain surface).
ADR-019: per-file recipient routing for tenant isolation without multi-vault. Schema
additions: sops.recipient_groups + sops.recipient_rules in ontoref-project.ncl.
secrets-bootstrap generates .sops.yaml from project.ncl in declarative mode. Three
new secrets-audit checks: recipient-routing-coherent, recipient-routing-coverage,
no-multi-vault. Adoption templates: single-team/, multi-tenant/, agent-first/.
Integration templates: domain-producer/, mode-producer/, mode-consumer/.
UI: project_picker surfaces registry badge (⟳ participant) and vault badge
(⛁ vault_id · N, green=declarative / amber=legacy) per project card. Expanded panel
adds collapsible Registry section with namespace, endpoint, and push/pull capability.
manage.html gains Runtime Services card — MCP and GraphQL toggleable without restart
via HTMX POST /ui/manage/services/{service}/toggle.
describe.nu: capabilities JSON includes registry_topology and vault_state per project.
sync.nu: drift check extended to detect //! absence on newly registered crates.
qa.ncl: six entries — credential-vault-best-practice (layered data-flow diagram),
credential-vault-templates (paths A/B/C), credential-vault-troubleshooting (15 named
errors), integration-what-and-why (ADR-042 OCI federation), integration-how-to-implement,
integration-troubleshooting.
on+re: core.ncl + manifest.ncl updated to reflect OCI, MCP, and mode-hierarchy nodes.
Deleted stale presentation assets (2026-02 slides + voice notes).
4.8 KiB
No pude acceder directamente al artículo de Sainath Palla en AI in Plain English (la página bloquea el acceso automatizado), pero pude reconstruir su contenido a partir de las extensas citas textuales que el artículo anterior de Axius-SDC reprodujo, además de información complementaria del autor sobre AI-FDE y la ontología de Palantir.
Resumen: "Palantir AI FDE: cuando la ontología se convierte en motor de estrategia"
Autor: Sainath Palla (consultor senior de Palantir Foundry, fundador de Analyticorex). Publicado el 25 de marzo de 2026.
Tesis central
Palla argumenta que el AI-FDE de Palantir (la versión asistida por IA del clásico Forward Deployed Engineer) representa un cambio cualitativo, no incremental, en cómo se construyen los sistemas empresariales. Lo decisivo no es que la IA escriba código más rápido, sino que opera sobre la ontología: el modelo de datos vivo, los workflows existentes y el contexto operacional de la empresa. El AI-FDE traduce peticiones en lenguaje natural a operaciones de Foundry, encargándose de tareas como crear pipelines de transformación de datos, gestión de repositorios y construcción/mantenimiento de la ontología.
El argumento clave
"AI-FDE no opera sobre código aislado. Trabaja sobre la ontología, el modelo de datos existente y los workflows que ya representan al negocio. Ese contexto compartido es lo que le permite generar algo significativo. Sin él, solo obtienes andamiaje más rápido."
Esa frase final —sin la ontología solo obtienes andamiaje más rápido— es la idea que vertebra el ensayo. Para Palla, los enfoques de IA centrados en el modelo (más parámetros, más velocidad) están atacando el problema equivocado: el cuello de botella empresarial no es generar código, sino dotar a la IA de un sustrato semántico sobre el cual razonar.
El cambio en el rol del practicante
Palla describe un desplazamiento del trabajo humano:
"Menos esfuerzo va a escribir transformaciones, conectar datasets y unir workflows básicos, y más a decidir qué debe construirse, revisar cómo está estructurado y dar forma a cómo se comporta el sistema una vez en marcha."
El cuello de botella se mueve de la implementación al juicio. El practicante deja de ser un ejecutor para convertirse en arquitecto y revisor.
El gobierno mediante branching
Palla destaca un aspecto que evita el caos: cuando el AI-FDE realiza cambios, siempre crea una "Branch Proposal" y la presenta para revisión humana. Los humanos quedan liberados de la tarea tediosa de "conectar datos" y pasan al rol más avanzado de revisar y aprobar las ontologías construidas y las acciones propuestas por la IA para garantizar que se "alinean con la intención del negocio". Es, en esencia, Git para operaciones empresariales: cada cambio propuesto por la IA pasa por un pull request antes de tocar la realidad.
La metáfora del ferrocarril
Aquí Palla introduce su advertencia, que el artículo de Axius-SDC retomó críticamente:
"Un cambio en un lugar empieza a influir en otros. Nada está realmente aislado. Los cambios no se quedan locales. Se propagan por todo el sistema."
A medida que las vías se tienden más rápido, el reto deja de ser construir una ruta aislada y pasa a ser cómo se cruzan, cómo se comparte la capacidad y cómo los cambios en una parte de la red afectan a todo lo demás. La velocidad de construcción aumenta la complejidad de las intersecciones.
Conclusión del autor
"Los practicantes que piensan en términos de sistemas, no solo de implementaciones, se vuelven más importantes. A medida que la capacidad aumenta, la complejidad no desaparece. Se desplaza. Y alguien tiene que darle forma."
Para Palla, el AI-FDE no elimina al ingeniero: lo eleva. La IA escala la construcción, pero el diseño sistémico, las decisiones de gobernanza y la coherencia entre dominios siguen siendo trabajo humano —y se vuelven más críticos, no menos.
Diferencia esencial entre los dos artículos
| Palla (este artículo) | Axius-SDC (artículo anterior) | |
|---|---|---|
| Postura | Celebratoria: la ontología como "motor de estrategia" valida el enfoque de Palantir | Crítica: la ontología centralizada genera dependencia del proveedor |
| Foco | El cambio del rol del practicante hacia el juicio sistémico | Quién es el dueño de ese juicio (los FDEs de Palantir vs. los tuyos) |
| Metáfora | Red ferroviaria que crece y exige nueva disciplina | Estándar de ancho de vía distribuido en cada segmento |
Axius-SDC tomó las observaciones de Palla como punto de partida —admitiendo que tiene razón en el diagnóstico— para luego argumentar que la solución debería ser una gobernanza distribuida y de código abierto, en lugar de una ontología propietaria gestionada por los ingenieros desplegados de Palantir.