Observation
is not assessment.

An accurate report can produce an inaccurate operational picture. The failure may begin long before anyone notices a factual contradiction.

Consider a straightforward observation: Subject A enters a public establishment, speaks briefly with Subject B, and leaves. An observer documents the encounter accurately. A second analyst describes the two subjects as associates. A third system converts that description into a relationship edge. Later reports repeat the relationship, and the association begins to appear established.

At the beginning of this chain there was an event. At the end there is an apparently corroborated conclusion. The record may never contain evidence sufficient to connect the two.

No deliberate dishonesty is required. Ordinary interpretation, abbreviated reporting, interface defaults, and the tendency to reuse prior assessments can transform a reasonable possibility into a durable claim of fact. If left unexamined, that claim may affect prioritization, tasking, resource allocation, and operational decisions.

WP-002 proposes an engineering discipline for that problem. It does not demand that analysts stop interpreting information. Interpretation is indispensable. It requires that the system preserve the distinction between the original record, the proposed explanation, the assessed conclusion, and any action subsequently authorized.

One encounter. Several possible explanations.

An observer reports that Subject A speaks with Subject B for approximately five minutes. The interaction is directly observed, but its purpose is unknown. A prior relationship is possible. So are a chance encounter, a routine service interaction, mistaken identification, or a deliberately staged approach.

This distinction also protects against adversarial manipulation. An observed event can be genuine and still be deliberately arranged to produce a misleading inference. In that case, stronger confidence in the observation does not necessarily produce stronger confidence in the inferred relationship.

Five records. Five different responsibilities.

A conventional system may store observations and conclusions as paragraphs, notes, tags, or undifferentiated relationship records. That format is easy to enter and difficult to interrogate. WP-002 proposes typed information objects with explicit links between them.

These objects need not be displayed to the operator as five complicated forms. The distinction belongs in the underlying model even when the interface presents a concise view. Good software can reduce visible friction without destroying the distinctions that make later review possible.

Repetition is not verification.

A relationship claim is introduced in an analyst note. A subsequent report cites that note. Another system ingests the subsequent report and treats it as new corroboration. A graph now shows multiple references supporting the same edge. The appearance of growing certainty is an artifact of document circulation, not independent observation.

Systems should therefore preserve both content lineage—where a claim originated—and evidence lineage—which underlying observations actually support it. Reports that derive from the same origin may still be useful, but should not silently count as independent confirmation. This connects WP-002 directly to WP-003, The Independence Problem.

Confidence must have an object

High confidence that an interaction occurred is not high confidence that the participants were associates. High confidence in a source's identity does not establish the accuracy of every source statement. Even when the same report contains all three claims, each has a different basis and must be independently reviewable.

Correction cannot erase history

When an assessment changes, the system should preserve the prior judgment, its supporting material, the reason for revision, and the subsequent operational consequences. Quietly overwriting an old relationship edge produces a clean current picture at the cost of accountability. A revision history is part of the evidence model, not an optional audit decoration.

Make the distinction enforceable.

For Command-1 research, the following are proposed functional requirements for a prototype information-integrity layer. They are not claims about currently deployed behavior.

1. Typed records. The data model distinguishes observation, assertion, hypothesis, assessment, and decision at the storage and service layers.
2. Source preservation. Every record retains who or what supplied it, when it was created, and the path by which it entered the system.
3. Relationship discipline. An observed interaction may produce an interaction record; it cannot automatically establish association, affiliation, intent, or shared purpose.
4. Explicit derivation. Assertions and assessments link to supporting or contradicting records, including derivative-report lineage.
5. Attributable judgment. An assessment includes author, time, rationale, confidence basis, limitations, and material alternative explanations.
6. No silent promotion. Changes in epistemic status require an explicit, reviewable event rather than an unnoticed transformation during ingestion, synchronization, or summarization.
7. Reversible views. Operators can move from a concise assessment back to the observations and claims on which it depends.
8. Revision history. Contradictions, corrections, and superseded assessments remain available with timestamps and reasons for change.
9. Mission-linked action. New tasks require a documented connection to authorized objectives, rather than automatic escalation from speculative association.
10. Controlled automation. Automated extraction or summarization must label inferred relationships and preserve uncertainty, rather than outputting unsupported assertions as established facts.

Test the failure, not just the feature.

A synthetic evaluation would begin with one observed encounter, two plausible competing explanations, one deliberately unsupported relationship assertion, and several derivative reports that repeat it. The exercise would then introduce contradictory material and require the system to update the current picture without rewriting the history.

The proposed prototype would be evaluated against an ordinary document-and-feed workflow. The purpose is not to show more annotations or richer charts. It is to determine whether the architecture prevents unsupported promotion of claims while still allowing analysts to reach timely, defensible decisions.

A successful demonstration would need to establish measurable improvement, including an assessment of tradeoffs. An implementation that reduces false inferences but delays critical recognition, or overwhelms users with annotations, has not fully solved the operational problem.

Traceability is not truth.

Even a perfectly preserved observation may be incomplete, mistaken, selectively framed, or staged. Provenance describes the origin of a claim; it does not guarantee the claim is accurate. Confidence scores may imply precision that the evidence cannot support. Separating records also cannot eliminate cognitive bias or substitute for experienced human analysis.

The proposed model introduces implementation costs: greater storage complexity, version management, source-protection concerns, and potential user friction. Sensitive-source handling and access controls may appropriately limit what an operator can inspect, requiring carefully designed provenance summaries rather than indiscriminate disclosure.

Most importantly, maintaining alternative hypotheses does not mean assigning every explanation equal weight. Analysts must remain able to dismiss unsupported possibilities, concentrate on the assigned mission, and change course when new evidence genuinely warrants it.