Assessment
Levels, claims, and the observableAssessments slot shape
This page is the reference for the assessment machinery: the evidentiary levels, the claim type, and the exact shape of the slot.
Assessment levels
Five tiers, ordered by how strongly the signal is established:
| Level | Meaning |
|---|---|
not_indicated | Evaluated and found absent — an explicit negative, not missing data |
reported | Asserted by witnesses, but not independently documented |
documented | Written records, photographs, or contemporaneous documentation of the signal exist |
measured | Quantitative instrument data captured the signal — radar, FLIR, or other sensors |
confirmed | Peer-reviewed analysis with independent verification establishes the signal |
import { ASSESSMENT_LEVELS, isAssessmentLevel, formatAssessmentLevel } from '@disclosureos/observables';Two distinctions worth internalizing:
not_indicatedvs. absence. An observable missing from the map means nobody evaluated it.not_indicatedmeans somebody looked and found nothing — which is real, scoreable information.- Level vs. confidence. The level says what kind of evidence backs the claim;
confidencesays how sure the evaluator is of their own judgment. A radar-measured anomaly with ambiguous data ismeasuredwith low confidence — notreported.
The claim shape
ObservableClaim composes the shared Claim envelope with the level and confidence:
interface ObservableClaim {
level: AssessmentLevel;
confidence?: number; // [0, 1]
rationale?: string; // the evaluator's reasoning
evaluatedBy?: string; // who made it
evaluatedAt?: string; // ISO datetime (factory defaults to now)
evidenceRefs?: string[]; // "sensor:<id>", "media:<id>", ...
}Build claims with the factory — it parses on construction, so out-of-range confidence throws:
import { createObservableClaim } from '@disclosureos/observables';
const claim = createObservableClaim('measured', {
confidence: 0.7,
rationale: 'Two independent radar tracks with consistent kinematics.',
evidenceRefs: ['sensor:radar-01', 'sensor:radar-02'],
evaluatedBy: 'example-institution',
});Note there's no observableId field — the claim's position in the map supplies it.
The slot shape
interface ObservableAssessmentMap {
technology?: Partial<Record<TechnologyObservableId, ObservableClaim[]>>;
biologics?: Partial<Record<BiologicsObservableId, ObservableClaim[]>>;
}observation.observableAssessments = {
technology: {
instantaneous_acceleration: [claimFromSCU, claimFromAARO], // arrays — always
low_observability: [
createObservableClaim('not_indicated', {
rationale: 'Object maintained continuous track on all sensors.',
}),
],
},
};Arrays are the point. When two institutions assess the same observable differently, both claims stand, attributed. The scoring layer reads the spread: agreement strengthens a case, contradiction flags it contested.
Standalone assessment type
ObservableAssessment is the claim plus an explicit observableId — useful when claims travel outside the map (queues, review tools, exports):
import type { ObservableAssessment } from '@disclosureos/observables';
// { observableId: string; level: AssessmentLevel; confidence?: number; ... }Validation
import { validateObservableAssessments } from '@disclosureos/observables';
const issues = validateObservableAssessments(observation.observableAssessments);
// ValidationIssue[] — unknown observable ids, bad levels, out-of-range confidenceThis validates the slot in isolation. For the whole enriched record — including whether claim evidenceRefs resolve — use parseEnrichedObservation and disclosureos validate.