▐▛███▜▌ Claude Code v2.1.119 ▝▜█████▛▘ Sonnet 4.6 · Claude Max ▘▘ ▝▝ /Users/Akasha/Development/ontoref ❯ puedes sacar el texto de este contenido ?

In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published “The New New Product Development Game” in the Harvard Business Review, describing how Honda, Canon, and Fuji-Xerox organized teams to build copiers and automobiles.1 Jeff Sutherland read that article, combined it with lean manufacturing principles and object oriented programming, and in 1993 adapted it for software development at Easel Corporation. Ken Schwaber formalized the method at the OOPSLA conference in 1995.2 By 2001, seventeen software developers gathered at a ski lodge in Snowbird, Utah, and signed the Agile Manifesto, declaring that they were “uncovering better ways of developing software.”3 Not knowledge or meaning. A manufacturing framework for software.

Read full story

⏺ Here's the plain text extracted from the HTML: --- In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published "The New New Product Development Game" in the Harvard Business Review, describing how Honda, Canon, and Fuji-Xerox organized teams to build copiers and automobiles. Jeff Sutherland read that article, combined it with lean manufacturing principles and object oriented programming, and in 1993 adapted it for software development at Easel Corporation. Ken Schwaber formalized the method at the OOPSLA conference in 1995. By 2001, seventeen software developers gathered at a ski lodge in Snowbird, Utah, and signed the Agile Manifesto, declaring that they were "uncovering better ways of developing software." Not knowledge or meaning. A manufacturing framework for software. The Agile Manifesto's own language is explicit about its scope, yet the industry has applied Agile methodology to virtually everything in a technological environment — including knowledge work, semantic systems and now artificial intelligence. And within the same breath, organizations and experts regale the industry with talk of innovation and the emergence of a new paradigm in ways of working. Yet those ways of working are locked inside of Agile methodologies and Scrum, designed for the factory floor and the codebase — not for the messy, recursive, deeply human work of making meaning out of complexity. Scrum Is a Manufacturing Schedule Let's return to the Takeuchi and Nonaka paper, where the title—"The New New Product Development Game" describes how product teams at Japanese firms developed physical goods such as the FX-3500 copier and the Honda City car. They draw on the rugby metaphor because the team "tries to go the distance as a unit, passing the ball back and forth." The unit of delivery is a working prototype of a material artifact. The feedback loop is a machine that works or fails. Sutherland's 2014 book, Scrum: The Art of Doing Twice the Work in Half the Time, reinforces this with military and manufacturing case studies such as the F-86 fighter production and Toyota. Sutherland's book rebuilds the argument with the same assumption—that the thing being built has discrete, inspectable, testable parts that, when finished, are finished. The 2020 Scrum Guide defines the Increment as "a concrete stepping stone toward the Product Goal," one that is "additive to all prior Increments and thoroughly verified, ensuring that all Increments work together." These words are sensible if you are building a mobile application, with a login screen and a settings page. But for knowledge systems, these words are destructive, because the components of a semantic architecture are not additive in the way Scrum dictates. A controlled vocabulary is not a subcomponent of a taxonomy the way a login screen is a subcomponent of an app. A taxonomy without disciplined, vocabulary control as its underpinnings does not function well, if at all. You cannot ship half a taxonomy and call it an Increment. You see, Scrum assumes tame problems that can be time-boxed, estimated with planning poker, decomposed into user stories, tracked on a velocity chart and declared done against a checklist. If only knowledge were this tame. Knowledge organization is anything but tame. More than fifty-years-old, in 1973 Horst Rittel and Melvin Webber warned that applying the engineering paradigm uniformly to all problems was "bound to fail." And yet here we are, applying a manufacturing schedule and methodologies to knowledge, expecting that knowledge will fit into the confines of old ways of working — an artifact of the Third Industrial Revolution imposed on the demands of the Fourth. In 2016, Klaus Schwab wrote about this historical pattern. The First Industrial Revolution, beginning around 1760, gave us steam and mechanical production. The Second, in the late nineteenth century, gave us electricity and the assembly line — the world that produced Toyota, lean manufacturing, and the production logic that Scrum still carries as its core ethos. The Third, beginning in the 1960s, gave us semiconductors, mainframe computing, and eventually the internet — the world in which Agile was born, by software developers, for software development. The Fourth Industrial Revolution, Schwab argued, is fundamentally different, in kind, as it is defined by the fusion of artificial intelligence, cyber-physical systems and knowledge technologies that blur the boundaries between the physical, digital and biological worlds. The problems of this era are not necessarily engineering problems with stable requirements. We are wrestling with problems such as how to ground machine intelligence in meaning, how to organize evolving knowledge and how to build systems that can explain themselves. These are wicked problems that demand new epistemologies and frameworks for problem solving. Agile may have been the right methodology for the Third Industrial Revolution but we are no longer in the Third Industrial Revolution. The frameworks have not caught up, and the cost of that lag is exacerbated every time an organization forces Third Industrial Revolution principles applied to Fourth Industrial Revolution work. In other words, this is not a product problem or a platform problem—it is learning to embrace new ways of working. This is an infrastructure problem that is governed by epistemology—a fundamental philosophy pertaining to knowledge. Why Knowledge Cannot Be Sprinted An ontology is, per Thomas Gruber's foundational definition, "a specification of a conceptualization." A conceptualization is a whole, not parts of a whole. Specifying half of it produces logical incoherence, not a minimally viable product. For example, ANSI/NISO Z39.19, the standard for constructing controlled vocabularies, requires resolving synonymy, homonymy and scope before terms enter production, because any inconsistency propagates downstream into every subsequent use. SKOS, the W3C standard for encoding knowledge organization systems, requires that hierarchical relationships form coherent structures with transitive closure and OWL 2 requires that class axioms be satisfiable. These are preconditions, necessary for logical systems to reason and express meaning. In practice, I have watched organizations attempt Agile delivery of knowledge systems in two patterns and neither ends well. In the first, the team holds stand-ups, ceremonies and retrospectives. The taxonomist brings tickets and adds fifteen terms to the product vocabulary. Tickets close and a velocity chart goes up. Nothing is integrated, because integration is the hard part and integration does not fit into two weeks so that goes to the backlog. Six months later, the vocabulary is a collection of inconsistently scoped terms, the ontology has orphan classes and the knowledge graph — if it exists — cannot reliably answer queries. But the burndown chart is immaculate and leadership is blindly satisfied because boxes were checked. In the second pattern, the team borrows from other methodologies while still calling it Agile. The taxonomist conducts multi-week domain analysis and stakeholder interviews — that is ethnography. She does card sorting and concept modeling — that is design research. She iterates with subject matter experts — that is participatory design. She ships, eventually, a coherent model. The sprint cadence was irrelevant to the work. Martin Fowler named this phenomenon in his 2018 keynote: "faux-agile" — the Agile Industrial Complex. Ron Jeffries, another original signatory of the Agile Manifesto, told developers the same year, 2018, to abandon the word entirely. Dave Thomas declared in 2014 that "Agile" had become "a magnet for anyone with points to espouse, hours to bill or products to sell." When three of the seventeen authors of a framework say it has been hollowed out, one has to wonder if Agile is appropriate for all technology work and if it is time to revisit ways of working. Innovation Does Not Fit in a Backlog The deeper issue is that Agile and Scrum were never designed to inspire or foster innovation. They were designed to deliver known requirements with increasing efficiency. The Scrum Guide's entire apparatus — product backlog, sprint planning, Definition of Done — presupposes that the problem has been formulated by a product owner who can write it in a user story. But knowledge work, like design, is wicked. Rittel and Webber's first property of a wicked problem is that "There is no definitive formulation." The second property states that there is no stopping rule. And the fifth property illuminates that every solution is a "one-shot operation" because there is no opportunity to learn by trial-and-error without consequence. Given the nature of wicked problems, it would seem that Agile is ill fitted for wicked problems. And for that matter, ill fitted for the dynamic nature of knowledge, where knowledge infrastructures are never one-shot operations, necessitate stopping rules and without a doubt defies definitive formulations. Therefore, knowledge organization in an enterprise domain is wicked in exactly this sense. The problem of how to represent "customer" in a telecommunications company's semantic model has no pre-existing correct answer. Its formulation depends on who is doing what with the representation, and that changes as you build. The scope of the vocabulary shifts as you interview stakeholders. The taxonomy reorganizes as you encounter edge cases. The ontology's axioms tighten or loosen as the reasoner surfaces contradictions. Don't be mistaken—this does not bend to the Agile principle of welcoming changing requirements, as the requirements are constituted through the work. The problem is under construction, often evolving, during the solving. Organizations that manage all work through Scrum are, in effect, optimizing for predictability in domains that demand exploration. The results resist innovation and take on the appearance of productivity. Velocity charts rise while the underlying intellectual architecture is flattened into bit sized deployments, uncoupled from the continuum that is knowledge. Design Thinking Belongs in the Swamp Donald Schön drew the distinction that "In the varied topography of professional practice, there is a high, hard ground where practitioners can make effective use of research-based theory and technique, and there is a swampy lowland where situations are confusing 'messes' incapable of technical solution." Agile lives on the high ground while knowledge work lives in the swamp. Schön's term for how competent practitioners navigate the swamp was "reflection-in-action" — the iterative, tacit recalibration that happens while the work is happening. Design thinking, in the lineage of Herbert Simon, Richard Buchanan and Schön, is the methodology of the swamp. It assumes the problem is under construction. Its five phases — empathize, define, ideate, prototype, test — are not a linear pipeline but a recursive, iterative process that expects the definition of the problem to change as understanding deepens. Research in the Handbook of Human-Centered Artificial Intelligence confirms this alignment—integrating design thinking into AI development makes systems more user-focused, iterative and impactful, emphasizing data governance, transparency, explainability and bias mitigation. Carnegie Mellon University's Tepper School of Business now teaches a dedicated program on design thinking with AI, arguing that the combination addresses "complex, systemic problems" that linear frameworks cannot manage successfully. IBM's enterprise design thinking practice, developed over two decades, has been applied across client engagements precisely it keeps human experience at the center, while technology evolves underneath — design thinking is "timeless," while technology is "timestamped." A 2026 study in Scientific Reports examined the relationship between higher order thinking, generative AI chatbot use and engineering creativity, finding that higher order thinking had significantly greater importance for creative outcomes than AI tool use alone — reinforcing that cognitive depth, not tool velocity, drives innovation. Research in the Proceedings of the Design Society further argues that generative AI is shifting the designer's role from executor to paradigm-setter, making design thinking more essential as AI handles production tasks while humans must guide framing, ethics and meaning. To be clear, these frameworks are not different flavors of the same methodology. Scrum and design thinking represent totally different epistemologies. Scrum assumes the problem was handed to you while design thinking assumes the problem must be found and wrestled with. Is AI a Knowledge Tool? This brings us to the question the industry avoids and I, for one, have been itching to ask. Is AI a knowledge tool? How do you classify it? A large language model generates plausible sequences of text. Returning to the Bender, Gebru, McMillan-Major, and Mitchell paper mentioned earlier, the authors defined a language model as a system for stitching together linguistic forms according to probabilistic patterns, "without any reference to meaning." Without reference to meaning, as LLMs out-of-the-box are absent of external grounding. They optimize for plausibility, not truth and therefore as a standalone, can be best categorized as an information-processing tool. It becomes a knowledge tool only when grounded in a semantic layer — controlled vocabularies, taxonomies, ontologies, knowledge graphs — that provides reference and provenance. The industry's own corrective measures and associated marketplace confirms this as fact. Retrieval-augmented generation, knowledge graphs for LLMs and what recent discourse calls "context engineering" are, underneath the packaging, the semantic infrastructure that should have been built first. But it was bolted on after the fact to prevent hallucination that was pretty much guaranteed, the moment the model was deployed without one. The RAG paper from 2020 called out this problem, identifying that parametric memory is opaque and cannot be updated and that retrieval from structured sources is how provenance is captured and encoded. But it seems the industry has a memory problem or it was too early for most to hear the message. Ironically, provenance is a core element of knowledge management and ontology work, as provenance is a principled tenant of the discipline and problem space. Without provenance, knowledge cannot exist. Organizations are only now discovering they need it, because their generative systems cannot explain themselves. Call it lineage, call it traces. But if you are building for knowledge, call it provenance, as provenance includes traces, lineage, citations, the temporal and the spatial. So if generative AI is an information processing tool, I posture that for AI to become a knowledge tool, there must be provenance and descriptive logic. And to be frank, nobody sprints their way into provenance as it is architected and sustained. Knowledge Is a Spiral, Not a Sprint The irony does not escape the moment. The same Nonaka who co-authored the 1986 paper that inspired Scrum, went on to develop the SECI model of knowledge creation in 1995, describing knowledge as a spiral between tacit and explicit forms, moving through socialization, externalization, combination and internalization. The spiral does not have an end, as is true with spirals, emblematic of life. Each rotation creates new knowledge that becomes the substrate for the next rotation. There is no Definition of Done because the definition of what is being done is itself being constructed. Scrum took the team structure from Nonaka's first paper and discarded his next decade of work because it did not fit neatly with Scrum. The mechanisms of knowledge work, as Nonaka spent a decade arguing, are metaphor, tacit skill, apprenticeship, shared space and the patient conversion of hunches into models and models back into practice. The Ontology Pipeline™ mirrors this spiral. You start with a controlled vocabulary — a disciplined process involving agreements, as to what terms mean. You mature it into a taxonomy by introducing hierarchy, structuring terms into parent-child relations. Thereafter, the taxonomy is matured into a thesaurus by adding associative relationships and synonymy, encoded in SKOS. The thesaurus is baseline work from which an ontology is developed, adding formal semantics using OWL and RDF. You architect a knowledge graph, assembling components to include the knowledge assets developed through the Ontology Pipeline™ iterative framework. Each stage prepares the ground for the next and stages cannot be skipped or bypassed. You cannot ship the knowledge graph without an ontology, and the ontology must be logically consistent and coherent to make sense of data. A knowledge graph without a vocabulary control risks becoming a confident liar or failing to work with natural language. Because knowledge assets are dimensional interconnected, knowledge is indeed a spiral, unable to be contained by manufacturing logic. The Pattern and the Cure Organizations budget for platforms — Confluence, SharePoint, LLM subscriptions, vector databases, a RAG vendor. But they do not budget for descriptive logic and knowledge, perhaps because the problem is not solved by a single tool and is seemingly too amorphous in an Agile, data centric world. The controlled vocabulary is cut unless it delivers value for the database. Often, the taxonomy is cut because it does not demo well and its value sits in the plumbing, delivering its punch over time. The result is an ever-growing pile of documents with a chatbot stapled to the front, confidently answering questions in the voice of a system that has no reference for any of the terms sprinkled throughout the documents. Then the system hallucinates. It contradicts itself across sessions. It surfaces outdated policy as current and surfaces private outlook messages from deactivated employees. I have seen this IRL more times than I can count. And the optics are worse when a vendor tool is responsible for revealing private chats and email transactions. Usually the executive sponsor asks why the investment has not worked, ignoring the evidence of faux pas such as the surfacing of private communications. All in a days work, when burndown charts and velocity set the precedence for ways of working and reward systems. Executives ignore the fact that the system was never grounded. It was never grounded because grounding requires the slow, expensive, disciplined work of knowledge organization — work that does not fit into a sprint, does not demo well and fails to produce a velocity chart. The organization chooses to bypass investment in the descriptive knowledge apparatus because the lines are too blurry to clearly define according to Agile speak. Because knowledge is infrastructure, not a product or a platform. Knowledge is the gas in the tank, the fuel for meaning, the material that justifies logical reasoning. Design thinking gives that knowledge work a home. It is comfortable with ambiguity. It treats problem discovery as an equal to problem solving. It certainly does not demand a shippable increment every fourteen days. Instead, design thinking demands that you understand what you are building before you build it — and that you keep revising that understanding as the work proceeds. Library and information science, with over a century of standards for knowledge organization, provides the methods while design thinking provides the epistemology. Together, they offer what Agile never could—a framework suited to the nature of knowledge itself. A two-week sprint to deliver what? If you are building knowledge systems, two weeks will get you nothing coherent. Knowledge is not built fast and broken into shape. It is built carefully, with provenance, governance and patience. Knowledge is not a product to be manufactured and no—you cannot buy off-the-shelf knowledge that perfectly matches a domain or organization. Knowledge is nuanced, specific to each organization, domain and person. In the spirit of VC-speak, knowledge is the moat, and that moat is not Agile. --- By Jessica Talisman — Intentional Arrangement (Substack) ✻ Brewed for 2m 25s ❯ puedes generar una traducción precisa y elegante del contenido al español ⏺ --- En 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaron "The New New Product Development Game" en Harvard Business Review, describiendo cómo Honda, Canon y Fuji-Xerox organizaban sus equipos para fabricar copiadoras y automóviles. Jeff Sutherland leyó ese artículo, lo combinó con los principios de manufactura lean y la programación orientada a objetos, y en 1993 lo adaptó al desarrollo de software en Easel Corporation. Ken Schwaber formalizó el método en la conferencia OOPSLA de 1995. En 2001, diecisiete desarrolladores de software se reunieron en un albergue de esquí en Snowbird, Utah, y firmaron el Manifiesto Ágil, declarando que estaban "descubriendo mejores maneras de desarrollar software." No conocimiento ni significado. Un marco de manufactura aplicado al software. El propio lenguaje del Manifiesto Ágil es explícito sobre su alcance, y sin embargo la industria ha aplicado la metodología ágil a prácticamente todo lo que existe en un entorno tecnológico — incluyendo el trabajo del conocimiento, los sistemas semánticos y ahora la inteligencia artificial. Y en el mismo aliento, organizaciones y expertos colman la industria con discursos sobre innovación y el surgimiento de un nuevo paradigma en las formas de trabajo. Sin embargo, esas formas de trabajo permanecen encerradas dentro de las metodologías ágiles y Scrum, diseñadas para la línea de producción y la base de código — no para el trabajo profundamente humano, recursivo y desordenado de construir significado a partir de la complejidad. Scrum es un calendario de manufactura Volvamos al artículo de Takeuchi y Nonaka, cuyo título — "The New New Product Development Game" — describe cómo los equipos de producto en empresas japonesas desarrollaban bienes físicos como la copiadora FX-3500 y el Honda City. Los autores recurren a la metáfora del rugby porque el equipo "intenta recorrer la distancia como una unidad, pasándose el balón de un lado al otro." La unidad de entrega es un prototipo funcional de un artefacto material. El ciclo de retroalimentación es una máquina que funciona o falla. El libro de Sutherland de 2014, Scrum: The Art of Doing Twice the Work in Half the Time, refuerza esto con casos de estudio militares y de manufactura como la producción del caza F-86 y Toyota. El libro reconstruye el argumento sobre la misma premisa: que aquello que se construye tiene partes discretas, inspeccionables y verificables que, una vez terminadas, están terminadas. La Guía Scrum de 2020 define el Incremento como "un peldaño concreto hacia el Objetivo del Producto", uno que es "aditivo respecto a todos los Incrementos anteriores y rigurosamente verificado, asegurando que todos los Incrementos funcionen en conjunto." Estas palabras tienen sentido si se está construyendo una aplicación móvil, con una pantalla de inicio de sesión y una página de configuración. Pero para los sistemas de conocimiento, estas palabras son destructivas, porque los componentes de una arquitectura semántica no son aditivos de la manera en que Scrum prescribe. Un vocabulario controlado no es un subcomponente de una taxonomía del mismo modo en que una pantalla de inicio de sesión lo es de una aplicación. Una taxonomía sin un control de vocabulario disciplinado como fundamento no funciona bien, o directamente no funciona. No se puede entregar media taxonomía y llamarla un Incremento. Scrum asume problemas dóciles que pueden enmarcarse en el tiempo, estimarse con planning poker, descomponerse en historias de usuario, rastrearse en un gráfico de velocidad y declararse resueltos frente a una lista de verificación. Si tan solo el conocimiento fuera así de dócil. La organización del conocimiento está muy lejos de serlo. Con más de cincuenta años de antigüedad, en 1973 Horst Rittel y Melvin Webber advirtieron que aplicar el paradigma de la ingeniería de manera uniforme a todos los problemas estaba "condenado al fracaso." Y sin embargo aquí estamos, aplicando un calendario de manufactura y sus metodologías al conocimiento, esperando que el conocimiento quepa en los confines de viejas formas de trabajar — un artefacto de la Tercera Revolución Industrial impuesto sobre las exigencias de la Cuarta. En otras palabras, esto no es un problema de producto ni de plataforma — es el desafío de aprender a abrazar nuevas formas de trabajar. Es un problema de infraestructura gobernado por la epistemología: una filosofía fundamental sobre el conocimiento. Por qué el conocimiento no puede ejecutarse en sprints Una ontología es, según la definición fundacional de Thomas Gruber, "una especificación de una conceptualización." Una conceptualización es un todo, no partes de un todo. Especificar la mitad produce incoherencia lógica, no un producto mínimamente viable. Por ejemplo, la norma ANSI/NISO Z39.19 para la construcción de vocabularios controlados exige resolver la sinonimia, la homonimia y el alcance antes de que los términos entren en producción, porque cualquier inconsistencia se propaga hacia abajo en cada uso posterior. SKOS, el estándar del W3C para codificar sistemas de organización del conocimiento, requiere que las relaciones jerárquicas formen estructuras coherentes con cierre transitivo, y OWL 2 exige que los axiomas de clase sean satisfacibles. Estas son precondiciones necesarias para que los sistemas lógicos razonen y expresen significado. En la práctica, he observado organizaciones intentando entregar sistemas de conocimiento de forma ágil en dos patrones, y ninguno termina bien. En el primero, el equipo celebra stand-ups, ceremonias y retrospectivas. El taxonomista trae tickets y añade quince términos al vocabulario del producto. Los tickets se cierran y el gráfico de velocidad sube. Nada se integra, porque la integración es la parte difícil y no cabe en dos semanas, de modo que va al backlog. Seis meses después, el vocabulario es una colección de términos con alcances inconsistentes, la ontología tiene clases huérfanas y el grafo de conocimiento — si existe — no puede responder consultas de manera confiable. Pero el burndown chart es impecable y el liderazgo está ciegamente satisfecho porque las casillas fueron marcadas. En el segundo patrón, el equipo toma prestado de otras metodologías sin dejar de llamarlo ágil. La taxonomista conduce análisis de dominio y entrevistas con partes interesadas durante varias semanas — eso es etnografía. Realiza card sorting y modelado conceptual — eso es investigación en diseño. Itera con expertos en la materia — eso es diseño participativo. Finalmente entrega un modelo coherente. El ritmo del sprint fue irrelevante para el trabajo. Martin Fowler denominó este fenómeno en su conferencia magistral de 2018: "faux-agile" — el Complejo Industrial Ágil. Ron Jeffries, otro signatario original del Manifiesto Ágil, les dijo a los desarrolladores ese mismo año, 2018, que abandonaran la palabra por completo. Dave Thomas declaró en 2014 que "Ágil" se había convertido en "un imán para cualquiera con puntos que exponer, horas que facturar o productos que vender." Cuando tres de los diecisiete autores de un marco dicen que ha sido vaciado de contenido, uno tiene que preguntarse si Agile es apropiado para todo el trabajo tecnológico y si ha llegado el momento de revisar las formas de trabajar. La innovación no cabe en un backlog El problema más profundo es que Agile y Scrum nunca fueron diseñados para inspirar o fomentar la innovación. Fueron diseñados para entregar requisitos conocidos con eficiencia creciente. Todo el aparato de la Guía Scrum — product backlog, sprint planning, Definición de Hecho — presupone que el problema ha sido formulado por un product owner capaz de escribirlo en una historia de usuario. Pero el trabajo del conocimiento, como el diseño, es rebelde. La primera propiedad de un problema retorcido según Rittel y Webber es que "No existe una formulación definitiva." La segunda propiedad establece que no hay regla de parada. Y la quinta propiedad ilumina que cada solución es una "operación de un solo disparo" porque no hay oportunidad de aprender por ensayo y error sin consecuencias. Dada la naturaleza de los problemas retorcidos, parecería que Agile está mal equipado para enfrentarlos. Y por la misma razón, mal equipado para la naturaleza dinámica del conocimiento, donde las infraestructuras de conocimiento nunca son operaciones de un solo disparo, requieren reglas de parada y desafían sin lugar a dudas las formulaciones definitivas. Por lo tanto, la organización del conocimiento en un dominio empresarial es retorcida exactamente en este sentido. El problema de cómo representar "cliente" en el modelo semántico de una empresa de telecomunicaciones no tiene una respuesta correcta preexistente. Su formulación depende de quién hace qué con esa representación, y eso cambia a medida que se construye. El alcance del vocabulario se desplaza conforme se entrevista a las partes interesadas. La taxonomía se reorganiza al encontrar casos límite. Los axiomas de la ontología se tensan o aflojan cuando el razonador descubre contradicciones. No hay que equivocarse — esto no se pliega al principio ágil de bienvenida a los requisitos cambiantes, porque los requisitos se constituyen a través del trabajo. El problema está en construcción, evolucionando frecuentemente, durante su resolución. Las organizaciones que gestionan todo el trabajo a través de Scrum están, en efecto, optimizando para la previsibilidad en dominios que exigen exploración. Los resultados inhiben la innovación y adoptan la apariencia de productividad. Los gráficos de velocidad suben mientras la arquitectura intelectual subyacente se aplana en entregas fragmentadas, desconectadas del continuo que es el conocimiento. El pensamiento de diseño pertenece al pantano Donald Schön trazó la distinción de que "En la variada topografía de la práctica profesional, hay una meseta alta y firme donde los profesionales pueden hacer uso efectivo de la teoría y la técnica basadas en la investigación, y hay una tierras bajas pantanosas donde las situaciones son 'enredos' confusos incapaces de solución técnica." Agile vive en la meseta mientras que el trabajo del conocimiento vive en el pantano. El término de Schön para describir cómo los profesionales competentes navegan el pantano fue "reflexión-en-acción" — la recalibración iterativa y tácita que ocurre mientras el trabajo transcurre. El pensamiento de diseño, en el linaje de Herbert Simon, Richard Buchanan y Schön, es la metodología del pantano. Asume que el problema está en construcción. Sus cinco fases — empatizar, definir, idear, prototipar, probar — no son un flujo lineal sino un proceso recursivo e iterativo que espera que la definición del problema cambie a medida que la comprensión se profundiza. La investigación en el Handbook of Human-Centered Artificial Intelligence confirma esta alineación — integrar el pensamiento de diseño en el desarrollo de IA hace que los sistemas sean más centrados en el usuario, iterativos e impactantes, enfatizando la gobernanza de datos, la transparencia, la explicabilidad y la mitigación del sesgo. La Tepper School of Business de Carnegie Mellon University imparte ahora un programa dedicado a pensamiento de diseño con IA, argumentando que la combinación aborda "problemas complejos y sistémicos" que los marcos lineales no pueden gestionar con éxito. La práctica de diseño empresarial de IBM, desarrollada a lo largo de dos décadas, se ha aplicado en compromisos con clientes precisamente porque mantiene la experiencia humana en el centro mientras la tecnología evoluciona por debajo — el pensamiento de diseño es "atemporal", mientras que la tecnología está "fechada". Un estudio de 2026 en Scientific Reports examinó la relación entre el pensamiento de orden superior, el uso de chatbots de IA generativa y la creatividad en ingeniería, encontrando que el pensamiento de orden superior tenía una importancia significativamente mayor para los resultados creativos que el uso de herramientas de IA por sí solo — reforzando que la profundidad cognitiva, no la velocidad de las herramientas, impulsa la innovación. La investigación en las Proceedings of the Design Society argumenta además que la IA generativa está desplazando el rol del diseñador de ejecutor a configurador de paradigmas, haciendo que el pensamiento de diseño sea más esencial a medida que la IA gestiona las tareas de producción mientras los humanos deben guiar el encuadre, la ética y el significado. Para ser claros, estos marcos no son distintos sabores de la misma metodología. Scrum y el pensamiento de diseño representan epistemologías completamente diferentes. Scrum asume que el problema te fue entregado, mientras que el pensamiento de diseño asume que el problema debe encontrarse y lidiarse con él. ¿Es la IA una herramienta de conocimiento? Esto nos lleva a la pregunta que la industria evita y que yo, por mi parte, llevo tiempo deseando formular. ¿Es la IA una herramienta de conocimiento? ¿Cómo se clasifica? Un modelo de lenguaje de gran escala genera secuencias plausibles de texto. Volviendo al artículo de Bender, Gebru, McMillan-Major y Mitchell mencionado anteriormente, los autores definieron un modelo de lenguaje como un sistema para ensamblar formas lingüísticas según patrones probabilísticos, "sin ninguna referencia al significado." Sin referencia al significado, dado que los LLMs sin configuración adicional carecen de anclaje externo. Optimizan para la plausibilidad, no para la verdad, y por lo tanto, como sistemas autónomos, pueden clasificarse mejor como herramientas de procesamiento de información. Se convierte en una herramienta de conocimiento únicamente cuando se ancla en una capa semántica — vocabularios controlados, taxonomías, ontologías, grafos de conocimiento — que proporciona referencia y procedencia. Las propias medidas correctivas de la industria y el mercado asociado confirman esto como un hecho. La generación aumentada por recuperación, los grafos de conocimiento para LLMs y lo que el discurso reciente denomina "ingeniería de contexto" son, bajo el empaquetado, la infraestructura semántica que debería haberse construido primero. Pero fue añadida a posteriori para prevenir alucinaciones que estaban prácticamente garantizadas desde el momento en que el modelo fue desplegado sin ella. El artículo sobre RAG de 2020 señaló este problema, identificando que la memoria paramétrica es opaca y no puede actualizarse, y que la recuperación desde fuentes estructuradas es el modo en que la procedencia se captura y codifica. Pero parece que la industria tiene un problema de memoria, o el mensaje llegó demasiado pronto para que la mayoría pudiera escucharlo. Irónicamente, la procedencia es un elemento central de la gestión del conocimiento y el trabajo ontológico, pues constituye un principio fundacional de la disciplina y su espacio de problemas. Sin procedencia, el conocimiento no puede existir. Las organizaciones están descubriendo ahora que la necesitan, porque sus sistemas generativos no pueden explicarse a sí mismos. Llámalo linaje, llámalo trazabilidad. Pero si construyes para el conocimiento, llámalo procedencia, porque la procedencia abarca trazas, linaje, citaciones, lo temporal y lo espacial. De modo que si la IA generativa es una herramienta de procesamiento de información, sostengo que para que la IA se convierta en una herramienta de conocimiento debe haber procedencia y lógica descriptiva. Y para ser francos, nadie llega a la procedencia haciendo sprints — esta se arquitecta y se sostiene. El conocimiento es una espiral, no un sprint La ironía no pasa desapercibida en este momento. El mismo Nonaka que coescribió el artículo de 1986 que inspiró Scrum, desarrolló el modelo SECI de creación de conocimiento en 1995, describiendo el conocimiento como una espiral entre formas tácitas y explícitas, que avanza a través de la socialización, la externalización, la combinación y la internalización. La espiral no tiene fin, como es propio de las espirales, emblema de la vida. Cada rotación crea nuevo conocimiento que se convierte en el sustrato de la siguiente. No existe una Definición de Hecho porque la definición de lo que se está haciendo está siendo construida en sí misma. Scrum tomó la estructura de equipo del primer artículo de Nonaka y descartó su siguiente década de trabajo porque no encajaba limpiamente en Scrum. Los mecanismos del trabajo del conocimiento, como Nonaka argumentó durante una década, son la metáfora, la habilidad tácita, el aprendizaje por proximidad, el espacio compartido y la paciente conversión de intuiciones en modelos y de modelos de vuelta en práctica. El Ontology Pipeline™ refleja esta espiral. Se comienza con un vocabulario controlado — un proceso disciplinado que implica acuerdos sobre lo que significan los términos. Se madura hacia una taxonomía introduciendo jerarquía y estructurando los términos en relaciones padre-hijo. Posteriormente, la taxonomía se madura hacia un tesauro añadiendo relaciones asociativas y sinonimia, codificadas en SKOS. El tesauro es el trabajo base a partir del cual se desarrolla una ontología, incorporando semántica formal mediante OWL y RDF. Se arquitecta un grafo de conocimiento, ensamblando componentes que incluyen los activos de conocimiento desarrollados a través del marco iterativo del Ontology Pipeline™. Cada etapa prepara el terreno para la siguiente y las etapas no pueden saltarse ni eludirse. No se puede entregar el grafo de conocimiento sin una ontología, y la ontología debe ser lógicamente consistente y coherente para dotar de sentido a los datos. Un grafo de conocimiento sin control de vocabulario arriesga convertirse en un mentiroso convincente o en fallar al trabajar con lenguaje natural. Porque los activos de conocimiento son dimensionalmente interdependientes, el conocimiento es efectivamente una espiral, incapaz de ser contenida por la lógica de la manufactura. El patrón y el remedio Las organizaciones presupuestan para plataformas — Confluence, SharePoint, suscripciones a LLMs, bases de datos vectoriales, un proveedor de RAG. Pero no presupuestan para la lógica descriptiva y el conocimiento, quizás porque el problema no se resuelve con una sola herramienta y resulta demasiado amorfo en un mundo centrado en los datos y en Agile. El vocabulario controlado se recorta a menos que genere valor inmediato para la base de datos. Con frecuencia, la taxonomía se recorta porque no hace una buena demostración y su valor reside en la fontanería, entregando su impacto con el tiempo. El resultado es una pila siempre creciente de documentos con un chatbot pegado en la entrada, respondiendo preguntas con confianza en la voz de un sistema que no tiene referencia para ninguno de los términos dispersos a lo largo de los documentos. Entonces el sistema alucina. Se contradice a sí mismo entre sesiones. Presenta como vigente una política desactualizada y muestra mensajes privados de Outlook de empleados cuyas cuentas fueron desactivadas. He visto esto en la vida real más veces de las que puedo contar. Y la percepción es peor cuando una herramienta de proveedor es responsable de revelar chats y transacciones de correo privadas. Habitualmente, el patrocinador ejecutivo pregunta por qué la inversión no ha funcionado, ignorando la evidencia de los errores, como la exposición de comunicaciones privadas. Trabajo de un día cualquiera, cuando los burndown charts y la velocidad marcan el precedente de las formas de trabajar y los sistemas de recompensa. Los ejecutivos ignoran el hecho de que el sistema nunca fue anclado en el conocimiento. Nunca lo fue porque anclar requiere el trabajo lento, costoso y disciplinado de la organización del conocimiento — trabajo que no cabe en un sprint, que no hace una buena demostración y que no genera un gráfico de velocidad. La organización elige eludir la inversión en el aparato de conocimiento descriptivo porque las líneas son demasiado difusas para definirse claramente según el vocabulario de Agile. Porque el conocimiento es infraestructura, no un producto ni una plataforma. El conocimiento es la gasolina del depósito, el combustible del significado, el material que justifica el razonamiento lógico. El pensamiento de diseño le da al trabajo del conocimiento un hogar. Es cómodo con la ambigüedad. Trata el descubrimiento del problema como un igual a la resolución del problema. Desde luego no exige un incremento entregable cada catorce días. En cambio, el pensamiento de diseño exige que entiendas lo que estás construyendo antes de construirlo — y que sigas revisando esa comprensión a medida que el trabajo avanza. La biblioteconomía y la ciencia de la información, con más de un siglo de estándares para la organización del conocimiento, proporcionan los métodos mientras el pensamiento de diseño proporciona la epistemología. Juntos ofrecen lo que Agile nunca pudo — un marco adecuado a la naturaleza del conocimiento mismo. ¿Un sprint de dos semanas para entregar qué? Si estás construyendo sistemas de conocimiento, dos semanas no producirán nada coherente. El conocimiento no se construye rápido y se moldea a la fuerza. Se construye con cuidado, con procedencia, gobernanza y paciencia. El conocimiento no es un producto que pueda manufacturarse y no — no se puede comprar conocimiento estándar que encaje perfectamente con un dominio u organización. El conocimiento es matizado, específico a cada organización, dominio y persona. En el espíritu del argot del capital de riesgo: el conocimiento es el foso, y ese foso no es Ágil. --- Por Jessica Talisman — Intentional Arrangement (Substack) ✻ Baked for 2m 38s ❯ Con el título A Two-Week Sprint for Knowledge From Agile to Design Thinking Jessica Talisman, MLS Apr 21, 2026 y su traducción al espanõl genera documentos en pdf y md en inglés y en español ⏺ Primero verifico si pandoc está disponible para generar los PDFs. ⏺ Bash(which pandoc && pandoc --version | head -1) ⎿  /usr/local/bin/pandoc pandoc 3.7.0.2 ⏺ Bien. Creo los cuatro archivos en /tmp/talisman-article/. ⏺ Bash(mkdir -p /tmp/talisman-article) ⎿  Done ⏺ Write(/tmp/talisman-article/a-two-week-sprint-for-knowledge.md) ⎿  Wrote 101 lines to ../../../../tmp/talisman-article/a-two-week-sprint-for-knowledge.md 2 ## From Agile to Design Thinkinge 4 **Jessica Talisman, MLS** 6 *Apr 21, 2026* 7 --- 9 In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published "The New escribing how Honda, Canon, and Fuji-Xerox organized teams to bui ld copiers and automobiles. Jeff Sutherland read that article, co programming, and in 1993 adapted it for software development at E A conference in 1995. By 2001, seventeen software developers gath ered at a ski lodge in Snowbird, Utah, and signed the A … +364 lines (ctrl+o to expand) ❯ usa typst ? ⏺ Write(/tmp/talisman-article/un-sprint-de-dos-semanas-para-el-conocimiento.md) ⎿  Wrote 101 lines to ../../../../tmp/talisman-article/un-sprint-de-dos-s emanas-para-el-conocimiento.md 2 ## De Agile al Pensamiento de Diseñoonocimiento 4 **Jessica Talisman, MLS** 6 *21 de abril de 2026* 7 --- 9 En 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaron "The New N biendo cómo Honda, Canon y Fuji-Xerox organizaban sus equipos par a fabricar copiadoras y automóviles. Jeff Sutherland leyó ese art gramación orientada a objetos, y en 1993 lo adaptó al desarrollo o en la conferencia OOPSLA de 1995. En 2001, diecisiete desarroll adores de software se reuniero … +407 lines (ctrl+o to expand) ⏺ El usuario preguntó sobre Typst. Verifico si está disponible. ⏺ Bash(which typst && typst --version) ⎿  /opt/homebrew/bin/typst typst 0.14.2 (unknown hash) ⏺ Typst disponible. Genera PDFs mucho más elegantes que pandoc. Creo los fuentes .typ y compilo. ⏺ Write(/tmp/talisman-article/en.typ) ⎿  Wrote 160 lines to ../../../../tmp/talisman-article/en.typ 1 #set document( 2 title: "A Two-Week Sprint for Knowledge", 3 author: "Jessica Talisman, MLS", 4 ) 5 6 #set page( 7 paper: "a4", 8 margin: (top: 2.8cm, bottom: 3cm, left: 3cm, right: 3cm), 9 footer: context [ 10 #set text(size: 9pt, fill: luma(140)) … +433 lines (ctrl+o to expand) ⏺ Write(/tmp/talisman-article/es.typ) ⎿  Wrote 160 lines to ../../../../tmp/talisman-article/es.typ 1 #set document( 2 title: "Un Sprint de Dos Semanas para el Conocimiento", 3 author: "Jessica Talisman, MLS", 4 ) 5 6 #set page( 7 paper: "a4", 8 margin: (top: 2.8cm, bottom: 3cm, left: 3cm, right: 3cm), 9 footer: context [ 10 #set text(size: 9pt, fill: luma(140)) … +475 lines (ctrl+o to expand) ⏺ Ahora compilo los dos PDFs en paralelo. ⏺ Bash(typst compile /tmp/talisman-article/en.typ /tmp/talisman-article/a-two-week-sprint-for-knowledge.pdf 2>&1) ⎿  warning: unknown font family: linux libertine ┌─ ../../../../private/tmp/talisman-article/en.typ:17:8 │ … +2 lines (ctrl+o to expand) ⏺ Bash(typst compile /tmp/talisman-article/es.typ /tmp/talisman-article/un-sprint-de-dos-semanas-para-el-conocimiento.pdf 2>&1) ⎿  warning: unknown font family: linux libertine ┌─ ../../../../private/tmp/talisman-article/es.typ:17:8 │ … +2 lines (ctrl+o to expand) ⏺ Solo warnings de fallback de fuente, no errores. Verifico los archivos generados. Listed 1 directory (ctrl+o to expand) ⏺ Los 4 archivos están en /tmp/talisman-article/: ┌───────────────────────────────────────────────────┬────────┐ │ Archivo │ Tamaño │ ├───────────────────────────────────────────────────┼────────┤ │ a-two-week-sprint-for-knowledge.md │ 20 KB │ ├───────────────────────────────────────────────────┼────────┤ │ a-two-week-sprint-for-knowledge.pdf │ 101 KB │ ├───────────────────────────────────────────────────┼────────┤ │ un-sprint-de-dos-semanas-para-el-conocimiento.md │ 23 KB │ ├───────────────────────────────────────────────────┼────────┤ │ un-sprint-de-dos-semanas-para-el-conocimiento.pdf │ 108 KB │ └───────────────────────────────────────────────────┴────────┘ Sí, usé Typst para los PDFs — produce tipografía profesional con justificación, guiones automáticos por idioma (lang: "en" / lang: "es"), paginación, y un bloque de autor limpio. Georgia como fuente serif principal. Los fuentes .typ también están ahí si quieres ajustar el estilo. ✻ Cogitated for 11m 45s