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).
53 lines
4.8 KiB
Markdown
53 lines
4.8 KiB
Markdown
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.
|