Knowledge Is Not the Same Thing as Its Container.
Books, documentation, lectures, research papers, and courses can carry valuable knowledge — but they also combine that knowledge with interpretation, examples, narrative, context, structure, repetition, and style. Knowledge Domain Protocol explores whether those layers can be modeled separately so that useful knowledge structures can later be transformed into new forms of explanation and active learning.
A book contains knowledge. It is not identical to the knowledge it contains. KDP begins by treating the artifact and the domain it represents as related — but separable — structures.
The Same Domain Can Exist Inside Many Different Containers.
A knowledge artifact is a particular representation. The underlying domain may extend beyond that artifact, predate it, appear in other sources, or be interpreted differently by another author.
A Book
A complete authored object created for reading, explanation, persuasion, instruction, documentation, or another communicative purpose.
One Artifact. Several Things Happening at Once.
KDP treats these layers as analytically distinguishable rather than assuming the entire artifact is one indivisible block.
Not Every Part of an Artifact Carries the Same Density of Domain Information.
KDP began from a Pareto-inspired intuition: long-form material can contain a relatively concentrated set of high-value domain relationships surrounded by a much larger presentation layer.
What Must Be Understood?
Core concepts, relationships, rules, conditions, trade-offs, models, dependencies, and other structures that carry substantial explanatory or operational value inside the domain.
How Was That Knowledge Made Into an Artifact?
Stories, repetition, examples, analogies, persuasion, historical context, style, pacing, explanation, narrative structure, and other elements that make long-form communication work.
Executable Knowledge Has a Natural Feedback Mechanism.
In programming, learners can write code, execute it, observe behavior, inspect errors, and revise their reasoning. The environment itself helps expose whether an implementation actually works.
What Happens When the Knowledge Is Not Executable?
Strategy, architecture, leadership, system design, operational reasoning, and many other domains do not always provide a compiler or runtime that can directly evaluate the learner’s understanding. KDP emerged as an experiment in structuring those domains so they can later become active learning experiences.
What becomes possible when the knowledge-bearing structure of an artifact can be modeled separately from the way that knowledge was originally presented?
One Protocol. Different Types of Domains.
KDP emerged from a practical limitation inside Coding5s: the framework was strongest where knowledge could be practiced through executable code. Extending active learning into strategy, architecture, operations, leadership, system design, and other conceptual fields required a different way to represent what the learner was supposed to understand and act upon.
KDP Was Created to Remove Several Architectural Bottlenecks.
The protocol did not begin as an attempt to model all human knowledge. It began as an experiment for solving specific problems encountered while expanding the Coding5s framework.
Knowledge Is Often Locked Inside Its Presentation.
A useful principle may be embedded inside hundreds of pages of narrative, examples, historical context, repetition, argumentation, and authorial interpretation. The learner receives the entire artifact even when the learning objective concerns only part of the underlying domain.
Not Every Domain Has a Compiler.
Programming gives Coding5s a powerful feedback mechanism: code can execute, fail, expose errors, and be corrected. Strategy, leadership, architecture, operational reasoning, and many conceptual domains do not provide the same natural execution loop.
Coding5s Needed a Path Beyond Programming Languages.
If the framework remained dependent on syntax and executable code, many potentially useful domains would stay outside its architecture. KDP explores whether structured domain models can become another source of active learning material.
Enrich the Framework Without Pretending Every Domain Works Like Code.
KDP explores a bridge between the original Coding5s environment and fields where the primary material is conceptual rather than executable.
Executable Technical Learning
Programming languages naturally expose syntax, behavior, errors, outputs, and implementation constraints that can be turned into structured learner actions.
Structured Conceptual Domains
Model concepts, principles, relationships, reasoning patterns, conditions, expertise, and other domain structures so they can later be transformed into scenarios, decisions, explanations, simulations, or curricula.
KDP Is the Protocol. Knowledge Domain and Author Domain Are Specific Applications.
The protocol defines the broader domain-modeling process. What changes is the thing being modeled.
Knowledge Domain Protocol
Experimental architecture for identifying, structuring, grounding, transforming, and potentially recombining coherent domains.
Knowledge Domain
Models a body of subject knowledge: concepts, relationships, principles, conditions, trade-offs, exceptions, evidence, uncertainty, and other structures useful for understanding how the domain works.
Author Domain
Treats a person as a multidimensional domain that may include knowledge, expertise, experience, worldview, reasoning patterns, personality, communication, explanatory habits, decision tendencies, and other attributable characteristics.
Author Domain is not a separate protocol. It is one specialized use of Knowledge Domain Protocol, just as a conventional Knowledge Domain is another specialized use of the same architecture.
More Domains Could Become Raw Material for Active Learning.
KDP is being explored as one possible way to enrich Coding5s with structured material that does not begin as programming syntax.
Strategic Reasoning
Principles and trade-offs could become scenario-based decisions instead of passive summaries.
System Design
Architectural relationships and constraints could become diagnosis, trade-off, and design-defense exercises.
Operational Decisions
Incident response, risk, prioritization, and process reasoning could become interactive simulations.
Leadership & Communication
Human situations could be modeled through competing constraints, consequences, context, and decision pathways.
Architectural Concept + Early Experiments
KDP currently exists as a Research Lab architecture with initial decompositions, small proof-of-concept transformations, and exploratory examples. It is developed enough to investigate, but not mature enough to claim broad effectiveness.
How Far the Architecture Can Generalize
There is not yet formal validation showing that every domain can be modeled effectively, that the proposed schema is optimal, or that KDP-derived learning artifacts improve learning outcomes across domains. Those remain research questions.
KDP is not an attempt to declare one universal structure for all knowledge. It is an experiment in asking whether different kinds of domains can be modeled explicitly enough to become new building material for active learning.
A Book Is a Projection of Knowledge Through an Author.
A book does not contain only facts or principles. It also reflects what an author selected, how they understood it, what they considered important, how they chose to explain it, and the historical and editorial conditions under which the work was created. KDP treats those layers as potentially distinguishable rather than assuming the book and the domain behind it are the same thing.
A Book Is a Constructed Representation.
This is not a mathematical formula. It is a useful decomposition model for understanding why extracting a domain from a book is different from simply summarizing the book.
One Object Can Contain Several Different Layers.
KDP explores whether those layers can be identified separately enough to preserve what matters, transform what is useful, and avoid confusing the author’s presentation with the entire domain.
Book
A single published object can simultaneously carry domain knowledge, interpretation, explanation, narrative, culture, history, persuasion, and style.
Domain Knowledge
Concepts, relationships, principles, conditions, models, trade-offs, and other structures that belong to the subject being discussed.
Author Interpretation
What the author notices, emphasizes, connects, rejects, prioritizes, or views through a particular intellectual lens.
Narrative Structure
Chapters, progression, repetition, examples, anecdotes, pacing, rhetorical order, and other structures required to make a long-form work readable.
Explanatory Layer
Analogies, illustrations, simplified models, stories, teaching devices, and other ways the author makes abstract ideas understandable.
Historical & Cultural Context
Assumptions, language, social conditions, institutions, technologies, and events surrounding the creation of the work.
Style & Voice
Tone, vocabulary, cadence, humor, formality, rhetorical habits, and other characteristics of presentation.
The Goal Is Not to Throw Away the Larger Layer.
The 80/20 intuition becomes more useful when it is treated as a way to think about information density, not as a rule declaring most of a book worthless.
What Must Survive?
The relatively concentrated set of concepts, relationships, principles, conditions, constraints, and decision structures that carry substantial meaning inside the domain.
What Helped Turn That Knowledge Into a Book?
Examples, repetition, narrative, persuasion, interpretation, analogies, historical references, explanations, style, and other elements that may be essential for communication even when they are not themselves the domain core.
Separation Makes the Representation Potentially Transformable.
KDP is investigating whether explicit layers can give creators more control over what is preserved and what is changed when knowledge is reconstructed.
Preserve
Keep an analogy, historical case, explanatory structure, or other layer when it remains useful.
Isolate
Extract a concept or relationship so it can be studied independently from the original artifact.
Compare
Examine how multiple authors or artifacts represent similar domains differently.
Replace
Swap an outdated example or presentation layer while attempting to preserve the underlying domain relationship.
Transform
Convert passive explanation into another format: scenario, decision, simulation, diagnosis, or active exercise.
Recombine
Experiment with a knowledge structure through a different explanatory, contextual, or author-domain projection.
From Source Material to a Reusable Domain Model.
This is the current conceptual workflow being explored inside KDP. It is an R&D architecture, not a proven universal extraction procedure.
The objective is not to strip a book down until only a summary remains. The objective is to understand which layers belong to the domain, which belong to its representation, and which may be preserved or transformed intentionally when building a new learning experience.
What Replaces the Compiler When the Subject Is Knowledge?
Structuring a domain is only part of the problem. Coding5s was designed around learners doing something with what they are learning. When there is no executable program to run, KDP explores other ways to create actions, consequences, reasoning checks, and feedback around conceptual knowledge.
Programming Has Something Many Domains Do Not.
Code can be executed. A conceptual principle often cannot. KDP therefore needs a different interaction model if the learner is going to practice instead of simply consume explanations.
Programming
The learner produces an implementation and the environment responds. Syntax errors, exceptions, tests, outputs, runtime behavior, and system state provide concrete evidence that something worked, failed, or behaved unexpectedly.
Knowledge-Based Practice
The learner may instead need to interpret a situation, choose between competing actions, diagnose a problem, defend a decision, recognize a pattern, or reason through consequences.
Turn a Domain Relationship Into a Situation That Requires Reasoning.
The current KDP hypothesis is that at least some conceptual knowledge can be practiced by transforming explicit domain structures into constrained situations where the learner must make or defend a decision.
There Does Not Need to Be One Universal Replacement for the Compiler.
Different domains may require different interaction mechanisms. These are examples of artifact types KDP can investigate, not a claim that every type works equally well for every subject.
Scenario Decision
Place the learner inside a realistic situation where several actions appear plausible but lead to different consequences.
Diagnosis
Present symptoms, evidence, constraints, or system behavior and require the learner to identify the most plausible underlying problem.
Trade-Off Analysis
Force a choice between competing priorities where no option is universally correct outside the scenario’s constraints.
Pattern Classification
Ask the learner to identify which principle, category, failure mode, or model best explains a concrete case.
Prioritization
Require actions, risks, evidence, or interventions to be ordered according to domain-specific constraints.
Decision Defense
The learner chooses a solution and must explain which principles, assumptions, and trade-offs justify the choice.
Branching Simulation
Decisions alter subsequent conditions, creating a small interactive environment where reasoning changes what happens next.
Explain the Mechanism
Present an outcome and require the learner to reconstruct the principle or relationship that produced it.
Do Not Stop at “Explain This Concept.”
KDP is intended to enrich the content available to Coding5s by creating structures that can support action, not merely shorter summaries.
Concept → Summary
The learner receives a cleaner or shorter explanation, but the fundamental interaction remains consumption. This can be useful, but it does not by itself reproduce the active character Coding5s is trying to preserve.
Concept → Situation → Decision
The learner must recognize when the concept matters, determine how it applies, make a choice, and connect the result back to the domain structure.
KDP Does Not Need to Produce an Entire Course Every Time.
A modeled domain may support one useful exercise or become raw material for a much larger structured learning sequence.
Structured Learning Material
The same modeled knowledge can potentially be transformed at different scales depending on the learning objective.
Active Learning Artifact
One scenario, simulation, reasoning challenge, case, diagnosis, micro-lesson, or other independent learning object created from a domain structure.
Coding5s Learning Sequence
Multiple domain-derived artifacts can potentially be organized through the Coding5s progression to create a larger curriculum or structured learning experience.
KDP Enriches the Material. Coding5s Structures the Learning Journey.
The two architectures solve different problems and can work together without becoming the same thing.
Some Conceptual Knowledge May Become More Practiceable.
Explicit domain models may help convert selected principles and relationships into situations where learners must recognize, apply, and defend their understanding rather than merely recall a summary.
A Simulation Is Not a Compiler.
Unlike executing deterministic code, evaluating conceptual reasoning may involve interpretation, ambiguity, incomplete evidence, multiple defensible answers, or domain disagreement. KDP does not claim to eliminate those differences.
The objective is not to make every field behave like programming. KDP investigates whether the active character of Coding5s can be preserved by giving learners something meaningful to analyze, decide, diagnose, defend, or solve when executable code is no longer the primary medium.
The Same Knowledge Can Be Reconstructed Through Different Lenses.
KDP becomes easier to understand when the transformation is
visible from beginning to end. This experiment starts with
The Art of War, isolates one strategic
relationship, combines it with communication-oriented Author
Domain projections, transfers the idea into a software-team
conflict, and turns the result into an active comparison.
The Spanish and English examples deliberately use different
cultural comedy treatments while attempting to preserve the
same underlying Knowledge Domain relationship.
This is an exploratory proof of concept — not evidence that
the extracted principle is universal or that KDP has been
formally validated.
From Historical Artifact to Active Software-Team Scenario.
The experiment changes presentation, cultural rendering, context, and learning format while attempting to keep the relevant strategic relationship traceable.
The Art of War Meets a Development Team Having a Very Bad Day.
The example separates the original artifact, the Knowledge Domain relationship, the Author Domain projections, and the final learning interaction.
Start With the Knowledge Artifact
The experiment does not attempt to transform the entire book. It selects one strategic idea and treats the book as the artifact carrying it.
The Art of War
Historical strategy work used here as source material for a small KDP experiment.
Do Not Remove Every Exit
A pressured opponent with no acceptable path to retreat or cooperate may become more willing to resist or escalate.
Isolate the Knowledge Domain Relationship
The selected idea becomes a compact working representation while its status as a strategic heuristic remains explicit.
Combine It With Communication-Oriented Author Domains
The Knowledge Domain remains the same, but KDP can experiment with different ways of rendering it. Here, two communication profiles are used for the same software-team situation.
First, Make the Strategic Mistake
The same domain relationship is moved into a software-team incident and deliberately applied badly. The two language versions preserve the same mechanism while changing the comedic rendering.
Mira, producción está caída, el dashboard parece árbol de Navidad pero puro foco rojo, Slack ya tiene cuarenta personas preguntando “¿alguna actualización?” como si preguntar cada treinta segundos fuera a reparar Kubernetes, y enfrente tienes al pobre dev con cara de que ya está calculando cuántos meses puede sobrevivir vendiendo su PlayStation. Entonces entra el líder con su maestría en inteligencia emocional sacada de TikTok y dice: “A ver, campeón, si en cinco minutos no me dices exactamente qué hiciste, hoy mismo te vas.” ¡Excelente! El servidor se está incendiando y tú acabas de amenazar al único cuate que sabe dónde dejaron el extinguidor. Ahora el dev ya no está pensando en recuperar producción. Está pensando en Recursos Humanos, en actualizar LinkedIn, en si todavía tiene acceso al repositorio y en qué momento de su vida creyó que estudiar sistemas era una buena idea. Lo arrinconaste. Ya no le diste una razón para ayudarte; le diste una razón para sobrevivirte.
Production is DOWN. The dashboard got so much red on it you would think the server owed somebody money. Slack is exploding — “Any update?” “Any update?” Man, if asking “any update” fixed Kubernetes, we would have been home twenty minutes ago! And there is your developer sitting there looking like he just remembered rent is due Friday. Then the manager walks in like he is about to solve everything: “You got five minutes to tell me exactly what you did or you’re fired.” Five minutes?! Man, the building is on fire and you just threatened the one dude holding the map to the fire extinguisher! Now he ain’t thinking about your database. He is thinking about HR. He is thinking about LinkedIn. He is thinking, “Do I still have dental until midnight?” You didn’t create urgency. You turned the only person with useful information into a hostage negotiator for his own career.
The team lead increases the perceived cost of disclosure at the exact moment when cooperation is operationally valuable. Accountability may still be necessary, but combining immediate recovery with immediate personal threat can intensify defensive behavior.
Now Change One Variable: Give Cooperation an Exit
The technical incident is almost identical. The strategic variable that changes is the developer’s perceived path forward.
Ahora llega otro líder y dice: “Ahorita no estamos decidiendo quién mañana desayuna desempleado. Primero levantemos producción. Enséñame qué cambiaste, pásame los logs y después revisamos juntos qué salió mal.” Ah, mira qué curioso. De pronto al muchacho le regresó la memoria RAM humana. Ya se acordó de la contraseña. Aparecieron los logs. Hasta encontró ese archivo que hace tres minutos juraba que probablemente nunca había existido. ¿Por qué? Porque cada dato que entrega ya no parece otra pala para cavar su propia tumba corporativa. Le diste una salida: coopera ahora, recuperamos el servicio y la conversación incómoda viene después. No eliminaste la responsabilidad. Solo evitaste convertir el incidente técnico en Los Juegos del Hambre: edición stand-up diario.
Now watch the second manager walk in: “Nobody is getting fired in the next ten minutes. Right now I need the service back. Show me what changed, give me the logs, and when production is stable we’ll figure out what happened.” Look at that! Suddenly this developer got a firmware update! “Oh yeah, I remember the password.” “Actually, I do have the logs.” “Matter of fact, there is one little file I forgot to mention…” Oh, NOW you remember! Three minutes ago this man had amnesia like he woke up in a soap opera. What changed? He stopped feeling like every piece of information was another exhibit in his own trial. You didn’t erase accountability. You just told him, “Help us put the fire out first. We can discuss who bought the gasoline later.”
Immediate system recovery is separated from the later accountability review. The developer retains an acceptable cooperative path while the organization preserves its ability to investigate the incident afterward.
Same Incident. Same Developer. Different Strategic Choice.
Which response better applies the modeled CORNERED_ADVERSARY_ESCALATION principle?
Disclosure becomes associated with immediate punishment, increasing one source of defensive resistance.
Cooperation retains an acceptable immediate path while accountability remains possible after stabilization.
The learner is not being asked to memorize a sentence from The Art of War. The learner must recognize the strategic relationship after it has been moved into a completely different environment and distinguish between two possible applications. The Spanish and English comedy layers also demonstrate that the presentation can change while the underlying KDP relationship remains the same.
The Domain Stayed Stable While Several Other Layers Changed.
The source knowledge, cultural communication layer, operational context, and learning interaction are separate parts of the experiment.
The Book Is Not the Final Learning Unit.
One strategic relationship was separated from a larger historical artifact and represented as a compact Knowledge Domain element.
One Knowledge Domain. Multiple Communication Domains.
The strategic relationship remains recognizable while Spanish and English cultural comedy projections alter rhythm, analogy, vocabulary, and presentation.
Explanation Becomes a Decision.
The learner receives competing behaviors and must recognize the modeled strategic relationship inside a completely different operational environment.
Domain Models May Become Building Blocks for New Learning Material.
KDP also explores whether selected relationships from different modeled domains can be combined intentionally. This remains a research direction rather than a proven general capability.
An Architectural Idea With Early Experiments — Not a Validated Knowledge Engine.
KDP currently has enough structure to experiment with, but not enough evidence for broad claims about extraction accuracy, learning effectiveness, or generalization.
Early KDP Architecture
Open Research Questions
Modeling Knowledge Is Not the Same as Capturing Truth.
KDP becomes more useful when the limitations of the abstraction remain visible instead of being hidden.
Extraction Can Remove Meaning.
Separating a principle too aggressively from history, assumptions, exceptions, or surrounding argument can make the resulting model misleading.
Domains Can Be Contested.
Strategy, leadership, philosophy, history, and other fields may contain competing interpretations rather than one universally accepted model.
A New Lens Can Distort the Original.
Humor, Author Domains, analogies, and interdisciplinary mappings may improve accessibility while also introducing assumptions absent from the source.
Not Every Problem Has One Correct Output.
Conceptual situations may support multiple defensible decisions. Evaluation should expose reasoning rather than pretend to behave like deterministic code.
Provenance Should Remain Visible.
A domain model should preserve enough connection to source material to distinguish evidence, interpretation, abstraction, uncertainty, and later transformation.
KDP May Not Fit Every Domain.
Some knowledge may resist compact modeling or lose too much when decomposed. Discovering those limits is part of the Research Lab work.
Beyond Programming Does Not Mean Beyond Practice.
Knowledge Domain Protocol was conceived as an experimental
way to enrich Coding5s when the material being learned no
longer fits naturally inside an executable programming
environment.
The research direction is broader than books:
identify a useful domain, model its important
relationships and context, experiment with different
representations, and transform selected parts into something
the learner can actively reason about.
A Knowledge Domain can model a subject.
An Author Domain can model a person.
Both are specific applications of the same Knowledge Domain
Protocol — and they can potentially be combined to construct
new learning experiences.
The bilingual experiment above adds another question:
can the same Knowledge Domain remain recognizable
while its cultural communication layer changes substantially?
research.question = can_domains_be_modeled_recombined_localized_and_transformed_for_active_learning?