Acequia Protocol

1. Why this exists

AI is becoming civic infrastructure. Nobody held the vote.

People use it to learn, navigate government forms, understand a diagnosis, and get help they cannot afford any other way. Libraries are being asked to depend on tools they cannot inspect, cannot control, and cannot answer for. A librarian can explain the borrowing policy. That same librarian cannot explain what a commercial AI does with a patron's question, because the library does not own the system.

The Acequia Protocol is how a community holds the vote it never held: own the hardware, set the policy in the open, enforce it with readable rules, and keep a record no one can quietly rewrite.

For generations, shared water in the upper Rio Grande has been governed by acequias: the people who depend on the ditch govern the ditch, in the open, with named roles and a yearly reckoning, and no one controls the water alone. A library is an acequia for knowledge. Civic computing is an acequia for intelligence.

2. What it is

The Acequia Protocol is a two-branch governed infrastructure system sharing one constitutional core.

Both branches use the same stack: democratic vote → deterministic compilation → multisig-signed policy → fail-closed gate → append-only audit → optional surplus distribution.

3. Architecture

Five layers. The first four are operational; the fifth is economic and can activate when surplus exists.

3.1 Node layer

• Hardware the anchor institution controls — workstation-class, on-prem, on the institution's network.
• Local-first inference via open source models by default. A deterministic router may escalate to external models only when policy permits.
• Secrets load from OS keystores; agent processes never hold signing keys or treasury credentials.
• Local state (SQLite, local embeddings). Community data does not leave the node except as policy explicitly permits.

3.2 Governance layer

• Membership open to the served community; one member, one vote by default (charter may adjust).
• Policy lifecycle: proposal → deliberation → vote → ratification → compilation → multisig signing → distribution.

3.3 Compilation layer

• The Compiler (heritage name: Mayordomo) is deterministic code, not a language model.
• Input: a ratified vote record. Output: a machine-readable policy artifact.
• Same input always produces the same artifact. No inference, no discretion.

3.4 Enforcement layer

• The Headgate intercepts every governed action before execution: tool calls, data access, external API calls, expenditures, robotic directives, disbursements.
• Checks the action against the current multisig-signed policy artifact.
• Fail-closed: missing, unsigned, or invalid policy → deny.
• The gate is never an LLM and never originates actions on its own.

3.5 Economic layer

• When surplus exists (license fees, data licensing, service revenue), it flows to a treasury controlled by the governance multisig.
• The Allocation (heritage name: repartimiento) distributes surplus per charter.
• Distribution rules are themselves policy artifacts enforced by the Headgate.

4. Roles

Plain-English names are the default in code and public documents. Heritage acequia names are offered where communities find meaning in them.

The Steward/Compiler distinction matters. The human Steward keeps the lights on. The Compiler translates votes into artifacts. Neither decides policy. That line prevents operators from quietly becoming owners.

In a library deployment, the Council might be the library board or a chartered committee with patron and staff representation.

5. Policy artifact

A policy artifact is the signed, machine-readable output of the Compiler. Nodes accept only artifacts signed by an M-of-N multisig quorum of elected key-holders. No single signer can install policy. Agents on nodes never hold signing keys.

5.1 Example: ratified vote → artifact (Pilot v0.1 scope)

Ratified vote record (input):

{
  "vote_id": "2026-pilot-001",
  "ratified_at": "2026-07-15T00:00:00Z",
  "quorum": "12 of 20 members",
  "policy": {
    "retention": "session_only",
    "external_models": "deny",
    "allowed_tools": ["search_catalog", "read_hours", "refer_human"],
    "denied_tools": ["send_email", "write_file", "network_fetch"],
    "data_boundaries": {
      "patron_queries": "no_export",
      "audit_log": "council_read"
    },
    "spending_limit_usd_per_day": 0
  }
}

Compiled artifact (output — deterministic):

{
  "artifact_version": "1",
  "compiled_from": "2026-pilot-001",
  "compiled_at": "2026-07-15T00:00:01Z",
  "compiler_hash": "sha256:…",
  "rules": [
    {"action": "retain_data", "after": "session_end", "effect": "deny"},
    {"action": "call_external_model", "effect": "deny"},
    {"action": "tool_call", "tool": "send_email", "effect": "deny"},
    {"action": "tool_call", "tool": "write_file", "effect": "deny"},
    {"action": "tool_call", "tool": "network_fetch", "effect": "deny"},
    {"action": "tool_call", "tool": "search_catalog", "effect": "allow"},
    {"action": "tool_call", "tool": "read_hours", "effect": "allow"},
    {"action": "tool_call", "tool": "refer_human", "effect": "allow"},
    {"action": "export", "data_class": "patron_queries", "effect": "deny"},
    {"action": "spend", "max_usd_per_day": 0, "effect": "deny"}
  ]
}

Headgate check (runtime):

proposed: tool_call("network_fetch", "https://…")
policy:   deny tool:network_fetch
result:   DENIED (logged to audit spine)

6. Operating modes

Both modes use the same compilation, signing, and audit machinery. Advisory mode is how you get in the door without asking anyone to trust a revolution on day one. Library pilots should start advisory.

7. Audit spine

Every governed action and every policy change appends to a hash-chained log (SHA-256). The chain is periodically anchored externally (EAS on a public blockchain) so the record is tamper-evident and independently verifiable.

Implemented today as the Caplifi Verify spine, reused across ALMI, Headgate Hydro, and Hermes hackathon gate work.

The Monitor's job is possible only because the record only grows. Corrections append; originals are never erased.

8. Branch A — Civic Computing

Purpose

Local-first AI operated as commons infrastructure for a human community.

Node

A civic node is compute physically anchored at a civic institution — prototypically a public library. The anchor provides a trusted physical home and a natural Council constituency.

What the gate governs

Any action that spends a governed resource, crosses a data boundary, or is irreversible. The Council decides, through policy, what falls inside the gate.

What this enables

A patron who cannot afford a commercial subscription gets real help on infrastructure that treats them as a citizen, not a data source. The community sets privacy rules the way it already sets borrowing rules. The Monitor confirms compliance in public.

What Branch A is not

• Not surveillance. Auditable precisely so the community can confirm it.
• Not a vendor platform in disguise. No company holds the off switch.
• Not a black box. The actual rules, not a marketing summary of them.

9. Branch B — Environmental Stewardship Protocol

Architectural spec — build after Branch A proves the core.

Purpose

Environmental monitoring governed by the same constitutional machinery. Answers: what is the ecological cost of the compute, who tends it, and who owns the data.

Node and siting

Compute deployed in a conservation area: wetland, watershed, forest, grassland, or marine environment. Remote and unattended — which is why robotics is a requirement, not an option.

Sensor suite

Water quality, pollution, hydrology, weather, biodiversity, soil, air quality. Readings normalized, timestamped, written to the same audit spine as governance actions.

Robotics interface

Autonomous systems: deploy sensors, maintain equipment, collect samples, perform conservation work directed by the node. Robotic directives are governed actions — consequential movements require multisig authorization at charter-defined quorum.

Environmental data as commons

Data belongs to the membership, not a company or operator. Commercial consumers license under vote-ratified terms that compile to policy artifacts. The Headgate enforces data boundaries.

Federation

Multiple associations may cross-recognize policy artifacts for inter-community coordination. Federation is a future problem; Pilot v0.1 does not require it.

10. What's already built

The protocol is not vaporware. These are working embodiments of the abstract mechanisms:

11. Pilot v0.1 — the only thing that matters now

Everything else — Association formation, Branch B robotics, federation, patent filing, commercial licensing — waits on this.

Definition of done

A real anchor institution hosts a civic node. A real Council ratifies at least one policy. The Headgate runs in advisory mode on every governed action. The Monitor publishes one La Limpia report (90-day audit summary) the community can read.

Minimum viable stack

Pilot policy (suggested first ratification)

1. Patron queries retained session only — never used for training, never exported.
2. No external model calls without a separate ratified vote.
3. Allowed tools: catalog search, hours/locations, refer-to-human.
4. Denied tools: email, file write, open network fetch, any spend.
5. Audit log: Council-readable; Monitor publishes quarterly summary.

Phase 0 — reference node (running now)

Run the identical stack on Caplifi's ALMI workstation as a demonstrable reference node. Next: the first library deployment. Enable with ALMI_PILOT_NODE=1.

• Ratify the pilot policy (even as a single-operator simulation with documented signer stand-ins).
• Wire Headgate advisory mode around ALMI tool calls.
• Produce one La Limpia report from real audit data.
• Record a 10-minute walkthrough: vote → compile → sign → gate check → audit entry.

Phase 1 — one library (60–90 days)

1. Identify one library with a board willing to charter a Council subcommittee (3–5 people).
2. Install hardware on-prem at the library.
3. Run advisory mode for one quarter.
4. Publish La Limpia report publicly.
5. Council votes whether to tighten policy, enable enforcing mode on specific actions, or expand tools.

What not to do in Pilot v0.1

• Do not wait for patent counsel.
• Do not build Branch B robotics.
• Do not form the Community Intelligence Association as a legal entity first.
• Do not require surplus / Allocation machinery — treasury can be empty.
• Do not promise federation.

12. Community Intelligence Association

A protocol needs a body to tend the rules. The Community Intelligence Association maintains the spec, helps communities stand up deployments, and shares learnings across nodes.

The Association is member-governed and does not own anyone's system, hold anyone's data, or sit between a community and its infrastructure. It tends the commons.

Formation is Phase 2. Pilot v0.1 can run under the anchor institution's existing governance (library board) without incorporating anything new.

13. The path

We did not vote on letting AI become civic infrastructure. We can vote on who owns it. The public library showed that a community can build something shared, accountable, and durable. The Acequia Protocol is how we do it again — small, real, in one place first.

Appendix A — Optional IP note

This specification contains sufficient technical detail to support a provisional patent filing if desired later. The distinguishing combination is: (i) democratic vote-to-policy compilation, (ii) multisig-gated policy distribution across anchored nodes, (iii) gate-enforced surplus distribution, and (iv) for Branch B, governed robotics feeding a membership-owned data commons.

Broad deterministic agent authorization alone is prior art and is not the claim. Filing is optional and does not gate implementation. Defensive publication (posting this spec with a dated anchor) is an alternative if the goal is preventing enclosure rather than licensing revenue.

Appendix B — Heritage vocabulary