# RBP-1 — Reality Boundary Protocol

**Status:** OSOIX experimental protocol, version 1  
**Identifier:** `osoix.rbp.v1`  
**First profile:** `osoix.rbp.orbital-state.v1`

## Abstract

RBP-1 is a machine-readable protocol for declaring the reality status of claims made by digital twins, mission systems, AI systems and scientific interfaces.

Provenance standards describe where data came from and how it was transformed. RBP-1 adds a different question:

> What kind of reality assertion is the system making right now, what supports it, and which conclusions survive when a source or transformation is removed?

RBP-1 does not calculate truth probability. It prevents reported records, calculated states, projections and inferences from being presented as direct observations without an explicit machine-readable boundary.

## 1. Reality classes

Every RBP claim MUST declare exactly one `realityClass`.

| Class | Meaning |
| --- | --- |
| `OBSERVED` | A direct measurement from an identified sensor or observation process is included. |
| `REPORTED` | A source supplied a record, statement or metadata item. RBP does not assert that the source record is a direct observation. |
| `CALCULATED` | A deterministic or declared transformation produced the value for the evaluation time. |
| `PROJECTED` | A model produced a value for a time later than its source basis. |
| `INFERRED` | A conclusion was derived by comparing or combining other claims. |
| `SYNTHETIC` | The value was generated for simulation, testing, illustration or augmentation. |
| `UNKNOWN` | The claim cannot be established from the available evidence, or the required evidence is explicitly absent. |

A class is not a confidence score. `OBSERVED` does not mean correct, and `PROJECTED` does not mean unreliable. The class declares the relationship between the claim and its evidence.

## 2. Claim contract

An RBP claim MUST contain:

- a stable claim identifier;
- a subject identifier;
- a human-readable statement;
- a reality class;
- a JSON value;
- source identifiers;
- dependency claim identifiers;
- declared transformations;
- source epoch, evaluation time and projection horizon;
- uncertainty mode and covariance availability;
- authority level and command-path status;
- a SHA-256 digest over canonical claim content.

Claims MUST NOT imply operational authority merely because an authoritative source was used.

## 3. Temporal boundary

RBP distinguishes:

1. **source epoch** — the time basis of the source record;
2. **evaluation time** — the time at which the system evaluated the claim;
3. **horizon** — the offset between the evaluation time and the claimed future state.

A future claim MUST be `PROJECTED`. A calculated present state derived from an older source epoch remains `CALCULATED`, not `OBSERVED`.

## 4. Uncertainty boundary

Every claim MUST declare one uncertainty mode:

- `formal` — a defined mathematical uncertainty product is attached;
- `proxy` — freshness, disagreement, quality flags or other non-probabilistic indicators are attached;
- `unavailable` — the system has no applicable uncertainty product.

Proxy indicators MUST NOT be presented as formal probability.

For the orbital profile, no collision probability may be claimed without the required covariance and safety-of-flight inputs.

## 5. Contradiction surface

An RBP capsule MAY compare claims that refer to the same subject and evaluation time.

A contradiction record MUST disclose:

- the claims being compared;
- the comparison method;
- the numerical delta when available;
- source-epoch separation;
- a statement explaining what the delta does and does not mean.

A source delta does not establish which source is correct.

## 6. Source-removal survivability

RBP-1 introduces **counterfactual survivability**.

For each declared removal scenario, the capsule identifies:

- claims directly invalidated by the removed source;
- dependent claims invalidated transitively;
- claims that remain derivable;
- whether a current state remains available;
- whether a future projection remains available;
- the surviving-claim ratio.

This is not a reliability probability. It is a reproducible dependency analysis.

## 7. Capsule integrity

Each claim is hashed independently. The complete capsule is then hashed over its canonical unsigned content.

A validator MUST check:

- supported protocol and profile identifiers;
- unique claim IDs;
- dependency existence;
- absence of self-dependencies;
- claim digest integrity;
- declared scientific boundaries.

## 8. W3C PROV alignment

RBP-1 includes a compact JSON-LD projection aligned with W3C PROV:

- sources map to `prov:Entity`;
- claims map to `prov:Entity`;
- claim dependencies map to `prov:wasDerivedFrom`;
- RBP reality classes and digests use the OSOIX RBP namespace.

W3C PROV remains the provenance foundation. RBP-1 is a domain-neutral claim-boundary layer built above it.

References:

- W3C PROV-O: `https://www.w3.org/TR/prov-o/`
- W3C PROV Overview: `https://www.w3.org/TR/prov-overview/`

## 9. Orbital-state profile

The first OSOIX profile applies RBP-1 to public orbital element records and derived states.

It distinguishes:

- reported GP element records;
- calculated present states;
- projected future states;
- inferred cross-source deltas;
- unavailable direct observation;
- unavailable formal covariance;
- explicit absence of spacecraft command, uplink, transmission and scheduling authority.

The profile is research and decision-support infrastructure. It is not an operational conjunction data message, spacecraft telemetry product or command system.

## 10. Design principle

RBP-1 follows one rule:

> A system should never display a stronger relationship to reality than its evidence can support.