PEACEBINFLOW

Posted on Oct 9

The Neural Handshake

#devchallenge #hf26challenge #ai #programming

Ripples, Agents and Organs Emerging from a Continuous Exchange Between an Offline Ledger System and an Online Ecosystem Intelligence, with Barren Land near Maun as Subject

SAGEWORKS AI | PeacebinfLow | Maun, Botswana | October 2026

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Status legend. Every statement in this paper is one of three kinds. BUILT means it exists today. SPECIFIED means it is designed but not yet run. ILLUSTRATIVE means the values are examples that show a format. All transcripts, packet contents, hop counts and table entries in Sections 5 and 6 are ILLUSTRATIVE. They are not findings and they are not field data. Where a detail about either system is unknown to this draft, it reads "to be confirmed by the author" and is listed in the open items note at the end.

Abstract

This paper describes a continuous exchange, which I call a neural handshake, between two systems that think differently. Library Ground (also called Aerie) is an offline, ledger-native system that asks what is actually written and where. EcoSynapse is an online ecosystem platform in which every plant is an agent, and it asks what an organism did, what that caused, and in what order. The subject set between them is barren land around Maun, Botswana. The handshake is not a pipeline and not a tool for fixing land. It is a conversation that stays open for as long as the repository path between the two systems is open. Each turn is a signed packet that carries a parent reference, so the whole exchange can be read back as a causal chain. The paper defines three things that are observed, not designed: ripples, agents and organs. It shows three illustrative rounds, introduces Arian as the place where out-of-scope questions and unplaced patterns are registered, and maps each partner tool to the part of the handshake it expresses. It makes no ecological claim about the land.

Keywords: emergence, multi-agent systems, offline-first, ledger, event log, open-weight models, Botswana, barren land, Hacktoberfest

1. Introduction

A handshake differs from a pipeline because neither side owns the result. In a pipeline, system A produces something and system B consumes it. The work flows one way, and the interesting question is whether the output was correct. In a handshake, each side speaks from its own record and listens from its own record, and the interesting question is what the pair of records starts to say that neither held alone.

I chose this shape because the two systems I build do not think alike. Aerie is audit-first. It is happiest when an answer can be pointed at: this line, this column. EcoSynapse is causal and event-driven. It is happiest when it can say that one packet led to another. Put side by side, the first is a reader of what is written and the second is a reader of what happened. A conversation between those two readers should produce questions that neither would ask alone. That is the claim this paper sets out to make visible. It is a claim about structure, and I do not present it as proven.

Barren land is the subject because it is a hard subject for a ledger and a plant platform to share. Bare, pale, cracked ground near Maun in the dry season has very little in it to record, and yet it is not empty. It has edges, a dry channel, a few seedlings, a date since the last rain. A subject with so little in it forces both systems to be careful about what they claim. The paper is not about repairing such land. It is not a restoration plan, a forecast or a survey. The land is the thing the two systems talk about so that the talking can be observed.

The paper is organised as follows. Section 2 introduces the two parties. Section 3 specifies the handshake. Section 4 sets the subject. Section 5 is the core: three consecutive illustrative rounds and what emerged from each. Section 6 introduces Arian. Section 7 maps the partner tools. Section 8 relates the exchange to a walk on real ground. Sections 9 and 10 cover open innovation and limits. A short DEV submission wrapper and the references follow.

2. The two parties

2.1 Library Ground / Aerie (offline)

Aerie is a ledger-native cognitive system that runs offline from a command prompt. It is described as a Windows 10 native build driven by PowerShell, with a Rust reference workspace alongside it. Its present build status is to be confirmed by the author, and this paper treats the structure below as SPECIFIED.

Its core structure has Subjects, Sources, organs, a subconscious brain, a conscious brain and physics laws. Most organs behave as topics. Several layers are built before any organ exists: an English Codex (nouns, verbs and tense, so that a statement is marked as was, is or will be), a core-mathematics codex, an internal-system-distance codex, a shapes and glyphs codex, a Source of Truth layer that every AI re-grounds against continuously, and a line-column evidence grid. Plain text is the input. Large inputs are divided by topic and split into lines on ingestion.

The most important rule for this paper is the Expansion Ledger. Anything in Aerie may expand, but expansion is written to a separate ledger and the original coherent ledger stays unchanged. That rule is what lets Aerie take part in an open-ended conversation without being rewritten by it.

Four eagles carry distinct roles:

Eagle	Role
Herald	The front end. The only eagle that speaks to the user. When something is unclear it asks by naming the unclear term.
Meridian	Ledger and audit. Answers by pointing to the exact dataset entries behind an answer.
Cairn	Sourcing and filing. Observes inputs and builds a ledger of importance, hierarchies and timelines.
Forge	Deep builder. Introduces new things and is questioned by the other three.

Further organs include Lens, Keeper and Warden. The eagles talk to each other in a separate machine-language protocol, the Aerie protocol, which is distinct from the human-facing language and can improve itself. One feature is deliberately left undefined: when a topic becomes heavy it may spin up its own agent, and the authority and trigger for that are intentionally not fixed. I left them open so that I could observe when and how the system chooses to do it. Section 5 returns to this.

2.2 EcoSynapse (online)

EcoSynapse treats a botanical environment as a network of communicating agents. It is published as my Earth Day 2026 whitepaper [1], and its description here is BUILT as far as that paper states it. Every plant is an agent with an identity, a behavioural state and a communication pathway to adjacent organisms. The state fields are water_intake, light_absorption, stress_index, growth_stage and interaction_log.

All actions are signed protocol packets. The ACP envelope carries packet_id, agent_id, timestamp, action_type, authorization_scope, payload, signature and parent_packet_id, and each packet is written to an immutable log before it executes. Agents never call each other directly. A protocol handler mediates every exchange. The reference ecosystem is the Okavango, and the reference species are Acacia senegal, Combretum imberbe and Terminalia sericea. The system has agent, event, memory, intelligence, orchestration and ownership layers. The intelligence layer interprets events in natural language.

2.3 Two ways of thinking

The contrast between the parties is the engine of the paper, so I state it plainly.

	Aerie	EcoSynapse
Question it asks	What is actually written, and where?	What did this organism do, what did that cause, and in what order?
Unit of record	A line and a column in a ledger	A signed packet in an event log
Relation to time	Tense marked on statements: was, is, will be	Order marked by parent references
Posture	Grounded, questioning, audit-first	Behavioural, causal, event-driven
Runs	Offline, on a laptop	Online

3. The handshake

3.1 Principles

The handshake is a continuous exchange, and each principle below follows from that.

Literal and continuous. The paper shows an ongoing exchange, not one request and one response.
Asymmetric in timing. The offline side pushes whenever it is next online. The online side answers whenever the push arrives. Neither waits on the other.
Causal by construction. Each turn is a signed packet with a parent_packet_id, so the conversation is a chain that can be read back.
Two ledgers, one conversation. Each side keeps its own ledger and speaks from it. The differences between the two ledgers are what make the conversation productive.
Never declared finished. The conversation is open-ended. The paper shows a window onto it, not an ending.

3.2 The channel

The channel is the repository path, and the repository's own vocabulary carries the meaning. One branch holds one conversation thread. One commit is one turn. A pull request is a formal question. A merge is a moment of agreement. All of this is SPECIFIED. Because the channel is a Git history, any turn can be inspected, and the order of turns cannot be quietly changed.

3.3 The packet

The turn format borrows the ACP envelope from EcoSynapse [1]. Figure 1 shows where packets travel, and Code Block 1 shows one packet.

flowchart LR
  subgraph OFF["Offline path: Library Ground / Aerie"]
    HER["Herald"]
    MER["Meridian"]
    CAI["Cairn"]
    FOR["Forge"]
    AL[("Aerie ledger")]
  end
  subgraph ON["Online path: EcoSynapse"]
    PH["Protocol handler"]
    PA["Plant agents"]
    EL[("Event log")]
  end
  subgraph AUTH["Authority path: Arian"]
    ARI["Arian"]
    RES[("Residual ledger")]
  end
  GH{{"Epicentre 1: GitHub repository path"}}
  TD{{"Epicentre 2: Tiger Data record"}}
  AL --> GH
  GH --> PH
  PH --> EL
  EL --> GH
  GH --> AL
  GH --> ARI
  ARI --> RES
  GH --> TD
  ARI --> TD

Figure 1. Architecture of the three paths (offline, online, Arian) and the two epicentres (GitHub as the channel, Tiger Data as the accumulated record). SPECIFIED.

Code Block 1. An ACP-style packet (ILLUSTRATIVE).

{
  "packet_id": "P-001",
  "agent_id": "aerie.herald",
  "timestamp": "2026-10-XXT00:00:00Z",
  "action_type": "subject.set",
  "authorization_scope": "thread/barren-maun-001",
  "payload": {"subject": "barren land, Maun area", "ledger_ref": "L-0012"},
  "signature": "ILLUSTRATIVE-PLACEHOLDER",
  "parent_packet_id": null,
  "status": "ILLUSTRATIVE"
}

3.4 The four ledger tiers

Four tiers of ledger make every sentence in the paper traceable.

System ledger. Aerie's own ledger.
Connected-system ledger. EcoSynapse's event log.
Step ledgers. One short ledger per turn, chained to the one before.
Combined ledger. A merge of the first three, from which any sentence in the paper can be traced to its source line.

Code Block 2 shows one sealed Aerie patch card, the kind of record that sits in the system ledger.

Code Block 2. A sealed Aerie patch card (ILLUSTRATIVE).

{
  "card_id": "PC-001",
  "sealed_by": "meridian",
  "subject": "barren-land-maun",
  "lines": [
    {"line": 12, "cols": "1-58", "tense": "is",
     "text": "bare pale cracked surface, no grass cover"}
  ],
  "expansion_ref": null,
  "ledger": "system",
  "status": "ILLUSTRATIVE"
}

3.5 Three definitions of what emerges

The paper observes three things and designs none of them.

Ripple. A change in one side's ledger that is caused by the other side's packet and that in turn causes a further packet. I count ripples and record how far each travels, measured in hops. A hop is one ledger change on one side caused by a packet from the other.
Agent. A conversation thread that persists across several rounds and acquires its own ledger name, its own subject and its own recurring questions. The observation criterion is stated here and is not a trigger: a thread is counted as an agent when it (a) recurs in at least two consecutive rounds, (b) holds a single subject, (c) has been given a ledger name by one of the systems and not by me, and (d) repeats at least one question form. Nothing creates the agent. The criterion only decides when I write it down.
Organ. A recurring function that agents begin to share and that becomes a topic of its own in the ledger. The observation criterion: a function is counted as an organ when at least two separate threads each call on it and a ledger entry names it as a topic.

4. Subject setup

The subject is set on Library Ground and not on EcoSynapse. Barren land in Botswana, Maun area, is entered into Aerie as a Subject. That is deliberate. Aerie is the side that holds what is written, so it holds the subject. EcoSynapse then brings the botanical and behavioural makeup of Botswana plant life: which species could establish, which are already present, and how they respond to water, light and stress.

The first round is seeded with concrete field-style observations, entered as plain text. In this paper they are ILLUSTRATIVE examples of the format, not a survey:

bare pale cracked surface
no grass cover
a few acacia seedlings at one edge
a dry channel on one side
dry season, last rain long ago

Aerie ingests these as lines, divides them by topic and writes them to its ledger with tense marked. Which species and which behavioural parameters EcoSynapse draws on for Maun specifically is to be confirmed by the author, because the EcoSynapse paper names the Okavango as its reference ecosystem [1].

5. Observed emergence

This is the core of the paper, and everything in it is ILLUSTRATIVE. The three rounds below show the format and the kind of thing the handshake is meant to make visible. Their content was composed to show the structure. No real run produced them. When a real run exists, the same layout will hold the real packets.

5.1 Round 1: seeding

[branch thread/barren-maun-001]  [commit 1: Aerie push]
P-001  aerie.herald -> subject.set
  "Subject: barren land, Maun area. Ledger lines 12-16 sealed.
   Seen: pale cracked surface; no grass; few acacia seedlings at one edge;
   dry channel one side. Tense: is. Last rain: was, long ago."

[commit 2: EcoSynapse reply]  parent: P-001
P-002  eco.handler -> candidates.list
  "Established here: none recorded. Present: acacia seedlings.
   Candidate behaviours to watch: water_intake, stress_index.
   Question: how many seedlings, and at what distance from the channel?"

[commit 3: Aerie reply]  parent: P-002
P-003  aerie.cairn -> filing.update
  "Count not written. Distance not written. Filing 'seedling edge'
   as a sub-topic under the subject."

What emerged. One ripple. Aerie's packet (P-001) changed EcoSynapse's record (a candidate list and a question). That change caused P-002, which changed Aerie's ledger when Cairn filed a new sub-topic. The ripple travelled 2 hops. Nothing counts as an agent or organ yet. Outlet: GitHub. The branch is the thread, and the three commits are the three turns.

5.2 Round 2: cross-questioning

[commit 4: EcoSynapse]  parent: P-003
P-004  eco.handler -> sequence.ask
  "For the seedlings: what happened first, and what followed?
   I need order, not only state."

[commit 5: Aerie]  parent: P-004
P-005  aerie.meridian -> evidence.point
  "Written: line 14 'few acacia seedlings at one edge' (tense: is).
   Not written: any earlier or later entry. I can only say what is
   at line 14. Forge proposes an expansion entry: 'seedling edge'
   thread, to hold counts and dates as they arrive."

[commit 6: EcoSynapse]  parent: P-005
P-006  eco.handler -> thread.name
  "Accepting expansion. Naming the thread 'seedling-edge'.
   Recurring question: what changed since the last entry?"

What emerged. A second ripple. EcoSynapse's question exposed a gap in Aerie's ledger, which led Forge to propose an expansion entry. That entry changed EcoSynapse's record again when it named the thread. The ripple travelled 3 hops. The thread 'seedling-edge' now has its own ledger name, a single subject and one recurring question, and it appeared in Rounds 1 and 2. By the observation criterion it is counted as the first agent. Aerie recorded the proposal in the Expansion Ledger and the original ledger stayed unchanged. Outlets: MongoDB Atlas (the agent entry is written to the registry as a document, with its own shape) and Tiger Data (each packet is stored as a row).

5.3 Round 3: a question neither side can place

[commit 7: Aerie]  parent: P-006
P-007  aerie.herald -> question.open
  "A second thread, 'dry-channel', asks the same kind of thing:
   what is the condition of the surface near the channel edge?
   And how does it differ from the seedling edge?"

[commit 8: EcoSynapse]  parent: P-007
P-008  eco.handler -> scope.decline
  "My records hold plant state, not surface state. I cannot answer.
   Routing to Arian."

[commit 9: Arian]  parent: P-008
P-009  arian -> prompt.build  (state card S-001, routed via Backboard)
  "Unplaced: surface-condition difference, edge vs channel.
   Kept in the residual ledger as U-001. Re-offered on new data."

What emerged. A third ripple, the longest so far. It runs from Aerie's question, through EcoSynapse's decline, to Arian's state card, and back into Aerie's ledger, which gained a topic. It travelled 4 hops. Two threads, 'seedling-edge' and 'dry-channel', each independently needed something that reads surface condition. That function was entered in the ledger as a topic, and by the observation criterion it is counted as the first organ, 'surface-condition reading'. 'dry-channel' has only appeared in one round, so it is a candidate agent and is not yet counted. The pattern that neither side could place is kept as the residual U-001. Outlets: Backboard (the routed prompt), Tiger Data (hybrid search for earlier packets resembling U-001), and MongoDB Atlas (the organ's registry entry).

5.4 Summary of the three rounds

Table 1. Rounds, speech, emergence and outlet (ILLUSTRATIVE).

Round	What Aerie said	What EcoSynapse said	What emerged	Outlet
1	Subject set with five field-style lines, tense marked	Candidate behaviours; asked for count and distance	Ripple, 2 hops	GitHub (branch and commits)
2	Pointed to line 14 only; Forge proposed an expansion entry	Asked for order, not state; named the thread	Ripple, 3 hops; agent 'seedling-edge'	MongoDB Atlas, Tiger Data
3	Opened 'dry-channel' and asked about surface condition	Declined as out of scope; routed to Arian	Ripple, 4 hops; organ 'surface-condition reading'; candidate agent 'dry-channel'; residual U-001	Backboard, Tiger Data, MongoDB Atlas

5.5 Figures

sequenceDiagram
  participant A as Aerie (offline)
  participant R as Repository path
  participant E as EcoSynapse (online)
  participant X as Arian
  A->>R: R1 branch thread/barren-maun-001, commit 1 (P-001)
  R->>E: push received
  E->>R: R1 reply commit 2 (P-002)
  R->>A: pulled on next online
  A->>R: R1 reply commit 3 (P-003)
  E->>R: R2 commit 4 (P-004)
  A->>R: R2 commit 5 (P-005)
  E->>R: R2 commit 6 (P-006)
  A->>R: R3 commit 7 (P-007)
  E->>R: R3 decline, commit 8 (P-008)
  R->>X: out of scope
  X->>R: R3 state card, commit 9 (P-009)

Figure 2. Handshake sequence over three rounds, showing the branch, each commit and each reply commit. ILLUSTRATIVE.

flowchart LR
  L12["Aerie ledger L-0012"] --> P1["P-001"]
  P1 -->|"hop 1"| E1["EcoSynapse record: candidates"]
  E1 --> P2["P-002"]
  P2 -->|"hop 2"| A1["Aerie ledger: seedling edge filed"]
  A1 --> P5["P-005 expansion"]
  P5 -->|"hop 3"| E2["EcoSynapse record: thread named"]
  E2 --> P8["P-008 decline"]
  P8 -->|"hop 4"| AR["Arian state card S-001"]
  AR --> A2["Aerie ledger: new topic"]

Figure 3. Ripple propagation across the two ledgers, with hops marked. The chain is condensed from Rounds 1 to 3. ILLUSTRATIVE.

flowchart LR
  T1["Round 1: first ripple (2 hops)"] --> T2["Round 2: ripple (3 hops), agent 'seedling-edge'"]
  T2 --> T3["Round 3: ripple (4 hops), organ 'surface-condition reading', candidate agent 'dry-channel', residual U-001"]
  T3 --> T4["Open: conversation continues"]

Figure 4. Emergence timeline showing when each agent and organ was first observed. ILLUSTRATIVE.

6. Arian: out-of-scope questions and the residual ledger

Arian is a third path and not a ruler. It holds the authorities. These are what each side may ask, which prompt forms are valid, and what counts as in scope. The full list of those authorities is to be confirmed by the author. In this paper Arian does one job: when a question falls outside both parties, neither guesses. The question is handed to Arian.

Arian builds a consistent prompt in the style of the Ping Engine and routes it through Backboard. The Ping Engine style uses a state card that holds a topic thread, a focus, a running count and a carry-forward line. Code Block 3 shows the state card from Round 3.

Code Block 3. An Arian state card (ILLUSTRATIVE).

{
  "card_id": "S-001",
  "topic_thread": "dry-channel",
  "focus": "surface condition, channel edge vs seedling edge",
  "running_count": 1,
  "carry_forward": "ask again when new lines mention surface or moisture",
  "routed_via": "backboard",
  "status": "ILLUSTRATIVE"
}

Patterns that fit nowhere are not discarded. They are written to a residual ledger, marked 'unplaced', and re-offered when new data arrives. U-001 in Round 3 is the example. Arian is also where agents, ripples and organs are registered once they meet an observation criterion, so it is where the handshake leaves a lasting mark. I keep Arian small on purpose. It is a registry and a router. It does not answer questions about the land and it does not steer the exchange. The two-way conversation between Aerie and EcoSynapse stays the centre of the paper.

7. Outlets: how each partner tool expresses the handshake

The partner tools are the outlets where the exchange is expressed and made visible. They are not the point of the paper. Each tool below is named only with a concrete function. Whether each was used in a real run is to be confirmed by the author, and this section describes the SPECIFIED design.

Tool	What part of the handshake it expresses
GitHub (Actions, Copilot)	The repository path. Branches are threads, commits are turns, and Actions workflows are the micro agents that react to a push. Copilot generated schema and workflow scaffolding (to be confirmed).
Tiger Data (Postgres with pgvector, Tiger MCP)	The accumulated record. Packets, cards, ripples and residuals are rows with embeddings. Hybrid keyword and vector search lets Arian ask which earlier packets resemble an unplaced pattern. Tiger MCP lets an agent create tables for a new subject path.
MongoDB Atlas (Vector Search, long-term memory)	The registry of emergent agents and organs. Their shapes differ, so they are stored as documents. Also long-term memory for an agent across rounds.
Backboard	The single routing point for model calls. Memory and retrieval over the project's own history keep Arian's prompts consistent with my way of communicating. Open-weight models can be compared per role behind one key.
Gemma (open-weight)	The local model at the offline end as Herald's language layer, and the narrator at the online end. The ledger grounds it and the model proposes.
Entire (optional)	Publishes the agent sessions that produced the handshake as part of the process record. Included only for the session placeholder in the wrapper.

I considered TabPFN, Temporal, Sentry Agent Tracing, Render and Mastra and left them out of this version. Each is possible, but I would not name a tool without a concrete function in the build, and none yet has one. If a later version adds them, each should be listed here with its own function.

flowchart LR
  GH["GitHub"] --> CH["Channel: branches, commits, pull requests"]
  GH --> MA["Micro agents: Actions workflows"]
  TD["Tiger Data"] --> RE["Record: packets, cards, ripples, residuals"]
  TD --> HS["Hybrid search for unplaced patterns"]
  MG["MongoDB Atlas"] --> RG["Registry: agents and organs"]
  MG --> LM["Long-term agent memory"]
  BB["Backboard"] --> RT["Routing and project memory for Arian"]
  GM["Gemma"] --> HL["Herald's language layer and online narrator"]
  EN["Entire"] --> PR["Process record: published agent sessions"]

Figure 5. Tool-to-function map connecting each outlet to the part of the handshake it expresses. SPECIFIED.

Code Block 4. A GitHub Actions trigger (YAML, SPECIFIED).

name: ack-turn
on:
  push:
    branches: ['thread/**']
jobs:
  ack:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Parse newest packet
        run: echo "read latest packet, verify parent_packet_id, write reply"

Code Block 5. A pgvector hybrid query (SQL, SPECIFIED).

WITH kw AS (
  SELECT packet_id, ts_rank(tsv, plainto_tsquery('english', :q)) AS k
  FROM packets WHERE tsv @@ plainto_tsquery('english', :q)),
vec AS (
  SELECT packet_id, 1 - (embedding <=> :qvec) AS v
  FROM packets ORDER BY embedding <=> :qvec LIMIT 20)
SELECT p.packet_id, p.subject,
       COALESCE(k,0)*0.4 + COALESCE(v,0)*0.6 AS score  -- weights illustrative
FROM packets p
LEFT JOIN kw USING (packet_id) LEFT JOIN vec USING (packet_id)
WHERE k IS NOT NULL OR v IS NOT NULL
ORDER BY score DESC LIMIT 5;

Code Block 6. An emergent-agent registry document (MongoDB-style JSON, ILLUSTRATIVE).

{
  "_id": "agent:seedling-edge",
  "named_by": "eco.handler",
  "subject": "acacia seedlings at one edge",
  "first_observed": "round-2",
  "criteria_met": ["recurs", "single_subject", "named_by_system", "repeated_question"],
  "recurring_questions": ["what changed since the last entry?"],
  "ledger_refs": ["L-0012", "P-004", "P-006"],
  "organs_used": ["organ:surface-condition-reading"],
  "status": "ILLUSTRATIVE"
}

8. Getting off the screen

The screen is the shortest part of the experience, and the ground is the longest. The exchange in Section 5 is fed by observations, and observations come from standing on real ground, not from a keyboard. The field protocol is SPECIFIED. I walk out to the land, look, and write plain-text lines on the spot: what the surface is, what is at the edges, what is dry, what is green. Those lines are ingested into Aerie when I am next at the laptop. Aerie does not need a connection for that step. It runs offline and keeps the lines on my own machine.

The handshake only starts when the laptop next connects and the offline side pushes. In between, the ground carries on at its own pace and the ledger waits. That asymmetry is not a flaw. It matches the real tempo of the subject. Barren land changes in seasons, and a conversation that waits for the next walk is closer to that tempo than one that is always on.

This is also what the theme asks. The challenge theme, Touch Grass, is about getting away from the screen. In this design, the screen is where two systems exchange packets. The ground is where the subject actually lives. The walk is the part that cannot be automated, and I believe it should stay that way. No real field walk is reported in this paper. The seed observations in Section 4 are illustrative.

9. Why open innovation matters here

Three open pieces make this design possible, and a closed API would remove each of them.

An open-weight model runs offline. Gemma at the offline end means Herald can speak with the network switched off, on a laptop. A closed hosted model cannot do that, because every question would need a connection. The ledger grounds the model, and the model only proposes.
A plain-text ledger keeps field observations on my own machine. Observations about land near Maun stay on a disk I control until I choose to push a turn. They do not sit on a server I do not control. Plain text is also readable without any special software.
An inspectable Git history is the conversation itself. Every turn is a commit. Anyone can read the chain, check a parent reference and follow a ripple hop by hop. A closed pipeline would give me a result, but not a record that others can audit.

Open weights also let me swap models per role. Backboard supports comparing open-weight models behind one key, so the language layer for Herald, for the online narrator and for Arian's routed prompts can each be changed without changing the ledger. The ledger is the stable part, and the model is replaceable.

I do not claim that this is free to run. Gemma has its own licence terms, and the hosted services in Section 7 have their own tiers and limits. Their current cost for this workload is to be confirmed by the author.

10. Limits, status and future work

Status. EcoSynapse exists as a published paper [1]. Aerie's structure is described, and its build status is to be confirmed by the author. The handshake itself, the repository channel, the Tiger Data schema, the Atlas registry and Arian's routing are SPECIFIED and have not yet been run end to end. Every transcript, hop count and registry entry in this paper is ILLUSTRATIVE.

Limits.

The paper shows structure, not results. It has no measurements, latencies, costs, field data or test outcomes, and it should not be read as having any.
The paper makes no ecological claim about the land. It does not say what would grow, what is wrong with the ground or what should be done.
The definition of a hop, and the observation criteria for agents and organs, are my own working definitions. They are set out in Section 3.5 so that they can be challenged.
Aerie's rule for when a heavy topic spins up its own agent is deliberately undefined. That is a design choice. It also means the first real run may show behaviour I did not predict, including none at all.
Arian's list of authorities is incomplete in this draft.

Future work. The first step is a real run: a real walk, real lines entered into Aerie, and real packets exchanged over the branch. After that the illustrative rounds in Section 5 can be replaced with the actual transcript. Further steps are to run the observation criteria across many more rounds, to see how often a candidate agent becomes an agent, to look at whether the residual ledger is re-offered usefully, and to decide whether any of the optional tools (TabPFN, Temporal, Sentry, Render, Mastra) earns a function.

DEV submission wrapper

What I Built

I built a design for a continuous neural handshake between Library Ground (an offline, ledger-native system) and EcoSynapse (an online ecosystem platform), with barren land near Maun as the subject. The paper documents how ripples, agents and organs are observed to emerge from the exchange, and how Arian registers what neither side can place. Sections 3 to 6 give the full structure. The design is SPECIFIED, and the transcripts are ILLUSTRATIVE.

Demo

[PLACEHOLDER: author to add a demo link, screenshot or recording, if one exists.] The illustrative rounds in Section 5 show the format a real demo would follow.

Code

[PLACEHOLDER: author to add repository links for Library Ground / Aerie and EcoSynapse, and for the handshake repository.] Code Blocks 1 to 6 in the paper show the packet, card, workflow, query and registry formats.

How I Built It

The design draws on two existing systems of mine, the published EcoSynapse paper and the Library Ground ledger structure, joined through a repository channel in which branches are threads and commits are turns. GitHub carries the channel, Tiger Data holds the record, MongoDB Atlas holds the registry of agents and organs, Backboard routes Arian's prompts, and Gemma provides the language layer. Section 7 maps each tool to its function. Which tools were used in a real run is to be confirmed by the author.

Why Does Open Innovation Matter?

Open weights let the offline side run on a laptop with no connection, a plain-text ledger keeps field observations on my own machine, and an inspectable Git history makes the conversation itself auditable. A closed API would remove all three. Section 9 sets this out and states what I do not claim about cost.

My Agent Session

[PLACEHOLDER: author to add a link to the published agent session, for example through Entire, or remove this section if none is published.] Section 7 describes the intended function of Entire in this design.

Prize Categories

Best Use of GitHub Copilot, Best Use of Tiger Data, Best Use of MongoDB Atlas, Best Use of Backboard, Best Use of Gemma, and Best Use of Entire. Each is tied to a specific function in Section 7. The author should drop any category for which no real use can be shown.

References

[1] SAGEWORKS AI / PeacebinfLow. EcoSynapse whitepaper (Earth Day 2026). Self-reference. Link to be added by the author.

[2] SAGEWORKS AI / PeacebinfLow. Ping Engine articles. Self-reference. Links to be added by the author.

[3] SAGEWORKS AI / PeacebinfLow. MindsEye articles. Self-reference. Links to be added by the author.

[4] Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 21(7).

[5] Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.

[6] Wooldridge, M. (2009). An Introduction to MultiAgent Systems (2nd ed.). Wiley.

[7] Trewavas, A. (2003). Aspects of Plant Intelligence. Annals of Botany, 92(1).

[8] Simard, S. W., et al. (1997). Net transfer of carbon between ectomycorrhizal tree species in the field. Nature, 388.

[9] Odum, E. P. (1969). The Strategy of Ecosystem Development. Science, 164.

[10] Holland, J. H. (1998). Emergence: From Chaos to Order. Addison-Wesley.

[11] Mitchell, M. (2009). Complexity: A Guided Tour. Oxford University Press.

Suggested in-text placement. [4] supports the use of parent references to order events (Sections 1 and 3). [5] supports the append-only, inspectable record (Section 3.4). [6] supports the multi-agent framing (Section 2). [7] and [8] are background for plants as communicating organisms (Section 2.2). [9] supports ecosystem development as a process over time (Section 4). [10] and [11] support the working notion of emergence (Section 3.5). None of these sources is used to support a claim about the land.

To verify before publishing. Official documentation pages for GitHub Actions, GitHub Copilot, Tiger Data (including Tiger MCP), pgvector, MongoDB Atlas Vector Search, Backboard, Gemma and Entire. I can name each product but cannot confirm exact page titles or URLs, so I have not numbered them. Please add them from the live documentation.

Open items

The author needs to supply or confirm the following before publishing.

Attach or paste the EcoSynapse whitepaper and the Library Ground / Aerie documents, so that Sections 2 to 4 can be checked against their real parameters and names.
Confirm Aerie's current build status (the Windows 10 PowerShell build and the Rust reference workspace).
Confirm which EcoSynapse species and parameters apply to Maun, since the paper's reference ecosystem is the Okavango.
Confirm Arian's full list of authorities and the Ping Engine state card fields.
Confirm which partner tools were actually used in a real run, including whether Copilot generated the scaffolding.
Supply real packets, ledger lines and hop counts from a real run to replace the ILLUSTRATIVE material in Section 5.
Add links for the self-references, the Demo, the Code and My Agent Session placeholders, and the documentation pages under "To verify before publishing".
Confirm the cost and licence position of Gemma and the hosted services, if you want to say anything about cost.

The Neural Handshake, Part 2: Building the Three-Way System, Connecting Agents Across AI Layers, and Showing the Effects of the Handshake

SAGEWORKS AI | PeacebinfLow | Maun, Botswana | October 2026

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Status legend. Every statement is one of three kinds. BUILT means it exists today. SPECIFIED means it is designed but not yet run. ILLUSTRATIVE means the values are examples that show a format. In this part, nothing is marked BUILT except the published EcoSynapse paper [1]. Every round, packet, count and trace in Sections 4 to 6 is ILLUSTRATIVE. None of it is a finding or field data. Where a detail is unknown to this draft it reads "to be confirmed by the author" and is listed in the open items note at the end.

Abstract

Part 1 described a continuous exchange, a neural handshake, between Library Ground (Aerie, offline) and EcoSynapse (online), with Arian as an authority and routing path. Part 2 is about building that three-way system. It stacks the system into seven AI layers, from a walk on real ground up to a read-only window, and runs two spines through every layer: one for durability and one for tracing. It then shows how a single conversation thread can be followed through all seven layers, so that the agents at each layer are visibly connected. The main subject is the effect of the handshake. I define six observable effects, none of which is a claim about the land, and I show them over six illustrative rounds. The central observed effect is cross-adoption: each side begins to use the other's way of asking. I also specify a control design that isolates what the handshake itself does. Each partner tool is given one concrete function, and tools without one are left out.

Keywords: layered agent architecture, multi-agent systems, emergence, durable execution, agent tracing, offline-first, open-weight models, Botswana

1. What Part 2 adds

Part 1 showed that the exchange could be read; Part 2 shows that it can be built and measured. Part 1 defined ripples, agents and organs, and showed three illustrative rounds. It treated the tools as outlets. It did not show how the agents on each side connect across the layers of the system, and it did not say how the effects of the handshake would be judged.

Part 2 does three things.

It specifies seven layers and the agents that live at each one (Section 2).
It specifies how one thread runs through all the layers, so that an agent is not a thing at a single layer but a path through several (Section 3).
It defines six effects of the handshake and shows them over six illustrative rounds, together with a control design that would test them (Sections 4 to 6).

The subject is unchanged: barren land around Maun, Botswana, set on Library Ground. The paper still says nothing about what the land needs, what will grow or what should be done. It is about the exchange.

Part 1 is referred to throughout as Part 1. Figures and code blocks continue its numbering, so the two parts can be pasted together.

2. The seven layers

The system is built bottom-up, from the ground to a window, and each layer has a counterpart on each of the three paths. The three paths are Aerie (offline), EcoSynapse (online) and Arian (authority). Not every path has a member at every layer, and the gaps are part of the design. Figure 6 shows the stack, and Table 2 lists each layer's agents and its tool.

flowchart TB
  subgraph L7["L7 Window"]
    W1["Render: read-only listening window"]
    W2["ElevenLabs: narration for the demo"]
  end
  subgraph L6["L6 Memory and forecast"]
    M1["Tiger Data: packets, cards, residuals"]
    M2["MongoDB Atlas: agent and organ registry"]
    M3["TabPFN: forecasts from the patch table"]
  end
  subgraph L5["L5 Authority and routing"]
    A1["Arian: state cards, residual ledger"]
    A2["Backboard: routed model calls"]
  end
  subgraph L4["L4 Agents"]
    G1["Aerie eagles: Herald, Meridian, Cairn, Forge"]
    G2["EcoSynapse plant agents, orchestrated by Mastra"]
  end
  subgraph L3["L3 Language"]
    N1["Herald language layer: Gemma, local"]
    N2["Online narrator: Gemma"]
  end
  subgraph L2["L2 Ledger"]
    D1["Aerie ledgers"]
    D2["EcoSynapse event log"]
    D3["GitHub: branches and commits"]
  end
  subgraph L1["L1 Ground"]
    F1["Walk and voice notes, ElevenLabs transcription"]
    F2["Optional: Arduino UNO Q surface sensor"]
  end
  F1 --> D1
  F2 --> D1
  D1 --> D3
  D3 --> D2
  D1 --> N1
  D2 --> N2
  N1 --> G1
  N2 --> G2
  G1 --> A1
  G2 --> A1
  A1 --> A2
  A1 --> M1
  A1 --> M2
  M1 --> M3
  M1 --> W1
  M2 --> W1
  W2 --> W1
  subgraph SP["Spines through every layer"]
    T1["Temporal: durable handshake"]
    S1["Sentry: agent tracing"]
  end
  T1 -.-> D3
  T1 -.-> G2
  S1 -.-> G1
  S1 -.-> G2
  S1 -.-> A1

Figure 6. The seven-layer stack, with the two spines. SPECIFIED.

The layering follows an old idea in robotics, in which a system is built as stacked layers that each do something useful on their own and that sit above one another [12]. I borrow the stacking, not the control rules.

Table 2. Layers, agents and tools (SPECIFIED).

Layer	What lives here	Tool
L1 Ground	The walk, spoken field notes, plain-text lines. Optionally one physical sensor.	ElevenLabs (speech-to-text for field notes); Arduino UNO Q only if the author has the board
L2 Ledger	Aerie's ledgers, EcoSynapse's event log, the channel between them	GitHub (branches, commits, pull requests, Actions)
L3 Language	Herald's local language layer; the online narrator	Gemma (open-weight)
L4 Agents	The eagles offline; the plant agents online	Mastra orchestrates the online agents
L5 Authority and routing	Arian, state cards, the residual ledger, routed prompts	Backboard
L6 Memory and forecast	The accumulated record; the registry; forecasts from the patch table	Tiger Data, MongoDB Atlas, TabPFN
L7 Window	A read-only view of the live conversation; narration	Render, ElevenLabs
Spines	Durability and tracing at every layer	Temporal, Sentry Agent Tracing

Two choices in this table are conditional. The sensor at L1 is listed only if the author has an Arduino UNO Q, which is to be confirmed. A sensor would give the organ 'surface-condition reading', first named in Part 1, a physical source of lines. Without one, that organ is fed by spoken notes. Likewise, hosting the online narrator on a DigitalOcean GPU Droplet is possible, but I do not list it because the build has not chosen a host. That is to be confirmed.

3. The three-way system and the thread through the layers

3.1 The three paths, connected

The three paths are connected by one shared packet shape, extended with a layer and a lane. In Part 1 each turn was an ACP-style packet with a parent reference [1]. Part 2 adds two fields. layer says where in the stack the packet was produced. lane says which path produced it: offline, online or arian. Code Block 7 shows the extension.

Code Block 7. A layered packet (ILLUSTRATIVE).

{
  "packet_id": "P-014",
  "agent_id": "aerie.herald",
  "lane": "offline",
  "layer": "L3",
  "action_type": "question.open",
  "authorization_scope": "thread/barren-maun-001",
  "payload": {"thread": "seedling-edge", "term_unclear": "crumbles"},
  "parent_packet_id": "P-013",
  "signature": "ILLUSTRATIVE-PLACEHOLDER",
  "status": "ILLUSTRATIVE"
}

The layer field means the combined ledger can answer a new kind of question: not only which packet caused which, but at which layer each cause acted.

3.2 How the agents connect across layers

Agents on different paths meet at the same layer, and agents at different layers meet through the thread. There are two kinds of link.

Horizontal links join the paths at one layer. At L3, Herald's language layer and the online narrator are both Gemma, one local and one online, and they exchange only through the repository. At L4, the eagles and the plant agents never call each other. EcoSynapse's rule that a protocol handler mediates every exchange [1] applies across the paths too.
Vertical links join the layers on one path. An eagle at L4 takes lines from L2 and speaks through L3. Arian at L5 reads from L4 and writes to L6.

The eagle roles from Part 1 keep their meaning. Herald is the only eagle that speaks to the user, and it asks by naming the unclear term. Meridian points to the exact entries. Cairn files. Forge proposes, and is questioned by the other three.

On the online side, Mastra orchestrates the plant agents. Its concrete function is to take a packet from the handler and decide which plant agents see it, then collect their replies into one packet. It does not replace the protocol handler. The handler still signs and logs, and Mastra only sequences. How the plant agents are grouped for Maun is to be confirmed by the author.

3.3 One thread through seven layers

A thread is not a thing at one layer. It is a path through several, and following it is how the handshake becomes visible. Table 3 follows the 'seedling-edge' thread from Part 1 through the stack. Figure 7 shows the same path.

Table 3. One thread through the layers (ILLUSTRATIVE).

Layer	What the thread looks like there
L1 Ground	A spoken note: "seedlings at the east edge, surface near the channel crumbles"
L2 Ledger	Two new lines in Aerie's ledger, plus a commit on the thread branch
L3 Language	Herald asks what 'crumbles' means, naming the unclear term
L4 Agents	Meridian points to the lines; the plant agents at that edge receive the packet via Mastra
L5 Authority	An Arian state card carries the thread name and a carry-forward line
L6 Memory	A row per packet in Tiger Data; one registry document in MongoDB Atlas
L7 Window	A tile in the listening window showing the thread's latest turns

flowchart LR
  T1["L1 spoken note"] --> T2["L2 ledger lines and commit"]
  T2 --> T3["L3 Herald asks about 'crumbles'"]
  T3 --> T4["L4 Meridian points, plant agents receive"]
  T4 --> T5["L5 Arian state card"]
  T5 --> T6["L6 rows and registry document"]
  T6 --> T7["L7 window tile"]
  T7 -.->|"new walk"| T1

Figure 7. The thread 'seedling-edge' as a path through the seven layers. ILLUSTRATIVE.

The dotted arrow closes the loop. The window shows the conversation, the conversation prompts another walk, and the walk yields new lines. This is the same asymmetry described in Part 1, now with the whole stack under it.

4. The effects of the handshake

An effect is an observable change in the records that would not be there if the two systems had not exchanged packets. None of the six effects below is a claim about the land. All are claims about the records.

Effect	Definition
E1 Cross-adoption	A side begins to use a question or packet form that originated on the other side.
E2 Vocabulary overlap	The share of terms that appear in both ledgers: terms in both divided by terms in either.
E3 Ripple reach	The number of hops each ripple travels (Part 1, Section 3.5).
E4 Emergence count	How many agents, candidate agents and organs have been counted under the Part 1 criteria.
E5 Residual re-offer rate	Of the patterns marked unplaced, the share later placed when new data arrived.
E6 Reconstructability	The share of sentences in the paper that can be traced to a source line through the combined ledger.

Cross-adoption is the effect I most want to see. Aerie asks for line and column. EcoSynapse asks for order. If the handshake does anything beyond swapping data, each should start to carry a trace of the other: Aerie's packets arriving with an order, and EcoSynapse's replies citing a line. Section 5 shows what that looks like. If it does not happen in a real run, that is a result too, and the paper should say so.

5. Six rounds, shown as effects

Rounds 1 to 3 are in Part 1. Rounds 4 to 6 below continue the same thread, and every packet is ILLUSTRATIVE. Round 4 begins when a new spoken note is transcribed into lines.

5.1 Round 4: the residual is re-offered

[L1] spoken note transcribed -> lines 21-22, tense: is
  "seedlings at east edge, count 7; surface near channel crumbles"

[commit 10: Aerie]  P-010  aerie.cairn -> filing.update  (layer L4)
  "Lines 21-22 sealed. Filed under 'seedling-edge' and 'dry-channel'."

[commit 11: Arian]  P-011  arian -> residual.reoffer  (layer L5)
  "U-001 resembles P-010 (hybrid search match on 'surface').
   Re-offering U-001 to both sides."

[commit 12: EcoSynapse]  P-012  eco.handler -> line.cite  (layer L4)
  "Interaction_log entry added for the edge agents. Citing
   lines 21-22 for the entry."

Effect. The ripple travels 3 hops. U-001 is no longer only unplaced: its two contributing lines are now attached to the organ 'surface-condition reading' (E5). And P-012 shows cross-adoption (E1): EcoSynapse cited line numbers, which is Aerie's habit, when nothing in its own format required it. Outlets: ElevenLabs (the note), Tiger Data (the match), GitHub (the commits).

5.2 Round 5: the other habit crosses over

[commit 13: Aerie]  P-013  aerie.meridian -> sequence.offer  (layer L4)
  "Line 22 follows line 14 by one visit. Offering order with
   the state, as EcoSynapse asked in P-004."

[commit 14: EcoSynapse]  P-014  eco.handler -> thread.confirm
  "'dry-channel' now recurs in rounds 3 to 5. Counting it."

[commit 15: Aerie]  P-015  aerie.forge -> topic.propose  (expansion ledger)
  "Proposing 'time-since-rain' as a topic. Source: line 16, tense: was."

Effect. This is the second half of cross-adoption: Aerie, which had only said what is written, now offers an order (E1). 'dry-channel' meets the Part 1 criterion and is counted as the second agent (E4). Forge's proposal is entered in the Expansion Ledger and the original ledger stays unchanged. The ripple travels 4 hops. Outlets: MongoDB Atlas (the registry entry for the second agent), GitHub (the Actions workflow acknowledges each push).

5.3 Round 6: the link drops

[commit 16: Aerie]  P-016  aerie.herald -> question.open
  "Which of the two threads asks about 'time-since-rain' first?"

[link dropped mid-turn]
[workflow resumed]  P-016 re-sent once; parent chain intact
  (retry recorded in the trace; no change to packet content)

[commit 17: EcoSynapse]  P-017  eco.handler -> answer
  "Both threads cite line 16. Neither asked first. Parent: P-016."

Effect. The conversation survives a dropped link, and its causal chain is unbroken, which supports reconstructability (E6). The retry appears in the trace, not in the ledger, so neither ledger gains an extra turn. Outlets: Temporal (the resume), Sentry (the recorded retry).

5.4 Effects over the six rounds

Table 4. Effect values by round (ILLUSTRATIVE). These values were composed to show the format. They are not measurements.

Round	E1 cross-adoption (cumulative)	E2 overlap	E3 reach (hops)	E4 agents / candidates / organs	E5 residuals placed / total	E6 traceable
1	0	low	2	0 / 0 / 0	0 / 0	all lines
2	0	low	3	1 / 0 / 0	0 / 0	all lines
3	0	low	4	1 / 1 / 1	0 / 1	all lines
4	1	rising	3	1 / 1 / 1	1 / 1	all lines
5	2	rising	4	2 / 0 / 1	1 / 1	all lines
6	2	rising	2	2 / 0 / 1	1 / 1	all lines

I have deliberately left E2 as words and not numbers. A real run should compute it from the two ledgers, and I will not make up a figure.

5.5 What the handshake did, in one picture

flowchart LR
  AH["Aerie habit: cite line and column"] -->|"Round 4 (P-012)"| EC["EcoSynapse starts citing lines"]
  EH["EcoSynapse habit: ask for order"] -->|"Round 5 (P-013)"| AO["Aerie starts offering order"]
  EC --> SH["Shared practice: state, order and source line together"]
  AO --> SH

Figure 8. Cross-adoption: each side picks up the other's habit. ILLUSTRATIVE.

6. Testing the effects: a control design

To say the handshake caused an effect, the effect has to be compared with a run in which the handshake did not happen. This design is SPECIFIED and has not been run.

Run H (handshake). Both ledgers exchange packets as in Section 5.
Run I (isolated). Both systems ingest the same field lines and the same number of rounds, but never read each other's packets.

At the same round count, I compare E1, E2 and E4. If Run H shows cross-adoption and rising overlap, and Run I does not, the handshake is a candidate cause. If the two runs look alike, then the effects in Section 5 are not due to the handshake. With few rounds and one site, this would be a single case, not a result that generalises. The design is meant to stop me from reading the effects into the data, not to prove them.

7. The spines and the window

7.1 Temporal: the handshake survives

Temporal gives the handshake the durability it needs because the offline side is often offline. Round 6 is the case in point. A turn that is interrupted should resume and not duplicate. The workflow wraps one turn: send the packet, wait for the reply commit, record it. Code Block 8 is a sketch.

Code Block 8. A durable turn (Python sketch, SPECIFIED).

from datetime import timedelta
from temporalio import workflow

@workflow.defn
class HandshakeTurn:
    @workflow.run
    async def run(self, packet: dict) -> dict:
        await workflow.execute_activity(
            "push_packet", packet,
            start_to_close_timeout=timedelta(minutes=5))
        reply = await workflow.execute_activity(
            "await_reply_commit", packet["packet_id"],
            start_to_close_timeout=timedelta(hours=12))
        await workflow.execute_activity(
            "record_turn", reply,
            start_to_close_timeout=timedelta(minutes=5))
        return reply

The timeouts are placeholders. Whether the offline machine can run a Temporal worker, or whether the durable part lives on the online side only, is to be confirmed by the author.

7.2 Sentry: the work of each agent is shown

Sentry Agent Tracing shows what each micro agent did, so that an effect can be traced to the span that produced it. Each packet becomes a span, tagged with its lane and layer. A retry shows up as a repeated span. The excerpt below is ILLUSTRATIVE, and its measurements are left blank on purpose, since I will not invent latencies, token counts or costs.

trace: thread/barren-maun-001
  span L4 aerie.herald question.open     P-016   duration: <to be measured>
  span L2 push_packet (attempt 1)                status: failed
  span L2 push_packet (attempt 2)                status: ok
  span L4 eco.handler  answer            P-017   tokens: <to be measured>

7.3 TabPFN: forecasting from the patch table

TabPFN has a function only once the patch table has enough rows, and in this paper it is specified but not exercised. The patch table has one row per ripple, with columns such as hops, thread age, layers crossed and whether a residual was involved. A tabular foundation model could be asked to flag which new ripples are likely to travel far. Six rounds are far too few to forecast anything. Code Block 9 shows the intended call and nothing more.

Code Block 9. A forecast call on the patch table (SPECIFIED, to verify against the TabPFN documentation).

from tabpfn import TabPFNClassifier

# X: hops, thread_age, layers_crossed, residual_involved
# y: 1 if the ripple later reached four or more hops
clf = TabPFNClassifier()
clf.fit(X_train, y_train)
risk = clf.predict_proba(X_new)[:, 1]

I make no claim about what such a forecast would say. Its use here would be as a check on whether ripple reach is predictable at all, which is a question about the exchange and not about the land.

7.4 Render and ElevenLabs: the window and the voice

Render hosts a read-only listening window, and ElevenLabs gives the exchange a voice at both ends. The window shows each thread's latest turns and lets a visitor watch the conversation without being able to change it. It reads from the record at L6 and writes nothing. Code Block 10 is a minimal service definition.

Code Block 10. A listening-window service (YAML sketch, SPECIFIED).

services:
  - type: web
    name: handshake-window
    runtime: python
    buildCommand: pip install -r requirements.txt
    startCommand: python serve_window.py
    envVars:
      - key: READ_ONLY
        value: "true"

ElevenLabs has two functions. At L1 it transcribes spoken field notes into plain-text lines, which suits a walk on real ground where typing is awkward. At L7 it can narrate the demo. I would use it for narration only if the demo includes one. Both uses are to be confirmed by the author.

7.5 What each effect needs

Each of the six effects is read from a specific tool, so that no effect rests on a tool that is not in the build. E1 and E2 are read from the ledgers at L2. E3 comes from the packet chain in Tiger Data. E4 comes from the MongoDB registry. E5 comes from Arian's residual ledger and the hybrid search. E6 comes from the combined ledger. Sentry and Temporal are what make the six rounds trustworthy as a record: Sentry shows what happened, and Temporal means an interrupted turn does not corrupt the chain.

Code Block 11 shows the per-round effects snapshot that would be stored at L6.

Code Block 11. An effects snapshot per round (JSON, ILLUSTRATIVE).

{
  "round": 5,
  "thread_branch": "thread/barren-maun-001",
  "e1_cross_adoption": 2,
  "e2_overlap": "computed from both ledgers",
  "e3_ripple_hops": [4],
  "e4": {"agents": 2, "candidates": 0, "organs": 1},
  "e5_residuals": {"placed": 1, "total": 1},
  "e6_traceable": "computed from combined ledger",
  "status": "ILLUSTRATIVE"
}

8. Tools, layers and prize categories

Each tool below earns one concrete function. Tools that do not are left out.

Tool	Layer	Function in Part 2
GitHub (Actions, Copilot)	L2	The channel; Actions as micro agents that react to a push; Copilot for scaffolding (to be confirmed)
Gemma	L3	Herald's local language layer; the online narrator
Mastra	L4	Orders the online plant agents' replies into one packet
Backboard	L5	Routes Arian's prompts; memory over the project's history; model comparison per role
Tiger Data	L6	Packets and residuals as rows with embeddings; hybrid search
MongoDB Atlas	L6	Registry of agents and organs; long-term agent memory
TabPFN	L6	Forecast from the patch table (specified, not exercised)
Render	L7	Read-only listening window
ElevenLabs	L1, L7	Transcribes field notes; narrates the demo
Temporal	Spine	Makes each turn durable
Sentry Agent Tracing	Spine	Traces each micro agent
Entire	Process	Publishes the agent sessions

flowchart LR
  GH["GitHub"] --> C2["L2: channel and micro agents"]
  GM["Gemma"] --> C3["L3: language"]
  MA["Mastra"] --> C4["L4: ordering plant agents"]
  BB["Backboard"] --> C5["L5: routing and memory"]
  TD["Tiger Data"] --> C6["L6: record and search"]
  MG["MongoDB Atlas"] --> C6b["L6: registry"]
  TP["TabPFN"] --> C6c["L6: forecast"]
  RN["Render"] --> C7["L7: window"]
  EL["ElevenLabs"] --> C1["L1: field notes and L7 voice"]
  TM["Temporal"] --> SP1["Spine: durability"]
  SE["Sentry"] --> SP2["Spine: tracing"]

Figure 9. Tool-to-layer map. SPECIFIED.

Left out, and why.

Tinker. It needs a fine-tuned model that beats a baseline on performance, latency or cost. I have no baseline and no such measurement, so naming it would be empty.
SerpApi. Live web search would let Arian pull outside claims about land into the ledger. That would invite ecological statements this paper deliberately avoids.
DigitalOcean and Arduino UNO Q. Both are possible and both are conditional on the author's choices, as noted in Section 2.

A note on prize categories. Twelve tools are listed, but a category should be claimed only where the write-up can show a real use, such as a trace, a screenshot, a repository link or a published session. A category claimed on design alone is a weak claim. The author should keep only those for which evidence exists by the submission date.

9. Limits, status and future work

Status. EcoSynapse is a published paper [1]. Nothing in Part 2 has been run. The layers, the packet extension, the effects and the control design are SPECIFIED, and every round, count and trace is ILLUSTRATIVE.

Limits.

The effects are defined by me and are about the records, not the land.
Cross-adoption may not occur in a real run. If it does not, that should be reported.
A single site and a handful of rounds cannot show that an effect generalises.
E2 and E6 have no numbers here, because they must be computed from real ledgers.
The control design needs a second, isolated run, which has not been done.
Whether the offline side can run durable workflows locally is open.

Future work. The first step is one real run: a real walk, real spoken lines, real packets, and real traces. After that, Run I can be added so that the effects have something to be compared with. Only then does it make sense to feed the patch table to TabPFN.

DEV submission wrapper: Part 2 additions

What I Built

Part 2 specifies a seven-layer, three-way agent system joining Library Ground, EcoSynapse and Arian, with a durable and traced handshake running through it. It defines six observable effects of the handshake and a control design to test them. Sections 2 to 6 give the detail. All of it is SPECIFIED, and the rounds are ILLUSTRATIVE.

Demo

[PLACEHOLDER: author to add a link to the listening window or a recorded run, if one exists.]

Code

[PLACEHOLDER: author to add repository links.] Code Blocks 7 to 11 show the formats.

How I Built It

I stacked the system into layers from the ground up and gave each layer one tool with one function (Table 2 and Section 8). GitHub carries the channel, Mastra orders the online agents, Backboard routes Arian's prompts, Tiger Data and MongoDB Atlas hold the record and registry, Temporal and Sentry run through every layer, and Render hosts a read-only window. Which of these were used in a real run is to be confirmed by the author.

Why Does Open Innovation Matter?

Open weights, a plain-text ledger and a Git history that anyone can read are what let the offline side run on a laptop and let the effects be traced hop by hop. Part 1, Section 9 sets this out.

My Agent Session

[PLACEHOLDER: author to add a link to the published agent session, or remove this section.]

Prize Categories

Candidates: GitHub Copilot, Tiger Data, MongoDB Atlas, Backboard, Gemma, Entire, Mastra, Temporal, Sentry Agent Tracing, Render, TabPFN and ElevenLabs. The author should keep only those with evidence in the submission.

References

Numbering continues from Part 1, where [1] to [11] are listed.

[1] SAGEWORKS AI / PeacebinfLow. EcoSynapse whitepaper (Earth Day 2026). Self-reference. Link to be added by the author.

[12] Brooks, R. A. (1986). A Robust Layered Control System for a Mobile Robot. IEEE Journal of Robotics and Automation, RA-2(1).

To verify before publishing. Official documentation for Temporal, Sentry Agent Tracing, Mastra, Render, TabPFN (Prior Labs) and ElevenLabs. I can name each product but cannot confirm exact page titles or URLs, and the code sketches above should be checked against the current documentation before they are published as working code.

Open items

The author needs to supply or confirm the following before publishing.

Attach the EcoSynapse paper and the Library Ground / Aerie documents so the layer descriptions can be checked against real names and parameters.
Whether you have an Arduino UNO Q, and whether to host the online narrator on DigitalOcean.
Whether the offline machine can run a Temporal worker, or whether durability sits on the online side only.
How plant agents are grouped for Maun, and what Mastra's grouping rule is.
Which tools were used in a real run, and which categories you can show evidence for.
Real packets, lines, traces and effect values from a real run to replace the ILLUSTRATIVE material.
Whether a Run I (isolated) is possible before the deadline.
Links for the self-references, Demo, Code and My Agent Session, and the documentation pages listed under "To verify before publishing".