<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://revolveteam.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://revolveteam.com/" rel="alternate" type="text/html" /><updated>2026-02-25T15:21:30+00:00</updated><id>https://revolveteam.com/feed.xml</id><title type="html">(r)evolve</title><subtitle>Revolve to Evolve</subtitle><entry><title type="html">HIVE Protocol Joins Defense Unicorns</title><link href="https://revolveteam.com/blog/hive-joins-defense-unicorns/" rel="alternate" type="text/html" title="HIVE Protocol Joins Defense Unicorns" /><published>2026-02-25T00:00:00+00:00</published><updated>2026-02-25T00:00:00+00:00</updated><id>https://revolveteam.com/blog/hive-joins-defense-unicorns</id><content type="html" xml:base="https://revolveteam.com/blog/hive-joins-defense-unicorns/"><![CDATA[<p>We’re pleased to announce that HIVE Protocol has been acquired by <a href="https://defenseunicorns.com/">Defense Unicorns</a>.</p>

<h2 id="what-hive-is">What HIVE Is</h2>

<p>HIVE is a hierarchical coordination protocol for distributed autonomous systems. It applies lessons from centuries of military command structure to the problem of getting machines to work together at scale — organizing swarms of autonomous agents into nested tiers that compress information upward and push intent downward, so that large formations can coordinate without drowning in data.</p>

<p>We wrote extensively about the ideas behind HIVE on this blog: from <a href="../blog/device-is-the-network/">treating every device as the network</a> to <a href="../blog/hierarchy-is-compression/">hierarchy as communication optimization</a>. Those posts reflect what we believed when we wrote them, and we still stand behind the core thinking.</p>

<h2 id="why-defense-unicorns">Why Defense Unicorns</h2>

<p>Defense Unicorns builds open-source tooling that helps defense organizations deploy and operate software in disconnected, contested, and resource-constrained environments. That mission overlaps squarely with what HIVE was designed for. They have the team, the community, and the operational credibility to take HIVE places we couldn’t take it alone.</p>

<p>We evaluated this carefully. HIVE needed a home where the protocol would be built, deployed, and iterated on at real scale — not just theorized about. Defense Unicorns is that home.</p>

<h2 id="what-we-built">What We Built</h2>

<p>We’re proud of the foundation we laid. HIVE started as a question — <em>what if we stopped treating autonomous coordination as a networking problem and started treating it as an organizational design problem?</em> — and grew into a working protocol with a clear architecture for hierarchical task decomposition, intent propagation, and state compression across tiers.</p>

<p>The ideas are sound. The architecture is sound. Now it’s time for someone with deeper operational reach to carry it forward.</p>

<h2 id="whats-next">What’s Next</h2>

<p>As part of this transition, I — Kit Plummer, CEO and Founder of (r)evolve — am joining Defense Unicorns as VP, Data, AI and Autonomy. I’ll be leading the work to take HIVE and the broader autonomy mission forward from inside Defense Unicorns, with the resources and operational reach to deliver at scale.</p>

<p>(r)evolve continues forward with a sharpened focus on human-machine-AI teaming, coagency, and holistic performance.</p>

<h2 id="to-the-hive-community">To the HIVE Community</h2>

<p>If you’ve been following HIVE’s development — thank you. The protocol is in excellent hands, and we’re excited to see what Defense Unicorns builds with it.</p>]]></content><author><name></name></author><summary type="html"><![CDATA[HIVE Protocol has found a new home. We're proud to announce its sale to Defense Unicorns, where it will continue to grow.]]></summary></entry><entry><title type="html">Hierarchy Isn’t Bureaucracy—It’s Evolved Communication Optimization</title><link href="https://revolveteam.com/blog/hierarchy-is-compression/" rel="alternate" type="text/html" title="Hierarchy Isn’t Bureaucracy—It’s Evolved Communication Optimization" /><published>2026-01-26T00:00:00+00:00</published><updated>2026-01-26T00:00:00+00:00</updated><id>https://revolveteam.com/blog/hierarchy-is-compression</id><content type="html" xml:base="https://revolveteam.com/blog/hierarchy-is-compression/"><![CDATA[<blockquote>
  <p>“He will win who knows when to fight and when not to fight. He will win who knows how to handle both superior and inferior forces.”
— Sun Tzu, <em>The Art of War</em></p>
</blockquote>

<p>Sun Tzu wrote those words around 500 BCE, codifying principles that Chinese armies had refined over centuries. But buried in his treatise on generalship is something more fundamental than tactics: an information architecture for coordinating thousands of soldiers across contested terrain with nothing but signal flags, drums, and runners.</p>

<p>He didn’t have radios. He didn’t have GPS. He certainly didn’t have mesh networks. And yet his armies coordinated at scales that modern autonomous systems programs struggle to match.</p>

<p>What did he understand that we’ve forgotten?</p>

<p><img src="/img/bamboo-slips-art-of-war.png" alt="Bamboo slips containing Sun Tzu's Art of War, discovered in the Yinqueshan Han Tombs in 1972." />
<em>Bamboo slips containing Sun Tzu’s Art of War, discovered in 1972. The oldest surviving copy of the text, sealed in a tomb around 134 BCE. Photo: Gary Todd / Wikimedia Commons / Public Domain</em></p>

<h2 id="the-modern-prejudice-against-hierarchy">The Modern Prejudice Against Hierarchy</h2>

<p>In contemporary discussions of autonomous systems, hierarchy is treated as an obstacle—bureaucratic overhead inherited from rigid institutional thinking. The prevailing assumption is that flat, decentralized architectures are inherently more agile, more resilient, more modern.</p>

<p>This assumption is wrong.</p>

<p>Hierarchy isn’t about authority. It’s about information flow. And it turns out that human organizations discovered the optimal information architecture for large-scale coordination roughly five thousand years ago.</p>

<h2 id="the-cognitive-constraint">The Cognitive Constraint</h2>

<p>In 1956, psychologist George Miller published one of the most cited papers in cognitive science: “The Magical Number Seven, Plus or Minus Two.” His finding was simple but profound: human working memory can only hold about seven items at once.</p>

<p>This isn’t a software limitation we can patch. It’s a hardware constraint baked into the architecture of the human brain. And it explains why every military organization in history—from Roman legions to modern infantry battalions—has converged on the same basic structure: small teams of 4-8 people, led by individuals who report to leaders coordinating 3-5 teams.</p>

<p>A Roman centurion didn’t track 80 individual soldiers. He tracked 10 squad leaders. A modern Army company commander doesn’t manage 120 soldiers directly—she coordinates with 3-4 platoon leaders who each manage 3-4 squad leaders.</p>

<p>This pattern isn’t bureaucratic tradition. It’s cognitive load management.</p>

<h2 id="hierarchy-as-compression">Hierarchy as Compression</h2>

<p>Here’s the insight that matters for autonomous systems: <strong>hierarchy is a compression algorithm</strong>.</p>

<p>When a platoon leader reports to the company commander, they don’t transmit the position, status, ammunition count, and physiological state of every soldier under their command. They transmit a summary: “Second platoon is combat-effective, in position at grid reference XY, ready to execute.”</p>

<p>That summary compresses perhaps 40 individual data points into one capability statement. The company commander can then hold 3-4 such summaries in working memory—exactly what cognitive science predicts—and make decisions at their echelon.</p>

<p>This compression happens at every level of the hierarchy. Squad leaders summarize fire teams. Platoon leaders summarize squads. Company commanders summarize platoons. The information that flows upward is <em>aggregated</em>, with detail appropriate to the decision-making authority at each level.</p>

<p>Sun Tzu understood this intuitively:</p>

<blockquote>
  <p>“If words of command are not clear and distinct, if orders are not thoroughly understood, the general is to blame. But if his orders are clear, and the soldiers nevertheless disobey, then it is the fault of their officers.”</p>
</blockquote>

<p>Clear orders flowing down. Summarized status flowing up. Coordination happening laterally between peers. Three information flows, each optimized for its purpose.</p>

<h2 id="the-mathematics-of-flat-vs-hierarchical">The Mathematics of Flat vs. Hierarchical</h2>

<p>Let’s make this concrete with some numbers.</p>

<p>In a flat mesh network where every node must coordinate with every other node, the number of communication links grows as n(n-1)/2. For practical purposes, this is O(n²)—quadratic scaling.</p>

<table>
  <thead>
    <tr>
      <th>Nodes</th>
      <th>Links (Flat Mesh)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10</td>
      <td>45</td>
    </tr>
    <tr>
      <td>20</td>
      <td>190</td>
    </tr>
    <tr>
      <td>100</td>
      <td>4,950</td>
    </tr>
    <tr>
      <td>1,000</td>
      <td>499,500</td>
    </tr>
  </tbody>
</table>

<p>Now consider a hierarchical structure where each node only communicates with its immediate superior and 4-6 peers. The communication complexity drops to O(n log n).</p>

<table>
  <thead>
    <tr>
      <th>Nodes</th>
      <th>Links (Hierarchy)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10</td>
      <td>~23</td>
    </tr>
    <tr>
      <td>20</td>
      <td>~53</td>
    </tr>
    <tr>
      <td>100</td>
      <td>~332</td>
    </tr>
    <tr>
      <td>1,000</td>
      <td>~4,983</td>
    </tr>
  </tbody>
</table>

<p>At 1,000 nodes, the hierarchical approach requires roughly 1% of the communication bandwidth. This isn’t a marginal optimization—it’s the difference between systems that work and systems that collapse under their own coordination overhead.</p>

<p><img src="/img/trajans-column-legionaries.jpg" alt="Relief from Trajan's Column showing Trajan reviewing his troops, circa 113 CE." />
<em>Trajan reviews his troops from a tribunal, flanked by officers—hierarchy in action. The column depicts 2,662 figures across 155 scenes, organized by cohort and century. Photo: R.B. Ulrich / trajans-column.org</em></p>

<h2 id="three-flows-not-one">Three Flows, Not One</h2>

<p>The hierarchy insight isn’t just about reducing bandwidth. It’s about recognizing that coordination requires three distinct information flows, each with different characteristics:</p>

<p><strong>Upward: Aggregation.</strong> Raw state becomes summarized capability. “I have 12 UAVs with 47% average battery” becomes “ISR coverage available for 3 hours.” The next echelon doesn’t need to know which specific platforms are assigned—they need to know what the team can do.</p>

<p><strong>Downward: Dissemination.</strong> Commander’s intent becomes specific tasking. “Maintain situational awareness on Route Tampa” gets translated at each level into increasingly specific guidance, until individual platforms receive actionable instructions appropriate to their capabilities.</p>

<p><strong>Lateral: Coordination.</strong> Peers synchronize directly without routing through higher echelons. Adjacent squads coordinate their boundaries. Neighboring platoons deconflict their movements. This happens at machine speed, without burdening the hierarchy with routine coordination traffic.</p>

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>        ┌─────────────────┐
        │   Commander     │
        │   (Intent)      │
        └────────┬────────┘
                 │
    ┌────────────┼────────────┐
    │            │            │
    ▼            ▼            ▼
┌───────┐   ┌───────┐   ┌───────┐
│ Plt 1 │◄─►│ Plt 2 │◄─►│ Plt 3 │  ← Lateral coordination
└───┬───┘   └───┬───┘   └───┬───┘
    │           │           │
    ▼           ▼           ▼
 [Squads]    [Squads]    [Squads]

    ▲           ▲           ▲
    │           │           │
    └───────────┴───────────┘
         Aggregated status
            flows UP
</code></pre></div></div>

<p>These flows map directly to military doctrine because doctrine encodes the patterns that work.</p>

<p>Sun Tzu again:</p>

<blockquote>
  <p>“The control of a large force is the same principle as the control of a few men: it is merely a question of dividing up their numbers.”</p>
</blockquote>

<p>Divide, aggregate, coordinate. The pattern scales because it was designed to scale.</p>

<h2 id="what-this-means-for-autonomous-systems">What This Means for Autonomous Systems</h2>

<p>If hierarchy is evolved communication optimization, then treating it as bureaucratic overhead is an architectural mistake. The challenge isn’t to eliminate hierarchy—it’s to implement it properly.</p>

<p>This means:</p>

<p><strong>Design for aggregation.</strong> Platforms should advertise capabilities, not just positions. “I can provide persistent surveillance for 4 hours at 10km range” is more useful to a coordination layer than raw telemetry.</p>

<p><strong>Respect cognitive limits.</strong> Human operators in the loop should see summarized team capabilities, not individual platform states. If your interface requires an operator to track 20+ entities simultaneously, you’ve exceeded human cognitive capacity.</p>

<p><strong>Enable lateral coordination.</strong> Peers should be able to synchronize directly without routing through a central coordinator. Boundary management between adjacent teams is a local problem that should be solved locally.</p>

<p><strong>Preserve authority at appropriate echelons.</strong> Not every decision should flow to the top. Define what can execute autonomously, what requires approval, and what demands human judgment—then encode those policies into the coordination architecture.</p>

<h2 id="the-oldest-new-idea">The Oldest New Idea</h2>

<p>We tend to assume that modern problems require modern solutions. But the coordination of large numbers of heterogeneous agents across contested environments with unreliable communications isn’t a new problem. It’s arguably the oldest problem in organized human activity.</p>

<p>Military hierarchies evolved over millennia precisely because they solve this problem. The Roman legion could coordinate 5,000 soldiers across miles of battlefield with nothing but flags and horns. The Mongol army could execute complex maneuvers across hundreds of miles with relay riders.</p>

<p>These weren’t primitive solutions waiting for technology to replace them. They were sophisticated information architectures optimized by centuries of selection pressure. The organizations that got coordination wrong didn’t survive to pass on their patterns.</p>

<p>Sun Tzu’s armies didn’t need mesh networks. They understood something more fundamental: that hierarchy isn’t the enemy of agility—it’s the precondition for it.</p>

<blockquote>
  <p>“In war, the way is to avoid what is strong, and strike at what is weak.”</p>
</blockquote>

<p>Flat coordination architectures are strong in small teams. They are weak at scale. Hierarchy is the way to avoid that weakness.</p>

<p>The ancients figured this out with bronze swords and signal fires. Perhaps it’s time we remembered what they knew.</p>

<hr />

<p><em>(r)evolve is building HIVE Protocol, open coordination infrastructure for human-machine-AI teams. We’re encoding five millennia of organizational wisdom into protocol.</em></p>

<hr />

<h3 id="image-credits">Image Credits</h3>

<ul>
  <li><strong>Hero image:</strong> Yinqueshan bamboo slips of Sun Zi’s Art of War, Western Han Dynasty, Shandong Museum permanent collection. <a href="https://govt.chinadaily.com.cn/s/202206/14/WS62a82e87498ea2749279aae8/bamboo-slips-chronicle-chinas-ancient-military-philosophy.html">China Daily</a>.</li>
  <li><strong>Trajan’s Column relief:</strong> Scene VII, Trajan reviews his troops from a tribunal. Photo by R.B. Ulrich. <a href="https://www.trajans-column.org/?page_id=107">trajans-column.org</a>.</li>
</ul>]]></content><author><name></name></author><summary type="html"><![CDATA[What five millennia of military organization teach us about coordinating autonomous systems at scale.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://revolveteam.com/img/bamboo-slips-art-of-war.png" /><media:content medium="image" url="https://revolveteam.com/img/bamboo-slips-art-of-war.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">Building a CI Pipeline for Radicle with goa</title><link href="https://revolveteam.com/blog/goa-radicle-ci/" rel="alternate" type="text/html" title="Building a CI Pipeline for Radicle with goa" /><published>2026-01-10T00:00:00+00:00</published><updated>2026-01-10T00:00:00+00:00</updated><id>https://revolveteam.com/blog/goa-radicle-ci</id><content type="html" xml:base="https://revolveteam.com/blog/goa-radicle-ci/"><![CDATA[<h1 id="building-a-ci-pipeline-for-radicle-with-goa">Building a CI Pipeline for Radicle with goa</h1>

<p><em>By Kit Plummer, (r)evolve</em></p>

<hr />

<p><a href="https://radicle.xyz">Radicle</a> is a peer-to-peer code collaboration stack built on Git. Unlike GitHub or GitLab, Radicle is decentralized—your code lives on your machine and is replicated across a network of nodes. But this raises a question: how do you run CI/CD for a decentralized repository?</p>

<p>Enter <strong>goa</strong> (GitOps Agent), a lightweight tool I created about 5 years ago to assist with some MLOps work I was doing that watches repositories for changes and executes commands when updates are detected. With goa’s Radicle support, you can build a self-hosted CI pipeline for your Radicle projects.  Thanks to Claude Code for helping review and refresh the original goa codebase quickly.</p>

<h2 id="why-goa-for-radicle-ci">Why goa for Radicle CI?</h2>

<ul>
  <li><strong>No external services required</strong> - runs entirely on your local machine or server</li>
  <li><strong>Watches both pushes and patches</strong> - trigger CI on new commits or when contributors submit patches (Radicle’s equivalent of pull requests)</li>
  <li><strong>Simple setup</strong> - single binary, no complex configuration</li>
  <li><strong>Environment variables</strong> - access commit info, patch details, and more in your CI scripts</li>
</ul>

<h2 id="prerequisites">Prerequisites</h2>

<ul>
  <li>A running <a href="https://radicle.xyz/guides/user">Radicle node</a> (<code class="language-plaintext highlighter-rouge">rad</code> CLI installed and initialized)</li>
  <li>Your repository seeded to your node</li>
  <li>Rust toolchain (for installing goa) or install one of the binaries at <a href="https://github.com/kitplummer/goa/releases">https://github.com/kitplummer/goa/releases</a>.</li>
</ul>

<h2 id="installation">Installation</h2>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cargo <span class="nb">install </span>gitops-agent
</code></pre></div></div>

<p>This installs the <code class="language-plaintext highlighter-rouge">goa</code> binary.</p>

<h2 id="basic-setup">Basic Setup</h2>

<h3 id="1-find-your-repository-id">1. Find Your Repository ID</h3>

<p>Every Radicle repository has a unique identifier (RID). Find yours with:</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>rad inspect
</code></pre></div></div>

<p>You’ll see output like:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>rad:z3fF7wV6LXz915ND1nbHTfeY3Qcq7
</code></pre></div></div>

<h3 id="2-identify-your-seed-node">2. Identify Your Seed Node</h3>

<p>Your local node exposes an HTTP API. By default, it’s available at <code class="language-plaintext highlighter-rouge">http://localhost:8080</code>. You can also use public seed nodes like <code class="language-plaintext highlighter-rouge">https://seed.radicle.garden</code>.</p>

<h3 id="3-start-watching">3. Start Watching</h3>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>goa radicle <span class="se">\</span>
  <span class="nt">--seed-url</span> http://localhost:8080 <span class="se">\</span>
  <span class="nt">--rid</span> rad:z3fF7wV6LXz915ND1nbHTfeY3Qcq7 <span class="se">\</span>
  <span class="nt">--command</span> <span class="s1">'./ci.sh'</span> <span class="se">\</span>
  <span class="nt">--watch-patches</span> <span class="se">\</span>
  <span class="nt">--delay</span> 60
</code></pre></div></div>

<p>This tells goa to:</p>
<ul>
  <li>Connect to your local Radicle node’s HTTP API</li>
  <li>Watch the specified repository</li>
  <li>Run <code class="language-plaintext highlighter-rouge">./ci.sh</code> when changes are detected</li>
  <li>Check for both push and patch updates</li>
  <li>Poll every 60 seconds</li>
</ul>

<h2 id="writing-your-ci-script">Writing Your CI Script</h2>

<p>goa passes context about the trigger via environment variables. Here’s a complete CI script:</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c">#!/bin/bash</span>
<span class="nb">set</span> <span class="nt">-e</span>

<span class="nb">echo</span> <span class="s2">"=== Radicle CI ==="</span>
<span class="nb">echo</span> <span class="s2">"Repository: </span><span class="nv">$GOA_RADICLE_RID</span><span class="s2">"</span>
<span class="nb">echo</span> <span class="s2">"Trigger: </span><span class="nv">$GOA_TRIGGER_TYPE</span><span class="s2">"</span>
<span class="nb">echo</span> <span class="s2">"Commit: </span><span class="nv">$GOA_COMMIT_OID</span><span class="s2">"</span>

<span class="c"># Clone from local Radicle storage</span>
<span class="nv">WORK_DIR</span><span class="o">=</span><span class="s2">"/tmp/ci-</span><span class="si">$(</span><span class="nb">date</span> +%s<span class="si">)</span><span class="s2">"</span>
<span class="nv">STORAGE_PATH</span><span class="o">=</span><span class="s2">"</span><span class="nv">$HOME</span><span class="s2">/.radicle/storage/</span><span class="k">${</span><span class="nv">GOA_RADICLE_RID</span><span class="p">#rad</span>:<span class="k">}</span><span class="s2">"</span>

git clone <span class="s2">"</span><span class="nv">$STORAGE_PATH</span><span class="s2">"</span> <span class="s2">"</span><span class="nv">$WORK_DIR</span><span class="s2">"</span>
<span class="nb">cd</span> <span class="s2">"</span><span class="nv">$WORK_DIR</span><span class="s2">"</span>

<span class="c"># Checkout the specific commit</span>
git checkout <span class="s2">"</span><span class="nv">$GOA_COMMIT_OID</span><span class="s2">"</span>

<span class="c"># If this is a patch, show details</span>
<span class="k">if</span> <span class="o">[</span> <span class="s2">"</span><span class="nv">$GOA_TRIGGER_TYPE</span><span class="s2">"</span> <span class="o">=</span> <span class="s2">"patch"</span> <span class="o">]</span><span class="p">;</span> <span class="k">then
  </span><span class="nb">echo</span> <span class="s2">"Patch ID: </span><span class="nv">$GOA_PATCH_ID</span><span class="s2">"</span>
  <span class="nb">echo</span> <span class="s2">"Title: </span><span class="nv">$GOA_PATCH_TITLE</span><span class="s2">"</span>
  <span class="nb">echo</span> <span class="s2">"State: </span><span class="nv">$GOA_PATCH_STATE</span><span class="s2">"</span>
  <span class="nb">echo</span> <span class="s2">"Base: </span><span class="nv">$GOA_BASE_COMMIT</span><span class="s2">"</span>
<span class="k">fi

</span><span class="nb">echo</span> <span class="s2">"=== Running Tests ==="</span>

<span class="c"># Your build/test commands here</span>
cargo build
cargo <span class="nb">test

echo</span> <span class="s2">"=== CI Complete ==="</span>

<span class="c"># Cleanup</span>
<span class="nb">cd</span> /
<span class="nb">rm</span> <span class="nt">-rf</span> <span class="s2">"</span><span class="nv">$WORK_DIR</span><span class="s2">"</span>
</code></pre></div></div>

<p>Save this as <code class="language-plaintext highlighter-rouge">ci.sh</code> and make it executable:</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">chmod</span> +x ci.sh
</code></pre></div></div>

<h2 id="environment-variables-reference">Environment Variables Reference</h2>

<p>goa provides these environment variables when triggered:</p>

<table>
  <thead>
    <tr>
      <th>Variable</th>
      <th>Description</th>
      <th>Example</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GOA_RADICLE_RID</code></td>
      <td>Repository ID</td>
      <td><code class="language-plaintext highlighter-rouge">rad:z3fF7wV6LXz915ND1nbHTfeY3Qcq7</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GOA_RADICLE_URL</code></td>
      <td>Seed node URL</td>
      <td><code class="language-plaintext highlighter-rouge">http://localhost:8080</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GOA_TRIGGER_TYPE</code></td>
      <td><code class="language-plaintext highlighter-rouge">push</code> or <code class="language-plaintext highlighter-rouge">patch</code></td>
      <td><code class="language-plaintext highlighter-rouge">patch</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GOA_COMMIT_OID</code></td>
      <td>Commit SHA to test</td>
      <td><code class="language-plaintext highlighter-rouge">a1b2c3d4...</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GOA_PATCH_ID</code></td>
      <td>Patch ID (if patch)</td>
      <td><code class="language-plaintext highlighter-rouge">abc123...</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GOA_PATCH_TITLE</code></td>
      <td>Patch title (if patch)</td>
      <td><code class="language-plaintext highlighter-rouge">Fix memory leak</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GOA_PATCH_STATE</code></td>
      <td>Patch state (if patch)</td>
      <td><code class="language-plaintext highlighter-rouge">open</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GOA_BASE_COMMIT</code></td>
      <td>Base commit (if patch)</td>
      <td><code class="language-plaintext highlighter-rouge">def456...</code></td>
    </tr>
  </tbody>
</table>

<h2 id="running-as-a-system-service">Running as a System Service</h2>

<p>For production use, run goa as a systemd service:</p>

<div class="language-ini highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c"># /etc/systemd/system/radicle-ci.service
</span><span class="nn">[Unit]</span>
<span class="py">Description</span><span class="p">=</span><span class="s">Radicle CI Agent</span>
<span class="py">After</span><span class="p">=</span><span class="s">network.target radicle-node.service</span>

<span class="nn">[Service]</span>
<span class="py">Type</span><span class="p">=</span><span class="s">simple</span>
<span class="py">User</span><span class="p">=</span><span class="s">ci</span>
<span class="py">WorkingDirectory</span><span class="p">=</span><span class="s">/home/ci/myproject</span>
<span class="py">ExecStart</span><span class="p">=</span><span class="s">/usr/local/bin/goa radicle </span><span class="se">\
</span>  <span class="s">--seed-url http://localhost:8080 </span><span class="se">\
</span>  <span class="s">--rid rad:z3fF7wV6LXz915ND1nbHTfeY3Qcq7 </span><span class="se">\
</span>  <span class="s">--command './ci.sh' </span><span class="se">\
</span>  <span class="s">--watch-patches </span><span class="se">\
</span>  <span class="s">--delay 60 </span><span class="se">\
</span>  <span class="s">--timeout 600 </span><span class="se">\
</span>  <span class="s">--verbosity 1</span>
<span class="py">Restart</span><span class="p">=</span><span class="s">on-failure</span>
<span class="py">RestartSec</span><span class="p">=</span><span class="s">10</span>

<span class="nn">[Install]</span>
<span class="py">WantedBy</span><span class="p">=</span><span class="s">multi-user.target</span>
</code></pre></div></div>

<p>Enable and start:</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">sudo </span>systemctl <span class="nb">enable </span>radicle-ci
<span class="nb">sudo </span>systemctl start radicle-ci
</code></pre></div></div>

<p>View logs:</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>journalctl <span class="nt">-u</span> radicle-ci <span class="nt">-f</span>
</code></pre></div></div>

<h2 id="advanced-testing-patches-before-merge">Advanced: Testing Patches Before Merge</h2>

<p>One powerful use case is automatically testing patches (PRs) before they’re merged. Here’s an enhanced CI script that posts results back:</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c">#!/bin/bash</span>
<span class="nb">set</span> <span class="nt">-e</span>

<span class="nv">WORK_DIR</span><span class="o">=</span><span class="s2">"/tmp/ci-</span><span class="si">$(</span><span class="nb">date</span> +%s<span class="si">)</span><span class="s2">"</span>
<span class="nv">STORAGE_PATH</span><span class="o">=</span><span class="s2">"</span><span class="nv">$HOME</span><span class="s2">/.radicle/storage/</span><span class="k">${</span><span class="nv">GOA_RADICLE_RID</span><span class="p">#rad</span>:<span class="k">}</span><span class="s2">"</span>
<span class="nv">RESULT_FILE</span><span class="o">=</span><span class="s2">"/tmp/ci-result-</span><span class="nv">$$</span><span class="s2">"</span>

<span class="c"># Clone and checkout</span>
git clone <span class="s2">"</span><span class="nv">$STORAGE_PATH</span><span class="s2">"</span> <span class="s2">"</span><span class="nv">$WORK_DIR</span><span class="s2">"</span>
<span class="nb">cd</span> <span class="s2">"</span><span class="nv">$WORK_DIR</span><span class="s2">"</span>
git checkout <span class="s2">"</span><span class="nv">$GOA_COMMIT_OID</span><span class="s2">"</span>

<span class="c"># Run tests, capture result</span>
<span class="k">if </span>cargo <span class="nb">test </span>2&gt;&amp;1 | <span class="nb">tee</span> <span class="s2">"</span><span class="nv">$RESULT_FILE</span><span class="s2">"</span><span class="p">;</span> <span class="k">then
  </span><span class="nv">STATUS</span><span class="o">=</span><span class="s2">"passed"</span>
<span class="k">else
  </span><span class="nv">STATUS</span><span class="o">=</span><span class="s2">"failed"</span>
<span class="k">fi</span>

<span class="c"># If this was a patch, we could comment on it</span>
<span class="c"># (Radicle CLI support for this is evolving)</span>
<span class="k">if</span> <span class="o">[</span> <span class="s2">"</span><span class="nv">$GOA_TRIGGER_TYPE</span><span class="s2">"</span> <span class="o">=</span> <span class="s2">"patch"</span> <span class="o">]</span><span class="p">;</span> <span class="k">then
  </span><span class="nb">echo</span> <span class="s2">"Patch </span><span class="nv">$GOA_PATCH_ID</span><span class="s2">: tests </span><span class="nv">$STATUS</span><span class="s2">"</span>
  <span class="c"># Future: rad patch comment $GOA_PATCH_ID "CI $STATUS"</span>
<span class="k">fi</span>

<span class="c"># Cleanup</span>
<span class="nb">rm</span> <span class="nt">-rf</span> <span class="s2">"</span><span class="nv">$WORK_DIR</span><span class="s2">"</span> <span class="s2">"</span><span class="nv">$RESULT_FILE</span><span class="s2">"</span>

<span class="c"># Exit with appropriate code</span>
<span class="o">[</span> <span class="s2">"</span><span class="nv">$STATUS</span><span class="s2">"</span> <span class="o">=</span> <span class="s2">"passed"</span> <span class="o">]</span>
</code></pre></div></div>

<h2 id="tips-and-best-practices">Tips and Best Practices</h2>

<ol>
  <li><strong>Use <code class="language-plaintext highlighter-rouge">--timeout</code></strong> to prevent runaway builds:
    <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>goa radicle ... <span class="nt">--timeout</span> 600  <span class="c"># 10 minute limit</span>
</code></pre></div>    </div>
  </li>
  <li><strong>Adjust <code class="language-plaintext highlighter-rouge">--delay</code></strong> based on your needs:
    <ul>
      <li>Development: 30-60 seconds</li>
      <li>Production: 120-300 seconds</li>
    </ul>
  </li>
  <li><strong>Use <code class="language-plaintext highlighter-rouge">--verbosity 2</code></strong> for debugging:
    <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>goa radicle ... <span class="nt">--verbosity</span> 2
</code></pre></div>    </div>
  </li>
  <li><strong>Isolate CI environments</strong> - use containers or VMs for untrusted code:
    <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c"># In ci.sh</span>
docker run <span class="nt">--rm</span> <span class="nt">-v</span> <span class="s2">"</span><span class="nv">$WORK_DIR</span><span class="s2">:/src"</span> my-ci-image /src/run-tests.sh
</code></pre></div>    </div>
  </li>
  <li><strong>Monitor multiple repositories</strong> by running multiple goa instances:
    <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>goa radicle <span class="nt">--rid</span> rad:z111... <span class="nt">--command</span> <span class="s1">'./ci-project1.sh'</span> &amp;
goa radicle <span class="nt">--rid</span> rad:z222... <span class="nt">--command</span> <span class="s1">'./ci-project2.sh'</span> &amp;
</code></pre></div>    </div>
  </li>
</ol>

<h2 id="conclusion">Conclusion</h2>

<p>With goa, you can bring CI/CD to the decentralized world of Radicle without relying on centralized services. Your code stays sovereign, your CI runs locally, and you maintain full control over your development workflow.</p>

<p>The combination of Radicle’s peer-to-peer collaboration and goa’s lightweight automation creates a powerful, self-hosted development environment that respects your autonomy while providing the conveniences of modern DevOps practices.</p>

<hr />

<p><strong>Resources:</strong></p>
<ul>
  <li><a href="https://crates.io/crates/gitops-agent">goa on crates.io</a></li>
  <li><a href="https://github.com/kitplummer/goa">goa on GitHub</a></li>
  <li><a href="https://radicle.xyz/guides">Radicle Documentation</a></li>
</ul>]]></content><author><name></name></author><summary type="html"><![CDATA[How to set up self-hosted continuous integration for Radicle's peer-to-peer code collaboration stack using goa, a lightweight GitOps agent.]]></summary></entry><entry><title type="html">NATO’s Unmanned Systems Standard: Right Problem, Wrong Model?</title><link href="https://revolveteam.com/blog/standards-problem/" rel="alternate" type="text/html" title="NATO’s Unmanned Systems Standard: Right Problem, Wrong Model?" /><published>2026-01-05T00:00:00+00:00</published><updated>2026-01-05T00:00:00+00:00</updated><id>https://revolveteam.com/blog/standards-problem</id><content type="html" xml:base="https://revolveteam.com/blog/standards-problem/"><![CDATA[<h1 id="natos-unmanned-systems-standard-right-problem-wrong-model">NATO’s Unmanned Systems Standard: Right Problem, Wrong Model?</h1>

<p><em>By Kit Plummer, (r)evolve</em></p>

<hr />

<p>NATO is building a standard for coordinating unmanned systems across domains. It’s called <a href="https://www.janes.com/osint-insights/defence-and-national-security-analysis/stanag4817-nato-maritime-unmanned-systems-jigsaw">STANAG 4817</a>, and it’s being positioned as the backbone of future multi-domain operations — enabling drones, UUVs, and USVs from different nations to share data and operate together.</p>

<p>On paper, it sounds essential. In practice, there are problems — both with the approach and with how it’s being developed.</p>

<h2 id="what-4817-is-trying-to-do">What 4817 Is Trying to Do</h2>

<p>STANAG 4817 builds on <a href="https://en.wikipedia.org/wiki/STANAG_4586">STANAG 4586</a>, the existing NATO standard for UAV control interfaces. Where 4586 defined how an operator controls a single unmanned aircraft, 4817 extends to multi-domain: air, surface, and underwater systems coordinated from unified control stations.</p>

<p>The standard incorporates the <a href="https://ieeexplore.ieee.org/document/10244669">Collaborative Autonomy Tasking Layer (CATL)</a>, a message format developed by <a href="https://www.sto.nato.int/">NATO’s SCI-343 Research Task Group</a> for sharing task and status information between autonomous systems. CATL has been tested at exercises like <a href="https://www.yourdefensenews.com/repmus-2023-nato-tests-unmanned-maritime-systems-in-portugal/">REPMUS</a> and <a href="https://www.act.nato.int/article/dynamic-messenger-22-an-opex-exercise-designed-for-the-future/">Dynamic Messenger</a>, demonstrating interoperability between platforms from multiple nations.</p>

<p>The stated goals are reasonable:</p>
<ul>
  <li>Common data formats for unmanned systems across domains</li>
  <li>Interoperability between different manufacturers and nations</li>
  <li>Unified situational awareness through data fusion</li>
</ul>

<p>So what’s the problem?</p>

<h2 id="the-transparency-problem">The Transparency Problem</h2>

<p>Try to find the STANAG 4817 specification. Or the CATL message schema. Or documentation on how the standard is being developed.</p>

<p>We did. We’re a defense contractor. We couldn’t find it either.</p>

<p>The <a href="https://fourdrobotics.com/_sys/june-3-6-nato-stanag-4817-custodial-support-team-meeting-lockheed-martin-canada-cdl-systems-calgary/">Custodian Support Team</a> meets periodically — hosted by organizations like Lockheed Martin Canada and NATO Centers of Excellence. Participants include representatives from NATO and Partnership for Peace nations. The work builds on recommendations from NATO Industrial Advisory Group studies (NIAG SG-157 and SG-202).</p>

<p>We know CATL exists because researchers reference it in <a href="https://ieeexplore.ieee.org/document/10244669">published papers</a>. We know exercises like REPMUS test it. We know it defines “four message types for task administration and data synchronization.” But the actual schema? The message definitions? The protocol specification? Not publicly available — and apparently not available through normal defense industry channels either.</p>

<p>Compare this to how other standards are developed:</p>
<ul>
  <li><strong>IETF RFCs</strong>: Public drafts, open mailing lists, anyone can comment</li>
  <li><strong>W3C</strong>: Public working drafts, community feedback periods</li>
  <li><strong>IEEE</strong>: Published specifications, academic participation</li>
  <li>Even <strong>SAE/JAUS</strong>: While the final documents cost money, there are <a href="https://openjaus.com/">open-source implementations</a> and public working groups</li>
</ul>

<p>If the goal is interoperability across nations and vendors, developing the standard behind closed doors is counterproductive. The companies that need to implement it can’t see it. The researchers who could improve it can’t review it. The broader defense industrial base is locked out until… when, exactly?</p>

<h2 id="the-bigger-problem-data-centric-vs-decision-centric">The Bigger Problem: Data-Centric vs. Decision-Centric</h2>

<p>Even setting aside transparency concerns, there’s a more fundamental issue with the approach.</p>

<p>The 4817/CATL model is built on a <strong>data-centric</strong> mental model:</p>
<ul>
  <li>Move data from sensors and platforms to control stations</li>
  <li>Fuse that data into a “comprehensive operational picture”</li>
  <li>Give commanders a “unified view” of the battlespace</li>
</ul>

<p>This made sense when the constraint was information scarcity. Historically, commanders didn’t have enough data. The solution was to collect more and aggregate it centrally.</p>

<p>But that’s not the problem anymore. The problem now is <strong>information overload</strong>. Commanders are drowning in data. Adding more sensors, more platforms, and more data fusion doesn’t help — it makes cognitive load worse.</p>

<p>AI-enhanced decision support requires the opposite approach — <strong>decision-centric</strong> rather than data-centric:</p>

<table>
  <thead>
    <tr>
      <th>Data-Centric (4817 model)</th>
      <th>Decision-Centric (what’s needed)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Move data to where decisions happen</td>
      <td>Move decisions to where data lives</td>
    </tr>
    <tr>
      <td>Comprehensive operational picture</td>
      <td>Filtered, contextual information</td>
    </tr>
    <tr>
      <td>More data = better awareness</td>
      <td>Right data = better decisions</td>
    </tr>
    <tr>
      <td>Centralized fusion</td>
      <td>Distributed processing</td>
    </tr>
    <tr>
      <td>Human processes the picture</td>
      <td>AI reduces cognitive load</td>
    </tr>
  </tbody>
</table>

<p>The goal shouldn’t be showing commanders everything. It should be showing them <strong>only what they need to decide</strong>, with the supporting context, at the moment they need it.</p>

<p>This isn’t just a UI problem. It’s an architectural problem. A standard designed around “unified view” and “data fusion” bakes in assumptions that work against effective AI integration.</p>

<h2 id="what-would-actually-help">What Would Actually Help</h2>

<p>For human-machine-AI teams to operate effectively at scale, we need coordination frameworks that:</p>

<p><strong>Support hierarchical information flow.</strong> Military organizations aggregate information as it flows up and decompose decisions as they flow down. Flat data-sharing models don’t match how operations actually work.</p>

<p><strong>Enable distributed processing.</strong> AI and autonomy should filter, prioritize, and pre-process at the edge — not just add more streams to a central fusion engine.</p>

<p><strong>Reduce cognitive load.</strong> The measure of success isn’t how much data reaches the commander. It’s how little data reaches the commander while still enabling good decisions.</p>

<p><strong>Work in contested networks.</strong> Tactical communications are bandwidth-limited, high-latency, and unreliable. Standards that assume enterprise connectivity will fail in the field.</p>

<p><strong>Are actually open.</strong> If interoperability is the goal, the specifications need to be public. Implementations need to be testable. Participation needs to be accessible beyond the current defense insider club.</p>

<h2 id="where-were-focused">Where We’re Focused</h2>

<p>At <a href="https://revolveteam.com">(r)evolve</a>, we’re working on coordination infrastructure for human-machine-AI teams — building on concepts we first explored under <a href="https://www.diu.mil/">DIU’s Common Operational Database (COD)</a> program.</p>

<p>We think the solution requires a different starting point: decision-centric rather than data-centric, hierarchical rather than flat, designed for contested networks rather than enterprise connectivity. And we think it needs to be developed in the open.</p>

<p>More to share soon. If you’re working on similar challenges — or frustrated by the same gaps — <a href="mailto:kit@revolveteam.com">we’d like to hear from you</a>.</p>

<hr />

<p><em>Kit Plummer is the founder of (r)evolve.</em></p>]]></content><author><name></name></author><summary type="html"><![CDATA[STANAG 4817 aims to coordinate unmanned systems across domains. But its data-centric approach and closed development process work against the interoperability it's trying to achieve.]]></summary></entry><entry><title type="html">Stop Moving Data, Start Moving Decisions</title><link href="https://revolveteam.com/blog/stop-moving-data-blog/" rel="alternate" type="text/html" title="Stop Moving Data, Start Moving Decisions" /><published>2025-12-26T00:00:00+00:00</published><updated>2025-12-26T00:00:00+00:00</updated><id>https://revolveteam.com/blog/stop-moving-data-blog</id><content type="html" xml:base="https://revolveteam.com/blog/stop-moving-data-blog/"><![CDATA[<h1 id="stop-moving-data-start-moving-decisions">Stop Moving Data, Start Moving Decisions</h1>

<p>The IoT revolution made a promise: connect everything, send it all to the cloud, and intelligence will emerge. Sensors on every machine, every vehicle, every soldier. Terabytes flowing to data centers where AI would make sense of it all.</p>

<p>That promise is breaking.</p>

<p>Not because the cloud isn’t powerful—it is. Not because the AI isn’t capable—it’s extraordinary. The promise is breaking because the architecture assumes something that isn’t true: that you can always move data to where the compute lives.</p>

<p>In contested environments, you can’t.</p>

<h2 id="the-bandwidth-tax">The Bandwidth Tax</h2>

<p>Every byte you send costs something. On a fiber connection in a data center, that cost is negligible. On a tactical radio network, it’s ruinous.</p>

<p>Consider a simple scenario: ten autonomous platforms sharing situational awareness. If each platform sends its full sensor state to every other platform, you have 90 data flows (n² - n). Add a few cameras, some LIDAR, maybe radar returns, and you’re pushing gigabits across links measured in kilobits.</p>

<p>The math doesn’t work. It never did. We just pretended it would because Moore’s Law kept bailing us out on compute, and we assumed bandwidth would follow.</p>

<p>It didn’t. Physics doesn’t care about your roadmap.</p>

<p>Tactical networks—the mesh radios, satellite links, and contested spectrum that actual operations depend on—remain stubbornly constrained. And they degrade exactly when you need them most: when someone is actively trying to deny them.</p>

<h2 id="the-latency-problem">The Latency Problem</h2>

<p>Even when bandwidth exists, latency kills.</p>

<p>Round-trip to a cloud data center: 50-200 milliseconds on a good day. Longer through a satellite hop. Much longer through a congested tactical network under electronic attack.</p>

<p>For a drone making obstacle avoidance decisions at 60 mph, 200 milliseconds is 17 feet of travel. For a coordinated maneuver between platforms, it’s an eternity. For a human operator trying to maintain situational awareness, it’s the difference between seeing what’s happening and seeing what happened.</p>

<p>The IoT model assumes latency is a temporary engineering problem. For edge operations, it’s a permanent physical constraint.</p>

<h2 id="inverting-the-model">Inverting the Model</h2>

<p>Here’s the shift: instead of moving data to where decisions happen, move decision-making to where data lives.</p>

<p>This isn’t a fringe position anymore. The team at <a href="https://ditto.live">Ditto</a> has been evangelizing “<a href="https://interface.media/blog/2024/07/02/peer-to-peer-sync-making-the-cloud-optional-again/">cloud optional</a>” architecture for years—building peer-to-peer sync that lets devices share data directly without round-tripping through servers. They’ve proven the model works in retail, healthcare, and defense. The insight is spreading.</p>

<p>But “cloud optional” is just the first step. The deeper move isn’t just about <em>where</em> data lives—it’s about what you’re moving in the first place.</p>

<p>This isn’t a new idea. It’s how biological systems work. Your hand doesn’t send raw nerve signals to your brain and wait for motor commands. The spinal cord handles reflexes locally. The brain gets summaries—”hand touched something hot”—and makes higher-order decisions—”don’t touch the stove again.”</p>

<p>The nervous system is a hierarchical decision architecture. Raw data stays local. Abstractions flow up. Intent flows down.</p>

<p>Apply this to autonomous systems:</p>

<p><strong>Local decisions stay local.</strong> Obstacle avoidance, sensor fusion, immediate responses—these happen on the platform, with the data, in microseconds. No round-trip required.</p>

<p><strong>Relevant abstractions propagate.</strong> Instead of sending video frames, send “vehicle detected at grid reference.” Instead of raw telemetry, send “capability degraded, estimate 30 minutes to repair.” The information that matters for coordination is orders of magnitude smaller than the raw data that produced it.</p>

<p><strong>Intent distributes.</strong> Higher echelons don’t micromanage. They set objectives, constraints, boundaries. “Maintain surveillance of this area.” “Avoid engagement unless threatened.” “Coordinate with adjacent units.” Platforms interpret intent locally, using local data, making local decisions.</p>

<p>This is the control plane / data plane separation that network engineers have understood for decades. The data plane handles packets at line rate, locally. The control plane handles routing decisions, tolerating latency because the decisions are less frequent and more abstract.</p>

<h2 id="what-changes">What Changes</h2>

<p>When you stop moving data and start moving decisions, several things shift:</p>

<p><strong>Bandwidth requirements collapse.</strong> Sharing “I can provide ISR coverage for grid squares A1-A3 for the next 2 hours” costs bytes. Sharing the video feed that informed that assessment costs megabytes per second. The ratio can be 1000:1 or more.</p>

<p><strong>Resilience improves.</strong> When the network degrades—and it will—local operations continue. Platforms have what they need to execute. They’re not waiting for permission or data from somewhere else. When connectivity returns, they sync state and continue.</p>

<p><strong>Latency becomes tolerable.</strong> Coordination decisions can handle hundreds of milliseconds of delay because they’re not time-critical in the same way reflexive actions are. You’ve separated the fast path from the slow path.</p>

<p><strong>Humans stay in the loop.</strong> When the system moves decisions rather than data, humans can actually engage at the decision level. They’re not drowning in sensor feeds they can’t possibly process. They’re seeing actionable information at the right level of abstraction for their role.</p>

<h2 id="the-hard-part">The Hard Part</h2>

<p>This architecture isn’t free. It requires something the IoT model avoided: defining what decisions matter at each level.</p>

<p>When you pump raw data to the cloud, you defer that question. “We’ll figure out what’s important later, with ML, in the cloud.” It’s intellectually lazy but operationally simple.</p>

<p>Moving decisions requires you to think hard about abstraction boundaries. What does a platform need to decide locally? What does a team leader need to know? What does a commander need to see? These aren’t just technical questions—they’re questions about doctrine, authority, and trust.</p>

<p>They’re also the questions that matter. If you can’t answer them, no amount of bandwidth will save you. If you can, you’ve built something that works when the network doesn’t.</p>

<h2 id="the-point">The Point</h2>

<p>The IoT-to-cloud model works beautifully in environments where connectivity is assumed. Smart homes. Fleet management. Industrial monitoring. Anywhere you have reliable, high-bandwidth, low-latency connections to capable infrastructure.</p>

<p>Contested environments aren’t that. Tactical edge isn’t that. Disaster response isn’t that. Space operations aren’t that.</p>

<p>For those domains, the architecture has to change. Stop assuming you can move data to compute. Start moving compute—and decisions—to data.</p>

<p>The cloud is a tool, not a destination. Use it when you can. Don’t depend on it when you can’t.</p>

<hr />

<p><em>Kit Plummer is the founder of (r)evolve, building coordination protocols for human-machine-AI teams. More at <a href="https://revolveteam.com">revolveteam.com</a>.</em></p>]]></content><author><name></name></author><summary type="html"><![CDATA[The IoT-to-cloud model breaks in contested environments. The fix: move decision-making to where data lives, not the other way around.]]></summary></entry><entry><title type="html">Bluetooth’s Best-Kept Secret: Why You’re Ignoring 4x Range for Free</title><link href="https://revolveteam.com/blog/btle-coded-phy-blog/" rel="alternate" type="text/html" title="Bluetooth’s Best-Kept Secret: Why You’re Ignoring 4x Range for Free" /><published>2025-12-22T00:00:00+00:00</published><updated>2025-12-22T00:00:00+00:00</updated><id>https://revolveteam.com/blog/btle-coded-phy-blog</id><content type="html" xml:base="https://revolveteam.com/blog/btle-coded-phy-blog/"><![CDATA[<h1 id="bluetooths-best-kept-secret-why-youre-ignoring-4x-range-for-free">Bluetooth’s Best-Kept Secret: Why You’re Ignoring 4x Range for Free</h1>

<p><em>Most BLE implementations leave half the toolbox untouched. Coded PHY changes everything—and almost nobody’s using it.</em></p>

<hr />

<p>Bluetooth Low Energy has a perception problem. Ask any developer what BLE is good for and they’ll tell you: short-range, low-power, consumer stuff. Fitness trackers. Headphones. Maybe some smart home gadgets.</p>

<p>They’re wrong. Or rather, they’re describing BLE circa 2016.</p>

<p>Since Bluetooth 5.0 shipped in 2017, the spec has included a capability that roughly quadruples transmission range without increasing power consumption. It’s called <strong>Coded PHY</strong>, and based on our conversations with teams building tactical wearables, industrial IoT systems, and edge computing deployments, almost nobody’s using it.</p>

<p>This is a problem worth fixing.</p>

<h2 id="what-coded-phy-actually-does">What Coded PHY Actually Does</h2>

<p>Standard BLE (the LE 1M PHY) transmits at 1 megasymbol per second, where each symbol represents one bit. Simple, fast, but range-limited—typically 30-100 meters depending on environment.</p>

<p>Coded PHY takes a different approach. Instead of just sending your data, it wraps it in forward error correction (FEC) using convolutional encoding. The receiver can then reconstruct the original signal from a much weaker reception, because it has redundant information to work with.</p>

<p>The spec defines two modes:</p>

<ul>
  <li><strong>S=2</strong>: Two symbols per bit, 500 kbps effective throughput, roughly 2x range</li>
  <li><strong>S=8</strong>: Eight symbols per bit, 125 kbps effective throughput, roughly 4x range</li>
</ul>

<p>Nordic Semiconductor field-tested this and hit 1,300 meters in connected state with Coded PHY versus 680 meters with standard 1M PHY—nearly doubling range at the same transmit power. In ideal conditions, you can push past a kilometer.</p>

<p>That’s not a typo. Bluetooth. A kilometer. At milliwatt power levels.</p>

<h2 id="the-physics-are-elegant">The Physics Are Elegant</h2>

<p>Here’s the part that trips people up: Coded PHY doesn’t require more transmission power to achieve longer range. The raw data still goes out at 1 Mbps—the radio hardware is unchanged. What changes is how much <em>information</em> is embedded in that signal.</p>

<p>By spreading each bit across multiple symbols, you’re effectively lowering the data rate in exchange for receiver sensitivity. The math works out to roughly 12 dB improvement in link budget for S=8 mode, which translates to approximately 4x the distance in free space.</p>

<p>The tradeoff is throughput. 125 kbps isn’t going to stream video. But for the vast majority of IoT, tactical, and industrial applications? Position updates, sensor telemetry, status messages, coordination signals? 125 kbps is <em>abundant</em>.</p>

<h2 id="why-isnt-everyone-using-this">Why Isn’t Everyone Using This?</h2>

<p>We’ve been building HIVE Protocol with Coded PHY support baked in from the start, and when we talk to teams in adjacent spaces, we keep hearing the same reasons for not adopting it:</p>

<p><strong>“We didn’t know it existed.”</strong> Fair. The Bluetooth 5.0 marketing focused heavily on 2M PHY (the <em>faster</em> option) and kind of buried the long-range story. Most developers learned BLE from tutorials written for 4.x.</p>

<p><strong>“Our SDK doesn’t expose it.”</strong> This one’s on the toolchain vendors. Many popular BLE stacks abstract away PHY selection entirely, defaulting to 1M mode. You have to dig into platform-specific APIs (BlueZ on Linux, CoreBluetooth on Apple, etc.) to actually configure it.</p>

<p><strong>“We thought long range meant more power.”</strong> Intuition says extending range requires boosting transmission. With Coded PHY, the opposite is true—you’re doing more <em>processing</em> at both ends, not more <em>transmitting</em>.</p>

<p><strong>“125 kbps sounds unusably slow.”</strong> It’s not. A complete position update with metadata fits in under 100 bytes. At 125 kbps, you can send 150+ of those per second. For most coordination and telemetry use cases, that’s overkill.</p>

<h2 id="real-world-implications">Real-World Implications</h2>

<p>The use cases that benefit most from Coded PHY:</p>

<p><strong>Wearables that actually last.</strong> Current sync solutions drain batteries in 3-4 hours because they keep the radio active constantly. We’ve seen this firsthand with tactical wearables—teams report Samsung watches running sync software dying mid-mission. Coded PHY combined with intelligent duty cycling can push that to 18-24 hours.</p>

<p><strong>Indoor operations.</strong> Coded PHY’s error correction doesn’t just extend range in open air—it punches through walls and obstacles more reliably. Building-internal coordination without repeater infrastructure.</p>

<p><strong>Denied spectrum scenarios.</strong> When WiFi and cellular are unavailable or contested, BLE on Coded PHY provides an alternative communication path that’s harder to detect and jam.</p>

<p><strong>Sensor mesh at scale.</strong> Environmental sensors, asset trackers, perimeter monitoring—all scenarios where you want maximum coverage from minimum infrastructure.</p>

<h2 id="the-adaptive-strategy">The Adaptive Strategy</h2>

<p>The real power move isn’t picking one PHY and sticking with it. It’s switching dynamically based on conditions.</p>

<p>Smart implementations should support PHY selection strategies:</p>

<ul>
  <li><strong>MaxRange</strong>: Always use Coded S=8 when you need to guarantee connectivity at distance</li>
  <li><strong>MaxThroughput</strong>: Always use LE 2M when you have strong signal and need speed</li>
  <li><strong>Adaptive</strong>: Switch based on RSSI thresholds with hysteresis to prevent oscillation</li>
</ul>

<p>A device close to its gateway can sync at 2 Mbps. The same device, as it moves away, can gracefully degrade to 1M, then S=2, then S=8, maintaining connectivity across the full range of conditions.</p>

<p>This is table stakes for serious BLE implementations. Yet most SDKs don’t expose it, and most developers don’t know to ask.</p>

<h2 id="getting-started">Getting Started</h2>

<p>If you’re building on BLE and haven’t explored Coded PHY, here’s the minimum you need:</p>

<ol>
  <li>
    <p><strong>Hardware</strong>: Both sides need BLE 5.0+ silicon. Most modern chips (Nordic nRF52840, ESP32-C3/S3, Silicon Labs EFR32, etc.) support it.</p>
  </li>
  <li>
    <p><strong>Software</strong>: You’ll need to explicitly request Coded PHY mode. On Linux with BlueZ, this means using the <code class="language-plaintext highlighter-rouge">bt_conn_le_phy_update()</code> or equivalent. On embedded platforms, check your SDK’s PHY configuration options.</p>
  </li>
  <li>
    <p><strong>Testing</strong>: Actual range depends heavily on environment. Do real field tests—the spec guarantees capability, not miracles.</p>
  </li>
</ol>

<h2 id="and-then-theres-bluetooth-60">And Then There’s Bluetooth 6.0</h2>

<p>Just as the industry is finally waking up to Coded PHY, the Bluetooth SIG dropped version 6.0 in September 2024. Devices are starting to ship now, with broader adoption expected through 2026.</p>

<p>The headline feature is <strong>Channel Sounding</strong>—a ranging capability that achieves centimeter-level distance measurement between devices. Where RSSI-based distance estimation gives you maybe 3-5 meter accuracy (and that’s being generous), Channel Sounding uses phase-based ranging and round-trip timing to get down to 10 centimeters. That’s UWB territory, but with the ubiquity of Bluetooth.</p>

<p>The implications are significant:</p>

<p><strong>Digital keys that actually work.</strong> Your car or building can unlock only when your phone is within a precise radius—not just “somewhere nearby.” This closes relay attack vectors that have plagued current implementations.</p>

<p><strong>Find-my networks with room-level precision.</strong> Instead of “your AirTag is somewhere in this building,” you get “it’s in the third drawer of that desk.”</p>

<p><strong>Spatial computing.</strong> AR applications that need to know exactly where devices are relative to each other finally have a low-power, standards-based way to do it.</p>

<p>Channel Sounding also brings security improvements—built-in protections against man-in-the-middle attacks and relay attacks that current Bluetooth ranging lacks.</p>

<p>Beyond Channel Sounding, 6.0 introduces <strong>Decision-Based Advertising Filtering</strong>, which lets devices be smarter about what advertisements they pay attention to. In crowded RF environments (trade shows, stadiums, dense IoT deployments), this dramatically reduces wasted scanning time and associated battery drain.</p>

<p>The catch? Both devices need 6.0 support to use the new features. Your shiny 6.0-capable phone will still talk to your old 5.0 headphones just fine—but you won’t get Channel Sounding or the new filtering capabilities.</p>

<p>Qualcomm’s Snapdragon 8 Elite already supports 6.0. The iPhone 17 is widely expected to include it. Silicon Labs has certified chips shipping now. The rollout is happening faster than previous major version transitions.</p>

<h2 id="what-this-means-for-system-designers">What This Means for System Designers</h2>

<p>If you’re building systems today, you have a choice:</p>

<p><strong>For range-critical applications</strong>, Coded PHY is available <em>now</em> in every BLE 5.0+ device. It’s been sitting there since 2017, waiting for you to use it. Stop leaving 4x range on the table.</p>

<p><strong>For precision-critical applications</strong>, plan for Bluetooth 6.0. Channel Sounding will enable use cases that previously required UWB or expensive infrastructure. The hardware is arriving; make sure your architecture can take advantage of it.</p>

<p><strong>For both</strong>, understand that these capabilities stack. There’s nothing preventing a future implementation from using Coded PHY for extended range <em>and</em> Channel Sounding for precise ranging within that range.</p>

<h2 id="the-bigger-picture">The Bigger Picture</h2>

<p>Bluetooth’s evolution isn’t just a technical curiosity. It represents a fundamental shift in what’s possible with ultra-low-power wireless.</p>

<p>For years, if you needed range, you reached for WiFi (power hungry), cellular (expensive, requires infrastructure), or LoRa (specialized hardware, limited throughput). Coded PHY put legitimate long-range capability into the same radio that’s already in every phone, tablet, and wearable on the planet.</p>

<p>Now, with 6.0, Bluetooth is adding precision that rivals dedicated ranging technologies—again, in hardware that’s already everywhere.</p>

<p>The industry just hasn’t caught up yet.</p>

<p>At (r)evolve, we’re building coordination systems for environments where connectivity is contested, power is limited, and precision matters. That means we pay attention when Bluetooth quietly adds capabilities that most implementations ignore. Coded PHY today, Channel Sounding tomorrow—these aren’t optional features. They’re the foundation of what comes next.</p>

<p>If you’re building systems that need to coordinate across distance without draining batteries or requiring infrastructure, stop ignoring your radio’s full capability. The hardware is ready. The question is whether your software is.</p>

<hr />

<p><em>Kit Plummer is the founder of (r)evolve, building coordination protocols for human-machine-AI teams at scale. Follow our work at <a href="https://revolveteam.com">revolveteam.com</a>.</em></p>]]></content><author><name></name></author><summary type="html"><![CDATA[Most BLE implementations leave half the toolbox untouched. Coded PHY changes everything—and almost nobody's using it.]]></summary></entry><entry><title type="html">The Cathedral and the Bazaar: Lessons for Autonomous Systems</title><link href="https://revolveteam.com/blog/cathedral-bazaar-autonomy/" rel="alternate" type="text/html" title="The Cathedral and the Bazaar: Lessons for Autonomous Systems" /><published>2025-12-12T00:00:00+00:00</published><updated>2025-12-12T00:00:00+00:00</updated><id>https://revolveteam.com/blog/cathedral-bazaar-autonomy</id><content type="html" xml:base="https://revolveteam.com/blog/cathedral-bazaar-autonomy/"><![CDATA[<p>In 1997, Eric Raymond published “<a href="http://www.catb.org/~esr/writings/cathedral-bazaar/">The Cathedral and the Bazaar</a>“—an essay that would reshape how we think about software development. His central argument: the “bazaar” style of development, with its frequent releases, continuous user feedback, and decentralized community of co-developers, produces superior software compared to the “cathedral” model of tightly controlled, isolated development.</p>

<p>Nearly three decades later, these principles have profound implications for autonomous systems and human-machine teaming. And they reveal an uncomfortable truth: the autonomy industry is stuck in cathedral mode while the rest of the software world has moved on.</p>

<h2 id="the-current-state-cathedrals-everywhere">The Current State: Cathedrals Everywhere</h2>

<p>Look at the drone and robotics landscape today. It’s a collection of proprietary silos—closed hardware, closed software, closed ecosystems. Every vendor builds their own cathedral, and interoperability is largely a fiction we tell ourselves at trade shows.</p>

<p>The standards we do have are artifacts of a different era. <a href="https://nso.nato.int/nso/nsdd/main/standards?search=4586">STANAG 4586</a>, NATO’s standard for UAV interoperability, dates to 2002. It was designed for a world of large, expensive platforms with human operators in ground control stations—not swarms of autonomous agents coordinating in real-time. <a href="https://www.mitre.org/news-insights/publication/cursor-target-message-router-users-guide">Cursor-on-Target</a> (CoT), MITRE’s protocol for sharing tactical information, is similarly long in the tooth. These aren’t foundations for the future; they’re legacy infrastructure we’re forced to route around.</p>

<p>The result? Every integration is a custom engineering effort. Every new platform requires bespoke adapters. “Interoperability” means spending months building point-to-point bridges that break when either side updates. We’ve created a world where combining a drone from Vendor A with sensors from Vendor B and a command system from Vendor C requires a small army of integration engineers and a large budget for middleware.</p>

<p>This is cathedral thinking at its worst: each vendor optimizing for lock-in rather than capability, and the entire ecosystem paying the tax.</p>

<h2 id="the-platform-trap">The Platform Trap</h2>

<p>The cathedral pattern isn’t limited to legacy defense contractors. It’s being replicated across every domain where autonomy is taking hold.</p>

<p><strong>Agriculture:</strong> John Deere has built an impressive autonomous farming stack—and locked it down completely. Farmers who buy Deere equipment can’t access their own data, can’t repair their own machines, can’t integrate third-party implements without Deere’s blessing. The <a href="https://www.deere.com/en/our-company/right-to-repair/">right-to-repair movement</a> exists largely because Deere turned tractors into cathedrals. Your farm, their platform.</p>

<p><strong>Autonomous vehicles:</strong> Every major AV player—Waymo, Cruise, Tesla, Motional—has built a vertically integrated stack. Sensors, perception, planning, control: all proprietary, all closed. There’s no “ONNX for autonomous driving” that lets you swap a better perception model into a competitor’s vehicle. Each company is building its own cathedral, betting they’ll be the one left standing.</p>

<p><strong>Warehouse robotics:</strong> Amazon acquired Kiva Systems in 2012 and promptly pulled it from the market, keeping the technology for themselves. Competitors had to build from scratch. The warehouse autonomy space has since fragmented into dozens of incompatible systems, each vendor hoping to become the platform that locks in the next generation of logistics.</p>

<p><strong>Industrial automation:</strong> Siemens, Rockwell, ABB—the incumbent automation giants—have spent decades building proprietary control systems with proprietary protocols. Integrating across vendors requires expensive middleware and specialized expertise. Sound familiar?</p>

<h3 id="the-defense-variant">The Defense Variant</h3>

<p>In defense, this pattern takes its most acute form. Anduril’s <a href="https://www.anduril.com/lattice/">Lattice</a> represents the explicit strategy: become the operating system for defense autonomy, with every other vendor’s hardware plugging into their mesh.</p>

<p>Give them credit—they recognized the interoperability problem and built technology to address it. But their solution is to <em>become</em> the platform. The pitch is seductive: one unified command-and-control layer, one interface, one vendor to call when things break. For acquisition officers exhausted by integration nightmares, it sounds like salvation.</p>

<p>But the end state is the same lock-in, just at a higher level of abstraction. Instead of being locked into a drone vendor, you’re locked into a <em>platform</em> vendor. The middleware becomes the moat. When one company controls the coordination layer, they control the narrative. They decide which systems integrate smoothly and which face friction. Startups with better sensors, better algorithms, better hardware? They succeed or fail based on Lattice compatibility.</p>

<p>This is the cathedral model dressed in software-company clothing. Move fast, ship product, but maintain control. The interoperability offered is interoperability <em>on their terms</em>, through their APIs, mediated by their platform.</p>

<p>Whether it’s tractors, taxis, warehouses, or weapons systems—the pattern is the same. And so is the outcome: lock-in, stagnation, and ecosystems that serve vendors rather than users.</p>

<h2 id="markets-and-procurement-why-cathedrals-win">Markets and Procurement: Why Cathedrals Win</h2>

<p>These platform traps don’t exist in a vacuum. They’re enabled by how we buy technology—whether through enterprise procurement, venture-backed growth, or government acquisition.</p>

<p><strong>The enterprise buyer</strong> wants “one throat to choke.” Integrated platforms reduce vendor management overhead, simplify support contracts, and provide someone to blame when things go wrong. Best-of-breed architectures require more sophistication to evaluate, purchase, and operate. Cathedrals are easier to buy.</p>

<p><strong>The venture model</strong> rewards platform plays. Investors want moats. They want network effects and switching costs that compound over time. An open, interoperable component is a commodity; a proprietary platform is a defensible business. The incentives push toward lock-in.</p>

<p><strong>Government acquisition</strong> takes these dynamics and amplifies them. The process rewards companies that can absorb compliance overhead, navigate byzantine procurement rules, and sustain years-long sales cycles. When a program office needs to show progress, buying a unified platform from a single vendor is the path of least resistance.</p>

<p>None of this fits neatly into a FAR-compliant contract vehicle. Open standards require coordination across stakeholders. Modular architectures require defining interfaces upfront and holding vendors to them. Bazaar-style development requires accepting that the best solution might come from a company that doesn’t exist yet.</p>

<p>The result is a self-reinforcing cycle: vendors build cathedrals because that’s what gets bought, and buyers keep buying cathedrals because that’s what vendors build. Each iteration entrenches the pattern further.</p>

<p>Breaking the cycle requires changes at every level: procurement language that mandates open interfaces, contract structures that reward interoperability, enterprise architects willing to manage multi-vendor complexity, and investors who recognize that open ecosystems can win too.</p>

<p>The bazaar isn’t just a development philosophy. It’s a procurement philosophy. And until buying catches up with building, we’ll keep erecting cathedrals by default.</p>

<h2 id="two-models-of-development">Two Models of Development</h2>

<table>
  <thead>
    <tr>
      <th>Feature</th>
      <th>Cathedral Model</th>
      <th>Bazaar Model</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>Development</strong></td>
      <td>Centralized, top-down, small exclusive team</td>
      <td>Decentralized, community-driven, widespread collaboration</td>
    </tr>
    <tr>
      <td><strong>Releases</strong></td>
      <td>Infrequent, with long periods between releases</td>
      <td>“Release early, release often”</td>
    </tr>
    <tr>
      <td><strong>Feedback</strong></td>
      <td>Limited to the internal team</td>
      <td>Continuous feedback from a large base of users/developers</td>
    </tr>
    <tr>
      <td><strong>Key Principle</strong></td>
      <td>Meticulous a priori design by experts</td>
      <td>“Given enough eyeballs, all bugs are shallow” (Linus’s Law)</td>
    </tr>
  </tbody>
</table>

<p>Raymond’s “Linus’s Law”—named for Linux creator Linus Torvalds—captures the bazaar’s core insight: with enough contributors examining the code, problems that seem intractable to a small team become obvious to someone in the crowd.</p>

<h2 id="why-this-matters-for-autonomy">Why This Matters for Autonomy</h2>

<p>The bazaar model offers distinct advantages for the complex and safety-critical field of autonomous systems:</p>

<p><strong>Improved Safety and Security.</strong> A larger and more diverse group of contributors can identify and resolve potential safety flaws, biases, and security vulnerabilities much faster than a small, closed team. <a href="https://outshift.cisco.com/blog/agntcy-the-open-source-agentic-framework">Cisco’s release of an open-source security framework</a> for autonomous agent networks exemplifies this approach—inviting the community to stress-test security assumptions rather than hiding them behind closed doors.</p>

<p><strong>Faster Innovation.</strong> The open model allows for rapid prototyping and an evolutionary approach to development. This accelerates the creation of better, more functional AI models and enables the emergence of new standards and protocols through collective experimentation rather than committee design.</p>

<p><strong>Enhanced Reliability.</strong> Continuous testing and error correction by the community lead to more robust systems. When thousands of developers can probe edge cases, the system hardens faster than any internal QA process could achieve.</p>

<p><strong>Standardization and Interoperability.</strong> Open-source foundations create neutral hubs for cross-industry standards. The <a href="https://opensource.org/ai/open-source-ai-definition">Open Source AI Definition</a> from the Open Source Initiative and emerging agent interoperability efforts demonstrate how open collaboration enables different AI agents and systems to integrate seamlessly—critical for heterogeneous human-machine teams.</p>

<h2 id="a-model-worth-following-how-ai-solved-interoperability">A Model Worth Following: How AI Solved Interoperability</h2>

<p>Here’s the contrast that should embarrass the autonomy industry: the AI/ML community faced the same fragmentation problem—and solved it.</p>

<p>In 2017, Facebook and Microsoft launched <a href="https://onnx.ai/">ONNX</a> (Open Neural Network Exchange). The problem was familiar: models trained in PyTorch couldn’t run in TensorFlow. Every framework was a walled garden. Moving a model from research to production meant rewriting it, sometimes from scratch.</p>

<p>ONNX created an open, vendor-neutral interchange format. Train your model anywhere, deploy it anywhere. Today, ONNX is supported by virtually every major ML framework and hardware accelerator. A model built by a researcher using PyTorch can be optimized and deployed on edge hardware from NVIDIA, Intel, Qualcomm, or a dozen others—without modification.</p>

<p>The AI community chose the bazaar. They built an open standard through collaboration rather than committee, iterated rapidly based on real-world usage, and created an ecosystem where competition happens on quality and performance rather than lock-in.</p>

<p>Now imagine if drones and robots worked this way. A perception model trained on one platform, deployable on any. A planning algorithm developed by one team, integratable by all. Control interfaces that speak a common language. Hardware that competes on capability rather than captivity.</p>

<p>This isn’t utopian thinking. It’s what the software world already does. The autonomy industry just hasn’t caught up.</p>

<h2 id="the-ros2-exceptionand-its-limits">The ROS2 Exception—And Its Limits</h2>

<p>To be fair, robotics has one genuine bazaar success story: <a href="https://docs.ros.org/en/rolling/index.html">ROS2</a> (Robot Operating System 2).</p>

<p>ROS2 got a lot right. It’s open-source, community-driven, and has become the de facto standard for robotics development. It provides a common framework for perception, planning, and control. It has a thriving ecosystem of packages. Companies that would never share proprietary code contribute to the commons because the rising tide lifts all boats.</p>

<p>For single-robot autonomy, ROS2 is the bazaar in action.</p>

<p>But ROS2 was designed for a different problem. It excels at making one robot work—coordinating sensors, actuators, and algorithms within a single system or a local cluster. What it doesn’t address:</p>

<p><strong>Collaborative autonomy.</strong> When dozens or hundreds of heterogeneous autonomous systems need to coordinate—sharing intent, negotiating tasks, maintaining coherent situational awareness—ROS2’s architecture doesn’t scale. It assumes a level of network reliability and latency that simply doesn’t exist in contested, distributed operations.</p>

<p><strong>Global distribution.</strong> ROS2’s original communication model (DDS) works well in a lab or a local network. It wasn’t built for systems scattered across continents, operating through intermittent satellite links, mesh networks, and degraded communications. The assumptions baked into DDS break down at scale. (Credit where due: the ROS2 community is actively addressing this. The move toward <a href="https://zenoh.io/">Zenoh</a> as an alternative middleware—designed from the ground up for constrained networks, edge computing, and global distribution—is exactly the kind of bazaar-style course correction that makes open ecosystems work. Recognize the problem, build the solution, iterate.)</p>

<p><strong>Cross-domain teaming.</strong> A future where ground robots, aerial drones, maritime vessels, and space assets collaborate seamlessly requires abstractions ROS2 doesn’t provide. It’s a robotics framework, not a coordination protocol for heterogeneous autonomous systems operating across domains.</p>

<p>ROS2 proved the bazaar model works for robotics. Now we need to apply the same philosophy to the harder problem: collaborative autonomy at global scale, across domains, under real-world constraints.</p>

<h2 id="implications-for-human-machine-teaming">Implications for Human-Machine Teaming</h2>

<p>For human-machine teams, the bazaar approach emphasizes flexible and adaptable systems that can be easily modified and integrated with diverse human workflows and data sources.</p>

<p><strong>Flexible Integration.</strong> Open-source AI models can be modified and optimized for specific operational needs, enabling better performance and superior decision-making within human-machine collaboration systems. Teams can adapt tools to their workflows rather than contorting workflows to fit tools.</p>

<p><strong>Focus on Human Oversight.</strong> Successful AI-human collaboration requires maintaining human oversight at critical decision points. This is significantly easier when the underlying system’s code and logic are transparent and open to inspection. The bazaar model makes “trust but verify” actually possible—you can verify.</p>

<p><strong>Collaborative Design.</strong> The development process can mirror the desired operational outcome: a collaborative environment where both humans and machines (or different teams building them) work together effectively. Building in the open trains organizations for operating in the open.</p>

<h2 id="the-cathedral-still-has-its-place">The Cathedral Still Has Its Place</h2>

<p>This isn’t to say closed development is always wrong. Some components—particularly those involving classified capabilities or zero-day vulnerabilities—may require cathedral-style protection. The art is knowing which parts of your system benefit from broad scrutiny and which require controlled access.</p>

<p>But for the core challenges of autonomous systems—reliability, safety, interoperability, and human-machine integration—the bazaar offers something the cathedral cannot: the collective intelligence of a community that has skin in the game.</p>

<p>Given enough eyeballs, all bugs are shallow. Given enough collaborators, even autonomous systems can be made trustworthy.</p>

<hr />

<p><em>Attribution: This post draws on Eric S. Raymond’s “<a href="http://www.catb.org/~esr/writings/cathedral-bazaar/">The Cathedral and the Bazaar</a>” (1997). Standards referenced include <a href="https://nso.nato.int/nso/nsdd/main/standards?search=4586">STANAG 4586</a> (NATO UAV interoperability) and MITRE’s <a href="https://www.mitre.org/news-insights/publication/cursor-target-message-router-users-guide">Cursor-on-Target</a> protocol. Open-source projects discussed: <a href="https://onnx.ai/">ONNX</a> (AI/ML interchange), <a href="https://docs.ros.org/en/rolling/index.html">ROS2</a> (robotics framework), <a href="https://zenoh.io/">Zenoh</a> (distributed middleware), <a href="https://outshift.cisco.com/blog/agntcy-the-open-source-agentic-framework">Cisco’s Outshift</a> (agentic security), and the <a href="https://opensource.org/ai/open-source-ai-definition">Open Source Initiative</a> (AI definitions). Proprietary platform examples: <a href="https://www.deere.com/en/our-company/right-to-repair/">John Deere</a> (agriculture), <a href="https://www.anduril.com/lattice/">Anduril Lattice</a> (defense).</em></p>]]></content><author><name></name></author><summary type="html"><![CDATA[Eric Raymond's seminal essay on open-source development offers a blueprint for building autonomous systems and human-machine teams—favoring the bazaar's distributed collaboration over the cathedral's closed design.]]></summary></entry><entry><title type="html">Trust as a Distributed System Problem</title><link href="https://revolveteam.com/blog/trust-distributed-system-problem/" rel="alternate" type="text/html" title="Trust as a Distributed System Problem" /><published>2025-12-09T00:00:00+00:00</published><updated>2025-12-09T00:00:00+00:00</updated><id>https://revolveteam.com/blog/trust-distributed-system-problem</id><content type="html" xml:base="https://revolveteam.com/blog/trust-distributed-system-problem/"><![CDATA[<p><strong>We’ve been thinking about trust wrong.</strong></p>

<p>The human-machine teaming conversation usually frames trust as a calibration problem: how do we get humans to trust AI <em>the right amount</em>? Not too much (automation complacency), not too little (underutilization). Find the sweet spot, train to it, problem solved.</p>

<p>This framing misses something fundamental. Trust isn’t a dial you set once. It’s a dynamic property of a system—one that emerges, propagates, degrades, and recovers across every node in the network.</p>

<p>Trust is a distributed system problem.</p>

<h2 id="the-byzantine-generals-of-human-machine-teams">The Byzantine Generals of Human-Machine Teams</h2>

<p>Distributed systems engineers have spent decades solving trust problems. How do you coordinate action when some nodes might fail? When messages might be delayed or lost? When you can’t verify every participant’s state in real-time?</p>

<p>The solutions aren’t about eliminating uncertainty. They’re about <em>operating despite it</em>.</p>

<p>Human-machine-AI teams face the same fundamental challenges:</p>

<ul>
  <li><strong>Partial observability.</strong> No single node—human or machine—has complete information about system state.</li>
  <li><strong>Asynchronous updates.</strong> Trust-relevant information (capability changes, performance history, context shifts) propagates at different speeds to different participants.</li>
  <li><strong>Partition tolerance.</strong> Teams must continue functioning when communication degrades, which means trust decisions must be made locally with incomplete data.</li>
</ul>

<p>The question isn’t “how much should the human trust the AI?” It’s “how does trust flow through this system, and what happens when that flow is interrupted?”</p>

<h2 id="trust-has-a-topology">Trust Has a Topology</h2>

<p>In any human-machine team, trust isn’t uniformly distributed. It has structure:</p>

<p><strong>Hierarchical trust.</strong> A squad leader trusts their autonomous wingmen differently than they trust a remote AI advisor. A field commander trusts aggregated intelligence differently than raw sensor feeds. Authority boundaries create trust boundaries.</p>

<p><strong>Earned trust.</strong> A system that has performed reliably in similar conditions accumulates trust capital. A system operating outside its demonstrated envelope should trigger appropriate skepticism—automatically, not just when a human remembers to be skeptical.</p>

<p><strong>Transitive trust.</strong> If I trust the commander, and the commander trusts the autonomous system’s assessment, how much of that trust transfers to me? Distributed systems have formal models for this. Human-machine teams mostly wing it.</p>

<p><strong>Trust decay.</strong> Trust isn’t static. A system that hasn’t been validated recently, that’s operating in novel conditions, or that’s reported anomalies should see its trust score degrade over time. This isn’t distrust—it’s appropriate uncertainty.</p>

<h2 id="what-this-means-for-architecture">What This Means for Architecture</h2>

<p>If trust is a distributed system property, then your coordination architecture needs to treat it as first-class data:</p>

<p><strong>Trust must be observable.</strong> Every node should be able to query its own trust relationships and be aware of how it’s trusted by others. Opacity breeds miscalibration.</p>

<p><strong>Trust must propagate.</strong> When conditions change—a sensor degrades, an AI model encounters distribution shift, a human operator becomes fatigued—that information needs to flow to nodes whose decisions depend on it.</p>

<p><strong>Trust must be local-first.</strong> You can’t phone home to ask whether you should trust your wingman. Trust decisions happen at the edge, which means the edge needs sufficient context to make them well.</p>

<p><strong>Trust boundaries should match authority boundaries.</strong> The natural structure of human organizations—squads, platoons, companies—represents evolved solutions to trust coordination. Technical architecture should respect these boundaries rather than flattening them.</p>

<h2 id="the-human-in-the-loop-reconsidered">The Human in the Loop, Reconsidered</h2>

<p>“Human in the loop” is often framed as a constraint—a regulatory or ethical requirement that slows down autonomous action. But viewed through the lens of distributed trust, humans serve a different function: they’re <em>trust anchors</em>.</p>

<p>In a system where machine nodes are making increasingly autonomous decisions, human judgment provides:</p>

<ul>
  <li><strong>Ground truth calibration.</strong> Humans can recognize when the world has shifted in ways that invalidate machine assumptions.</li>
  <li><strong>Trust reset authority.</strong> When something goes wrong, humans can intervene to re-establish trust baselines.</li>
  <li><strong>Contextual override.</strong> Humans carry context that may not be encoded in machine state—political considerations, ethical boundaries, commander’s intent.</li>
</ul>

<p>The goal isn’t to keep humans in every loop. It’s to position humans at the right points in the trust topology—where their judgment has maximum leverage and their attention isn’t wasted on decisions machines can reliably make.</p>

<h2 id="building-trust-aware-systems">Building Trust-Aware Systems</h2>

<p>We’re building HIVE with trust as a core architectural concern, not an afterthought:</p>

<ul>
  <li><strong>Capability advertisement</strong> lets nodes declare what they can do and under what conditions—making trust assessable rather than assumed.</li>
  <li><strong>Hierarchical aggregation</strong> ensures trust decisions happen at appropriate levels, with appropriate context.</li>
  <li><strong>Graceful degradation</strong> means that when trust relationships are disrupted (by communication loss, node failure, or detected anomalies), the system continues operating with appropriately reduced confidence rather than failing catastrophically.</li>
</ul>

<p>Trust isn’t a human factors problem bolted onto a technical system. It’s a distributed system property that emerges from architecture choices.</p>

<p>Design accordingly.</p>

<hr />

<p><em>This is the second in a series on the principles behind HIVE Protocol. Previously: <a href="/blog/device-is-the-network">The Device Is The Network</a></em></p>]]></content><author><name></name></author><summary type="html"><![CDATA[We've been thinking about trust wrong. Trust isn't a dial you set once. It's a dynamic property of a system—one that emerges, propagates, degrades, and recovers across every node in the network.]]></summary></entry><entry><title type="html">The Device Is The Network</title><link href="https://revolveteam.com/blog/device-is-the-network/" rel="alternate" type="text/html" title="The Device Is The Network" /><published>2025-12-08T00:00:00+00:00</published><updated>2025-12-08T00:00:00+00:00</updated><id>https://revolveteam.com/blog/device-is-the-network</id><content type="html" xml:base="https://revolveteam.com/blog/device-is-the-network/"><![CDATA[<p><strong>The Internet was supposed to be different.</strong></p>

<p>The original ARPANET designers understood something we’ve collectively forgotten: resilience comes from distribution. Every node was meant to be both consumer and producer, router and endpoint. The network existed <em>between</em> devices, not above them.</p>

<p>Somewhere along the way, we traded that vision for convenience. The cloud promised infinite scale, seamless synchronization, always-on connectivity. What it delivered was dependency—on backbone infrastructure, on hyperscale data centers, on the assumption that the center will always hold.</p>

<p><strong>The center doesn’t always hold.</strong></p>

<p>In contested environments—whether that’s a tactical edge with degraded communications, a disaster zone with failed infrastructure, or simply a subway tunnel—the cloud becomes a single point of failure. Your device, with all its compute power, becomes a dumb terminal waiting for permission from a server it can’t reach.</p>

<p>This isn’t just a military problem. It’s an architectural one.</p>

<h2 id="what-if-the-device-itself-was-the-network">What if the device itself was the network?</h2>

<p>Not as a fallback. Not as a degraded mode. As the <em>primary</em> design assumption.</p>

<p>Every modern device carries more compute power than the systems that ran the early Internet. Your phone could coordinate with its neighbors. Your drone could route traffic for its peers. Your sensor could reason about its own data before deciding what—if anything—needs to flow upstream.</p>

<p>This isn’t about abandoning hierarchy or coordination. It’s about relocating intelligence to where decisions actually happen: at the edge. The network emerges from the collective behavior of intelligent nodes, not from infrastructure imposed upon them.</p>

<h2 id="stop-moving-data-start-moving-decisions">Stop moving data. Start moving decisions.</h2>

<p>When every device is the network, you stop thinking about bandwidth as a pipe for raw data and start thinking about it as a channel for <em>meaning</em>. The question shifts from “how do I get this video to the cloud?” to “what does this video tell us, and who needs to know?”</p>

<p>This is the architecture we’re building with HIVE—not because decentralization is ideologically pure, but because it’s the only approach that works when you can’t guarantee the center.</p>

<p>The Internet’s original promise wasn’t about cloud services. It was about resilience through distribution. It’s time to remember that.</p>

<hr />

<p><em>This is the first in a series on the principles behind HIVE Protocol. Next: <a href="/blog/trust-distributed-system-problem">Trust as a Distributed System Problem</a></em></p>]]></content><author><name></name></author><summary type="html"><![CDATA[The Internet was supposed to be different. The original ARPANET designers understood something we've collectively forgotten: resilience comes from distribution.]]></summary></entry></feed>