Architecture
Leaves · nodes · sites
Trust on every reading, control at every device.
Praecise Furcate runs on networks the operator owns, from the leaf at the sensor to the person who signs for all of it. Four tiers, five roles, three planes, one reading envelope, one ladder of assurance and one order format, the same whether a device is reached directly or through a Furcate leaf.
01
Four tiers(4)
From the device that cannot change to the site that cannot be switched off from outside.
Devices stay as they are. Everything above them is yours.
A leaf does not join the cluster. It attaches to one parent node, attests with what its silicon offers, and represents the devices wired or paired to it. A node is complete by itself and is the only door to its devices. The site controller holds the roster, policy, the ledger and the kill switch, and a site runs with its uplink cut.
- 01
Devices
Cameras, microphones, meters, PLCs, sensors, locks and drives, on whatever protocol they already speak.
- 02
Leaves
Furcate edge hardware. One per bus, room or panel. Signs at the source, enforces interlocks, verifies orders, honours the kill switch offline.
- 03
Nodes
Furcate Node and Furcate Hub, or any server running Furcate. Adapters, the bus, local AI, storage and the provenance log.
- 04
Site
Controller, overlay, policy, ledger, kill switch, console and the MCP surface agents use.
02
Five roles(5)
From the sensor to the person who signs.
Every machine has a place on the chain, and every place answers to the operator.
Furcate Leaf works at the sensors and actuators. Furcate Node is the gateway: the door to a segment and the parent of the leaves around it. Furcate Hub is the edge AI tier, where cameras, microphones and models meet. Above them, Furcate servers and Praecise Cloud carry the largest models and the fleet. At the top is the operator, on a workstation, a Furcate server or Praecise Cloud, holding the key every grant below traces back to.
The shape is not fixed. Which parent a machine reports to is an operator-signed grant, a leaf keeps two or more parents so no single machine can strand it, and one machine can hold more than one role.
Down the chain
Grants signed by the operator, each tier authorising the one below within the operator's limits. Models from the Furcate model registry, cached and relayed tier to tier and verified at every step.
Up the chain
Readings and results, and, when a tier is unsure, a short summary of the event. Raw data stays at the lowest tier unless an operator-signed policy says otherwise.
03
Three planes(3)
Isolation is how an unauthenticated protocol gets a gatekeeper.
A device that can reach only its node cannot be written to by anything else.
Most installed devices accept a write from anything that can reach them. Furcate puts them on a segment only their node or leaf can reach, so every write passes policy, approval and the ledger before it reaches the wire.
| Plane | On it | Rule |
|---|---|---|
| Device segment | devices, a node's device port or VLAN, leaves' device-side ports and radios | Devices reach nothing but their node or leaf, and nothing else reaches them. |
| Cluster plane | nodes, the site controller, leaves' parent links | Signed envelopes only, with short-lived credentials and replay defence. Leaves speak signed CBOR to their parent, which publishes on the bus. |
| Uplink | the gateway | Optional, and holds no key. Nothing on the site needs it to run, stop or be erased. |
04
The leaf
A root of trust beside every device.
One key, held by the silicon, used but never read.
A Furcate leaf names itself with a single key its own hardware holds. Firmware can ask the hardware to sign with it; nothing can make it reveal the key, over the network or with the board on a bench. The leaf's name is derived from the public half of that key, so it cannot be chosen, copied or issued twice.
A leaf also listens for nothing. It opens no port and runs no service. It dials out, only to parents the operator has authorised, and everything it does travels inside that channel.
- 01
Signs at the source
Readings leave the leaf signed, counted rather than timestamped, because a leaf has no clock it can prove.
- 02
Interlocks that outlive the network
An operator-signed table of limits, exclusions and a dead-man timer. If the parent disappears, outputs go to their declared safe state.
- 03
A person's approval, checked at the actuator
Where policy wants a human, the order carries that person's passkey assertion and the leaf verifies it, so neither a node nor an agent can actuate alone.
- 04
Kill switch with no network
Signed orders relayed over Wi-Fi, the leaf mesh or Thread, honoured with no parent present.
- 05
Substitution is visible
A different device on a port shows up as a different device, and its readings wait for the operator.
- 06
In the wrong hands, a brick
A locked leaf runs only firmware the operator's release keys signed. With one in hand, the most an attacker can do is break it: the key cannot be read out, and the leaf cannot be turned.
05
The node
The only door to the device.
Adapters run as attested workloads that can reach one segment and the bus.
Each protocol adapter is a measured, unprivileged unit. Its hash is stamped into every reading it produces, so a value can be traced to the exact code that translated it, and a compromised adapter reaches nothing but its own segment.
One schema
Adapters describe devices as W3C Web of Things Thing Descriptions. A camera, a meter and a valve look the same to the bus, the console and agents.
Provenance for media
Each stream is hashed into a log whose roots are signed by the node's attested key. Signed video from the camera is verified and chained in; exports carry C2PA content credentials.
Redaction as an egress rule
Policy can require that a stream leaves the node only after redaction. The step signs which model and policy it applied. The original stays sealed, opened only on an approval that is itself recorded.
Local AI with a receipt
Detections and summaries carry the model's hash and, where the node can attest, its boot state.
06
Assurance on every reading(4)
Four rungs. Every value states one.
A reading is only worth what vouches for it, so every reading says.
Policy, exports and agents refer to the rung. A forecast can refuse observed values; an evidence export can require leaf-signed or better; an agent sees the rung beside the number.
| Rung | Meaning | Example |
|---|---|---|
| device-native | The device signed it with its own attested key. | Matter device, camera with signed video, 802.1AR identity |
| leaf-signed | A Furcate leaf wired to the sensor signed it at capture. | Sensor or meter wired to a Furcate leaf |
| bridged | An attested leaf or guard vouches for the channel, not the device. | Modbus meter behind a field bridge; camera behind a guard |
| observed | An attested node heard it on the wire; the device has no identity. | Modbus TCP meter, plain RTSP camera |
07
Orders
A write is an order, ruled on before it happens.
Proposed, ruled on, approved, signed, enforced, recorded.
The device still receives a plain protocol write. Everything that decides whether it should happen lives above it, on hardware the operator owns, and the refusal is recorded as carefully as the action.
- 01
Propose
A person or an agent proposes an action on a capability.
- 02
Rule
Policy checks interlocks and the safe ranges the device's description declares.
- 03
Approve
When policy requires a person, a passkey assertion is attached.
- 04
Sign and enforce
A signed order with a counter and an expiry reaches the leaf or node, which checks it again.
- 05
Record
The ledger holds the order, the approval and the outcome, including every refusal.
08
Air-gapped or connected
The same keys either way.
Cut the cable and nothing a device needs goes with it.
A site runs in one of two modes. Fully air-gapped, the operator works from a machine on site and new software arrives as signed bundles carried in by hand. Connected, Praecise Cloud relays and records, and the operator approves from anywhere. The keys, the signatures and the checks are the same in both, so a site moves between them without enrolling a single device again.
| Air-gapped | Connected | |
|---|---|---|
| Operator | a workstation or Furcate server on site | Praecise Cloud, or the operator's own machines |
| Approval | a passkey on the operator's machine | a passkey; the cloud relays and records, and never holds the key |
| Software and models | signed bundles on removable media, served machine to machine on site | synced from any mirror, verified on arrival |
| Top of the ladder | the largest machine on site | Furcate servers and Praecise Cloud, where the grant allows |
| Learning | combined on site; leaves only if the operator exports it | model updates, never data, combined in the cloud |
09
Inference at every tier
Escalate only when unsure.
Small models at the sensor, large ones at the top, and raw data that stays where it was born.
Every tier runs a model server fed from the Furcate model registry. A tier answers what it can and sends only a short summary of what it cannot one step up. Learning runs the other way: updates go up, never data, and improved models come back down, signed.
10
One operating system
An immutable base, with Furcate on top.
Update without reinstalling. Roll back without a technician.
Every Furcate machine above the leaf runs the same operating system: a small base that cannot change while it runs, kept in two copies, so an update boots on trial and the machine falls back by itself if it fails. Furcate arrives on top as signed add-on images, one per component, verified before they are staged and swapped as a single file. An update never touches the base, never reinstalls anything, and never touches the machine's identity, configuration or data.
The leaf follows the same pattern
Base firmware and model slots are separate signed artifacts, each with a fallback, so a new model loads without a reflash.
Signatures, not sources
Machines trust signatures, not the place a file came from, so a mirror, a neighbouring node or a stick carried into an air-gapped site serves an update equally well.
Status
Identity from the hardware, policy, the ledger, the kill switch, signed add-on images and model serving run on Furcate servers today. Furcate Leaf, Node and Hub, the two-copy base on them, and the inference ladder across them are available soon.