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).
3 KiB
resume esto https://axiussdc.substack.com/p/palantir-just-said-the-quiet-part
Resumen: "Palantir acaba de decir la parte que se callaba"
Tesis central: El artículo, publicado por Axius-SDC en abril de 2026, sostiene que Palantir admitió públicamente algo que la comunidad de arquitectura de datos lleva años discutiendo: la IA no es el producto, la ontología sí lo es. La IA es solo el motor de ejecución.
Lo que Palantir acierta
Citando un artículo de Sainath Palla sobre el AI-FDE (Foundry Development Environment) de Palantir, el autor reconoce que la ontología no es documentación, sino una capa operacional por la que fluyen datos, workflows y decisiones. El AI-FDE permite que la IA participe en construir el sistema (no solo asistir dentro de él), desplazando el cuello de botella de la implementación al juicio humano: qué construir y cómo debe comportarse.
Donde Palantir falla
El problema es estructural: la ontología vive dentro de la plataforma de Palantir y está gobernada centralmente. A medida que se añaden casos de uso, las intersecciones se multiplican y la carga de gobernanza crece más rápido que el ahorro en implementación. Las únicas personas capaces de manejar esa complejidad son los Forward Deployed Engineers (FDEs) de Palantir, lo que crea una dependencia del proveedor que ninguna IA puede eliminar. Estás "alquilando gobernanza", no comprando infraestructura.
La alternativa propuesta: gobernanza distribuida
En lugar de una ontología centralizada, el autor propone vincular las restricciones a los datos mismos a nivel de componente. La metáfora cambia: ya no construyes una red ferroviaria con intersecciones complejas, sino un estándar de ancho de vía donde cada segmento lleva su propia especificación. Modelos de workflow, atestación, cadenas de procedencia y roles viajan con el payload, no se gestionan desde una plataforma central. Una IA operando sobre este sustrato valida contra el modelo en tiempo de ejecución, sin necesidad de una ontología centralizada.
Tres preguntas para hacerle a tu account manager de Palantir el lunes:
- ¿Cuántos FDEs requiere tu despliegue, y qué pasa si reduces ese número a la mitad?
- Cuando el AI-FDE escala un nuevo caso de uso, ¿quién valida que no desestabilice los workflows existentes?
- ¿Puedes exportar la ontología y desplegarla en tu propia infraestructura sin dependencia de Palantir?
Conclusión
Palantir no es el enemigo: es el "rompehielos" que está educando al Fortune 500 sobre la IA basada en ontologías. La pregunta no es si la arquitectura debe estar guiada por una ontología, sino si esa ontología debe ser propietaria, centralizada y gestionada por ingenieros del proveedor, o abierta, determinista y mantenida por practicantes propios. El autor promociona el programa SDC Practitioner (Apache 2.0, lanzamiento mayo 2026) como esta alternativa abierta.
En una frase: Palantir demostró la tesis; según el autor, no deberías tener que pagarla en alquiler.