82a358f18d
ontoref-derive: #[onto_mcp_tool] attribute macro registers MCP tool unit-structs in
the catalog at link time via inventory::submit!; annotated item is emitted unchanged,
ToolBase/AsyncTool impls stay on the struct. All 34 tools migrated from manual wiring
(net +5: ontoref_list_projects, ontoref_search, ontoref_describe,
ontoref_list_ontology_extensions, ontoref_get_ontology_extension).
validate modes (ADR-018): reads level_hierarchy from workflow.ncl and checks every
.ncl mode for level declared, strategy declared, delegate chain coherent, compose
extends valid. mode resolve <id> shows which hierarchy level handles a mode and why.
--self-test generates synthetic fixtures in a temp dir for CI smoke-testing.
validate run-cargo: two-step Cargo.toml resolution — workspace layout first
(crates/<check.crate>/Cargo.toml), single-crate fallback by package name or repo
basename. Lets the same ADR constraint shape apply to workspace and single-crate repos.
ontology/schemas/manifest.ncl: registry_topology_type contract — multi-registry
coordination, push targets, participant scopes, per-namespace capability.
reflection/requirements/base.ncl: oras ≥1.2.0, cosign ≥2.0.0, sops ≥3.9.0, age
≥1.1.0, restic declared as Hard/Soft requirements with version_min, check_cmd, and
install_hint (ADR-017 toolchain surface).
ADR-019: per-file recipient routing for tenant isolation without multi-vault. Schema
additions: sops.recipient_groups + sops.recipient_rules in ontoref-project.ncl.
secrets-bootstrap generates .sops.yaml from project.ncl in declarative mode. Three
new secrets-audit checks: recipient-routing-coherent, recipient-routing-coverage,
no-multi-vault. Adoption templates: single-team/, multi-tenant/, agent-first/.
Integration templates: domain-producer/, mode-producer/, mode-consumer/.
UI: project_picker surfaces registry badge (⟳ participant) and vault badge
(⛁ vault_id · N, green=declarative / amber=legacy) per project card. Expanded panel
adds collapsible Registry section with namespace, endpoint, and push/pull capability.
manage.html gains Runtime Services card — MCP and GraphQL toggleable without restart
via HTMX POST /ui/manage/services/{service}/toggle.
describe.nu: capabilities JSON includes registry_topology and vault_state per project.
sync.nu: drift check extended to detect //! absence on newly registered crates.
qa.ncl: six entries — credential-vault-best-practice (layered data-flow diagram),
credential-vault-templates (paths A/B/C), credential-vault-troubleshooting (15 named
errors), integration-what-and-why (ADR-042 OCI federation), integration-how-to-implement,
integration-troubleshooting.
on+re: core.ncl + manifest.ncl updated to reflect OCI, MCP, and mode-hierarchy nodes.
Deleted stale presentation assets (2026-02 slides + voice notes).
905 lines
No EOL
55 KiB
Text
905 lines
No EOL
55 KiB
Text
▐▛███▜▌ 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&
|
||
utm_source=subscribe-widget&utm_content=194462271&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 |