A lineage of shared observation.
Every element of the protocol answers a problem that observing communities have already met: how to make measurements comparable, how to federate networks without surrendering them, how to agree on time, and how to keep the conditions of a measurement attached to its value.
- 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]
- WMO Global observing as a system
- The World Meteorological Organization’s Global Observing System collects weather, climate, water and environmental data from satellites and surface stations, and is now part of WIGOS, the overarching framework for all WMO observing systems. WIS 2.0 carries the exchange of those data onto open standards and Web technologies. The protocol treats these frameworks as the reference for describing stations and publishing their data. [3][4][5]
- Federations Networks of networks
- The International Federation of Digital Seismograph Networks unites the groups responsible for installing and maintaining seismographs in their own regions; the International GNSS Service has provided open access to high-quality GNSS data products since 1994, giving access to the global reference frame, the ITRF. Each shows that a federation keeps local ownership and still yields one coherent record. The protocol’s rule of one owner per fact, and its federation function, follow that model. [6][7][8]
- 2000 Common standards, many builders
- Since Argo started in 2000, its profiling floats have been built by companies and research institutions alike, all held to common standards set by an international steering team. Replaceable providers behind one shared contract is the arrangement the protocol makes normative. [9]
- 1972 Observation from orbit
- Landsat 1 launched on 23 July 1972 and began the longest-running Earth-observation satellite programme; Copernicus is the European Union’s Earth-observation programme. Space and ground observations meet in one product only when their time, geometry and quality are stated; the protocol requires that context on every value. [10][11]
- Time A shared clock
- Coordinated Universal Time is computed by the BIPM from data contributed by timing laboratories; IEEE 1588 defines the Precision Time Protocol, and ITU-T G.8275.1 profiles it for phase and time synchronisation across networks. In the protocol, time is a function in its own right: a measurement whose clock cannot be trusted cannot be published as trusted. [12][13][14]
- 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. [15][16][17]
- Semantics Shared vocabularies for sensing
- The OGC SensorThings API offers an open, geospatially enabled way to interconnect sensing devices, data and applications; the W3C Semantic Sensor Network ontology, a Recommendation since 2017, gives observations, sensors and samples a common meaning. The protocol describes instruments in these terms rather than in terms of its own. [18][19]
- 2013–2016 Provenance and reuse
- The W3C PROV documents (2013) define an interchange model for provenance; the FAIR Guiding Principles (2016) ask that data be findable, accessible, interoperable and reusable. The protocol attaches provenance, uncertainty, quality and correction state to every value, so that reuse never strips the conditions of measurement. [20][21]
- 2023 Attested identity
- The IETF RATS architecture (RFC 9334) describes how one party appraises evidence about the state of another. The protocol’s Join and Admit functions apply that model to instruments: a participant begins untrusted and is admitted on evidence, not on assertion. [22]
Eleven normative principles.
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.
- 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.
Twelve functions, from first contact to retirement.
Each function moves named objects between named actors and is drawn against open standards. Select a function to read its requirements.
Join
A node proves what it is, receives an identity and a policy, then a signed plan. A node MUST present attestation evidence (RATS, RFC 9334, passport model) rooted in a hardware root of trust where the device class has one (TPM 2.0, DICE or a secure element), or a software root explicitly marked SOFTWARE_ROOT otherwise. A verifier MUST bind the result to a nonce and an expiry. Identity MUST be short-lived and renewable (X.509 SVID, SPIFFE-style URI). Long-lived shared secrets MUST NOT be used. The bootstrap bundle MUST be signed by the site’s enrolment key and carry the trust anchors, policy reference and the first plan digest. Evidence: enrolment receipt, attestation result, identity issuance record.
- Objects
- 8
- Actors
- 0
- Standards
- 5
- Domains
- 6
Objects it moves
Actors it involves
Standards it is drawn against
Domains that rely on it
5G core and edge computing
Positioning, navigation and timing
Edge hardware and runtime
IoT and low-power wireless
Security, identity and supply chain
Field deployment and operations
Participants and the objects they exchange.
Every role and every object the specification defines. Open one to see the functions that use it.
12 of 30
States are entered on evidence, never on assertion.
Select a machine, then a state, to read its transitions and the evidence each one requires.
UNENROLLED
DISCOVERED
ATTESTING
IDENTITY_ISSUED
POLICY_BOUND
PLAN_STAGED
LOCAL_READY
DEGRADED
QUARANTINED
REVOKED
- Selected state
- UNENROLLED
- Leads to
- DISCOVERED when hardware inventory recorded
QUARANTINED when bootstrap integrity failure - Reached from
- Entry state
Composed from open standards.
3GPP, O-RAN, ITU-T timing, IETF attestation, WMO WIGOS, OGC and STAC: the standards the protocol is drawn against. They are design references, not claims of conformity.
12 of 48
One set of functions across observing domains.
The functions on which each observing domain relies. Select a function to open it.
| Domain | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Satellite and non-terrestrial links | Does not use Join | Uses Admit | Does not use Describe | Uses Time | Uses Observe | Does not use Qualify | Uses Federate | Does not use Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| Ground stations and terminals | Does not use Join | Uses Admit | Uses Describe | Does not use Time | Uses Observe | Uses Qualify | Does not use Federate | Does not use Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| Radio access network | Does not use Join | Uses Admit | Does not use Describe | Uses Time | Does not use Observe | Uses Qualify | Does not use Federate | Uses Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| AI-RAN shared compute | Does not use Join | Uses Admit | Does not use Describe | Uses Time | Does not use Observe | Uses Qualify | Does not use Federate | Uses Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| 5G core and edge computing | Uses Join | Uses Admit | Does not use Describe | Does not use Time | Does not use Observe | Does not use Qualify | Uses Federate | Uses Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| Positioning, navigation and timing | Uses Join | Does not use Admit | Does not use Describe | Uses Time | Does not use Observe | Uses Qualify | Does not use Federate | Does not use Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| Edge hardware and runtime | Uses Join | Uses Admit | Does not use Describe | Does not use Time | Does not use Observe | Does not use Qualify | Uses Federate | Uses Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| AI models and agents | Does not use Join | Uses Admit | Does not use Describe | Does not use Time | Does not use Observe | Uses Qualify | Does not use Federate | Uses Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| Earth observation | Does not use Join | Does not use Admit | Uses Describe | Does not use Time | Uses Observe | Uses Qualify | Does not use Federate | Does not use Orchestrate | Does not use Correct | Uses Exchange | Does not use Prove | Does not use Exit and decommission |
| GIS, maps and twins | Does not use Join | Does not use Admit | Uses Describe | Does not use Time | Does not use Observe | Uses Qualify | Does not use Federate | Does not use Orchestrate | Uses Correct | Uses Exchange | Does not use Prove | Does not use Exit and decommission |
| Sensors and instruments | Does not use Join | Does not use Admit | Uses Describe | Uses Time | Uses Observe | Uses Qualify | Does not use Federate | Does not use Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| IoT and low-power wireless | Uses Join | Uses Admit | Does not use Describe | Does not use Time | Uses Observe | Does not use Qualify | Does not use Federate | Uses Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| Power and energy | Does not use Join | Does not use Admit | Does not use Describe | Does not use Time | Uses Observe | Does not use Qualify | Does not use Federate | Uses Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Does not use Exit and decommission |
| Security, identity and supply chain | Uses Join | Uses Admit | Does not use Describe | Does not use Time | Does not use Observe | Does not use Qualify | Does not use Federate | Uses Orchestrate | Does not use Correct | Does not use Exchange | Uses Prove | Does not use Exit and decommission |
| Data, pipelines and exchange | Does not use Join | Does not use Admit | Uses Describe | Does not use Time | Uses Observe | Uses Qualify | Does not use Federate | Does not use Orchestrate | Uses Correct | Uses Exchange | Does not use Prove | Does not use Exit and decommission |
| Field deployment and operations | Uses Join | Does not use Admit | Does not use Describe | Does not use Time | Uses Observe | Uses Qualify | Does not use Federate | Does not use Orchestrate | Does not use Correct | Does not use Exchange | Does not use Prove | Uses Exit and decommission |
| 6 | 9 | 5 | 5 | 8 | 10 | 3 | 8 | 2 | 3 | 1 | 1 |
An open specification, changed in the open.
The protocol is stewarded by the Nexus Consortium. Any party may implement it, and changes are proposed and decided in public.
Read the specificationContribute- Stewardship
- The Observatory Protocol is an open protocol stewarded by the Nexus Consortium. Any party may implement it; changes are proposed upstream, in the open, before any implementation follows them.
- Versioning
- Protocol versions are written obsp/<major>.<minor>. Until 1.0 a minor version MAY break compatibility; from 1.0 only a major version does. Contract schemas carry their own schema version.
- Change proposals
- Changes are proposed in the open as Observatory Improvement Proposals: draft, review, accepted, implemented, or withdrawn. A proposal that changes a function updates the specification, the schemas and the conformance tests together.
- Conformance levels
- Declared, self-tested, lab-tested, qualified, with suspended and withdrawn. A level is reached only with the evidence the profile names. “Conformant” describes a tested scope only; it is never a certification.
- 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.
- Architecture
- Zero trust (NIST SP 800-207): every request is authenticated, authorised and logged; network position grants nothing.
- Device identity
- Attested; hardware root where the class has one; short-lived certificates; revocation within the site’s offline window.
- Workload identity
- SPIFFE-style SVIDs, rotated; no shared secrets.
- Keys
- Site keys held by the grid operator; customer-held keys for upstream services; HSM or TPM-sealed where available.
- Supply chain
- SBOM, SLSA provenance, signed artifacts, TUF update metadata, SUIT for firmware.
- Time
- Authenticated time (P3, §5.4); time integrity gates receipts.
- OT environments
- IEC 62443 zones and conduits for industrial deployments.
- Privacy
- Observation data that can identify a person is a declared data class with its own policy; default is not to collect it.
- Break glass
- Logged, time-bound, receipted.
References
Sources for the historical and standards statements on this page.
- Met Office. “Our history.” www.metoffice.gov.uk/about-us/who-we-are/our-history
- NOAA Pacific Marine Environmental Laboratory. “The First International Polar Year: History.” www.pmel.noaa.gov/arctic-zone/ipy-1/History.htm
- World Meteorological Organization. “Global Observing System (GOS).” community.wmo.int/en/activity-areas/global-observing-system-gos
- World Meteorological Organization. “WMO Integrated Global Observing System (WIGOS).” community.wmo.int/en/activity-areas/wigos
- World Meteorological Organization. “WMO Information System (WIS) and WIS 2.0.” community.wmo.int/en/activity-areas/wis
- International Federation of Digital Seismograph Networks. “About the FDSN.” www.fdsn.org/about/
- International GNSS Service. “About the IGS.” igs.org/about/
- IGN, ITRF Product Center. “International Terrestrial Reference Frame.” itrf.ign.fr/en/homepage
- Argo Program. “About Argo.” argo.ucsd.edu/about/
- NASA. “Landsat 1.” landsat.gsfc.nasa.gov/satellites/landsat-1/
- European Union. “Copernicus.” www.copernicus.eu/en
- Bureau International des Poids et Mesures. “Realizing and disseminating international reference time scales: UTC, UTCr and TT(BIPM).” www.bipm.org/en/time-ftp
- IEEE Std 1588-2019. “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems.” doi.org/10.1109/IEEESTD.2020.9120376
- ITU-T Recommendation G.8275.1. “Precision time protocol telecom profile for phase/time synchronization with full timing support from the network.” www.itu.int/rec/T-REC-G.8275.1
- 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
- Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org/rfc/rfc1958
- Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org/rfc/rfc7282
- Open Geospatial Consortium. “OGC SensorThings API.” www.ogc.org/standards/sensorthings/
- W3C (2017). “Semantic Sensor Network Ontology.” W3C Recommendation, 19 October 2017. www.w3.org/TR/vocab-ssn/
- W3C (2013). “PROV-Overview: An Overview of the PROV Family of Documents.” W3C Working Group Note, 30 April 2013. www.w3.org/TR/prov-overview/
- Wilkinson, M. D., et al. (2016). “The FAIR Guiding Principles for scientific data management and stewardship.” Scientific Data 3, 160018. doi.org/10.1038/sdata.2016.18
- Birkholz, H., et al. (2023). RFC 9334, “Remote ATtestation procedureS (RATS) Architecture.” IETF. www.rfc-editor.org/rfc/rfc9334
- Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org/rfc/rfc2119
- Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org/rfc/rfc8174