OSPOpen Smart Protocol
Register Publisher Register Renderer
Open Standard — v0.2 Working Draft
OSP
Open Smart Protocol

A transport-agnostic protocol for delivering structured intelligence payloads from publishers to registered renderers. A publisher produces one payload. Compliant gateways deliver it to any renderer. Renderers implement the protocol once.

Specification draft active Read the whitepaper ↓
20-byte Frame header
Tier 0 – 3 Renderer capability
HMAC-SHA256 Webhook signing
At-least-once Delivery semantics
The same intelligence. Formatted four times.

A financial analyst receives intelligence in a dashboard. A field engineer receives it on a ruggedized device. A language model receives it as context. A product manager receives it in Slack. In each case the underlying information is the same — entities, relationships, narrative state, confidence, provenance. Only the surface differs.

Today, each delivery path is engineered independently. The dashboard team builds a REST client. The mobile team builds a push notification schema. The LLM integration team designs a context injection format. The Slack integration team writes a webhook handler. The same intelligence is formatted four times, each time with different fidelity, different update semantics, and different failure modes. There is no shared contract.

OSP defines that contract.


Design Principles

Protocol-level commitments.

§ 2.1
Transport agnosticism

OSP payloads are transport-agnostic. The same envelope is valid over HTTPS webhooks, MQTT, SMS, cellular data, email, or any other transport a gateway supports. The frame header identifies the version and content type; the transport is irrelevant to the payload.

§ 2.2
Renderer neutrality

OSP does not define how intelligence is displayed. A Slack renderer formats a payload as a message block. An LLM gateway injects it as a structured system prompt fragment. A thin-client renderer displays it on an e-ink screen. The protocol is indifferent to presentation.

§ 2.3
Reach over bandwidth

Payload design favors semantic density over verbosity. A well-formed OSP payload delivers actionable intelligence in the smallest possible envelope, enabling delivery to constrained environments without sacrificing meaning.

§ 2.4 – 2.5
Gateway-side intelligence · Open by design

Intelligence lives at the gateway, not the device. The gateway handles tier adaptation, delivery retry, and acknowledgment tracking. The specification is published under CC BY 4.0. Any organization may implement a compatible gateway. Polari Technologies claims no proprietary position in the protocol.


Architecture

Two-layer transport model

OSP separates framing from payload. The frame layer defines a fixed 20-byte binary header carrying a magic version byte, flags, content type, publisher ID, monotonic sequence number, timestamp, payload length, and a CRC-16/CCITT checksum. It routes and validates — it carries no semantic content.

The payload layer defines typed schemas mapped to renderer capability tier. Core fields are present at all tiers. Extended fields — narrative state, sentiment distribution, cluster ID, geographic focus — are present at Tier 2 and above. Full graph and LLM context fields are Tier 3 only.

The flags byte encodes gateway behavior: ACK_REQUIRED for tracked delivery, EXPIRES for time-bounded payloads, DELTA for incremental updates, PRIORITY for queue-jumping, and ENCRYPTED for opaque end-to-end payloads.

OSP Frame header — 20 bytes fixed
VER
1B
FLAGS
1B
C_TYPE
2B
PUB_ID
4B
SEQ
4B
TS
4B
LEN
2B
CRC
2B
Content type registry (0x____)
0x0001
osp/text-plain — Tier 0, 160B max
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

Capability Tiers

A floor, not a ceiling.

Tier 0
Minimal
160 B
Max payload

Cellular SMS or equivalent. Display only. No acknowledgment required. Plain UTF-8. First entity name, truncated headline. Achievable on commodity MCU hardware with ~4KB ROM.

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

Low-power cellular data. Simple acknowledgment. Up to 5 entities with sentiment. MessagePack preferred for bandwidth efficiency.

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, and topic tags to the compact baseline.

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

HTTP/HTTPS or MQTT. Full payload plus streaming delta updates. Entity relationship graph, narrative threads, counter-narrative detection, and LLM context fragments.

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

OSP as LLM context infrastructure.

Language models have no persistent world model. Their knowledge is frozen at training time. Applications that require grounded, current intelligence must inject that intelligence into the context window at inference time.

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

The open_questions field tells the model what it should not assert. An LLM grounded against a contested story may otherwise synthesize a confident narrative from partial evidence. Declaring open questions explicitly reduces confabulation risk.

The valid_until field enforces time-bounded grounding. A gateway delivering to an LLM integration 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)

Participants

Two roles. One protocol.

Publisher
You emit structured intelligence.

Publishers connect intelligence pipelines to the OSP gateway and emit typed frames on events — when a story cluster forms, a trend spikes, an entity relationship changes, or a narrative state transitions. Any system that produces structured intelligence can be a publisher.

  • Register a publisher identity and obtain an emit token
  • Declare supported event types at registration
  • POST frames to the gateway on pipeline events
  • Receive per-frame delivery acknowledgements
Register as Publisher
Renderer
You consume and render intelligence.

Renderers subscribe to publisher streams and receive HMAC-SHA256-signed webhook deliveries for each qualifying frame. A renderer can be a dashboard, an LLM application, a Slack integration, a mobile app, an e-ink device, or any endpoint that consumes intelligence payloads.

  • Declare capability tier and delivery endpoint at registration
  • Subscribe to publishers with optional filter expressions
  • Filter by entity, topic, confidence, geography, or narrative state
  • ACK delivery; gateway handles exponential-backoff retry
Register as Renderer
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, the publisher and renderer interfaces, LLM context infrastructure, security considerations, 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 · Organizations interested in registering as publishers beyond Polari Technologies