ontoref/assets/presentation/docs/2026-04-25-000346-puedes-sacar-el-texto-de-este-contenido.txt

 ▐▛███▜▌   Claude Code v2.1.119
▝▜█████▛▘  Sonnet 4.6 · Claude Max
  ▘▘ ▝▝    /Users/Akasha/Development/ontoref

❯ puedes sacar el texto de este contenido ?                                     
  <div class="available-content reader2-post-content"><div dir="auto"           
  class="body markup"><div data-component-name="SubscribeWidget"                
  class="subscribe-widget is-signed-up"><div class="pencraft pc-reset           
  button-wrapper"><div class="pencraft pc-display-flex pc-justifyContent-center 
   pc-reset"><button tabindex="0" type="button"                                 
  data-href="https://jessicatalisman.substack.com/subscribe?utm_medium=web&amp; 
  utm_source=subscribe-widget&amp;utm_content=194462271&amp;next=https%3A%2F%2F 
  substack.com%2F%40jessicatalisman%2Fp-194462271" class="pencraft pc-reset     
  pencraft buttonBase-GK1x3M buttonText-X0uSmG buttonStyle-r7yGCK               
  priority_primary-RfbeYt size_md-gCDS3o"><span>Upgrade to                      
  paid</span></button></div></div></div><p><span>In 1986, Hirotaka Takeuchi and 
   Ikujiro Nonaka published “The New New Product Development Game” in the       
  </span><em>Harvard Business Review</em><span>, describing how Honda, Canon,   
  and Fuji-Xerox organized teams to build copiers and automobiles.</span><span  
  data-state="closed" style="min-width: 0px;"><a                                
  data-component-name="FootnoteAnchorToDOM" id="footnote-anchor-1"              
  href="#footnote-1" target="_self" class="footnote-anchor">1</a></span><span>  
  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.</span><span data-state="closed"            
  style="min-width: 0px;"><a data-component-name="FootnoteAnchorToDOM"          
  id="footnote-anchor-2" href="#footnote-2" target="_self"                      
  class="footnote-anchor">2</a></span><span> 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.”</span><span data-state="closed" style="min-width: 0px;"><a         
  data-component-name="FootnoteAnchorToDOM" id="footnote-anchor-3"              
  href="#footnote-3" target="_self" class="footnote-anchor">3</a></span><span>  
  Not knowledge or meaning. A manufacturing framework for                       
  software.</span></p><div class="captioned-image-container"><figure><a         
  target="_blank" href="https://substackcdn.com/image/fetch/$s_!c-hA!,f_auto,q_ 
  auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws 
  .com%2Fpublic%2Fimages%2F66254527-6290-4907-9186-3be299a56c91_664x861.jpeg"   
  data-component-name="Image2ToDOM" class="image-link image2                    
  is-viewable-img"><div class="image2-                                          
  ──── (0 lines hidden) ─────────────────────────────────────────────────────── 
  paddingBottom-0 pc-alignItems-center pc-reset"><a                             
  href="https://jessicatalisman.substack.com/p/the-semantics-of-semantics"      
  class="pencraft pc-reset align-center-y7ZD4w line-height-20-t4M0El            
  font-text-qe4AeH size-13-hZTUKr weight-medium-fw81nC reset-IxiVJZ"><div       
  class="pencraft pc-display-flex pc-gap-8 pc-alignItems-center pc-reset        
  link-HREYZo"><span class="pencraft pc-reset color-accent-BVX_7M               
  line-height-20-t4M0El font-text-qe4AeH size-14-MLPa7j weight-semibold-uqA4FV  
  reset-IxiVJZ">Read full story</span><svg xmlns="http://www.w3.org/2000/svg"   
  width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor"  
  stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide 
   lucide-arrow-right"><path d="M5 12h14"></path><path d="m12 5 7 7-7           
  7"></path></svg></div></a></div></div></div><p></p></div></div></div><div     
  class="pencraft pc-display-contents pc-reset dark-theme"><div class="pencraft 
   pc-display-flex pc-flexDirection-column pc-gap-4 pc-padding-4                
  pc-justifyContent-center pc-boxShadow-md pc-reset outline-detail-vcQLyr       
  pc-borderRadius-md popover-Q5L48i  " style="top: 208.797px; left:             
  557.645px;"><button tabindex="0" type="button" class="pencraft pc-reset       
  pencraft button-r00Nrm buttonBase-GK1x3M"><svg                                
  xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" 
   fill="none" stroke="var(--color-utility-white)" stroke-width="2"             
  stroke-linecap="round" stroke-linejoin="round" class="lucide                  
  lucide-refresh-cw"><path d="M3 12a9 9 0 0 1 9-9 9.75 9.75 0 0 1 6.74 2.74L21  
  8"></path><path d="M21 3v5h-5"></path><path d="M21 12a9 9 0 0 1-9 9 9.75 9.75 
   0 0 1-6.74-2.74L3 16"></path><path d="M8 16H3v5"></path></svg><div           
  class="pencraft pc-reset color-vibrance-primary-KHCdqV line-height-20-t4M0El  
  font-text-qe4AeH size-13-hZTUKr weight-medium-fw81nC                          
  reset-IxiVJZ">Restack</div></button><button tabindex="0" type="button"        
  class="pencraft pc-reset pencraft button-r00Nrm buttonBase-GK1x3M"><svg       
  xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" 
   fill="none" stroke="var(--color-utility-white)" stroke-width="2"             
  stroke-linecap="round" stroke-linejoin="round" class="lucide                  
  lucide-share"><path d="M4 12v8a2 2 0 0 0 2 2h12a2 2 0 0 0                     
  2-2v-8"></path><polyline points="16 6 12 2 8 6"></polyline><line x1="12"      
  x2="12" y1="2" y2="15"></line></svg><div class="pencraft pc-reset             
  color-vibrance-primary-KHCdqV line-height-20-t4M0El font-text-qe4AeH          
  size-13-hZTUKr weight-medium-fw81nC                                           
  reset-IxiVJZ">Share</div></button></div></div></div>                          

⏺ 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