Identity
Bind each spacecraft, sensor, ground station, operator, mission and payload to an authenticated identity and declared authority scope.
Draft specification · Research stage
Verification architecture for orbital events.
OSOIX Verify is intended to convert authenticated telemetry and independent observations into evidence that can be inspected, challenged and audited. This document defines the first public architecture and event model; it does not claim an operational verification service.
Verification chain
Acquisition
Collect signed telemetry, calibrated sensor output, mission-control records and independent observations with source and timestamp provenance.
Normalization
Convert heterogeneous inputs into a common event envelope without erasing their original source records or uncertainty.
Reconciliation
Compare expected, observed and independently corroborated states; record agreement, divergence and unresolved ambiguity.
Decision
Apply explicit verification rules and human review where required. General AI may assist analysis but cannot silently establish physical truth.
Evidence
Assemble the event record, source references, signatures, confidence, discrepancies and reviewer decisions into an auditable evidence package.
Use
Permit approved downstream uses such as mission review, regulatory reporting, insurance evidence or commercial settlement.
Assurance principles
Physical truth begins outside the ledger
A database or blockchain can preserve records, but cannot prove that a physical orbital event occurred without trustworthy sensors, identities and observations.
Provenance is mandatory
Every measurement and derived conclusion must retain its source, acquisition time, transformation history and signing identity.
Uncertainty is preserved
The system must record confidence, tolerances and conflicting observations rather than forcing a false binary answer.
Verification rules are inspectable
Rule versions, thresholds, reviewers and exceptions must remain reconstructable after the event.
Safety-critical control remains separate
Verification may inform decisions, but it does not replace deterministic flight controls, hardware interlocks or human authorization.
Settlement is downstream
No payment, certificate or contractual milestone should be triggered before the required verification state is reached.
Verifiable Event Model · Draft 0.1
Minimum public event envelope
{
"spec_version": "osoix-event-draft-0.1",
"event_id": "evt_...",
"event_type": "capture.confirmed",
"mission_id": "mission_...",
"asset_ids": ["asset_..."],
"observed_at": "2026-08-03T00:00:00Z",
"sources": [
{
"source_id": "sensor_...",
"identity": "did:example:...",
"record_hash": "sha256:...",
"signature": "..."
}
],
"expected_state": {},
"observed_state": {},
"discrepancies": [],
"confidence": 0.0,
"verification": {
"status": "unverified",
"rule_set": "verify-draft-0.1",
"review_required": true,
"reviewer_ids": []
},
"evidence_package_hash": "sha256:..."
}The envelope is intentionally transport-neutral. Future implementations may use conventional databases, signed object storage, permissioned ledgers or other regulated infrastructure. A ledger is not required for every use case.
Current boundary
This is a concept-stage specification. OSOIX does not currently operate a certified verification service, flight-qualified sensor trust chain, public production API, customer deployment or regulatory approval. The next evidence step is a reference implementation using simulated telemetry and independently generated observations.