--- title: "Architecture | Blackspire" description: "Blackspire's reference architecture: where the layer sits, what it connects, and how it turns contradictory signals from separate systems into one governed operational picture." url: https://blackspire.group/architecture --- Architecture # Blackspire does not replace your stack. It connects it. Most operations do not suffer from too little data. They suffer from separate systems observing the same physical reality and describing it differently, with no layer beneath them reasoning across the whole. Blackspire is that layer. Reference architecture ## Where the layer sits. This is a reference architecture, not a diagram of a specific customer deployment. It shows the shape of the problem and where Blackspire attaches to systems an operator already runs. Blackspire attaches to systems that already exist. It is additive to an operator's current investment, not a replacement for it. Reference architecture — not a customer case study ## The same operation, with and without a layer beneath it. Illustrated with a maritime logistics operation because the systems involved are easy to name. The pattern holds anywhere many systems describe one physical environment. #### Without a connecting layer - The fleet system holds one view of the vessel - The weather feed holds another - Maintenance records hold a third - The port system holds a fourth - Existing models each run on their own slice of data - Operators reconcile the contradictions by hand, under time pressure - No shared record of why a decision was made - Arrival is a statistical average with error attached #### With Blackspire - Every one of those systems stays exactly where it is - Signals are connected and aligned in time - Conflicting observations are made visible and reconciled - Physical constraints are applied across all of them at once - Every conclusion keeps its provenance back to source - Operators govern by exception instead of reconciling by hand - Downstream systems receive shared context, not another dashboard - Arrival is derived from load, drag, current and propulsion state Illustrative operating scenario ## How the reasoning runs. The following is a constructed example written to show the sequence of reasoning. It is not a record of a live deployment, a customer engagement, or a measured result, and no figure in it should be read as one. Every system named below is one an operator would already be running. #### Four systems report, separately The vessel reports reduced speed. The weather feed reports moderate headwinds. Maintenance shows recent propulsion degradation. The port system shows a narrowing berth window. #### The signals are aligned in time Each observation carries a different timestamp, latency and reliability. Before anything can be reasoned about, they have to describe the same moment. #### Physical law is applied across them Reduced speed is no longer an isolated reading. It is evaluated against drag, load, current and propulsion state — what the physics permits, given all four observations at once. #### Contradictions resolve Where two systems disagree, the disagreement is settled by what is physically possible rather than by which source is weighted more heavily. #### The operator gets one picture An arrival window derived from physics. The contributing factors. What remains genuinely unresolved. The options still available, and what each costs in fuel, delay or safety margin. #### The record survives the decision A full source-to-outcome audit trail: which signals, which constraints, which conclusion, in what order. Disputes become a read of the record rather than an argument. What it connects to ## Additive, not rip-and-replace. ### Sensing IoT and sensor networks, cameras and geospatial systems, radar, AIS and GNSS, edge devices in degraded or disconnected conditions. ### Systems of record ERP, fleet and logistics platforms, maintenance management, digital twins, control-room and workflow systems. ### Reasoning already in place Existing AI and machine-learning models, planners, optimizers, and the human reports and standing orders that sit alongside them. On what we are not claiming Nothing on this page describes a validated customer outcome. The architecture is real and the patented work behind it is public and dated. What an implementation produces in a specific environment is exactly what a first engagement exists to establish, and we would rather find that out with you than assert it in advance. ## Mapped against your systems, this stops being abstract. An architecture briefing covers what you already run, where those systems disagree, and which decision is being made without cross-system context today. [Request an architecture briefing](https://blackspire.group/engagement)