santismm-knowledge-mcp 0.2.2 → 0.3.0

package/README.md

@@ -26,8 +26,9 @@ Docs: https://santismm.com/en/mcp · Registry: `com.santismm/knowledge`
 npm ci && npm run build && npm start
 ```
 
-The corpus ships in `content/` and is read from disk, so this works offline.
-Point it elsewhere with `SANTISMM_CONTENT_DIR`.
+The core corpus ships in `content/` and is read from disk, so its tools work
+offline. The three federated Article tools read the canonical Articles API over
+HTTPS. Point the core corpus elsewhere with `SANTISMM_CONTENT_DIR`.
 
 ## Install from npm
 
@@ -67,11 +68,12 @@ is not a software licence and MIT is not a content licence.
 
 ## What it exposes
 
-19 read-only tools over knowledge, patterns, architectures, governance and the
-Harness Engineering Handbook, each declaring an `outputSchema` and returning
-validated `structuredContent`. Every tool is annotated `readOnlyHint: true`,
-`destructiveHint: false`, `idempotentHint: true`, `openWorldHint: false` —
-literally true: it reads a static corpus and nothing else.
+24 read-only tools over knowledge, patterns, architectures, governance, the
+Harness Engineering Handbook and first-party Articles, each declaring an
+`outputSchema` and returning validated `structuredContent`. Every tool is
+annotated `readOnlyHint: true`, `destructiveHint: false` and
+`idempotentHint: true`. The three federated Article tools declare
+`openWorldHint: true`; local-corpus tools remain `false`.
 
 Content in three languages (en/es/pt).
 

package/content/architectures/ai-workforce.json

@@ -13,7 +13,9 @@
     { "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" },
     { "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" }
   ],
-  "related": ["customer-service-agent", "enterprise-knowledge-assistant"],
+  "related": ["customer-service-agent", "enterprise-knowledge-assistant",
+    "operations-center",
+    "sales-copilot"],
   "locales": {
     "en": {
       "name": "AI Workforce",

package/content/claims/a-harness-can-degrade-the-agent.json

@@ -0,0 +1,51 @@
+{
+  "id": "HE-CLAIM-007",
+  "slug": "a-harness-can-degrade-the-agent",
+  "claimType": "santismm_thesis",
+  "confidenceLevel": "low",
+  "reviewed": "2026-08-27",
+  "version": "1.0.0",
+  "updated": "2026-08-27",
+  "supports": [
+    "HRN-001",
+    "HRN-004",
+    "HRN-012",
+    "harness-engineering"
+  ],
+  "sources": [
+    {
+      "title": "Harness Engineering Principles",
+      "author": "Santa María, S.",
+      "venue": "SANTISMM Harness Engineering Handbook",
+      "year": "2026",
+      "type": "personal_experience"
+    },
+    {
+      "title": "Case Studies in Harness Engineering",
+      "author": "Santa María, S.",
+      "venue": "SANTISMM Harness Engineering Handbook",
+      "year": "2026",
+      "type": "personal_experience"
+    }
+  ],
+  "locales": {
+    "en": {
+      "statement": "A harness is not monotonically good. A control that was correct for one model generation can degrade the agent in the next, and current practice makes that invisible because harness components are added and almost never removed.",
+      "basis": "Three mechanisms, all of them ordinary. Prompt rules that compensate for a limitation the next model does not have, and that now spend tokens teaching it something it already knows. Static context carried because the window was scarce, back when it was scarce. Tool surfaces narrowed to what an older model could be trusted with, which now bound what a better one is allowed to attempt. Each was correct when it was written, each is a cost now, and none of them announce themselves — a harness component has no expiry date unless somebody wrote one. So each control here declares what it assumes about the model and the condition under which it should be retired.",
+      "limitations": "Asserted, not measured: nothing in this corpus has been run with and without a control across a model generation change. The classification of which controls expire is one person's reading of retirement conditions the same person wrote, so it restates a judgement rather than evidencing it. The honest counterweight is in the data and points the other way: most controls in the matrix do not expire on capability grounds at all — an unvalidated Origin does not become safe because the model improved — so this is a real risk about a minority of components, not a general law about harnesses.",
+      "falsifiedBy": "Removing components whose stated retirement condition is met and measuring no improvement in cost per correctly verified outcome across a model generation change, repeatedly; or harnesses that never retire anything tracking those that do, on the same scorecard and the same task set."
+    },
+    "es": {
+      "statement": "Un harness no es monótonamente bueno. Un control que era correcto para una generación de modelos puede degradar al agente en la siguiente, y la práctica actual lo hace invisible porque los componentes de harness se añaden y casi nunca se quitan.",
+      "basis": "Tres mecanismos, todos corrientes. Reglas de prompt que compensan una limitación que el modelo siguiente ya no tiene, y que ahora gastan tokens enseñándole algo que ya sabe. Contexto estático que se arrastra porque la ventana era escasa, cuando lo era. Superficies de herramientas estrechadas a lo que se le podía confiar a un modelo más viejo, que ahora acotan lo que a uno mejor se le permite intentar. Cada una era correcta cuando se escribió, cada una es un coste ahora, y ninguna se anuncia: un componente de harness no tiene fecha de caducidad salvo que alguien la escribiera. Por eso cada control declara aquí qué supone sobre el modelo y bajo qué condición debería retirarse.",
+      "limitations": "Afirmado, no medido: nada en este corpus se ha ejecutado con y sin un control atravesando un cambio de generación de modelo. La clasificación de qué controles caducan es la lectura de una persona sobre condiciones de retirada que escribió esa misma persona, así que reformula un criterio en lugar de evidenciarlo. El contrapeso honesto está en los datos y apunta al otro lado: la mayoría de los controles de la matriz no caducan por capacidad —un Origin sin validar no se vuelve seguro porque el modelo mejore—, así que esto es un riesgo real sobre una minoría de componentes y no una ley general sobre los harnesses.",
+      "falsifiedBy": "Quitar componentes cuya condición de retirada declarada se cumple y no medir mejora en el coste por resultado correctamente verificado al cambiar de generación de modelo, de forma repetida; o que harnesses que nunca retiran nada vayan a la par de los que sí, en la misma scorecard y el mismo conjunto de tareas."
+    },
+    "pt": {
+      "statement": "Um harness não é monotonicamente bom. Um controle que era correto para uma geração de modelos pode degradar o agente na seguinte, e a prática atual torna isso invisível porque os componentes de harness são adicionados e quase nunca removidos.",
+      "basis": "Três mecanismos, todos corriqueiros. Regras de prompt que compensam uma limitação que o modelo seguinte já não tem, e que agora gastam tokens ensinando a ele algo que já sabe. Contexto estático carregado porque a janela era escassa, quando era. Superfícies de ferramentas estreitadas ao que se podia confiar a um modelo mais velho, que agora limitam o que a um melhor é permitido tentar. Cada uma estava certa quando foi escrita, cada uma é um custo agora, e nenhuma se anuncia: um componente de harness não tem data de validade a menos que alguém a tenha escrito. Por isso cada controle declara aqui o que supõe sobre o modelo e sob qual condição deveria ser removido.",
+      "limitations": "Afirmado, não medido: nada neste corpus foi executado com e sem um controle atravessando uma mudança de geração de modelo. A classificação de quais controles expiram é a leitura de uma pessoa sobre condições de remoção escritas por essa mesma pessoa, então reformula um critério em vez de evidenciá-lo. O contrapeso honesto está nos dados e aponta para o outro lado: a maioria dos controles da matriz não expira por capacidade — um Origin sem validação não fica seguro porque o modelo melhorou —, então isto é um risco real sobre uma minoria de componentes e não uma lei geral sobre harnesses.",
+      "falsifiedBy": "Remover componentes cuja condição de remoção declarada se cumpre e não medir melhora no custo por resultado corretamente verificado ao mudar de geração de modelo, de forma repetida; ou que harnesses que nunca removem nada acompanhem os que removem, no mesmo scorecard e no mesmo conjunto de tarefas."
+    }
+  }
+}

package/content/claims/harness-changes-outcomes.json

@@ -0,0 +1,57 @@
+{
+  "id": "HE-CLAIM-001",
+  "slug": "harness-changes-outcomes",
+  "claimType": "observed_fact",
+  "confidenceLevel": "high",
+  "reviewed": "2026-08-27",
+  "version": "1.0.0",
+  "updated": "2026-08-27",
+  "supports": [
+    "HRN-001",
+    "HRN-003",
+    "harness-engineering"
+  ],
+  "sources": [
+    {
+      "title": "Building Effective Agents",
+      "author": "Anthropic",
+      "venue": "Anthropic Engineering",
+      "year": "2024",
+      "type": "industry_observation"
+    },
+    {
+      "title": "How we built our multi-agent research system",
+      "author": "Anthropic",
+      "venue": "Anthropic Engineering",
+      "year": "2025",
+      "type": "industry_observation"
+    },
+    {
+      "title": "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?",
+      "author": "Jimenez, C. et al.",
+      "venue": "ICLR",
+      "year": "2024",
+      "type": "benchmark"
+    }
+  ],
+  "locales": {
+    "en": {
+      "statement": "Holding the model fixed and changing only the harness materially changes the outcome of the same task.",
+      "basis": "Published agentic benchmarks report different resolution rates for the same underlying model depending on the scaffold that drives it, and vendor engineering writeups describe the same effect when they change loop, tools or context strategy without changing the model.",
+      "limitations": "Establishes that the harness matters, not how much, nor which component carries the effect, nor whether it generalises across models. Published comparisons are self-reported and rarely control cost, repetitions or variance.",
+      "falsifiedBy": "A controlled study holding model, task, effort and budget constant across several harnesses that finds no difference in verified success rate beyond run-to-run variance."
+    },
+    "es": {
+      "statement": "Con el modelo fijo, cambiar solo el harness cambia materialmente el resultado de la misma tarea.",
+      "basis": "Los benchmarks agénticos publicados dan tasas de resolución distintas para el mismo modelo según el andamiaje que lo conduce, y los informes de ingeniería de los proveedores describen el mismo efecto al cambiar bucle, herramientas o estrategia de contexto sin tocar el modelo.",
+      "limitations": "Establece que el harness importa, no cuánto, ni qué componente produce el efecto, ni si generaliza entre modelos. Las comparaciones publicadas son autodeclaradas y rara vez controlan coste, repeticiones ni varianza.",
+      "falsifiedBy": "Un estudio controlado que, fijando modelo, tarea, esfuerzo y presupuesto, no encuentre diferencia en la tasa de éxito verificado entre varios harnesses más allá de la varianza entre ejecuciones."
+    },
+    "pt": {
+      "statement": "Com o modelo fixo, mudar apenas o harness muda materialmente o resultado da mesma tarefa.",
+      "basis": "Os benchmarks agênticos publicados dão taxas de resolução diferentes para o mesmo modelo consoante o andaime que o conduz, e os relatos de engenharia dos fornecedores descrevem o mesmo efeito ao mudar ciclo, ferramentas ou estratégia de contexto sem tocar no modelo.",
+      "limitations": "Estabelece que o harness importa, não quanto, nem que componente produz o efeito, nem se generaliza entre modelos. As comparações publicadas são autodeclaradas e raramente controlam custo, repetições ou variância.",
+      "falsifiedBy": "Um estudo controlado que, fixando modelo, tarefa, esforço e orçamento, não encontre diferença na taxa de sucesso verificado entre vários harnesses para além da variância entre execuções."
+    }
+  }
+}

package/content/claims/harness-engineering-is-a-distinct-discipline.json

@@ -0,0 +1,43 @@
+{
+  "id": "HE-CLAIM-003",
+  "slug": "harness-engineering-is-a-distinct-discipline",
+  "claimType": "santismm_thesis",
+  "confidenceLevel": "medium",
+  "reviewed": "2026-08-27",
+  "version": "1.0.0",
+  "updated": "2026-08-27",
+  "supports": [
+    "HRN-001",
+    "HRN-002",
+    "harness-engineering"
+  ],
+  "sources": [
+    {
+      "title": "Harness Engineering: Definition and Overview",
+      "author": "Santa María, S.",
+      "venue": "SANTISMM Harness Engineering Handbook",
+      "year": "2026",
+      "type": "personal_experience"
+    }
+  ],
+  "locales": {
+    "en": {
+      "statement": "Building the system around the model is an emerging engineering discipline in its own right, not a specialism of machine learning or of backend engineering.",
+      "basis": "The failure modes are new — the same input can take different paths and reach different conclusions — so confidence comes from measuring distributions and bounding authority rather than from assertions. The skills it demands (probabilistic reliability, evaluation design, context engineering, tool-contract design, adversarial security) sit cleanly in neither parent field.",
+      "limitations": "This is SANTISMM's position, not an industry consensus. There is no accreditation, no standard curriculum, no agreed body of knowledge and no professional body. 'Emerging' is doing real work in this sentence: the claim is that the discipline is forming, not that it is established.",
+      "falsifiedBy": "The concerns being absorbed as a normal specialism of platform or ML engineering — standard curricula and job ladders treating it as such — or model capability advancing far enough that the surrounding system stops needing distinct engineering."
+    },
+    "es": {
+      "statement": "Construir el sistema que rodea al modelo es una disciplina de ingeniería emergente por derecho propio, no una especialidad del aprendizaje automático ni de la ingeniería de backend.",
+      "basis": "Los modos de fallo son nuevos —la misma entrada puede seguir caminos distintos y llegar a conclusiones distintas—, así que la confianza sale de medir distribuciones y acotar la autoridad, no de aserciones. Las competencias que exige (fiabilidad probabilística, diseño de evaluación, ingeniería de contexto, diseño de contratos de herramientas, seguridad adversaria) no encajan limpiamente en ninguna de las dos disciplinas madre.",
+      "limitations": "Es la posición de SANTISMM, no un consenso del sector. No hay acreditación, ni currículo estándar, ni cuerpo de conocimiento acordado, ni organismo profesional. «Emergente» hace trabajo real en esta frase: se afirma que la disciplina se está formando, no que esté establecida.",
+      "falsifiedBy": "Que esas preocupaciones se absorban como una especialidad normal de la ingeniería de plataforma o de ML —currículos y carreras profesionales tratándola así—, o que la capacidad de los modelos avance lo bastante como para que el sistema alrededor deje de necesitar ingeniería propia."
+    },
+    "pt": {
+      "statement": "Construir o sistema que rodeia o modelo é uma disciplina de engenharia emergente por direito próprio, não uma especialidade da aprendizagem automática nem da engenharia de backend.",
+      "basis": "Os modos de falha são novos — a mesma entrada pode seguir caminhos diferentes e chegar a conclusões diferentes —, pelo que a confiança vem de medir distribuições e limitar a autoridade, não de asserções. As competências que exige (fiabilidade probabilística, desenho de avaliação, engenharia de contexto, desenho de contratos de ferramentas, segurança adversária) não encaixam de forma limpa em nenhuma das disciplinas-mãe.",
+      "limitations": "É a posição da SANTISMM, não um consenso do setor. Não há acreditação, currículo padrão, corpo de conhecimento acordado nem organismo profissional. «Emergente» faz trabalho real nesta frase: afirma-se que a disciplina se está a formar, não que esteja estabelecida.",
+      "falsifiedBy": "Que essas preocupações sejam absorvidas como especialidade normal da engenharia de plataforma ou de ML — currículos e carreiras a tratá-la assim —, ou que a capacidade dos modelos avance o suficiente para o sistema à volta deixar de precisar de engenharia própria."
+    }
+  }
+}

package/content/claims/harness-is-the-durable-asset.json

@@ -0,0 +1,43 @@
+{
+  "id": "HE-CLAIM-004",
+  "slug": "harness-is-the-durable-asset",
+  "claimType": "strategic_hypothesis",
+  "confidenceLevel": "low",
+  "reviewed": "2026-08-27",
+  "version": "1.0.0",
+  "updated": "2026-08-27",
+  "supports": [
+    "HRN-001",
+    "HRN-012",
+    "harness-engineering"
+  ],
+  "sources": [
+    {
+      "title": "Harness Engineering: Definition and Overview",
+      "author": "Santa María, S.",
+      "venue": "SANTISMM Harness Engineering Handbook",
+      "year": "2026",
+      "type": "personal_experience"
+    }
+  ],
+  "locales": {
+    "en": {
+      "statement": "As frontier model capability commoditises, the harness becomes the durable source of competitive advantage for an enterprise.",
+      "basis": "Models are bought by everyone on comparable terms, while the harness encodes an organisation's own data access, policies, tool contracts, evaluation suites and authority limits — none of which transfer with a model swap.",
+      "limitations": "A bet about the future, held at low confidence and with no supporting measurement. The opposite is equally arguable: capability gains may absorb harness work, and much of today's harness exists to compensate for limitations that the next model generation removes.",
+      "falsifiedBy": "Successive model generations reducing the harness needed to reach the same verified outcome — measurably fewer components for equal or better results — or enterprises finding that swapping models, not harness quality, is what moves their outcomes."
+    },
+    "es": {
+      "statement": "A medida que la capacidad de los modelos de frontera se comoditiza, el harness pasa a ser la fuente duradera de ventaja competitiva de una empresa.",
+      "basis": "Los modelos los compra todo el mundo en condiciones comparables, mientras que el harness codifica el acceso a datos propios, las políticas, los contratos de herramientas, las suites de evaluación y los límites de autoridad de una organización concreta — y nada de eso viaja al cambiar de modelo.",
+      "limitations": "Es una apuesta sobre el futuro, sostenida con confianza baja y sin medición que la respalde. Lo contrario es igual de defendible: las mejoras de capacidad pueden absorber el trabajo de harness, y buena parte del harness de hoy existe para compensar limitaciones que la siguiente generación de modelos elimina.",
+      "falsifiedBy": "Que generaciones sucesivas de modelos reduzcan el harness necesario para el mismo resultado verificado —medidamente menos componentes para resultados iguales o mejores— o que a las empresas les mueva los resultados cambiar de modelo y no la calidad del harness."
+    },
+    "pt": {
+      "statement": "À medida que a capacidade dos modelos de fronteira se comoditiza, o harness torna-se a fonte duradoura de vantagem competitiva de uma empresa.",
+      "basis": "Os modelos são comprados por todos em condições comparáveis, ao passo que o harness codifica o acesso a dados próprios, as políticas, os contratos de ferramentas, as suites de avaliação e os limites de autoridade de uma organização concreta — e nada disso viaja ao mudar de modelo.",
+      "limitations": "É uma aposta sobre o futuro, sustentada com confiança baixa e sem medição que a apoie. O contrário é igualmente defensável: os ganhos de capacidade podem absorver o trabalho de harness, e boa parte do harness de hoje existe para compensar limitações que a geração seguinte elimina.",
+      "falsifiedBy": "Que gerações sucessivas de modelos reduzam o harness necessário para o mesmo resultado verificado — mensuravelmente menos componentes para resultados iguais ou melhores — ou que às empresas o que lhes move os resultados seja mudar de modelo e não a qualidade do harness."
+    }
+  }
+}

package/content/claims/maturity-levels-are-ordered-by-dependency.json

@@ -0,0 +1,43 @@
+{
+  "id": "HE-CLAIM-006",
+  "slug": "maturity-levels-are-ordered-by-dependency",
+  "claimType": "santismm_thesis",
+  "confidenceLevel": "low",
+  "reviewed": "2026-08-27",
+  "version": "1.0.0",
+  "updated": "2026-08-27",
+  "supports": [
+    "HRN-001",
+    "HRN-004",
+    "harness-engineering"
+  ],
+  "sources": [
+    {
+      "title": "Harness Engineering Principles",
+      "author": "Santa María, S.",
+      "venue": "SANTISMM Harness Engineering Handbook",
+      "year": "2026",
+      "type": "personal_experience"
+    }
+  ],
+  "locales": {
+    "en": {
+      "statement": "The seven levels of the maturity model are ordered by dependency rather than by preference: a harness does not hold a level while any criterion below it fails, because each level is what makes the level above it measurable.",
+      "basis": "The dependencies are concrete, not decorative. Evaluation at level 4 is meaningless without the reproducibility of level 1 — you cannot regression-test a run you cannot reproduce. Reconstructing a run at level 5 needs the declared tool surface of level 2, because a call nobody catalogued is a call nobody can read back. Retiring a component at level 6 needs the measurement of level 4, or the retirement is a preference with a date on it.",
+      "limitations": "The order is asserted from one practitioner's experience of a small number of systems, and it is self-assessed: every criterion is a test somebody runs on themselves, which is the weakest form of assessment there is. Organisations demonstrably skip rungs — most ship tools before they version prompts — and this model calls that a failure at level 1 rather than a different valid path, which may be wrong. The ladder may be encoding one route rather than the route.",
+      "falsifiedBy": "An organisation holding a level with a criterion below it failing, and its outcomes not degrading in the way the dependency predicts — measured on the scorecard, not argued. Or a common path through the levels in a materially different order, followed by systems that work."
+    },
+    "es": {
+      "statement": "Los siete niveles del modelo de madurez están ordenados por dependencia y no por preferencia: un harness no sostiene un nivel mientras falle cualquier criterio por debajo, porque cada nivel es lo que hace medible al siguiente.",
+      "basis": "Las dependencias son concretas, no decorativas. Evaluar en el nivel 4 no significa nada sin la reproducibilidad del nivel 1: no se puede hacer test de regresión sobre una ejecución que no se puede reproducir. Reconstruir una ejecución en el nivel 5 necesita la superficie de herramientas declarada del nivel 2, porque una llamada que nadie catalogó es una llamada que nadie puede releer. Retirar un componente en el nivel 6 necesita la medición del nivel 4, o la retirada es una preferencia con fecha.",
+      "limitations": "El orden se afirma desde la experiencia de un solo profesional con un número pequeño de sistemas, y es autoevaluado: cada criterio es una prueba que alguien se hace a sí mismo, que es la forma más débil de evaluación que existe. Las organizaciones se saltan peldaños de forma demostrable —la mayoría pone herramientas antes de versionar prompts— y este modelo llama a eso un fallo en el nivel 1 y no un camino válido distinto, lo cual puede ser un error. La escalera puede estar codificando una ruta y no la ruta.",
+      "falsifiedBy": "Una organización que sostenga un nivel con un criterio inferior fallando y cuyos resultados no se degraden como predice la dependencia, medido en la scorecard y no argumentado. O un camino habitual por los niveles en un orden materialmente distinto, recorrido por sistemas que funcionan."
+    },
+    "pt": {
+      "statement": "Os sete níveis do modelo de maturidade estão ordenados por dependência e não por preferência: um harness não sustenta um nível enquanto qualquer critério abaixo falhar, porque cada nível é o que torna o seguinte mensurável.",
+      "basis": "As dependências são concretas, não decorativas. Avaliar no nível 4 não significa nada sem a reprodutibilidade do nível 1: não se pode fazer teste de regressão sobre uma execução que não se pode reproduzir. Reconstruir uma execução no nível 5 precisa da superfície de ferramentas declarada do nível 2, porque uma chamada que ninguém catalogou é uma chamada que ninguém pode reler. Aposentar um componente no nível 6 precisa da medição do nível 4, ou a aposentadoria é uma preferência com data.",
+      "limitations": "A ordem é afirmada a partir da experiência de um único profissional com um número pequeno de sistemas, e é autoavaliada: cada critério é um teste que alguém faz em si mesmo, que é a forma mais fraca de avaliação que existe. As organizações pulam degraus de forma demonstrável — a maioria coloca ferramentas antes de versionar prompts — e este modelo chama isso de falha no nível 1 e não de um caminho válido diferente, o que pode ser um erro. A escada pode estar codificando uma rota e não a rota.",
+      "falsifiedBy": "Uma organização que sustente um nível com um critério inferior falhando e cujos resultados não se degradem como a dependência prevê, medido no scorecard e não argumentado. Ou um caminho habitual pelos níveis em uma ordem materialmente diferente, percorrido por sistemas que funcionam."
+    }
+  }
+}

package/content/claims/practice-converges-on-eight-components.json

@@ -0,0 +1,58 @@
+{
+  "id": "HE-CLAIM-002",
+  "slug": "practice-converges-on-eight-components",
+  "claimType": "industry_synthesis",
+  "confidenceLevel": "medium",
+  "reviewed": "2026-08-27",
+  "version": "1.0.0",
+  "updated": "2026-08-27",
+  "supports": [
+    "HRN-003",
+    "HRN-004",
+    "harness-engineering",
+    "agentic-ai"
+  ],
+  "sources": [
+    {
+      "title": "Building Effective Agents",
+      "author": "Anthropic",
+      "venue": "Anthropic Engineering",
+      "year": "2024",
+      "type": "industry_observation"
+    },
+    {
+      "title": "A Survey on Large Language Model based Autonomous Agents",
+      "author": "Wang, L. et al.",
+      "venue": "survey",
+      "year": "2023",
+      "type": "paper"
+    },
+    {
+      "title": "AI Risk Management Framework (AI RMF 1.0)",
+      "author": "NIST",
+      "venue": "NIST",
+      "year": "2023",
+      "type": "industry_observation"
+    }
+  ],
+  "locales": {
+    "en": {
+      "statement": "Independent practitioners are converging on the same small set of concerns around the model — context and memory, tools, planning and orchestration, observability, evaluation, governance and security — even where they use different names for them.",
+      "basis": "Vendor engineering guidance, agent surveys and the control catalogues of AI governance frameworks describe overlapping concerns from different starting points, without citing one another as the source of the taxonomy.",
+      "limitations": "Convergence of concerns is not agreement on a taxonomy. No standard names, boundaries or component count exists, and SANTISMM's grouping into eight components across three layers is one cut among several defensible ones. Absence of cross-citation makes independence plausible, not proven.",
+      "falsifiedBy": "A published, adopted taxonomy that partitions the same space differently — or evidence that the apparent convergence traces back to a single common source rather than independent practice."
+    },
+    "es": {
+      "statement": "Practicantes independientes están convergiendo en el mismo conjunto reducido de preocupaciones alrededor del modelo —contexto y memoria, herramientas, planificación y orquestación, observabilidad, evaluación, gobierno y seguridad— aunque las nombren de forma distinta.",
+      "basis": "Las guías de ingeniería de los proveedores, los estudios sobre agentes y los catálogos de control de los marcos de gobierno describen preocupaciones solapadas partiendo de sitios distintos, sin citarse entre sí como origen de la taxonomía.",
+      "limitations": "Converger en las preocupaciones no es acordar una taxonomía. No existen nombres, fronteras ni número de componentes estándar, y agruparlos en ocho componentes y tres capas es un corte entre varios defendibles. Que no se citen hace plausible la independencia, no la demuestra.",
+      "falsifiedBy": "Una taxonomía publicada y adoptada que reparta el mismo espacio de otra forma, o evidencia de que la convergencia aparente procede de una fuente común y no de práctica independiente."
+    },
+    "pt": {
+      "statement": "Praticantes independentes estão a convergir no mesmo conjunto reduzido de preocupações à volta do modelo — contexto e memória, ferramentas, planeamento e orquestração, observabilidade, avaliação, governo e segurança — ainda que lhes deem nomes diferentes.",
+      "basis": "Os guias de engenharia dos fornecedores, os estudos sobre agentes e os catálogos de controle dos quadros de governo descrevem preocupações sobrepostas partindo de pontos distintos, sem se citarem como origem da taxonomia.",
+      "limitations": "Convergir nas preocupações não é acordar uma taxonomia. Não existem nomes, fronteiras nem número de componentes padrão, e agrupá-los em oito componentes e três camadas é um corte entre vários defensáveis. Não se citarem torna a independência plausível, não provada.",
+      "falsifiedBy": "Uma taxonomia publicada e adotada que reparta o mesmo espaço de outra forma, ou evidência de que a convergência aparente vem de uma fonte comum e não de prática independente."
+    }
+  }
+}

package/content/claims/verified-outcome-is-the-unit.json

@@ -0,0 +1,50 @@
+{
+  "id": "HE-CLAIM-005",
+  "slug": "verified-outcome-is-the-unit",
+  "claimType": "santismm_thesis",
+  "confidenceLevel": "low",
+  "reviewed": "2026-08-27",
+  "version": "1.0.0",
+  "updated": "2026-08-27",
+  "supports": [
+    "HRN-007",
+    "agentic-evaluation",
+    "harness-engineering"
+  ],
+  "sources": [
+    {
+      "title": "Evaluation of Agentic Systems",
+      "author": "Santa María, S.",
+      "venue": "SANTISMM Harness Engineering Handbook",
+      "year": "2026",
+      "type": "personal_experience"
+    },
+    {
+      "title": "The Stopwatch and the Exam",
+      "author": "Santa María, S.",
+      "venue": "SANTISMM Library",
+      "year": "2026",
+      "type": "personal_experience"
+    }
+  ],
+  "locales": {
+    "en": {
+      "statement": "The primary unit for comparing harnesses is cost per correctly verified outcome, not successful runs: a run the agent declares successful is a self-report, and it is the one thing a broken harness is still good at producing.",
+      "basis": "Every failure mode a harness exists to catch — a hallucinated result, an action taken on a hijacked instruction, a plan abandoned halfway and reported as done — is compatible with a run that finished. Moving the denominator to outcomes confirmed by something that does not share the agent's failure modes makes the number refuse to move until the work is actually done, and puts the cost of the failed attempts where it belongs, in the numerator.",
+      "limitations": "This is a proposal, not a measured result. Nothing here has been run against a real system, no threshold is calibrated, and the eleven metrics around it were chosen by argument rather than by finding out which ones predict anything. The independence rule is also the hardest part to satisfy honestly: for many agentic tasks the only available verifier is another model, and the rule then says the number cannot be trusted — which is correct and unhelpful at the same time.",
+      "falsifiedBy": "Two harnesses ranked differently by cost per correctly verified outcome and by outcomes their operators actually care about, repeatedly and in the same direction; or evidence that the self-reported success rate tracks the independently verified one closely enough that the distinction buys nothing."
+    },
+    "es": {
+      "statement": "La unidad principal para comparar harnesses es el coste por resultado correctamente verificado, no las ejecuciones exitosas: una ejecución que el agente declara exitosa es una autodeclaración, y es justo lo único que un harness roto sigue produciendo bien.",
+      "basis": "Todos los modos de fallo que un harness existe para atrapar —un resultado alucinado, una acción tomada sobre una instrucción secuestrada, un plan abandonado a medias y reportado como hecho— son compatibles con una ejecución que terminó. Llevar el denominador a los resultados confirmados por algo que no comparte los modos de fallo del agente hace que el número se niegue a moverse hasta que el trabajo esté hecho de verdad, y pone el coste de los intentos fallidos donde corresponde, en el numerador.",
+      "limitations": "Esto es una propuesta, no un resultado medido. Nada de esto se ha ejecutado contra un sistema real, ningún umbral está calibrado, y las once métricas que lo rodean se eligieron por argumento y no por averiguar cuáles predicen algo. La regla de independencia es además la parte más difícil de satisfacer con honestidad: en muchas tareas agénticas el único verificador disponible es otro modelo, y entonces la regla dice que el número no es de fiar, lo cual es correcto e inútil al mismo tiempo.",
+      "falsifiedBy": "Que dos harnesses queden ordenados de forma distinta por el coste por resultado correctamente verificado y por los resultados que a sus operadores les importan de verdad, de forma repetida y en la misma dirección; o evidencia de que la tasa de éxito autodeclarada sigue a la verificada de forma independiente lo bastante de cerca como para que la distinción no compre nada."
+    },
+    "pt": {
+      "statement": "A unidade principal para comparar harnesses é o custo por resultado corretamente verificado, não as execuções bem-sucedidas: uma execução que o agente declara bem-sucedida é uma autodeclaração, e é justamente a única coisa que um harness quebrado ainda produz bem.",
+      "basis": "Todos os modos de falha que um harness existe para pegar — um resultado alucinado, uma ação tomada sobre uma instrução sequestrada, um plano abandonado pela metade e relatado como feito — são compatíveis com uma execução que terminou. Levar o denominador aos resultados confirmados por algo que não compartilha os modos de falha do agente faz o número se recusar a mudar até o trabalho estar realmente feito, e põe o custo das tentativas fracassadas onde é devido, no numerador.",
+      "limitations": "Isto é uma proposta, não um resultado medido. Nada disto foi executado contra um sistema real, nenhum limiar está calibrado, e as onze métricas em volta foram escolhidas por argumento e não por descobrir quais delas predizem alguma coisa. A regra de independência é também a parte mais difícil de satisfazer com honestidade: em muitas tarefas agênticas o único verificador disponível é outro modelo, e então a regra diz que o número não é confiável, o que é correto e inútil ao mesmo tempo.",
+      "falsifiedBy": "Que dois harnesses fiquem ordenados de forma diferente pelo custo por resultado corretamente verificado e pelos resultados com que seus operadores realmente se importam, de forma repetida e na mesma direção; ou evidência de que a taxa de sucesso autodeclarada acompanha a verificada de forma independente perto o bastante para que a distinção não compre nada."
+    }
+  }
+}

package/content/governance/agentic-ai-governance-checklist.json

@@ -49,7 +49,9 @@
   "related": [
     "eu-ai-act",
     "iso-42001",
-    "nist-ai-rmf"
+    "nist-ai-rmf",
+    "enterprise-ai-governance-framework",
+    "human-oversight-and-accountability-policy"
   ],
   "locales": {
     "en": {

package/content/harness/HRN-001-definition-and-overview.es.md

@@ -1,12 +1,12 @@
 ---
 title: "Ingeniería de Harness: definición y panorama"
-summary: "La Ingeniería de Harness es la disciplina que construye sistemas agénticos fiables para entornos empresariales: el andamiaje de ingeniería —memoria, herramientas, orquestación, observabilidad, evaluación, gobernanza y seguridad— que rodea al modelo."
+summary: "La Ingeniería de Harness es la disciplina emergente que construye sistemas agénticos fiables para entornos empresariales: el andamiaje de ingeniería —memoria, herramientas, orquestación, observabilidad, evaluación, gobernanza y seguridad— que rodea al modelo."
 ---
 
 # Ingeniería de Harness: definición y panorama
 
 ## Resumen ejecutivo
-La Ingeniería de Harness es la disciplina responsable de construir sistemas agénticos fiables para entornos empresariales. Un modelo de lenguaje es un predictor probabilístico del siguiente token; una empresa necesita un sistema de confianza que haga el trabajo, respete la política y falle de forma segura. El harness es todo lo que se construye *alrededor* del modelo —memoria, herramientas, planificación, orquestación, observabilidad, evaluación, gobernanza y seguridad— para cerrar esa distancia. Este capítulo define la disciplina, enuncia su tesis y enmarca el resto del manual.
+La Ingeniería de Harness es la disciplina emergente responsable de construir sistemas agénticos fiables para entornos empresariales. Un modelo de lenguaje es un predictor probabilístico del siguiente token; una empresa necesita un sistema de confianza que haga el trabajo, respete la política y falle de forma segura. El harness es todo lo que se construye *alrededor* del modelo —memoria, herramientas, planificación, orquestación, observabilidad, evaluación, gobernanza y seguridad— para cerrar esa distancia. Este capítulo define la disciplina, enuncia su tesis y enmarca el resto del manual.
 
 ## Conceptos clave
 - **Modelo:** el núcleo probabilístico (un LLM o un modelo multimodal) que transforma un contexto en una distribución sobre los siguientes tokens. Potente, pero sin estado, sin gobernanza y no determinista por defecto.
@@ -17,7 +17,7 @@ La Ingeniería de Harness es la disciplina responsable de construir sistemas ag
 - **Entorno empresarial:** un contexto con riesgo real: datos regulados, requisitos de auditoría, acuerdos de nivel de servicio y adversarios.
 
 ## Definición
-La **Ingeniería de Harness** es la disciplina de ingeniería que se ocupa del diseño, la construcción y la operación de los sistemas que rodean a los modelos probabilísticos, de modo que el sistema agéntico resultante sea suficientemente fiable, observable, gobernable y seguro para uso empresarial. Donde el aprendizaje automático produce el *modelo*, la Ingeniería de Harness produce el *sistema*. Su unidad de trabajo no es un prompt ni una matriz de pesos, sino el bucle completo que convierte un objetivo en un resultado verificado y auditable.
+La **Ingeniería de Harness** es la disciplina de ingeniería emergente que se ocupa del diseño, la construcción y la operación de los sistemas que rodean a los modelos probabilísticos, de modo que el sistema agéntico resultante sea suficientemente fiable, observable, gobernable y seguro para uso empresarial. Donde el aprendizaje automático produce el *modelo*, la Ingeniería de Harness produce el *sistema*. Su unidad de trabajo no es un prompt ni una matriz de pesos, sino el bucle completo que convierte un objetivo en un resultado verificado y auditable.
 
 ## Explicación detallada
 La industria pasó de 2020 a 2023 aprendiendo que un modelo mejor es necesario pero no suficiente. Las demos que deslumbran con un prompt cuidado se derrumban en producción frente a entradas ambiguas, usuarios hostiles, datos obsoletos, fallos parciales de herramientas y el simple hecho de que la misma entrada puede dar dos salidas distintas. La respuesta no fue «un modelo más listo» sino *un sistema de ingeniería alrededor del modelo*. Ese sistema es el harness, y construirlo bien es una disciplina propia.
@@ -39,6 +39,9 @@ No son extras opcionales: son la estructura portante. La taxonomía de HRN-003 p
 
 **¿Por qué una disciplina nueva?** Porque los modos de fallo son nuevos. El software clásico es determinista: dada una entrada, calcula la misma salida, y lo pruebas con aserciones. Los sistemas agénticos son *estocásticos y autodirigidos*: la misma entrada puede tomar caminos distintos, invocar herramientas distintas y llegar a conclusiones distintas (a veces erróneas). No puedes llegar a la confianza a base de aserciones; tienes que *medir distribuciones*, acotar la autoridad del modelo e instrumentarlo todo. Las capacidades que exige —fiabilidad probabilística, diseño de evaluación, ingeniería de contexto, diseño de contratos de herramientas y seguridad adversaria— no encajan limpiamente ni en el aprendizaje automático tradicional ni en la ingeniería de backend. Ese hueco es la disciplina.
 
+
+**¿Por qué *emergente* y no simplemente una disciplina?** Porque la respuesta honesta tiene cuatro partes y no son igual de firmes. Que el mismo modelo con distintos harnesses dé resultados distintos es un **hecho observado**. Que la práctica esté convergiendo en las mismas preocupaciones —contexto, herramientas, evaluación, observabilidad, control— es una **lectura del sector**. Que esas preocupaciones constituyan una disciplina propia es **nuestra posición**, sostenida con confianza media: no hay acreditación, ni currículo estándar, ni cuerpo de conocimiento acordado, ni organismo profesional, y darla por establecida afirmaría más de lo que nadie puede demostrar. Que el harness, y no el modelo, acabe siendo el activo competitivo duradero es una **apuesta**, sostenida con confianza baja. Cada una se publica por separado, con sus límites y la observación que la retiraría, como `HE-CLAIM-001` a `HE-CLAIM-004`: se consultan con `get_claim`.
+
 **Para quién es.** La Ingeniería de Harness es para los equipos responsables de poner agentes en producción donde importa: ingeniería de plataforma que construye runtimes de agentes, ingeniería de IA aplicada que entrega funcionalidades agénticas, las funciones de seguridad y gobernanza que deben dar el visto bueno, y los arquitectos que responden del conjunto. Es explícitamente *enterprise-first*: las restricciones que definen la disciplina —auditoría, regulación, SLA, adversarios, escala— son precisamente las que el utillaje de aficionado ignora.
 
 **Una opinión, dicha sin rodeos:** el modelo es cada vez más una materia prima; el harness es el activo de ingeniería duradero y el foso defensivo. A medida que los modelos frontera convergen y se vuelven intercambiables, el valor diferencial y defendible de un sistema de IA empresarial migra hacia el harness: su arquitectura de memoria, su corpus de evaluación, sus controles de gobernanza, su observabilidad. Invertir en el harness es invertir en la parte que compone.

package/content/harness/HRN-001-definition-and-overview.md

@@ -7,7 +7,7 @@ status: Draft
 author: Santiago Santa María
 created: 2026-06-21
 updated: 2026-06-21
-summary: Harness Engineering is the discipline of building reliable agentic systems for enterprise environments — the engineered scaffolding of memory, tools, orchestration, observability, evaluation, governance, and security that surrounds the model.
+summary: Harness Engineering is the emerging discipline of building reliable agentic systems for enterprise environments — the engineered scaffolding of memory, tools, orchestration, observability, evaluation, governance, and security that surrounds the model.
 evidence_level: theoretical
 confidence_level: medium
 source_type:
@@ -28,7 +28,7 @@ tags:
 # Harness Engineering: Definition and Overview
 
 ## Executive Summary
-Harness Engineering is the discipline responsible for building reliable agentic systems for enterprise environments. A large language model is a probabilistic next-token predictor; an enterprise needs a dependable system that performs work, respects policy, and fails safely. The harness is everything engineered *around* the model — memory, tools, planning, orchestration, observability, evaluation, governance, and security — that closes the gap between the two. This chapter defines the discipline, states its thesis, and frames the rest of the handbook.
+Harness Engineering is the emerging discipline responsible for building reliable agentic systems for enterprise environments. A large language model is a probabilistic next-token predictor; an enterprise needs a dependable system that performs work, respects policy, and fails safely. The harness is everything engineered *around* the model — memory, tools, planning, orchestration, observability, evaluation, governance, and security — that closes the gap between the two. This chapter defines the discipline, states its thesis, and frames the rest of the handbook.
 
 ## Key Concepts
 - **Model:** The probabilistic core (an LLM or multimodal model) that maps a context to a distribution over next tokens. Powerful, but stateless, ungoverned, and non-deterministic by default.
@@ -39,7 +39,7 @@ Harness Engineering is the discipline responsible for building reliable agentic
 - **Enterprise environment:** A setting with real stakes — regulated data, audit requirements, SLAs, and adversaries.
 
 ## Definition
-**Harness Engineering** is the engineering discipline concerned with the design, construction, and operation of the systems that surround probabilistic models so that the resulting agentic system is reliable, observable, governable, and secure enough for enterprise use. Where machine learning produces the *model*, Harness Engineering produces the *system*. Its unit of work is not a prompt or a weight matrix but the end-to-end loop that turns a goal into a verified, auditable outcome.
+**Harness Engineering** is the emerging engineering discipline concerned with the design, construction, and operation of the systems that surround probabilistic models so that the resulting agentic system is reliable, observable, governable, and secure enough for enterprise use. Where machine learning produces the *model*, Harness Engineering produces the *system*. Its unit of work is not a prompt or a weight matrix but the end-to-end loop that turns a goal into a verified, auditable outcome.
 
 ## Architecture Diagram
 ```mermaid
@@ -88,6 +88,9 @@ These are not optional add-ons; they are the load-bearing structure. The taxonom
 
 **Why a new discipline?** Because the failure modes are new. Classical software is deterministic: given an input, it computes the same output, and you test it with assertions. Agentic systems are *stochastic and self-directed*: the same input may take different paths, invoke different tools, and reach different (sometimes wrong) conclusions. You cannot assert your way to confidence; you must *measure distributions*, bound the model's authority, and instrument everything. The skills required — probabilistic reliability, evaluation design, prompt-and-context engineering, tool contract design, and adversarial security — do not map cleanly onto either traditional ML or traditional backend engineering. That gap is the discipline.
 
+
+**Why *emerging*, and not simply a discipline?** Because the honest answer has four parts, and they are not equally strong. That the same model under different harnesses produces different results is an **observed fact**. That practice is converging on the same concerns — context, tools, evaluation, observability, control — is a **reading of the industry**. That those concerns constitute a discipline of its own is **our position**, held at medium confidence: there is no accreditation, no standard curriculum, no agreed body of knowledge and no professional body, and calling it settled would claim more than anyone can show. That the harness, rather than the model, becomes the durable competitive asset is a **bet**, held at low confidence. Each of those is published separately, with its limits and the observation that would retire it, as `HE-CLAIM-001` through `HE-CLAIM-004` — query them with `get_claim`.
+
 **Who it is for.** Harness Engineering is for the teams accountable for putting agents into production where it matters: platform engineers building agent runtimes, ML and applied-AI engineers shipping agentic features, security and governance functions who must sign off, and the architects who own the whole. It is explicitly *enterprise-first* — the constraints that define the discipline (audit, regulation, SLAs, adversaries, scale) are precisely the ones hobbyist tooling ignores.
 
 **An opinion, stated plainly:** the model is increasingly a commodity; the harness is the durable engineering asset and the moat. As frontier models converge and become swappable, the differentiated, defensible value of an enterprise AI system migrates into the harness — its memory architecture, its evaluation corpus, its governance controls, its observability. Investing in the harness is investing in the part that compounds.

package/content/harness/HRN-001-definition-and-overview.pt.md

@@ -1,12 +1,12 @@
 ---
 title: "Engenharia de Harness: definição e panorama"
-summary: "A Engenharia de Harness é a disciplina que constrói sistemas agênticos confiáveis para ambientes empresariais: o andaime de engenharia — memória, ferramentas, orquestração, observabilidade, avaliação, governança e segurança — que rodeia o modelo."
+summary: "A Engenharia de Harness é a disciplina emergente que constrói sistemas agênticos confiáveis para ambientes empresariais: o andaime de engenharia — memória, ferramentas, orquestração, observabilidade, avaliação, governança e segurança — que rodeia o modelo."
 ---
 
 # Engenharia de Harness: definição e panorama
 
 ## Resumo executivo
-A Engenharia de Harness é a disciplina responsável por construir sistemas agênticos confiáveis para ambientes empresariais. Um modelo de linguagem é um preditor probabilístico do próximo token; uma empresa precisa de um sistema de confiança que faça o trabalho, respeite a política e falhe em segurança. O harness é tudo aquilo que se constrói *em torno* do modelo — memória, ferramentas, planejamento, orquestração, observabilidade, avaliação, governança e segurança — para fechar essa distância. Este capítulo define a disciplina, enuncia sua tese e enquadra o resto do manual.
+A Engenharia de Harness é a disciplina emergente responsável por construir sistemas agênticos confiáveis para ambientes empresariais. Um modelo de linguagem é um preditor probabilístico do próximo token; uma empresa precisa de um sistema de confiança que faça o trabalho, respeite a política e falhe em segurança. O harness é tudo aquilo que se constrói *em torno* do modelo — memória, ferramentas, planejamento, orquestração, observabilidade, avaliação, governança e segurança — para fechar essa distância. Este capítulo define a disciplina, enuncia sua tese e enquadra o resto do manual.
 
 ## Conceitos-chave
 - **Modelo:** o núcleo probabilístico (um LLM ou um modelo multimodal) que transforma um contexto numa distribuição sobre os próximos tokens. Poderoso, mas sem estado, sem governança e não determinista por padrão.
@@ -17,7 +17,7 @@ A Engenharia de Harness é a disciplina responsável por construir sistemas agê
 - **Ambiente empresarial:** um contexto com risco real: dados regulados, requisitos de auditoria, acordos de nível de serviço e adversários.
 
 ## Definição
-A **Engenharia de Harness** é a disciplina de engenharia que se ocupa da concepção, construção e operação dos sistemas que rodeiam modelos probabilísticos, de modo que o sistema agêntico resultante seja suficientemente confiável, observável, governável e seguro para uso empresarial. Onde a aprendizagem automática produz o *modelo*, a Engenharia de Harness produz o *sistema*. Sua unidade de trabalho não é um prompt nem uma matriz de pesos, mas o ciclo completo que converte um objetivo num resultado verificado e auditável.
+A **Engenharia de Harness** é a disciplina de engenharia emergente que se ocupa da concepção, construção e operação dos sistemas que rodeiam modelos probabilísticos, de modo que o sistema agêntico resultante seja suficientemente confiável, observável, governável e seguro para uso empresarial. Onde a aprendizagem automática produz o *modelo*, a Engenharia de Harness produz o *sistema*. Sua unidade de trabalho não é um prompt nem uma matriz de pesos, mas o ciclo completo que converte um objetivo num resultado verificado e auditável.
 
 ## Explicação detalhada
 A indústria passou de 2020 a 2023 a aprender que um modelo melhor é necessário mas não suficiente. As demonstrações que deslumbram com um prompt cuidado se desmoronam em produção perante entradas ambíguas, usuários hostis, dados desatualizados, falhas parciais de ferramentas e o simples fato de a mesma entrada poder dar duas saídas diferentes. A resposta não foi “um modelo mais inteligente”, mas *um sistema de engenharia em torno do modelo*. Esse sistema é o harness, e construí-lo bem é uma disciplina própria.
@@ -39,6 +39,9 @@ Não são extras opcionais: são a estrutura portante. A taxonomia de HRN-003 to
 
 **Por que uma disciplina nova?** Porque os modos de falha são novos. O software clássico é determinista: dada uma entrada, calcula a mesma saída, e se testa com asserções. Os sistemas agênticos são *estocásticos e autodirigidos*: a mesma entrada pode seguir caminhos diferentes, invocar ferramentas diferentes e chegar a conclusões diferentes (por vezes erradas). Não se chega à confiança à custa de asserções; é preciso *medir distribuições*, limitar a autoridade do modelo e instrumentar tudo. As competências exigidas — confiabilidade probabilística, concepção de avaliação, engenharia de contexto, concepção de contratos de ferramentas e segurança adversária — não encaixam de forma limpa nem na aprendizagem automática tradicional nem na engenharia de backend. Essa lacuna é a disciplina.
 
+
+**Porquê *emergente* e não simplesmente uma disciplina?** Porque a resposta honesta tem quatro partes e não são igualmente firmes. Que o mesmo modelo com harnesses diferentes dê resultados diferentes é um **fato observado**. Que a prática esteja a convergir nas mesmas preocupações — contexto, ferramentas, avaliação, observabilidade, controle — é uma **leitura do setor**. Que essas preocupações constituam uma disciplina própria é a **nossa posição**, sustentada com confiança média: não há acreditação, currículo padrão, corpo de conhecimento acordado nem organismo profissional, e dá-la por estabelecida afirmaria mais do que alguém pode demonstrar. Que o harness, e não o modelo, acabe por ser o ativo competitivo duradouro é uma **aposta**, sustentada com confiança baixa. Cada uma é publicada em separado, com os seus limites e a observação que a retiraria, como `HE-CLAIM-001` a `HE-CLAIM-004`: consultam-se com `get_claim`.
+
 **Para quem é.** A Engenharia de Harness é para as equipes responsáveis por colocar agentes em produção onde isso importa: engenharia de plataforma que constrói runtimes de agentes, engenharia de IA aplicada que entrega funcionalidades agênticas, as funções de segurança e governança que têm de dar o aval, e os arquitetos que respondem pelo conjunto. É explicitamente *enterprise-first*: as restrições que definem a disciplina — auditoria, regulação, SLA, adversários, escala — são precisamente as que a ferramentaria de amador ignora.
 
 **Uma opinião, dita sem rodeios:** o modelo é cada vez mais uma matéria-prima; o harness é o ativo de engenharia duradouro e o fosso defensivo. À medida que os modelos de fronteira convergem e se tornam intermutáveis, o valor diferenciador e defensável de um sistema de IA empresarial migra para o harness: sua arquitetura de memória, seu corpus de avaliação, seus controles de governança, sua observabilidade. Investir no harness é investir na parte que compõe.

package/content/harness/HRN-013-glossary.es.md

@@ -20,7 +20,7 @@ Los nombres ingleses de uso establecido en la industria (*harness*, *tool*, *spa
 - **Agente:** un sistema que usa un modelo de lenguaje dentro de un bucle para perseguir un objetivo, decidiendo qué acciones (llamadas a herramientas) tomar a partir de las observaciones hasta que se cumple una condición de parada.
 - **Sistema agéntico:** un sistema de software cuyo comportamiento lo dirigen uno o varios agentes, incluyendo todo el andamiaje circundante necesario para hacerlos fiables.
 - **Harness:** el andamiaje de ingeniería alrededor de un modelo —memoria, herramientas, planificación, orquestación, observabilidad, evaluación, gobernanza y seguridad— que convierte un modelo en bruto en un sistema agéntico fiable.
-- **Ingeniería de Harness:** la disciplina responsable de construir sistemas agénticos fiables para entornos empresariales, diseñando y operando el harness.
+- **Ingeniería de Harness:** la disciplina emergente responsable de construir sistemas agénticos fiables para entornos empresariales, diseñando y operando el harness.
 - **Modelo / LLM:** el gran modelo de lenguaje subyacente que razona y genera; dentro del harness se trata como un componente potente pero no determinista y manipulable.
 - **Gradiente de autonomía:** el espectro de modos de control, de totalmente autónomo a humano en el bucle, asignado por política a cada clase de acción.
 - **Radio de impacto (*blast radius*):** el daño máximo que puede causar una acción, o un agente comprometido; una magnitud clave que hay que acotar.

package/content/harness/HRN-013-glossary.md

@@ -35,7 +35,7 @@ The following are the canonical definitions of terms used throughout this corpus
 - **Agent:** a system that uses a language model in a loop to pursue a goal, deciding which actions (tool calls) to take based on observations until a stopping condition is met.
 - **Agentic system:** a software system whose behavior is driven by one or more agents, including all the surrounding scaffolding required to make them reliable.
 - **Harness:** the engineered scaffolding around a model — memory, tools, planning, orchestration, observability, evaluation, governance, and security — that turns a raw model into a reliable agentic system.
-- **Harness Engineering:** the discipline responsible for building reliable agentic systems for enterprise environments by designing and operating the harness.
+- **Harness Engineering:** the emerging discipline responsible for building reliable agentic systems for enterprise environments by designing and operating the harness.
 - **Model / LLM:** the underlying large language model that performs reasoning and generation; in the harness it is treated as a powerful but non-deterministic, manipulable component.
 - **Autonomy gradient:** the spectrum of control modes from fully autonomous to human-in-the-loop, assigned per action class by policy.
 - **Blast radius:** the maximum harm an action (or a compromised agent) can cause; a core quantity to bound.

package/content/harness/HRN-013-glossary.pt.md

@@ -20,7 +20,7 @@ Os nomes ingleses de uso estabelecido na indústria (*harness*, *tool*, *span*,
 - **Agente:** um sistema que usa um modelo de linguagem dentro de um ciclo para perseguir um objetivo, decidindo que ações (chamadas a ferramentas) tomar a partir das observações até se cumprir uma condição de paragem.
 - **Sistema agêntico:** um sistema de software cujo comportamento é conduzido por um ou vários agentes, incluindo todo o andaime circundante necessário para os tornar confiáveis.
 - **Harness:** o andaime de engenharia em torno de um modelo — memória, ferramentas, planejamento, orquestração, observabilidade, avaliação, governança e segurança — que converte um modelo em bruto num sistema agêntico confiável.
-- **Engenharia de Harness:** a disciplina responsável por construir sistemas agênticos confiáveis para ambientes empresariais, desenhando e operando o harness.
+- **Engenharia de Harness:** a disciplina emergente responsável por construir sistemas agênticos confiáveis para ambientes empresariais, desenhando e operando o harness.
 - **Modelo / LLM:** o grande modelo de linguagem subjacente que raciocina e gera; dentro do harness é tratado como um componente poderoso mas não determinista e manipulável.
 - **Gradiente de autonomia:** o espectro de modos de controle, de totalmente autônomo a humano no ciclo, atribuído por política a cada classe de ação.
 - **Raio de impacto (*blast radius*):** o dano máximo que uma ação, ou um agente comprometido, pode causar; uma grandeza central a limitar.

package/content/knowledge/foundation-models.json

@@ -4,7 +4,8 @@
   "updated": "2026-06-21",
   "version": "1.0",
   "featured": true,
-  "related": ["fine-tuning", "embeddings", "agentic-ai", "harness-engineering"],
+  "related": ["fine-tuning", "embeddings", "agentic-ai", "harness-engineering",
+    "reasoning-models"],
   "references": [
     { "title": "Bommasani et al. — On the Opportunities and Risks of Foundation Models (2021)", "url": "https://arxiv.org/abs/2108.07258" },
     { "title": "Vaswani et al. — Attention Is All You Need (2017)", "url": "https://arxiv.org/abs/1706.03762" }