Deployed evidence longevity · research specification

Evidence that can explain itself after the system changes.

OSOIX immutable orbital evidence is designed so a future investigator can determine what was stored, which exact code produced it, which transformation rules were applied, which cryptographic policy and epoch governed the capture, which immutable record came before it, and whether the resulting historical chain can still be reproduced.

The reproducibility chain

01 · What data was stored?

The exact immutable orbital-catalog payload is retained and bound to a canonical SHA-256 digest. Historical replay opens that stored payload; it does not silently substitute newer orbital elements or re-propagate the past.

02 · What exact code produced it?

Every reproducible v2 capture binds the full 40-character producer Git revision. A capture without an exact deployed source revision is not eligible to become v2 reproducibility evidence.

03 · What transformation semantics were used?

The evidence manifest records the orbital transformation version, catalog profile, coordinate reference, propagation model, decay policy, position meaning, refresh policy and the satellite.js dependency version used for that historical state.

04 · What crypto policy / epoch governed it?

The cryptographic policy manifest that existed at capture time is embedded into the evidence record and hashed. Historical verification checks that embedded policy against its own digest instead of assuming that the current OSOIX crypto policy is still the same.

05 · Which evidence record preceded it?

New v2 records form a SHA-256 predecessor chain. PostgreSQL serializes v2 inserts and requires the declared predecessor to match the latest immutable v2 manifest, preventing two concurrent captures from silently forking the evidence chain.

06 · Is the historical chain still reproducible?

A record-only verifier recomputes payload and manifest digests, validates producer/temporal/transformation context, checks the embedded historical crypto context and verifies predecessor continuity. The verifier does not need the live OSOIX crypto-policy module or network access.

Current deployed orbital evidence layer

V1 history is preserved. New evidence can carry a self-describing v2 manifest.

Existing v1 immutable snapshots remain exactly what they were: payload-integrity evidence. OSOIX does not retroactively attach provenance that was never captured. Reproducible v2 records add forward-only context and establish their own genesis/predecessor chain only when a legitimate v2 capture occurs.

Canonical payload SHA-256

Exact producer Git revision

Source-generation and capture timestamps

Orbital transform/profile semantics

Coordinate reference and SGP4/SDP4 propagation context

Decay policy and dependency version

Embedded historical cryptographic policy manifest

Cryptographic policy digest and epoch context

Previous evidence-manifest SHA-256

Genesis vs linked-chain position

Evidence-only / no-command boundary

Public / private boundary

Transparency does not mean exposing operational secrets.

This public page explains schemas, integrity logic, reproducibility semantics and safety boundaries. Private Mission Control contains actual operational freshness, source-health details, evidence counts, current manifest hashes, assurance-domain states and alert thresholds. OSOIX does not publish private endpoints, credentials, private-key material, restricted source topology or sensitive reviewer/provider details.

How OSOIX operators are informed

Operational changes should become explicit signals—not hidden numbers.

The private OSOIX Alert Center converts authoritative Mission Control health and evidence state into actionable read-only signals. Alerting never executes remediation or grants operational authority.

In-app Alert Center

Private Mission Control derives current alerts from its authoritative operations overview: orbital freshness, source availability, immutable evidence state, v2-chain maturity, assurance-domain readiness, cryptographic-survivability state and the no-command boundary.

Server durable alert ledger

An hourly server-side durable alert transition ledger evaluates the same authoritative operations model even when Mission Control is closed. It records evaluations and opened, changed, resolved or reopened alert transitions; this monitoring history is operational state, not immutable orbital evidence.

Browser / PWA alerts

An operator may explicitly opt in to browser notifications. OSOIX notifies only newly appearing warning or critical transitions, and does not repeatedly notify an unchanged condition on every health refresh.

Local transition history

Mission Control retains a bounded browser-local alert-transition history for operator convenience. This local history is not an immutable server incident ledger and is not treated as evidence authority.

External delivery

Email, webhooks and true background push are not represented as active until a real delivery destination/provider is configured and verified. OSOIX does not claim that a notification was sent when no delivery channel exists.

Portable evidence package · broader research format

Required package components

The broader OSOIX Evidence Package remains a transport-neutral research format for packaging verified events, source references, decisions, integrity material and limitations beyond the narrower deployed orbital snapshot chain.

Manifest

Package identity, specification version, creation time, producer identity, included records and cryptographic hashes.

Event records

One or more verifiable event envelopes describing observed states, verification decisions and unresolved discrepancies.

Source index

References to signed telemetry, sensor output, mission-control logs, images, third-party observations and calibration records.

Decision record

Verification rules, thresholds, software versions, reviewer identities, approvals, exceptions and timestamps.

Integrity material

Content hashes, signatures, certificate chains, revocation information and optional trusted timestamp evidence.

Disclosure record

Known gaps, confidence limits, excluded sources, conflicting observations and restrictions on downstream use.

Portable package lifecycle

STEP 01
Create package manifest and immutable package identifier
STEP 02
Attach original source references without rewriting them
STEP 03
Add normalized event records and transformation provenance
STEP 04
Record automated checks and human review decisions
STEP 05
Seal package with hashes and authorized signatures
STEP 06
Validate package independently before downstream reliance
STEP 07
Archive, supersede or revoke with a traceable status record

Portable Evidence Package · Draft 0.1

Minimum package manifest

{
  "spec_version": "osoix-evidence-draft-0.1",
  "package_id": "evidence_...",
  "created_at": "2026-08-03T00:00:00Z",
  "producer": {
    "identity": "did:example:...",
    "authority_scope": ["mission.review"]
  },
  "mission_id": "mission_...",
  "event_ids": ["evt_..."],
  "artifacts": [
    {
      "media_type": "application/json",
      "uri": "urn:osoix:artifact:...",
      "sha256": "...",
      "source_identity": "did:example:..."
    }
  ],
  "verification_summary": {
    "status": "review_required",
    "confidence": 0.0,
    "unresolved_discrepancies": 0
  },
  "signatures": [],
  "limitations": [],
  "supersedes": null,
  "revocation_status": "active"
}

Portability and independent validation are more important than any particular storage technology. This portable format is broader than the deployed orbital snapshot evidence chain.

Current boundary

The deployed orbital snapshot longevity layer is an internal OSOIX evidence architecture, not an independent certification or regulatory evidence standard. The broader portable Evidence Package remains a draft research specification. No regulator, insurer, customer or aerospace operator is represented as having approved either format.