DEV Community: Rodrigo Giuliani

How I Used GitHub Copilot to Turn a Half-Finished Protocol Into a Certified Standard published

Rodrigo Giuliani — Wed, 27 May 2026 02:23:47 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

DoSync Protocol is an open-source communication protocol (Apache 2.0) that lets AI agents control physical devices using semantic intentions instead of commands. Instead of lock.unlock(), an AI agent says ensure_safety — and every registered device figures out its own role automatically.
The Python reference implementation was running in production on a Raspberry Pi 5. But a protocol with only one implementation isn't a standard — it's a library. The unfinished piece: a second independent Node.js implementation that could pass the DoSync certification suite.

Demo

GitHub: https://github.com/giulianireg-spec/dosync-protocol

── Tier BASIC ─────────────────────────────────────────────
  ✓  Hub reachable — version 0.1.0
  ✓  Protocol version declared — dosync/0.1
  ✓  Device can register — registered
  ✓  Device appears in registry — 1 device registered
  ✓  Hub returns device detail — status=200
  ✓  Capability manifest has all required fields — all present
── Tier STANDARD — Intents and events ─────────────────────
  ✓  Hub accepts notify_family intent — 4 actions executed
  ✓  Intent resolves correctly — 4 actions processed
  ✓  Device can send event — received
  ✓  Hub rejects unknown intents with 422 — status=422
  ✓  Hub rejects unregistered device events with 404 — status=404
── Result ──────────────────────────────────────────────────
  Tests passed: 11
  Tests failed: 0
  ✓ CERTIFIED — DoSync STANDARD

The Comeback Story

Before: The Node.js implementation (implementations/dosync-node) passed Basic certification (6/6 tests) — it could register devices and handle simple queries. But Standard tier was failing at test 1 because the server was missing GET /v1/status, the endpoint the certification suite uses to verify hub identity and protocol version.
Additionally, the certification CLI (certify.py) only supported HTTP — but the production hub runs on HTTPS with a local PKI. Running Standard tests against real infrastructure was impossible.
What changed:
certify.py — fixed to support real deployments:

HTTPS support with CA certificate validation via DOSYNC_CA_CERT
Bearer token injection via DOSYNC_TOKEN
Localhost detection: HTTP for local dev, HTTPS for remote
Connectivity test fixed to use /v1/status instead of / (which returns the HTML dashboard)

dosync-node — the missing endpoint, added with Copilot:

GET /v1/status — the single endpoint that unlocked Standard certification

After: dosync-node passes DoSync Standard certification (11/11). Two independent implementations in different languages, same protocol, same certification suite — the minimum criterion for an open standard.

My Experience with GitHub Copilot

Copilot contributed in two ways during this session.
Inline suggestions while editing certify.py. As I was modifying the HTTP helper to support HTTPS and token injection, Copilot's inline suggestions consistently anticipated the next line — the SSL context setup, the os.environ.get() calls, the exception handling pattern. It didn't write the logic, but it reduced the friction of writing boilerplate correctly on the first pass.
The endpoint that closed the gap. Once I identified that GET /v1/status was the missing piece, I asked Copilot Chat:

"I'm implementing the DoSync Protocol in Node.js. The certification suite requires a GET /v1/status endpoint that returns name, version, protocol, status, devices count, and audit_entries count. The existing code uses Fastify. Please add this endpoint following the same patterns already in the file."

Copilot read the existing file, identified the right variable names (registry, auditLog, VERSION, PROTOCOL), and generated:

javascript// GET /v1/status
app.get('/v1/status', async () => ({
  name:          'DoSync Hub',
  version:       VERSION,
  protocol:      PROTOCOL,
  status:        'running',
  devices:       registry.size,
  audit_entries: auditLog.length,
}))

Correct variable names. Correct Fastify pattern. No hallucinations. The key was giving Copilot the right context: the spec requirement, the existing code pattern, and the constraint. It didn't need to invent — it needed to synthesize what was already there.
After accepting the suggestion, the certification run went from 0/11 to 11/11. GitHub Copilot helped close the gap between "protocol with one implementation" and "protocol with a certified standard."

Repository: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

Why AI Agents and IoT Protocols Speak Different Languages

Rodrigo Giuliani — Tue, 26 May 2026 13:21:13 +0000

There's a distinction that comes up constantly when designing systems that connect AI to physical environments, and it's one that most protocols blur or ignore entirely.
The distinction is between an event and an intent.
They look similar on the surface. Both are messages. Both carry information about the world. But they describe fundamentally different things — and building a system that confuses them leads to brittleness, fragility, and automation that breaks exactly when it matters most.

What an event is

An event is a description of something that happened.

json{
  "device": "pir-sensor-01",
  "type": "motion_detected",
  "timestamp": 1748000000,
  "location": "entrance"
}

An event is past tense. It's factual. It carries no opinion about what should happen next. The PIR sensor doesn't know whether this motion means "the kids just got home" or "there's an intruder" or "the cat walked by again." It just observed something and reported it asynchronously — fire and forget.
Events are the raw material of a physical system. Sensors generate them constantly — temperature readings, contact closures, power measurements, motion pulses. They are objective and dumb, in the best possible sense.

What an intent is

An intent is a description of something that needs to happen.

json{
  "intent": "children_arrived_home",
  "urgency": "info",
  "context": {
    "trigger": "motion_detected",
    "time": "18:45",
    "day": "monday"
  }
}

An intent is future tense. It carries meaning. It encodes a goal — what the system should achieve — without specifying how to achieve it. The intent doesn't say "turn on lights 3, 7, and 9 at 80% brightness." It says "the kids are home." The infrastructure figures out the rest.

The leap from event to intent requires reasoning. Something has to look at the motion event, consider the time, the day, the history, and decide: this event means the kids just arrived. That reasoning is exactly what AI agents are good at.

Concretely, that transition looks like this:

[PIR fires motion_detected at 18:45 on Monday]
        ↓
  AI agent reasons:
  - time: 18:45 → within arrival window
  - day: Monday → weekday
  - location: entrance → consistent with arrival
        ↓
  fires: children_arrived_home [info]
        ↓
  hub resolves against device registry:
  → 5 lights turn on
  → SMS sent to parents
  → audit log updated

The agent handled the meaning. The protocol handled the coordination.

Why conflating the two breaks systems

Most smart home platforms today — Home Assistant automations, Matter scenes, Zigbee rules — are built on a hidden assumption: that the translation from event to action is a simple, static mapping.
IF motion_detected AND time > 18:00 AND day IN [Mon, Tue, Wed, Thu, Fri]
THEN turn_on(light_1), turn_on(light_2), send_sms("kids home")
This works until it doesn't. Add a new light and the rule doesn't know about it. Change the schedule and you rewrite rules. Move to a new home with different devices and you start over. The rule hardcodes both the reasoning ("this motion means the kids arrived") and the execution ("these specific lights, this specific message").
Separating events from intents breaks this coupling.
The AI agent handles the reasoning layer: event → intent. It observes the motion, considers the context, and decides what's happening. That reasoning can be as simple or as sophisticated as needed — a time-based rule, a learned pattern, or a full LLM inference.
The protocol handles the execution layer: intent → actions. Once the intent is declared, every device that registered as relevant participates automatically. Add a new light and it joins the response. Remove a device and the system adapts. No rules to rewrite.

Why this matters beyond the home

The event/intent separation is not a smart home concept. It's an architectural pattern for any system where AI needs to act on physical infrastructure.
In a factory: a temperature sensor fires threshold_exceeded on a critical component — that's an event. The AI reasons about it: abnormal reading, production line active, no scheduled maintenance — and determines execute_safe_shutdown. That's an intent. The execution is then coordinated automatically across the line: equipment powers down in sequence, the supervisor is paged, a maintenance request is logged, cooling activates. None of those responses were hardcoded for that specific sensor reading. Each system declared what it could do, and the protocol assembled the response.
The pattern is always the same: the AI reasons about meaning, the infrastructure handles coordination. The temperature sensor does not know about the cooling system. The cooling system does not know about the sensor. The protocol coordinates both.

How DoSync implements this separation

In DoSync, the separation is structural. Events flow in from sensors and adapters — raw, factual, carrying no prescription. Intents flow out from AI agents — meaningful, goal-oriented, carrying no implementation.
The hub sits in between: it receives intents, resolves them against every device's declared Capability Manifest, and builds an action plan at runtime. The resolver never sees the original event. The sensor never sees the resulting actions. The layers are cleanly decoupled.
That decoupling is what makes the system extensible by design. A new device joins the network, declares its capabilities, and automatically participates in every relevant intent — without any rule being written, without any configuration being changed.
That's the architectural difference that matters.

DoSync Protocol: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

Why AI Agents Like Hermes Need a Semantic Execution Layer for the Physical World

Rodrigo Giuliani — Sat, 23 May 2026 16:20:14 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

Most AI agents interact with the world through APIs, databases, and web services. The feedback loop is fast and forgiving — if something goes wrong, you retry.
Physical environments are different. A light that turns on twice isn't a problem. A door that unlocks at the wrong time is. An agent operating in the physical world needs not just reasoning capability, but a clear contract between what it decides and what actually executes.
This post is about that contract — and why Hermes Agent's architecture makes it a natural fit for physical systems.

What makes Hermes Agent relevant here

Hermes Agent has three characteristics that matter specifically for physical environments:
Native MCP support. Hermes connects to external systems via Model Context Protocol natively. Any hub or device layer that exposes an MCP server becomes immediately accessible — no custom integrations, no bridges.
Multi-step tool use with context. Hermes doesn't just call tools — it reasons about which tool to call, in what order, based on context. For physical systems where the right action depends on time, location, and state, this matters.
Open weights and local execution. Physical environments often have strict privacy requirements. A system that can run fully local — without sending home sensor data to a cloud provider — is architecturally different from one that can't.
These three properties together describe an agent that can act on physical systems in a way that's both capable and auditable.

The gap it needs to cross

Every physical device protocol was designed around one assumption: a human decides what to do, and a device executes it. The protocols speak in commands — lock.unlock(), light.set_brightness(100).
An AI agent doesn't produce commands. It produces understanding. "The kids just arrived home" is not a command. The translation from that understanding to the right set of device actions — for the specific devices available, in the right context — still has to be written by someone, in advance.
This is where most physical AI integrations break down. The agent reasons correctly and the devices exist, but the translation layer between them is a pile of hardcoded rules that grows more fragile with every new device.
A semantic execution layer inverts this. Instead of the agent knowing how to act, devices declare what they can do and when they're relevant. The agent expresses goals. The infrastructure handles translation at runtime.

An experiment: Hermes + DoSync
I tested this with DoSync Protocol, an open-source hub (Apache 2.0) that implements this semantic layer. Devices register with a capability manifest. The hub exposes a native MCP server.
Connecting Hermes to DoSync required three lines in ~/.hermes/config.yaml:

yaml
mcp_servers:
  dosync:
    command: python3
    args: [/path/to/dosync/mcp_server.py]
    env:
      DOSYNC_HUB_URL: http://localhost:47200
      DOSYNC_TOKEN: <token>

I gave Hermes a single prompt:
It's 18:45 on a Monday. The PIR sensor at the entrance just detected motion.
What does the system do?

Hermes queried the hub state, reasoned about the time and day, identified the appropriate semantic intent (children_arrived_home), and fired it once. Five physical lights turned on. An SMS was sent to the family. The audit log updated with two new SHA-256 chained entries.
What Hermes didn't need to know: which specific bulbs to address, the SMS provider, or the schedule policy restricting this intent to weekday evenings. That knowledge lived in the hub. Hermes expressed a goal — the infrastructure handled execution.

The open question

This experiment raises a boundary question that physical AI deployments will have to answer: where does agent reasoning end and infrastructure policy begin?
Should Hermes decide which intent to fire, or should context mapping be pre-configured? When an agent acts in a physical environment with real consequences, how much autonomy is appropriate before a human needs to confirm?
Hermes Agent's transparency — open weights, observable tool calls, local execution — makes it the right kind of system to explore these questions. You can see exactly what it reasoned and why. In physical environments, that auditability isn't a nice-to-have. It's a requirement.

DoSync Protocol (open source): https://github.com/giulianireg-spec/dosync-protocol
Hermes Agent: https://hermes-agent.nousresearch.com

Why Hardcoded Automations Fail AI Agents

Rodrigo Giuliani — Fri, 22 May 2026 12:39:00 +0000

DoSync Concepts — Part 2 of 5

There's a rule every smart home developer has written at least once:

if motion_detected and time > 22:00:
    turn_on(hallway_light)

It works. It's simple. And it's the foundation of how every major home automation platform thinks about intelligence today.
The problem isn't that the rule is wrong. The problem is what happens when you add an AI agent to the system — and why rules, no matter how many you write, are the wrong abstraction for that job.

The rule-writing problem
Rules are commands in disguise. "If X happens, do Y" is just a delayed command — the human still decided what Y should be, they just decided it in advance.
That works perfectly when you can anticipate every scenario, your device set never changes, and the AI's job is simply to trigger pre-approved responses. None of those assumptions hold in a real AI-augmented environment.
Consider what happens when you add a new device. A smart lock arrives. You register it with your platform. Now you have to go back through every relevant rule and add the lock. Miss one and the system silently does nothing in exactly the scenario where you needed it most.
Or consider an AI that detects unusual temperature patterns in the kitchen — a sensor reading that might mean the fridge compressor is failing. The AI knows something is wrong. But there's no rule for "fridge compressor anomaly," because nobody wrote one. The system does nothing.
This is the brittleness problem: hardcoded automations only respond to situations that were anticipated when the rule was written.

Why AI agents make this worse, not better
The intuitive solution is to write more rules, or smarter rules. Use the AI to generate them. Inspect logs and auto-suggest new automations.
But this misses the architectural problem.
An AI agent doesn't produce rules. It produces understanding. When a vision model detects a fall, it doesn't know it needs to call phone.call("911") and lock.unlock() and alarm.activate("emergency"). It knows there's an emergency. The translation from understanding to commands still has to be written somewhere — by someone — in advance.
The more capable the AI, the more situations it can detect. And every new situation the AI can detect is a new set of rules that needs to be written to respond to it. The rule surface grows faster than anyone can maintain it.

What capability-based discovery changes
The alternative is to shift where the knowledge lives.
Instead of centralizing the response logic in rules, distribute it to the devices themselves. Each device declares what it can do and in what contexts it's appropriate to act:

json{
  "device_id": "lock-frontdoor-01",
  "tags": ["door-lock", "entrance", "emergency"],
  "actuators": [
    { "type": "unlock", "emergency_capable": true }
  ],
  "emergency_capable": true
}

This manifest is not a rule. It's a declaration. The device is saying: I can unlock. I'm relevant in emergencies. I'm at the entrance.
When the AI fires a semantic intent — ensure_safety / emergency — the resolver reads every registered manifest and asks: which devices declared themselves relevant to this situation? It builds the response at runtime, from what's actually available.
ensure_safety [emergency]
→ lock-frontdoor-01 unlock (emergency_capable, entrance tag)
→ alarm-main-01 activate (emergency_capable)
→ wiz-living-01..10 turn_on (light tag, full brightness)
→ notifier-sms-01 notify (communication tag)
All in parallel. No rules written for this scenario.
Add the smart lock tomorrow — it participates automatically in every relevant scenario. No rule rewriting. No code changes. The device brought its own knowledge.

The difference that matters
Hardcoded automations are fragile because they encode knowledge in a central place that can't keep up with change. Every new device, every new scenario, every new AI capability requires human intervention to update the rules.
Capability-based discovery distributes that knowledge to the edges. Devices own their context. The system is resilient to change because adding new capabilities is additive, not a rewrite.
For AI agents specifically, this is the difference between a system that only responds to situations you anticipated and a system that responds to situations the AI can detect — whether you anticipated them or not.

GitHub: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

DoSync Concepts is a series exploring the ideas behind the DoSync Protocol — the semantic layer between AI agents and physical systems.

What is Semantic Intent? And Why It's Not the Same as a Command

Rodrigo Giuliani — Sun, 17 May 2026 16:34:48 +0000

DoSync Concepts — Part 1 of 5

There's a word that keeps appearing in conversations about AI and the physical world: intent.
We say things like "the AI understood my intent" or "I want the system to infer my intent from context." But when you actually sit down to build something — a smart home, a hospital room, a hotel — you quickly discover that most protocols don't have a concept of intent at all.
They have commands.
And that difference, small as it sounds, is architectural. It changes everything about how you build systems that are supposed to work with AI.

The command model
Every smart home protocol in existence today was designed around one assumption: a human decides what to do, an app translates that decision into a specific instruction, and a device executes it.
Human → App → Command → Device
lock.unlock()
light.set_brightness(80)
thermostat.set_temperature(21)
This is the command model. It works beautifully when the human is in the loop — when someone taps a button, sets a schedule, or writes a rule. The intent is implicit in the human's action. The app just needs to translate it correctly.
The problem starts when you remove the human.

What an AI agent actually produces
When an AI system observes the world — a camera detecting a fall, a sensor registering unusual temperature, a model inferring that nobody is home — it doesn't produce a command. It produces an understanding of a situation.
"There is an emergency."
"The person who lives here has arrived."
"Something is wrong with the refrigerator."
These are not commands. They're semantic descriptions of a state of the world. They describe what is happening or what needs to happen, not how to make it happen.
To translate this into device commands, someone has to write that translation — manually, in advance, for every possible situation, for every device combination. Miss one edge case and the system does nothing. Add a new device and you rewrite the rules.
This is the command gap. And it only becomes visible when you try to add AI to a physical system.

Semantic intent: a different contract
A semantic intent is a structured expression of a goal — what needs to be achieved — without specifying how to achieve it.
Compare:
json// Command (existing protocols)
{
"device": "lock-frontdoor-01",
"command": "unlock",
"duration": 300
}

// Semantic Intent (DoSync)
{
"intent": "ensure_safety",
"urgency": "emergency",
"context": {
"trigger": "fall_detected",
"location": "bedroom"
}
}
The command says: unlock this specific lock for 5 minutes.
The intent says: there is a safety emergency in the bedroom.
The difference isn't just syntactic. It's about who holds the knowledge.
In the command model, the knowledge of which devices to activate and how lives in the app, or in the rules engine, or in the code a developer wrote last year. That knowledge is static. It can't adapt to new devices, new scenarios, or new contexts.
In the intent model, that knowledge lives in the devices themselves — in their Capability Manifests. Each device declares what it can do and when it's appropriate to act. The system assembles the response at runtime, based on what's available.

How DoSync implements this
In DoSync, every device publishes a Capability Manifest when it joins the network:
json{
"device_id": "lock-frontdoor-01",
"tags": ["door-lock", "entrance", "emergency"],
"actuators": [
{ "type": "unlock", "description": "Unlock for emergency access" },
{ "type": "lock" }
],
"emergency_capable": true
}
This manifest is not a command interface. It's a declaration of capability and context. The device is saying: I can unlock. I am relevant in emergencies. I am at the entrance.
When an AI agent fires an intent:
json{
"intent": "ensure_safety",
"urgency": "emergency"
}
The DoSync semantic resolver reads every registered manifest and asks: which devices are relevant to this intent, given their declared capabilities and tags? It builds an action plan automatically — no rules written, no pre-configuration required.
ensure_safety [emergency]
→ lock-frontdoor-01 unlock (emergency_capable, entrance tag)
→ alarm-main-01 alarm (emergency_capable)
→ phone-family-01 call (communication tag)
→ wiz-living-01..10 turn_on (light tag, full brightness)
All in parallel. Under 100ms. No internet. No cloud.
Add a new device tomorrow — a smart siren, a second lock, a notification relay — and it participates automatically in every relevant scenario. No rule rewriting. No code changes.

Why this matters beyond the home
The command gap isn't unique to smart homes. It's structural — it appears anywhere an AI system needs to coordinate physical devices in response to real-world events.
A hospital AI detects a deteriorating patient. It knows there's urgency. But it doesn't know which room equipment to prepare, which staff to page, which doors to unlock for the crash cart. With command-based protocols, an engineer had to anticipate that exact scenario in advance. With semantic intent, each device declares its relevance and the system responds.
A factory line detects an anomaly on a critical component. The AI knows something is wrong. With commands, someone pre-wrote the response. With intent, the devices coordinate a safe shutdown based on their declared capabilities — and the audit log captures every action with a tamper-evident chain.
The protocol is domain-agnostic. The insight is not.

The deeper shift
Here's what semantic intent actually changes, at a philosophical level:
In the command model, the AI is a remote control. It knows the exact sequence of buttons to press. It breaks when a device changes, when a new device appears, or when a scenario wasn't anticipated.
In the intent model, the AI is a coordinator. It expresses what needs to happen. The devices figure out their role. The system is resilient to change because the knowledge is distributed — each device owns its own context.
This is not a small difference. It's the difference between building a system that works today and building a system that can grow.

What comes next
This is the first post in a series exploring the concepts behind DoSync — an open protocol (Apache 2.0) for semantic intent-based communication between AI and physical devices.
In the next post: Why hardcoded automations fail AI agents — and what a system designed from first principles for AI actually looks like.
GitHub: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

DoSync Concepts is a series exploring the ideas behind the DoSync Protocol — the semantic layer between AI agents and physical systems.

The Missing Layer Between AI Agents and Physical Systems

Rodrigo Giuliani — Fri, 15 May 2026 17:56:57 +0000

There's a fundamental mismatch at the heart of every smart home today, and most people building in this space haven't fully articulated what it is.

It's not a hardware problem. The sensors, locks, cameras, and thermostats we have today are genuinely capable. It's not a connectivity problem — Matter, Zigbee, and Z-Wave do a perfectly good job of letting apps talk to devices. The problem is architectural, and it only becomes visible when you try to add AI to the picture.

Let me show you what I mean.

The command gap

Every smart home protocol in existence was designed around a fundamental assumption: a human decides what to do, an app translates that decision into a command, and a device executes it.

Human decision → App → Command → Device
lock.unlock()
light.set_brightness(100)
thermostat.set_temperature(21)

This works perfectly for app-controlled scenarios. Matter is an excellent solution to the problem of letting different brands' apps control different brands' devices. Zigbee and Z-Wave solve real problems in mesh networking and low-power communication.

But AI systems don't think in commands. They think in goals.

When an AI detects a fall, it doesn't know it needs to call lock.unlock() and phone.call("911") and alarm.activate("emergency"). It knows there's an emergency. The translation from "there's an emergency" to the specific sequence of device commands has to be written by a human, device by device, scenario by scenario, in advance.

That translation layer is fragile. It breaks when you add a new device. It fails to anticipate scenarios. And in emergencies — where the system should be most reliable — it's exactly the layer most likely to have a gap.

Why this matters now

For the last decade, this wasn't a real problem. Smart home automation was primarily rule-based: "if motion sensor triggers after 10pm, turn on the hallway light." Rules are commands. The mapping was trivial.

But the emergence of capable AI agents changes the equation entirely. We now have systems that can:

Detect that an elderly person has fallen from camera footage
Infer from sensor data that a fridge compressor has failed
Understand from context that "nobody is home" without a button press
React to a smoke detector with a phased evacuation response

These are goal-oriented events, not command-oriented ones. And every existing protocol forces you to pre-write the translation between "goal" and "command" yourself. There is no standard interface for saying "ensure her safety" and having the home figure out the rest.

This problem isn't limited to the home. Consider a manufacturing line: a temperature sensor detects an abnormal reading on a critical component. The AI system knows there's an anomaly — but it doesn't know whether to stop the line, alert the supervisor, activate cooling, trigger a maintenance request, or all of the above. With existing protocols, an engineer had to anticipate this scenario and write that rule in advance. Miss one edge case and the system does nothing. With a semantic protocol, each device declares its capabilities and the resolver determines the appropriate response based on urgency and context — without any pre-written rules for that specific failure mode.

The same architectural gap exists in hospitals, hotels, smart buildings, and anywhere an AI needs to coordinate physical systems in response to real-world events.

What a semantic protocol actually needs

I've been working on this problem for several months, and the design space is clearer than it looks. A protocol that can bridge AI goals and physical devices needs a few specific things:

1. Capability-based device registration

Instead of a device waiting to receive commands, it announces what it can do when it joins the network:

{
  "device_id": "lock-frontdoor-01",
  "tags": ["door-lock", "entrance", "emergency"],
  "actuators": [
    { "type": "unlock", "emergency_capable": true },
    { "type": "lock" }
  ],
  "emergency_capable": true
}

This manifest lets the system discover what's available without any pre-configuration. Add a new device and it participates automatically in every relevant scenario.

2. Semantic intent, not commands

The AI layer submits an intent — what it wants to achieve — not a specific sequence of commands:

{
  "intent": "ensure_safety",
  "urgency": "emergency",
  "context": {
    "trigger": "fall_detected",
    "location": "bedroom"
  }
}

A semantic resolver then matches this intent against the registered device manifests, determines which devices are relevant, and builds an action plan. The AI doesn't need to know what devices exist.

3. Emergency override without confirmation

For urgent situations, the system must be able to act immediately. This means emergency_capable devices bypass the normal confirmation flow. Every action is logged with a tamper-evident chain — but the action executes without waiting.

4. Transport agnosticism

A semantic protocol should be independent of the physical layer. Whether devices communicate over WiFi, Zigbee, Z-Wave, BLE, or Thread should be an implementation detail, not an architectural constraint.

DoSync: a working implementation

I built a reference implementation of these ideas called DoSync Protocol (Apache 2.0). It's not a theoretical spec — there's a running hub, a web dashboard, a certification CLI, and hardware adapters.

Here's what happens when the system receives an emergency intent:

PIR sensor detects motion → gpio_adapter fires ensure_safety [emergency]
    → Semantic resolver scores all 23 registered devices
        → 10 Philips WiZ bulbs: turn_on at full brightness (WiZ UDP adapter)
        → HA lock: unlock for 5 minutes (Home Assistant adapter)  
        → Alarm: activate emergency pattern (simulated)
        → SMS: sent to emergency contact (Twilio)
        → Audit log: SHA-256 chain updated
All in under 100ms. No rules written. No pre-configuration.

The current hardware setup runs autonomously on a Raspberry Pi 5 with a PIR motion sensor and DHT22 temperature sensor. The hub survives reboots via systemd. Any LLM with MCP support (Claude, ChatGPT, etc.) can control the hub through a native MCP server.

What this doesn't solve

I want to be honest about the limitations, because I think intellectual honesty is what makes a protocol worth taking seriously.

DoSync is a protocol of application layer, not transport. It runs over HTTP/WebSocket today. It doesn't replace Zigbee or Z-Wave at the radio level — it sits above them and abstracts them.

The semantic resolver is simple. Today it's a capability matching algorithm that scores devices by tags, urgency, and emergency_capable flag. It works well for the scenarios we have, but a production-grade resolver needs to go further.

The current algorithm asks: which devices have the right tags and capabilities for this intent? A mature resolver would also ask:

Device state awareness — don't unlock a door that's already unlocked, don't turn on a light that's already at full brightness
Competing priorities — if two intents fire simultaneously (morning routine + motion detected), which takes precedence and how do they compose?
Contextual weighting — a motion sensor in a bedroom at 3am carries different weight than the same sensor at 3pm
Learned patterns — over time, the resolver should know that in this home, "save energy" means turning off the living room lights but never the hallway

The resolver interface is already decoupled from the rest of the protocol — you can implement a more sophisticated one without touching the adapter layer or the audit system. The spec defines what a resolver must do, not how. That's intentional. I plan to document this interface formally in v0.2 so that third-party resolver implementations can be dropped in. A production deployment might use a small local LLM as the resolver itself — the protocol is designed to support that path.

There is no hardware certification process yet. The CLI generates a signed JSON report, but there's no third-party review. That's the right long-term model — it's just not there yet.

It's one person's implementation. A protocol needs multiple independent implementations to become a standard. That's the next milestone.

The broader point

Smart home AI is arriving whether the protocol layer is ready or not. Home Assistant added MCP support in 2025. Claude and ChatGPT can already control devices via tool calls. The question isn't whether AI will be integrated into physical environments — it's whether the integration will be done well or badly.

Done badly: AI systems that call device APIs directly, with hardcoded rules, fragile integrations, no audit trail, and no standard for what "emergency capable" even means.

Done well: a semantic layer where devices declare what they can do, AI expresses what it wants to achieve, and the home figures out the rest — with full auditability and a clear certification model for safety-critical scenarios.

The hardware is ready. The AI is ready. The missing piece is a protocol designed from first principles for this use case.

Try it

git clone https://github.com/giulianireg-spec/dosync-protocol
cd dosync-protocol
python3 -m venv venv && source venv/bin/activate
pip install fastapi uvicorn websockets pywizlight aiohttp

PYTHONPATH=. uvicorn server:app --host 0.0.0.0 --port 47200 --reload
# Open http://localhost:47200

The dashboard shows registered devices, live events, and the audit log in real time. The certification CLI runs 16 tests across three tiers. The MCP server lets any compatible LLM control the hub directly.

Feedback, contributions, and adapter implementations are welcome. The RFC process is open.

GitHub: github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0
Contact: giulianireg@gmail.com

DoSync Protocol v0.1 — building the semantic layer between AI and physical systems.

Why Your Smart Home AI Can't Open the Door in an Emergency (And How to Fix It)

Rodrigo Giuliani — Tue, 05 May 2026 16:57:07 +0000

A practical story about the missing protocol between AI and physical devices — and the open-source project building it.

The scenario that started everything

Imagine your grandmother lives with your family. One afternoon, no one is home. She falls in the bedroom and can't get up.

Your home has a smart lock, a camera with AI fall detection, a connected phone hub, and an alarm system. All of them are online. All of them are certified Matter devices. And none of them can coordinate a response — because no standard exists that lets an AI say "ensure her safety" and have every device figure out its role automatically.

The camera can detect the fall. But it can't tell the lock to open. The lock can open, but it doesn't know there's an emergency. The phone hub can call 911, but it doesn't know when to. Each device speaks its own command language, and the AI speaks in goals.

That gap — between AI intent and physical action — is what DoSync is built to close.

The core problem with existing protocols

Matter, Zigbee, and Z-Wave are excellent at what they do: letting apps control devices. They define command clusters like OnOff, LevelControl, and Lock that work across manufacturers. That's genuinely valuable.

But they were designed for human-initiated control via apps. When an AI enters the picture, these protocols become a bottleneck:

# What existing protocols understand
lock.unlock()
light.set_brightness(100)
thermostat.set_temperature(21)

# What an AI actually thinks in
"ensure the safety of the person who fell"
"prepare the home for bedtime"  
"nobody is home — save energy"

Someone has to translate. Today, that translation is custom code written per-device, per-platform, per-scenario. It doesn't scale. It breaks when you add a new device. And it completely fails in emergencies where milliseconds matter.

Introducing DoSync

DoSync is an open communication protocol (Apache 2.0) that lets AI systems interact with physical home devices using semantic intent — expressing what they want to achieve, not how to achieve it.

The key insight: instead of the AI issuing commands, devices declare their capabilities, and a semantic resolver matches intent to capability automatically.

// A device announces what it can do (Capability Manifest)
{
  "device_id": "lock-frontdoor-01",
  "tags": ["door-lock", "entrance", "emergency"],
  "actuators": [
    { "id": "unlock", "type": "unlock" },
    { "id": "lock",   "type": "lock"   }
  ],
  "emergency_capable": true
}

// The AI sends an intent — not a command
{
  "intent": "ensure_safety",
  "urgency": "emergency",
  "context": {
    "trigger": "fall_detected",
    "location": "bedroom",
    "emergency_number": "911"
  }
}

// DoSync resolves this automatically to:
// → lock-frontdoor-01: unlock (emergency_capable = true)
// → phone-hub-01: call 911
// → alarm-01: activate emergency pattern
// → family phones: push notification
// All in parallel. No hardcoded rules.

The 5-layer architecture

DoSync is organized in 5 layers, similar to OSI but designed for AI-to-device communication:

Layer 5 — Intent        AI expresses goals in natural language or JSON
Layer 4 — Semantic      Intent → device action mapping via capability matching  
Layer 3 — Registry      Devices self-declare capabilities on network join
Layer 2 — Secure ch.    mTLS, local PKI, zero-trust — no internet required
Layer 1 — Transport     WiFi · BLE · Zigbee · Z-Wave · Thread · Ethernet

The transport-agnostic HAL (Hardware Abstraction Layer) means the same protocol runs over any physical medium. A manufacturer implements DoSync once and supports any AI system.

What's built today

The protocol is not theoretical. There's a working reference implementation:

git clone https://github.com/giulianireg-spec/dosync-protocol
cd dosync-protocol
pip install fastapi uvicorn

# Start the hub
PYTHONPATH=. uvicorn server:app --host 0.0.0.0 --port 47200 --reload

# Run the full demo — 7 scenarios
PYTHONPATH=. python3 examples/demo_full.py

# Run the certification suite
python3 certify.py --host localhost --port 47200 --tier emergency

The demo output looks like this:

══════════════════════════════════════════════════════════════
  Scenario 1 — Fall detected · Emergency
══════════════════════════════════════════════════════════════
  ▶  Camera emits event: fall_detected [EMERGENCY]
  ▶  AI resolves intent: ensure_safety [EMERGENCY]
  ✓  [lock-frontdoor-01] unlock  → {"status": "unlocked", "duration_seconds": 300}
  ✓  [alarm-main-01] alarm       → {"status": "activated", "pattern": "emergency"}
  ✓  [phone-family-01] call      → {"status": "calling", "number": "911"}
  ✓ SUCCESS  — 7 parallel actions in < 100ms

And the certification CLI:

── Tier EMERGENCY — Override and audit log ─────────────
  ✓  Emergency intent executes without confirmation
  ✓  Emergency-capable devices participate in response
  ✓  Audit log exists and has entries
  ✓  SHA-256 chain integrity verified
  ✓  Emergency event recorded in audit log
── Result ──────────────────────────────────────────────
  Tests passed: 16  ·  Tests failed: 0
  ✓ CERTIFIED — DoSync EMERGENCY
  Fingerprint: fb083f5740978b9a38c448bdc4fe3090…

The 7 working scenarios

The demo covers situations that no existing protocol handles automatically:

Scenario	Trigger	DoSync response
Fall detected	Camera AI	911 called · Door unlocked · Alarm · Family notified
Smoke / CO	Detector over threshold	3 phases: Alert → Evacuate → Unlock for responders
Fridge failure	Compressor off, temp rising	Family SMS before food spoils
Nobody home	Phone WiFi + power meter	Lights off · Thermostat eco · Alarm armed
Laundry done	Appliance cycle complete	Remind family before clothes wrinkle
Good morning	First motion of the day	Blinds 80% · Coffee on · Weather shown
Bedtime	Scheduler at 21:30	Lights dim to 10% · Blinds close

The smoke scenario is worth highlighting because it introduces phased execution — unlike the others that run in parallel, a fire evacuation needs a specific order:

PhasedActionPlan(phases=[
    Phase("ALERT — immediate notification", delay_after_ms=2000, actions=[
        PhaseAction("alarm-main-01",   "alarm",  {"pattern": "fire"}),
        PhaseAction("phone-family-01", "call",   {"number": "100"}),
        PhaseAction("phone-family-01", "notify", {"urgency": "emergency"}),
    ]),
    Phase("EVACUATION — visual guidance", delay_after_ms=3000, actions=[
        PhaseAction("lights-main-01",   "set_brightness", {"brightness": 100}),
        PhaseAction("lock-backdoor-01", "unlock",         {"duration_seconds": 600}),
    ]),
    Phase("ACCESS — entry for responders", actions=[
        PhaseAction("lock-frontdoor-01",  "unlock", {"duration_seconds": 600}),
        PhaseAction("camera-exterior-01", "record", {"reason": "fire_emergency"}),
    ]),
])

Presence inference — not detection

One of the less obvious design decisions: DoSync doesn't treat presence as a binary sensor. It uses an OccupancyEngine that aggregates weighted signals from multiple context providers:

# Phone leaves WiFi network (weight: 0.7)
hub.update_presence(PresenceSignal(
    device_id="phone-rodrigo-01",
    signal_type=ContextSignalType.PRESENCE,
    present=False,
    confidence=0.7,
))

# Hub infers: occupied=False | confidence=100% | signals=1
state = hub.get_occupancy()

When a smartwatch is added, its GPS signal (weight 0.9) combines with the phone WiFi signal for a more robust inference. If the phone battery died but the smartwatch is home, the system correctly infers someone is still there. The AI learns patterns over time — this is the bridge to FamilyOS, the generational AI project that DoSync is designed to power.

The certification model

Following the Matter approach, DoSync uses self-certification with three tiers:

Tier	Requirements
Basic	Connects, authenticates, publishes capability manifest
Standard	Responds to intents, sends events
Emergency	Emergency override + tamper-evident SHA-256 audit log

The CLI generates a signed dosync-cert.json report. No manual approval needed for Basic and Standard. Emergency tier requires human review.

dosync-certify --host 192.168.1.50 --tier standard --output cert.json

The tamper-evident audit log is worth a separate mention: every action chains to the previous one with SHA-256, similar to blockchain. If someone modifies any historical entry, the entire chain breaks and the system detects it immediately.

What's different from Matter, Zigbee, and Home Assistant

Matter solves device interoperability for app-controlled scenarios. It has no semantic layer, no emergency override, and no concept of AI intent. DoSync doesn't replace Matter — a device can be Matter-certified for app control and DoSync-certified for AI interaction simultaneously.

Home Assistant is a platform, not a protocol. It recently added MCP support for natural language, which is directionally similar, but it's adapting an existing command-based system rather than designing from first principles for AI communication.

DoSync is the only open protocol designed specifically for AI-to-device semantic communication, with transport agnosticism, emergency override, capability-based discovery, and a certifiable standard that any manufacturer can implement.

What's next

The Raspberry Pi hardware kit is on order. The next milestone is a physical demo: a real door lock opening in response to a semantic emergency intent. That demo, combined with the working certification CLI, is the artifact we're taking to hardware manufacturers and IoT investors.

The roadmap:

Already shipped: SQLite persistence · 7 working scenarios · REST API · Certification CLI 16/16

Q2 2026 — GPIO adapter for Raspberry Pi · Physical door lock demo
Q3 2026 — Home Assistant bridge · BLE transport adapter
Q4 2026 — 3 certified partner devices · First manufacturer outreach
2027+ — FamilyOS integration · Generational AI memory layer

Try it now

git clone https://github.com/giulianireg-spec/dosync-protocol
cd dosync-protocol
pip install fastapi uvicorn
PYTHONPATH=. uvicorn server:app --host 0.0.0.0 --port 47200 --reload
# Open http://localhost:47200/docs

The interactive API docs let you register devices, fire intents, and see the semantic resolver work in real time — no hardware required.

If you're building IoT firmware, smart home devices, or AI home assistants, I'd love to hear your feedback. The RFC process is open and transport adapter contributions are welcome.

GitHub: github.com/giulianireg-spec/dosync-protocol

License: Apache 2.0

Contact: giulianireg@gmail.com

Update — May 2026

Since this post was published, DoSync has moved from theory to working hardware.

Physical demo live: 10 Philips WiZ bulbs responding to semantic intents
via UDP — no cloud, no intermediary. A natural language conversation with
Claude Desktop controls real lights in real time.

📹 Watch the demo: https://youtu.be/2czAqoIrd08

What shipped since this post:

WebSocket endpoint — real-time event broadcasting to all connected clients
Web dashboard at http://localhost:47200 — live feed, intent launcher, audit log
API key authentication with SHA-256 hashing
Native MCP server — any LLM with MCP support can control the hub directly
Home Assistant bridge — imports devices from HA automatically (10 domains)
Automatic device discovery via UDP broadcast
WiZ adapter — direct UDP control of Philips WiZ bulbs
Full device management CLI (manage.py)
Raspberry Pi kit arrived — GPIO adapter in progress

The MCP integration deserves a mention: with the DoSync MCP server
configured in Claude Desktop, you can type "there's an emergency at home"
and physical lights respond immediately. No app. No command. Just intent.

The door lock demo (the scenario this project was built for) is coming
as soon as the physical lock hardware arrives.

DoSync is part of a larger project: FamilyOS — a private, local, generational AI for the home. The best inheritance we can leave our children is knowledge. DoSync is the protocol that lets the home itself become part of that inheritance.