Nexus Observatory Sign inCreate account
Observatory Protocol

/

Specification

/

Specification

Observatory Protocol 0.1.

The Observatory Protocol lets an instrument or computer that has never met the grid join it, prove what it is, keep time, publish what it measures with its metadata and quality, and be orchestrated, corrected, federated and finally retired, without trusting any single vendor, cloud or central service. This document is the draft specification of that protocol.

Read the specificationContribute
Functions
12
State machines
11
Objects
21
Standards
48

The practice this part continues.

1854 The observation as a public instrument
Vice-Admiral Robert FitzRoy founded the Met Office in 1854. The national weather service that followed rested on a premise this specification inherits: an observation becomes useful to others only when the conditions of its making are known and shared. [1]
1881–1884 Coordinated campaigns
The first International Polar Year, inspired by Karl Weyprecht, took place from 1881 to 1884 as the first series of coordinated international expeditions to the polar regions. It established that comparable measurement across sites is a matter of agreed method before it is a matter of instruments. [2]
1984 End to end, rough consensus
Saltzer, Reed and Clark argued that functions placed in the network can be completely and correctly implemented only with the knowledge of the end systems; RFC 1958 recorded the principle for the Internet’s architecture. The IETF’s working method, summarised in RFC 7282 as “rough consensus and running code”, sets the standard for how an open protocol should change. The protocol keeps authority at the site and changes only through open proposals. [3][4][5]

What the specification defines.

In scope
The participant roles, objects, identifiers, state machines, messages and wire bindings for the twelve functions, the conformance profiles and the security model.
Not a public authority
Warnings, emergency dispatch, regulation, spectrum assignment, insurance, certification and law enforcement stay with competent external bodies. A protocol receipt creates no legal, regulatory or financial authority.
No token
The protocol defines no token, coin or tradable unit.
Key words
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT and MAY are used as in RFC 2119 and RFC 8174 when they appear in capitals.

Eleven normative principles.

The commitments every function and state machine is held to.

Zero implicit trust
A participant starts untrusted. Trust is earned by attestation, admission and evidence, and lapses on expiry or revocation.
One owner per fact
Each fact family has exactly one authoritative owner. A site MAY cache and continue bounded state; it MUST NOT become a silent second source of truth.
Local first, offline is not policy-free
Approved local operation MUST continue through loss of upstream links for the autonomy window in the plan. Expired authority, revoked identity, compromised time or missing mandatory evidence MUST force quarantine even offline.
Typed, receipted commands
Every consequential command carries identity, purpose, policy, authority, repeat-safe key and a receipt.
Products keep their context
Every value carries provenance, time, uncertainty, quality, confidence and correction state.
Replaceable providers
Hardware, software, cloud, radio, satellite, model, data and service providers are replaceable behind typed contracts, with a tested exit path.
Separated planes
Control, data, evidence and exchange planes are separate. The exchange plane MUST NOT create an inbound management path into a site.
Each step is its own evidence
Installation is not qualification; qualification is not observation; observation is not assessment. No state is reached by wording.
Correction without erasure
Records are correction-addressable. Replacement never deletes history.
Scoped proof
A proof proves only the claim and scope in its evidence.
No dependency on another party
A conforming deployment MUST be operable by its owner without any service, data or approval from another organisation, unless the owner chooses to federate.

The parts of the specification.

Functions

Twelve functions, from first contact to retirement.

Join, Admit, Describe, Time, Observe, Qualify, Federate, Orchestrate, Correct, Exchange, Prove, and Exit.State machines

States are entered on evidence, never on assertion.

Eleven state machines, from enrolment to revocation.Flows

The functions in sequence.

The twelve functions read in order, each handing the next the objects it produces.Objects

What passes between participants.

21 typed objects: declarations, descriptions, plans, observations, evidence bundles and the records that link them.Participants

The roles the protocol defines.

9 roles, from the instrument and its node agent to the site operator, the grid and the external authorities whose decisions the protocol records but never assumes.Standards

Composed from open standards.

48 standards the protocol is drawn against, among them 3GPP, O-RAN, ITU-T timing, WMO WIGOS and WIS 2.0, OGC and STAC, and the IETF.Conformance

Conformance is a tested scope, stated with its evidence.

Five profiles define what each kind of implementation must do; four levels define how far that has been shown.Governance

An open specification, changed in the open.

The Nexus Consortium stewards the protocol.Changes

Every change carries its reasons.

A proposal that changes a function updates the specification, the schemas and the conformance tests together, so that text, contract and test never diverge.Implementers

Profiles and planes for implementers.

What an implementation of each profile must provide, and the planes across which it communicates.Wire bindings

One binding per plane, each an open standard.

The normative wire bindings of Observatory Protocol 0.1: control, data, events, exchange, evidence and telemetry.Reference scenes

The systems an observatory is composed of.

Wireframe scenes of the systems to which the protocol applies, each with its parts named for what they do.

References

Sources for the historical and standards statements on this page.

  1. Met Office. “Our history.” www.metoffice.gov.uk/about-us/who-we-are/our-history
  2. NOAA Pacific Marine Environmental Laboratory. “The First International Polar Year: History.” www.pmel.noaa.gov/arctic-zone/ipy-1/History.htm
  3. Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems 2(4). web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
  4. Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org/rfc/rfc1958
  5. Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org/rfc/rfc7282
  6. Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org/rfc/rfc2119
  7. Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org/rfc/rfc8174

Read it, test it, propose a change.

The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.

Read the specificationContribute

The specification, end to end.

The Observatory Protocol is the shared set of rules by which instruments, nodes, sites and clusters join an observing grid, prove what they are, and carry their metadata, time, quality and provenance with every value they produce. It lets hardware and software from any provider take part through typed contracts and admission for a stated scope, so that no vendor, cloud or central service becomes the owner of local truth, and it records evidence for each step.

Read it, test it, propose a change.

The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.

Read the specificationContribute