AI’s Missing Evidence Layer: The Failures We Never Record

TL;DR

Artificial intelligence has access to an extraordinary volume of recorded human knowledge. But much of what people learn through experimentation, troubleshooting, physical observation, and unsuccessful attempts never becomes part of a durable knowledge system. That creates a significant limitation for AI systems that depend on available evidence to make recommendations.

Enterprise knowledge repositories typically preserve approved procedures, successful architectures, completed projects, and final incident resolutions. They are less consistent at preserving the decisions, rejected hypotheses, environmental conditions, and unsuccessful interventions that explain how those outcomes were reached. The missing information can be particularly important when an AI system must reason about an unfamiliar situation or determine whether an established solution applies to a different environment.

The opportunity is to capture useful experience as governed evidence and connect it to retrieval, evaluation, and controlled experimentation. This does not require continuously retraining foundation models. It requires systems that can distinguish observations from conclusions, retain counterexamples, preserve provenance, and verify what actually happened.

Key takeaway: The next improvement in enterprise AI may come as much from capturing and validating the experience organizations currently lose as from giving models more published knowledge.

Introduction

Imagine an infrastructure team spending six months investigating an intermittent application failure.

During that investigation, engineers test several network configurations, change timeout values, examine packet captures, roll back software updates, investigate storage latency, and compare behavior across environments. Most attempts fail to resolve the problem. Some produce unexpected results. A few expose dependencies that nobody previously understood.

Eventually, the team identifies a workable solution. The architecture is updated, the incident is closed, and the final configuration becomes the new standard.

Six months later, another engineer encounters a similar problem.

The documentation explains the working configuration. It does not explain which alternatives were investigated, what evidence ruled them out, which environmental conditions mattered, or which hypotheses remain unresolved.

An AI assistant accessing that documentation faces the same information gap. It may explain the approved architecture and recommend familiar troubleshooting steps. It cannot reliably reconstruct the missing experimental history simply because its language model is capable of sophisticated reasoning.

This illustrates a problem that extends beyond infrastructure engineering.

A laboratory may preserve successful synthesis results without making every unsuccessful attempt accessible. Manufacturing systems may capture production metrics without preserving an operator’s interpretation of an unusual vibration. Experienced workers may recognize weak signals that were never translated into measurements or formal decision rules.

The unrecorded experience is not necessarily secret, proprietary, or particularly complicated. Often, it simply disappeared because no process existed to preserve it.

For enterprise AI, this raises a more useful question than how many additional documents we can ingest:

How do we preserve the evidence generated while people investigate, experiment, make decisions, and interact with real systems?

This article focuses on that missing evidence and the architecture required to capture it. It does not assume that every observation is correct, that all tacit expertise can be digitized, or that AI should be permitted to experiment autonomously in production.

The Knowledge We Preserve Is Often the Final Answer

Most enterprise documentation is organized around the result of work.

Architecture diagrams describe the approved design. Runbooks describe the supported procedure. Change records document authorized modifications. Incident reports explain how a service was restored.

These artifacts are essential. They support repeatability, accountability, maintenance, and operational consistency.

However, a final result represents only a portion of the work that produced it.

Consider the difference between these records:

An organization can have excellent documentation while still losing substantial amounts of its experiential knowledge.

Success Creates a Selection Problem

Consider an AI assistant that retrieves ten incident records. All ten describe a particular remediation as successful.

That pattern appears convincing.

But suppose the underlying engineering team attempted the same remediation thirty times, and it worked only under specific environmental conditions. If twenty unsuccessful attempts were never captured, the available records provide a misleading picture of its reliability.

The numbers here are illustrative, but the underlying statistical issue is real: a dataset selected around successful outcomes may not represent the wider population of attempts.

Scientific publishing has long recognized a related issue, often called the file drawer problem. Research with positive or statistically significant findings can be more likely to reach the published literature than research with null or unfavorable outcomes. The 2024 Nature Neuroscience editorial Reducing publication bias with Registered Reports discusses this problem and the effort to evaluate research methods before results are known.

Enterprise operational records can develop an analogous bias when documentation systems favor resolutions over unsuccessful investigations.

The practical consequences matter:

• A remediation may appear more reliable than the available evidence supports.
• A design recommendation may omit conditions under which the design fails.
• A troubleshooting assistant may repeatedly suggest approaches already rejected by experienced engineers.
• A project team may repeat expensive experiments because the earlier results are inaccessible.
• A successful outcome may be confused with proof that the preceding intervention caused it.

More retrieval capacity does not solve this selection problem when the missing observations were never recorded.

Negative Evidence Is Not Necessarily Failed Knowledge

The term failure needs care.

A test that does not achieve its objective may still provide useful evidence. But it does not always establish that the underlying hypothesis was wrong.

For example, suppose an engineer increases an application timeout and sees no measurable improvement.

That observation may weaken the hypothesis that the timeout setting was responsible. It may also be inconclusive because the test window was too short, the workload changed, another constraint dominated performance, or the monitoring data was incomplete.

A useful evidence system must distinguish:

Without these distinctions, capturing more unsuccessful attempts may simply produce a larger collection of misleading conclusions.

The objective is to preserve what was observed, how it was observed, and what conclusions the evidence can support.

Experiential Knowledge Comes in Different Forms

There is a temptation to describe all undocumented expertise as tribal knowledge. That term is too broad to guide an architecture decision.

Several different forms of missing information require different collection methods.

Undocumented Decisions

These include the alternatives an engineer considered, the assumptions used to reject them, and the reasoning behind the selected approach.

They can often be captured through short decision records linked to changes, incidents, experiments, or architecture reviews.

Unsuccessful Experiments

An experiment may fail to produce its intended result but still constrain the remaining solution space.

Capturing the proposed hypothesis, intervention, test conditions, observed outcome, and limitations allows another engineer or AI system to evaluate whether repeating the experiment is justified.

Tacit Expertise

Some expertise is difficult to express as a procedure.

An experienced mechanic may recognize a combination of engine sounds. A factory operator may detect an unusual vibration before a conventional alert threshold is crossed. An engineer may notice that a system is behaving differently from previous incidents even when its headline metrics look normal.

Capturing this expertise may require structured interviews, annotated sensor recordings, synchronized telemetry, or guided observation.

It is important not to confuse recording an expert’s interpretation with independently proving it. The interpretation is a valuable source of hypotheses, but measurement and validation remain necessary.

Environmental Context

A solution that works in a test environment may fail in production because of traffic patterns, component versions, hardware differences, topology, timing, data distribution, or external dependencies.

This information may already exist in logs, inventory systems, change histories, and monitoring tools. What is missing is often the relationship between those records and the decision being investigated.

An individual log event tells us something happened. A contextualized evidence record explains what was being tested when it happened and why the observation matters.

A Missing Evidence Layer for Enterprise AI

The proposed architecture is a governed evidence layer that preserves meaningful episodes of engineering and operational activity.

An episode is a bounded sequence involving a question, hypothesis, action, observation, and possible conclusion. A production incident, approved change, laboratory trial, or controlled performance test can each contain several episodes.

This is a narrower and more actionable idea than capturing every keystroke, conversation, or sensor reading indefinitely.

The following architecture separates raw observations from reviewed knowledge.

The key architectural distinction is that capturing an event, validating its meaning, and allowing an AI system to use it are separate operations.

A telemetry collector can capture what happened without deciding why. An engineer can offer an interpretation without turning it into an enterprise-wide rule. An AI assistant can retrieve the record without receiving permission to repeat the recorded intervention.

This separation also protects existing operational authority boundaries. The evidence layer is not a replacement for change control, privileged access management, experiment approval, or production safety systems.

The Evidence Record Needs Provenance

For experience to become reusable knowledge, the system must preserve its origin and context.

The World Wide Web Consortium’s PROV model provides a useful conceptual basis. It distinguishes entities, activities, and agents, enabling systems to describe what information was produced, which process produced it, and who or what was responsible.

An enterprise implementation does not need to adopt every part of PROV. It does need a comparable understanding of lineage.

For each episode, the organization should be able to reconstruct who or what performed an intervention, which environment and configuration were involved, what observations were captured, what evidence supports the conclusion, and whether the result remains applicable.

OpenTelemetry can provide correlated traces, metrics, and logs as part of that evidence. However, observability alone does not capture the engineer’s question, hypothesis, or interpretation. Both forms of information are needed.

A-Lab Shows Both the Opportunity and the Verification Problem

A useful example of AI interacting with reality comes from materials science.

The autonomous laboratory known as A-Lab combined machine learning, computational predictions, historical information, robotics, and experimental feedback to investigate the synthesis of inorganic materials.

Its research, published in Nature in November 2023, demonstrated an experimental system capable of using observed results to inform subsequent work.

This is fundamentally different from asking a language model to summarize scientific papers. The system could participate in producing new experimental evidence.

That distinction is important because an experiment can test assumptions that a training corpus cannot directly resolve.

However, A-Lab also provides an important warning about verification.

The January 2026 Correction Matters

On January 19, 2026, Nature published an author correction to the original A-Lab research.

The correction addressed concerns about identifying compound structures from diffraction measurements and about how the novelty of the reported materials had been described. The authors clarified that novelty referred to materials being new to the prediction platform, not necessarily previously unknown to science.

After manually reanalyzing diffraction patterns, the authors confirmed the platform’s conclusions for 36 of 40 reported successful syntheses. Four remained inconclusive. The correction also removed one compound from the discussion because it had mistakenly been included in the training data.

These details are significant.

The revised results still describe a functioning autonomous experimental system. The correction does not justify dismissing the broader approach to automated synthesis. But it demonstrates that an experimental feedback loop can produce conclusions requiring later reassessment.

An AI system can formulate a hypothesis, execute an authorized experiment, interpret instrument measurements, and select another experiment. None of those capabilities automatically establishes that its interpretation is correct.

Independent review, appropriate measurement methods, reproducibility, and explicit uncertainty remain essential.

The lesson for enterprise architects is that contact with reality improves the available evidence, but contact alone does not guarantee correct understanding.

A production-oriented evidence architecture should therefore preserve raw measurement artifacts and the ability to revise conclusions without erasing the original observation.

Build an Experience Record, Not Another Document Repository

The most practical starting point is a structured record of an engineering or experimental episode.

This record should explain the question being investigated, the action taken, the context in which it occurred, and the evidence obtained.

It should also make uncertainty visible.

Minimum Evidence Fields

The fields are intentionally focused on reconstructing an experiment or decision.

A complete transcript of every engineer’s activity is neither necessary nor desirable. The system needs enough information to understand consequential decisions and compare their observed outcomes.

A Machine-Readable Example

Consider an application experiencing intermittent request timeouts during a network failover scenario.

An engineer suspects that a client timeout configuration is responsible and tests a change in a controlled environment.

The following YAML illustrates how the experimental evidence could be recorded. It is a proposed, vendor-neutral schema, not a supported product configuration or a record of an actual test.

apiVersion: dtd.example/v1
kind: ExperienceRecord

metadata:
  record_id: example-001
  record_type: controlled_test

scope:
  service: orders-api
  environment: staging
  scenario: network-failover
  owner: application-platform-team

investigation:
  question: >
    Are client timeout settings responsible
    for request failures during failover?

  hypothesis: >
    Increasing the client timeout will
    reduce failover-related errors.

intervention:
  category: configuration-test
  approval_reference: example-change-reference
  action: increase-client-timeout

observations:
  result: >
    Request timeouts continued during
    the observed test window.

  evidence_references:
    - telemetry-before-change
    - telemetry-after-change
    - network-trace-reference

assessment:
  status: inconclusive
  confidence: low

  limitations:
    - staging-traffic-not-production-equivalent
    - insufficient-failover-samples

verification:
  independent_review: pending
  reviewer_role: application-owner

knowledge_use:
  classification: internal
  scope: orders-api-failover-investigation
  approved_for_shared_guidance: false
  approved_for_model_training: false

This example makes a useful distinction.

The intervention did not produce the desired improvement, but the evidence is insufficient to establish that the underlying hypothesis is false in every environment. The record remains inconclusive.

An AI troubleshooting assistant should be able to retrieve the record and explain that limitation.

It could recommend a better-controlled follow-up test instead of treating the unsuccessful attempt as proof that client timeout settings are irrelevant.

The knowledge_use fields describe intended policy. They do not enforce it by themselves. In an actual implementation, access control, retrieval filtering, retention, and training-data admission require enforceable platform mechanisms.

Successful adoption of this pattern would allow an organization to reconstruct prior tests and their limitations. It would not automatically authorize production changes or establish a universal troubleshooting procedure.

How to Capture Experience Without Creating More Administrative Work

The largest implementation risk may be the operational burden of capturing this information.

If engineers must write a detailed report every time they investigate a problem, the system will quickly become another compliance exercise.

Instead, the architecture should collect what it can automatically and request human input only where interpretation is necessary.

Start with One High-Value Investigation Class

Choose a bounded use case where missing experimental history creates measurable costs.

Good candidates include recurring network failures, repeated performance investigations, unsuccessful change attempts, infrastructure compatibility issues, or laboratory experiments involving expensive equipment.

Avoid beginning with an enterprise-wide initiative to capture all employee knowledge.

The first pilot should demonstrate that a specific form of missing experience can be captured accurately and reused.

Collect Evidence from Existing Systems

Many enterprise systems already preserve useful fragments of evidence:

• Observability platforms capture logs, traces, and metrics.
• Change-management systems capture approvals and implementation windows.
• Source control records code and configuration differences.
• Incident-management platforms retain timelines and remediation activities.
• Configuration and asset repositories provide environment context.
• Automated test systems preserve execution artifacts and results.

The opportunity is to correlate these existing signals around an episode identifier.

Where compatible identifiers are absent, integrations should provide explicit mappings rather than assuming that matching timestamps or service names prove a relationship.

Ask Engineers for Decisions, Not Transcripts

Human enrichment should focus on a few questions that machines cannot reliably infer:

What were you attempting to prove? What did you observe that surprised you? What explanation do you currently favor? What evidence is missing? Under what conditions should this approach not be repeated?

A short, structured reflection at an important decision boundary may be more valuable than a lengthy unstructured incident transcript.

The capture experience should fit into existing change, incident, engineering, or laboratory workflows.

Separate Storage from AI Access

An evidence record may contain sensitive operational data, proprietary research, customer information, credentials inadvertently captured in logs, or regulated information.

Preserving the record does not mean every AI system should be able to retrieve it.

Apply identity-aware access controls, classification, redaction, purpose restrictions, retention periods, and audit logging. Where data cannot legitimately be retained, preserve a permitted summary or metadata rather than collecting restricted source material.

This is especially important when capturing expert observations in healthcare or other regulated environments. The proposal is to preserve reusable technical evidence, not to indiscriminately collect patient encounters or personal data.

Measure Whether the Additional Evidence Improves Decisions

A larger repository is not automatically a better knowledge system.

The objective should be measurable improvement in engineering decisions, not the number of events collected.

A practical pilot can compare an AI assistant using existing approved documentation with the same assistant using the additional, permission-controlled experience records.

Both configurations should be evaluated against representative, held-out cases. The evaluation should avoid giving the richer system information that was only discovered after the historical decision being assessed.

The following measures would help determine whether the proposed evidence layer is worthwhile.

No improvement should be assumed before measurement.

A useful pilot would establish the current baseline, introduce evidence capture for a limited class of investigations, evaluate decisions using a consistent method, and compare the results.

Where possible, reviewers should assess the recommendations without knowing which evidence configuration produced them.

If the system produces longer explanations but no improvement in decisions, the evidence layer has not demonstrated its value.

If it causes engineers to repeat fewer inappropriate interventions while maintaining safe escalation behavior, that would be meaningful evidence of benefit.

Governance Determines Whether Experience Becomes Trustworthy Knowledge

Experiential knowledge carries risks that conventional documentation practices may not fully address.

An engineer can draw an incorrect conclusion. A sensor can be miscalibrated. An experiment can be confounded by simultaneous changes. A valid result can become obsolete after a platform upgrade.

Consequently, the evidence layer needs an explicit operating model.

These are proposed responsibilities, not evidence of a particular organizational structure.

The NIST Artificial Intelligence Risk Management Framework provides a useful voluntary governance foundation for evaluating the reliability, transparency, accountability, and lifecycle risks of AI systems.

The operational implementation must still define concrete controls, owners, review procedures, and evidence requirements appropriate to the organization.

Avoid Turning Experience into Permanent Truth

An evidence record should retain its original observation even when later analysis changes the interpretation.

For example, an initially suspected network fault may eventually be traced to application behavior. The original observation should remain available for historical reconstruction, but the unsupported diagnosis should no longer appear as an accepted finding.

Records therefore need versioned interpretations, review status, effective scope, and mechanisms for correction or withdrawal.

Successful outcomes also need qualification. An intervention can restore service without proving that the suspected root cause was correct.

Do Not Automate Learning From Every Observation

There are several ways an AI system can benefit from newly captured evidence.

It can retrieve approved records during inference. It can use selected records in an evaluation dataset. It can inform a proposed experiment. It can support expert review of a procedure.

A later decision may justify updating instructions, retrieval content, or model parameters.

Those are separate lifecycle choices, with different risks and approval requirements.

The evidence layer should not automatically convert every unsuccessful experiment into a warning, every successful intervention into a runbook, or every engineer’s judgment into authoritative knowledge.

Likewise, collecting more evidence should not create a surveillance mechanism that discourages engineers from investigating difficult problems or documenting mistakes.

The records should support learning and accountability, with proportionate retention, access, and employee-data protections.

What This Changes for Enterprise AI Architecture

The missing evidence problem changes how architects should evaluate enterprise AI readiness.

An organization may have a sophisticated model-serving platform, a well-designed retrieval-augmented generation (RAG) system, and strong API security, yet still lack the evidence required to answer its most difficult operational questions.

Those components solve important problems, but none can reconstruct observations that were never preserved.

This suggests several architecture priorities.

First, preserve the path to consequential decisions. A final configuration is useful, but the rejected options and the reasons behind them can be equally valuable.

Second, correlate measurements with interventions. Logs and metrics become more useful when the system knows which hypothesis was being tested, what changed, and which conditions remained constant.

Third, qualify knowledge before reuse. The system must distinguish what happened, what someone believes happened, and what independent evidence supports.

Fourth, preserve boundaries. An AI assistant receiving access to experiential evidence should not automatically acquire broader permissions to change infrastructure, operate equipment, or modify shared knowledge.

Finally, build the feedback loop around externally observable outcomes. Do not treat a model’s own explanation as sufficient proof that an experiment or remediation succeeded.

This approach can improve the evidence available to an AI system without assuming that increasing model size, adding context tokens, or continuously retraining weights is the right solution.

Conclusion

We have made enormous progress in preserving humanity’s formal knowledge. Research publications, technical documentation, source repositories, operational databases, and digital records provide AI systems with a remarkable foundation.

But an important portion of human learning still happens outside those durable records.

It happens when an engineer rejects a design after discovering an unexpected dependency. When an experiment fails under conditions that were never reported. When an experienced operator notices a weak signal before an automated threshold triggers. When a troubleshooting team discovers what does not work but documents only the final remediation.

The value of that experience is not automatically captured in the resulting configuration, publication, or completed ticket.

The opportunity for enterprise AI is to make useful experience observable, structured, permission-controlled, and independently verifiable. AI systems can then use that evidence to improve retrieval, reasoning, evaluation, and the selection of future experiments, without treating every observation as unquestionable truth.

The practical starting point is small: select one recurring engineering problem, preserve the hypotheses and unsuccessful attempts around it, connect the associated telemetry, and evaluate whether the additional evidence changes future decisions.

The question worth asking is this: If your most experienced engineer left tomorrow, could your AI systems reconstruct what that engineer learned from the approaches that failed?

If the answer is no, the next valuable AI investment may be in preserving evidence that your organization currently allows to disappear.

The next article in this series examines how to design an enterprise experience ledger that captures this knowledge systematically, without turning it into an uncontrolled data lake or another documentation burden.

External References

• Nature: An autonomous laboratory for the accelerated synthesis of inorganic materialsCanonical URL: https://www.nature.com/articles/s41586-023-06734-w
• Nature: Author Correction: An autonomous laboratory for the accelerated synthesis of inorganic materialsCanonical URL: https://www.nature.com/articles/s41586-025-09992-y
• Nature Neuroscience: Reducing publication bias with Registered ReportsCanonical URL: https://www.nature.com/articles/s41593-024-01762-9
• World Wide Web Consortium: PROV Model PrimerCanonical URL: https://www.w3.org/TR/prov-primer/
• OpenTelemetry: SignalsCanonical URL: https://opentelemetry.io/docs/concepts/signals/
• National Institute of Standards and Technology: AI Risk Management FrameworkCanonical URL: https://www.nist.gov/itl/ai-risk-management-framework

The post AI’s Missing Evidence Layer: The Failures We Never Record appeared first on Digital Thought Disruption.