Open Standard v0.2 Working Draft
OSP
Open Smart Protocol

A transport-agnostic protocol for delivering structured intelligence payloads from publishers to registered renderers. Where existing event protocols deliver raw signals, OSP delivers context — pre-computed, urgency-tiered, and ready for LLM consumption.

Fig. 1 — Signal propagation model
PUBLISHER RENDERER RENDERER RENDERER OSP FRAME · 20 BYTES VER 1B FLAGS 1B C_TYPE 2B PUB_ID 4B SEQ 4B TS 4B LEN 2B CRC 2B CONTENT TYPE REGISTRY 0x0001 osp/text-plain — Tier 0, 160B 0x0002 osp/structured-json 0x0003 osp/structured-msgpack — Tier 1–2 0x0004 osp/graph-json — Tier 3 0x0010 osp/llm-context — Tier 3, LLM injection CRC-16/CCITT over header bytes 0–17
Publisher → Gateway → Renderer · at-least-once delivery
20-byte Frame header
Tier 0 – 3 Renderer capability
HMAC-SHA256 Webhook signing
At-least-once Delivery semantics

The gap between raw event and LLM-ready context.

LLM-powered applications are becoming the dominant consumer of real-time data signals. This is a structural shift. The problem is that the existing infrastructure for real-time delivery — webhooks, polling APIs, streaming endpoints — was not designed for this. It delivers data. It was never designed to deliver reasoning context.

Webhooks tell you something happened. OSP tells you what it means, how urgent it is, and here is the context your LLM needs to reason about it.

When an LLM application consumes a webhook, it receives a payload it must interpret, contextualise, and reason over — every time, from scratch, with no shared vocabulary for urgency and no mechanism for the publisher to signal what tier of attention this event deserves.

OSP defines the layer between event publisher and LLM consumer. A publisher emits structured intelligence once. Any registered renderer receives it adapted to its declared capability tier, signed, and with delivery confirmed.


§ 2 · What OSP Defines

One payload. Every renderer.

§ 2.1 · Frame Layer
A fixed 20-byte binary header

The frame layer carries routing metadata and integrity verification before any payload is deserialised. Magic byte, flags, content type, publisher ID, sequence number, timestamp, payload length, and CRC-16/CCITT. Transport-agnostic — valid over HTTP, MQTT, SMS, or any byte stream.

§ 2.2 · Payload Layer
Typed schemas by renderer tier

Core fields at all tiers. Extended fields — narrative state, sentiment distribution, cluster ID — at Tier 2 and above. Full entity relationship graph and LLM context fragment at Tier 3. A publisher emits once; the gateway adapts the payload to each registered renderer's declared tier.

§ 2.3 · Gateway
Delivery, retry, and fan-out

The gateway handles publisher registration, renderer subscriptions, HMAC-SHA256 webhook signing, at-least-once delivery with exponential backoff, and acknowledgment tracking. Publishers do not manage renderer lists. Renderers do not poll publishers.

§ 2.4 · LLM Context Type
Content type 0x0010

The osp/llm-context content type packages intelligence as a structured fragment for direct prompt injection — grounding statement, ordered key facts, explicit open questions, and a hard valid_until expiry timestamp.

§ 3 · Participants

Two roles. One protocol.

§ 3.1 · Publisher
You produce structured intelligence.

A publisher is any system that maintains a stateful world model and emits discrete signals when that state changes. News pipelines, financial data providers, regulatory trackers, scientific preprint monitors — any source whose output has clear lifecycle semantics and urgency gradients.

The right publisher does not firehose documents. It knows when something changed, why it matters, and what tier of urgency it carries.

Fit criteria
  • Maintains a canonical world state with discrete transitions
  • Can assign confidence and urgency tier to each event
  • Produces entity-tagged, structured output — not raw document streams
  • Benefits from fan-out to multiple renderer types without custom integration per consumer
Register as Publisher
§ 3.2 · Renderer
You consume and act on intelligence.

A renderer is any endpoint that benefits from pre-computed, urgency-tiered, LLM-ready context delivered in real time. The gateway adapts each payload to the renderer's declared capability tier — a Tier 0 renderer receives a 160-byte summary; a Tier 3 renderer receives the full graph and LLM context fragment.

The defining characteristic of a good renderer: it contains an LLM that reasons over a domain, and that LLM's answers degrade when its context is stale.

Fit criteria
  • Exposes an LLM or LLM-powered interface to end users
  • Requires grounded, current-state context at inference time
  • Benefits from structured urgency signals
  • Currently polling or building custom parsers for each data source
Register as Renderer
§ 4 · Architecture

Frame and payload layers.

The frame layer is fixed at 20 bytes and carries no semantic content. It routes, validates, and signals gateway behaviour via a flags byte: ACK_REQUIRED for tracked delivery, EXPIRES for time-bounded payloads, DELTA for incremental updates, PRIORITY for queue pre-emption, and ENCRYPTED for opaque end-to-end payloads.

The payload layer defines typed schemas organised by renderer capability tier. Core fields are present at all tiers. Extended fields enter at Tier 2. The full LLM context type, 0x0010, is Tier 3 only.

A single publisher emit fans out to all subscribed renderers. The gateway handles tier adaptation, delivery confirmation, and exponential backoff retry. Renderers receive only payloads matching their declared subscription filters — by entity, topic, confidence threshold, geography, or narrative state.

OSP Frame — 20 bytes fixed
VER
1B
FLAGS
1B
C_TYPE
2B
PUB_ID
4B
SEQ
4B
TS
4B
LEN
2B
CRC
2B
Content type registry
0x0001
osp/text-plain — Tier 0, 160B
0x0002
osp/structured-json
0x0003
osp/structured-msgpack — Tier 1–2
0x0004
osp/graph-json — Tier 3
0x0010
osp/llm-context — Tier 3, LLM injection

§ 5 · Capability Tiers

A floor, not a ceiling.

Tier 0
Minimal
160 B
Max payload

Cellular SMS or equivalent. Display only. Plain UTF-8. First entity name, truncated headline. No acknowledgment required.

SMS · E-ink · Ruggedised devices
Tier 1
Compact
2 KB
Max payload

Low-power cellular. Simple acknowledgment. Up to five entities with sentiment scores. MessagePack preferred.

Low-power mobile · Cellular data endpoints
Tier 2
Standard
64 KB
Max payload

HTTP/HTTPS. Full acknowledgment and retry. Adds narrative state, sentiment distribution, geographic focus, cluster ID.

Mobile apps · Dashboards · Monitoring tools
Tier 3
Rich
Unbounded
Streaming supported

Full payload plus streaming delta updates. Entity relationship graph, narrative threads, counter-narrative detection, and LLM context fragment via 0x0010.

LLM grounding · Graph renderers · Analytics pipelines
§ 6 · Content type 0x0010

OSP as LLM context infrastructure.

Language models have no persistent world model. Their knowledge is frozen at training time. Applications requiring grounded, current intelligence must inject that intelligence into the context window at inference time — from a source that knows not just what happened, but what it means right now.

The osp/llm-context content type packages OSP intelligence as a structured fragment for direct injection. A compliant gateway maintains a current-state corpus keyed by cluster ID and injects the relevant fragment before inference.

The open_questions field is explicit about what the model must not assert — reducing confabulation risk at the protocol level, not the application layer. The valid_until field enforces time-bounded grounding. Gateways must enforce expiry strictly: delivery of stale intelligence is worse than non-delivery.

grounding_statement string // Declarative world-state summary key_facts [string] // Ordered verifiable claims open_questions [string] // What the model must not assert provenance [object] source string url string published_at uint32 reliability_score float valid_until uint32 // Unix timestamp — hard expiry // + all Tier 2 extended fields // + graph fields // (relationships, narrative_threads, // counter_narrative)
Working draft · v0.2 · 2026 · CC BY 4.0
Read the full specification.

The whitepaper covers the complete frame specification, tier model, payload schemas, delivery and acknowledgment semantics, publisher and renderer interfaces, LLM context infrastructure, and a Tier 0 minimum viable implementation in pseudocode.

Download Whitepaper ↓ View on GitHub ↗ Creative Commons Attribution 4.0
We are seeking implementers.

Independent gateways · OSP-capable renderers · Feedback from firmware engineers and protocol designers · Publishers beyond Polari Technologies