feat: add descriptive inline hyperlinks to all 5 reference sources

Author: rmax

notes/ai-fde-organizational-learning-systems/index.html

@@ -272,7 +272,7 @@ <h2>FDE exists because enterprise AI cannot be fully specified in advance</h2>
 <p>Many of these constraints become visible only when the system is used against production data by real operators.</p>
 <p>This is why FDE teams are embedded.</p>
 <p>They are not merely implementing a predefined product. They are discovering the real problem while building the solution.</p>
-<p>Databricks describes its FDE model as replacing consultant-style handoffs with embedded engineers who build alongside customers, while maintaining a direct connection with product and research teams. Crucially, when the platform cannot yet support a customer requirement, the field team works with R&D to extend it, allowing field learning to shape the product.</p>
+<p>Databricks describes its <a href="https://www.databricks.com/blog/forward-deployed-engineering-delivering-business-outcomes-ai">Forward Deployed Engineering model</a> as replacing consultant-style handoffs with embedded engineers who build alongside customers, while maintaining a direct connection with product and research teams. Crucially, when the platform cannot yet support a customer requirement, the field team works with R&D to extend it, allowing field learning to shape the product.</p>
 <p>This makes each FDE engagement a form of field research.</p>
 <p>The team observes where the platform fails, where workflows diverge from documented procedures, where deterministic controls are required, where users override model recommendations, and where local context cannot be generalized.</p>
 <p>The mistake is treating these findings as incidental details of delivery.</p>
@@ -286,7 +286,7 @@ <h2>The difference between delivery and learning</h2>
 <p>The first model scales mainly through headcount.</p>
 <p>The second can create compounding leverage.</p>
 <p>As field discoveries become shared capabilities, later teams begin with better infrastructure, stronger evaluations, clearer controls, and a more accurate understanding of the problem space. The marginal effort required for similar deployments should decline.</p>
-<p>This maps to James March's distinction between exploration and exploitation in organizational learning. Exploration searches for new knowledge and possibilities; exploitation refines, standardizes, and applies what has already been learned.</p>
+<p>This maps to James March's <a href="https://pubsonline.informs.org/doi/10.1287/orsc.2.1.71">distinction between exploration and exploitation in organizational learning</a>. Exploration searches for new knowledge and possibilities; exploitation refines, standardizes, and applies what has already been learned.</p>
 <p>FDE teams operate at the exploratory edge of the organization. They encounter new workflows, unfamiliar constraints, and real production failures.</p>
 <p>Platform and product teams perform exploitation. They turn validated discoveries into capabilities that can be maintained and reused.</p>
 <p>A scalable FDE model needs both.</p>
@@ -336,7 +336,7 @@ <h3>1. Observe</h3>
 <h3>2. Preserve</h3>
 <p>The team converts the raw discovery into a durable artifact.</p>
 <p>The appropriate artifact depends on the discovery. It might be an Architecture Decision Record, an evaluation case, a postmortem, a reusable test, a workflow diagram, an integration note, or an anti-pattern.</p>
-<p>An Architecture Decision Record captures a significant design decision together with its rationale, trade-offs, and consequences. This makes ADRs particularly useful for FDE work: the code records what the team built, while the ADR preserves why the team chose that design under the constraints it encountered.</p>
+<p>An <a href="https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions">Architecture Decision Record</a> captures a significant design decision together with its rationale, trade-offs, and consequences. This makes ADRs particularly useful for FDE work: the code records what the team built, while the ADR preserves why the team chose that design under the constraints it encountered.</p>
 <p>The objective is not comprehensive prose. It is to preserve enough context that another team can understand the problem, the environment in which it occurred, the attempted solution, the result, the known limitations, and the evidence supporting the conclusion. Knowledge capture should remain close to engineering work, because documentation treated as a separate post-delivery activity is usually incomplete, delayed, or abandoned.</p>
 <h3>3. Compare</h3>
 <p>A local solution becomes strategically interesting when similar problems appear across independent engagements.</p>
@@ -370,7 +370,7 @@ <h3>6. Measure, update, and deprecate</h3>
 <p>The organization should measure whether the capability reduces implementation effort, prevents duplicate work, lowers incident recurrence, simplifies handover, decreases dependence on FDE support, and remains useful as models and vendors evolve.</p>
 <p>Some abstractions will fail.</p>
 <p>Others will become obsolete because model or cloud providers absorb the capability. Some will prove too rigid for the variation found in the field.</p>
-<p>This process mirrors Nonaka's model of organizational knowledge creation: field teams acquire tacit knowledge through direct work, externalize it into artifacts, combine it across deployments, and allow future teams to internalize it through repeated use.</p>
+<p>This process mirrors <a href="https://hbr.org/2007/07/the-knowledge-creating-company">Nonaka's model of organizational knowledge creation</a>: field teams acquire tacit knowledge through direct work, externalize it into artifacts, combine it across deployments, and allow future teams to internalize it through repeated use.</p>
 <p>The learning loop must therefore include deprecation.</p>
 <p>A platform that only accumulates abstractions is not learning.</p>
 <p>It is preserving past assumptions.</p>
@@ -485,7 +485,7 @@ <h2>Conclusion: make adaptation cumulative</h2>
 <p>That position makes FDE a distributed sensing network.</p>
 <p>But sensing alone does not create learning.</p>
 <p>The organization needs a mechanism that converts observations into evidence, evidence into patterns, patterns into validated capability, and validated capability into better future deployments.</p>
-<p>This is closely related to Cohen and Levinthal's concept of absorptive capacity: an organization's ability to recognize valuable external knowledge, assimilate it, and apply it.</p>
+<p>This is closely related to Cohen and Levinthal's <a href="https://www.jstor.org/stable/2393553">concept of absorptive capacity</a>: an organization's ability to recognize valuable external knowledge, assimilate it, and apply it.</p>
 <p>FDE teams give the organization access to high-value operational knowledge.</p>
 <p>The learning system determines whether that knowledge becomes institutional capability or disappears with the engagement.</p>
 <p>In a weak FDE model, every deployment consumes expertise. In a strong FDE model, every deployment also produces expertise in a form that the rest of the organization can use.</p>

notes/ai-fde-organizational-learning-systems/index.md

@@ -69,7 +69,7 @@ This is why FDE teams are embedded.
 
 They are not merely implementing a predefined product. They are discovering the real problem while building the solution.
 
-Databricks describes its FDE model as replacing consultant-style handoffs with embedded engineers who build alongside customers, while maintaining a direct connection with product and research teams. Crucially, when the platform cannot yet support a customer requirement, the field team works with R&D to extend it, allowing field learning to shape the product.
+Databricks describes its [Forward Deployed Engineering model](https://www.databricks.com/blog/forward-deployed-engineering-delivering-business-outcomes-ai) as replacing consultant-style handoffs with embedded engineers who build alongside customers, while maintaining a direct connection with product and research teams. Crucially, when the platform cannot yet support a customer requirement, the field team works with R&D to extend it, allowing field learning to shape the product.
 
 This makes each FDE engagement a form of field research.
 
@@ -97,7 +97,7 @@ The second can create compounding leverage.
 
 As field discoveries become shared capabilities, later teams begin with better infrastructure, stronger evaluations, clearer controls, and a more accurate understanding of the problem space. The marginal effort required for similar deployments should decline.
 
-This maps to James March's distinction between exploration and exploitation in organizational learning. Exploration searches for new knowledge and possibilities; exploitation refines, standardizes, and applies what has already been learned.
+This maps to James March's [distinction between exploration and exploitation in organizational learning](https://pubsonline.informs.org/doi/10.1287/orsc.2.1.71). Exploration searches for new knowledge and possibilities; exploitation refines, standardizes, and applies what has already been learned.
 
 FDE teams operate at the exploratory edge of the organization. They encounter new workflows, unfamiliar constraints, and real production failures.
 
@@ -172,7 +172,7 @@ The team converts the raw discovery into a durable artifact.
 
 The appropriate artifact depends on the discovery. It might be an Architecture Decision Record, an evaluation case, a postmortem, a reusable test, a workflow diagram, an integration note, or an anti-pattern.
 
-An Architecture Decision Record captures a significant design decision together with its rationale, trade-offs, and consequences. This makes ADRs particularly useful for FDE work: the code records what the team built, while the ADR preserves why the team chose that design under the constraints it encountered.
+An [Architecture Decision Record](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) captures a significant design decision together with its rationale, trade-offs, and consequences. This makes ADRs particularly useful for FDE work: the code records what the team built, while the ADR preserves why the team chose that design under the constraints it encountered.
 
 The objective is not comprehensive prose. It is to preserve enough context that another team can understand the problem, the environment in which it occurred, the attempted solution, the result, the known limitations, and the evidence supporting the conclusion. Knowledge capture should remain close to engineering work, because documentation treated as a separate post-delivery activity is usually incomplete, delayed, or abandoned.
 
@@ -234,7 +234,7 @@ Some abstractions will fail.
 
 Others will become obsolete because model or cloud providers absorb the capability. Some will prove too rigid for the variation found in the field.
 
-This process mirrors Nonaka's model of organizational knowledge creation: field teams acquire tacit knowledge through direct work, externalize it into artifacts, combine it across deployments, and allow future teams to internalize it through repeated use.
+This process mirrors [Nonaka's model of organizational knowledge creation](https://hbr.org/2007/07/the-knowledge-creating-company): field teams acquire tacit knowledge through direct work, externalize it into artifacts, combine it across deployments, and allow future teams to internalize it through repeated use.
 
 The learning loop must therefore include deprecation.
 
@@ -424,7 +424,7 @@ But sensing alone does not create learning.
 
 The organization needs a mechanism that converts observations into evidence, evidence into patterns, patterns into validated capability, and validated capability into better future deployments.
 
-This is closely related to Cohen and Levinthal's concept of absorptive capacity: an organization's ability to recognize valuable external knowledge, assimilate it, and apply it.
+This is closely related to Cohen and Levinthal's [concept of absorptive capacity](https://www.jstor.org/stable/2393553): an organization's ability to recognize valuable external knowledge, assimilate it, and apply it.
 
 FDE teams give the organization access to high-value operational knowledge.