One envelope for everything
The Fibric reference kernel normalizes supported inputs into one canonical EventEnvelope with identity and tenancy fields. Current BearScope storage and tenancy controls apply to its governed data paths; this article does not claim that every source or database row in a generalized platform is already covered.
Ask an integration engineer what their system processes and you will get a list: conversations, orders, call events, and device updates. The Fibric reference kernel expects supported connectors to normalize those inputs into a canonical EventEnvelope. That is a contract for governed paths, not a claim that every source is already connected or that unvalidated payloads cannot exist elsewhere.
This is where common identity, tenancy, provenance, and validation controls can be attached once. Connector-specific semantics and store-level enforcement still need their own tests.
Three signals, one shape
Consider three events that could not come from more different worlds, and what they look like the moment they cross into Fibric:
A support conversation escalates. Source: a helpdesk connector. Entity: the conversation. Payload: the message thread delta.
A purchase order posts. Source: a commerce connector. Entity: the order. Payload: line items and totals.
A room reports temperature. Source: a BACnet connector. Entity: the zone. Payload: one float and a timestamp.
Supported reference-kernel envelopes carry the same required header: event id, source, entity reference, occurred-at, reseller_id, and tenant_id.
The payloads stay different; they should. Domain meaning belongs to the connector that understands the domain. But everything the kernel needs to route, govern, deduplicate and attribute an event lives in the header, and the header is identical for all three. The router does not know what a thermostat is. It does not need to.
Why one format beats N schemas
The alternative is the world most integration platforms live in: every source gets its own schema, and every cross-cutting concern — tenancy, ordering, dedupe, audit — gets reimplemented per schema. That approach fails quietly and combinatorially. The tenancy check exists for orders but was never ported to call events. The dedupe key is the ticket id in one pipeline and a hash in another. Each integration is individually reasonable, and the system as a whole is unauditable.
With one envelope, common validation can be written once against one shape for sources that conform to the contract. Single-flight may key off the entity reference, idempotency off event or intent identity, and records back to the envelope id. Store-level tenancy must still be implemented and tested for each governed data path.
Tenancy is stamped, not looked up
The reference contract attaches tenancy at ingestion and rejects an envelope whose scope cannot be established. Current BearScope governed tables use tenant-scoped application checks and row-level security where implemented. That is defense in depth, not a universal claim about every future store or integration.
What it buys in practice
BearScope is the live product proof point, with its current governed data plane implemented directly through the application BFF. Hotel telemetry and the broader reference kernel are managed patterns, while Invoice for Me is a separate live outbound-invoicing product pattern rather than proof that all three share one production runtime.
The catalog has 48 listings with a common manifest vocabulary: 5 live in BearScope and 43 managed early access. A manifest can standardize review inputs; it does not grant governance automatically or eliminate connector design work.
One format is a constraint, and constraints are the point. Every schema you decline to add is a class of bug you decline to ship.
Keep reading: Webhooks in, receipts out · Tenancy as law