# FEDERATION — Cross-Node Protocol > What happens when the Antiquity Guild has more than one Node. Drafted under § Federated Structure of the Guild + § Node Recognition & Attestation (Living Book). This document operationalizes the doctrinal frame so that when Node #2 forms, the protocol already exists and no one is improvising under pressure. (Per § Governance & Stewardship, there is no successor Guildmaster; continuity rests with the horizontal structure of Guardians and Representatives.) **Status:** Drafted 2026-05-16. Inert until Node #2 begins formation. The Renton Origin Node is the only active Node at this time. --- ## I. What a Node is Per Living Book § Definitions: *"A Guild Node — A decentralized local unit of the Guild's mission, formed wherever compassion meets actionable stewardship."* A Node is a place-rooted (or context-rooted) instance of the Guild that: - Has at least one Representative in good standing - Operates within a defined area (geographic, sometimes thematic) - Adheres to the Living Book as sole authority - Coordinates with other Nodes via this protocol when their work intersects - Maintains its own local context (Floor Registry, Culture Circles, local Agreements) while contributing to the shared Treasury and shared canon A Node is **NOT** a chapter, franchise, or affiliate. It is a peer. --- ## II. Recognition pathways Per Living Book § Node Recognition & Attestation, Nodes can form via two pathways: ### Top-down (formation phase only) - The Founding Guildmaster declares a new Node with a written attestation - Used during the early seed phase when there are no Guardians yet to attest - The Renton Origin Node was formed this way (2026-03-14) ### Bottom-up (steady state, default) - A group of ≥3 Reps + ≥3 Guardians (or interim equivalent until Guardian ranks fill) declare a Node forming - Each attests in writing why the Node is needed and what unmet need it addresses - Written declaration goes to the Transparency Hub for public review (30-day window) - If no objection from existing Nodes via § Consensus Practices, the Node is recognized The bottom-up path is the durable mode. Top-down should retire once the Guild has enough Guardians for consensus to function. --- ## III. What Nodes share, what Nodes do not share ### Shared (one Guild, multiple Nodes) - **The Living Book.** One Book, all Nodes. Amendments per § Amendments Process require cross-Node consensus. - **Core Values + Mission + Motto.** Identical everywhere. Unamendable per § Amendments Process. - **Treasury structure.** All Nodes report inflows + outflows through the same four channels (Overhead, Vault, Betterment, Compensation). The Perpetuity Vault is *one* Vault, not many. - **Guild canonical terms.** SCAS, Retroposity, Assistance Contract, Representative, Guardian — same meanings. - **Transparency Hub.** One public hub. Per-Node breakouts are sections, not separate hubs. - **Code Sovereignty / Software stack.** All Nodes use the Guild codebase. Changes flow through formal contribution paths. - **Founding Declaration.** One canonical identity (EIN, charity registration). Nodes are not separate legal entities by default. ### Local to each Node (Node autonomy) - **Floor Registry.** Each Node curates the Floor resources in its own geographic area. - **Culture Circles.** Locally declared and locally facilitated. - **Collaborative Actions.** Scoped to the Node's reach. - **Rep Capacity.** Reps live in a Node; capacity registry is per-Rep but Node-tagged. - **Local Agreements.** Per § Local Agreements Under Guild Presence, a Node may adopt local norms that don't conflict with the Book. - **Operational Reviews.** Quarterly Localized Review is per-Node; Annual Comprehensive Synthesis is Guild-wide. ### Choice (per-Node decision, no default) - **Node-level treasury sub-pool?** A Node may request a designated portion of Betterment Fund for its own SCAS pool. Per Living Book the SCAS is fundamentally one pool with per-Rep allocations; per-Node sub-pools are a permissive option that needs ratification via § Consensus Practices each fiscal year. - **Local banking?** Possible but adds complexity. Default: one Guild bank, one Stripe account. A Node may operate a local sub-account if local law requires; otherwise discouraged. - **Local social presence?** Each Node may run its own local outreach (community calendar, neighborhood updates) under the Guild aesthetic. --- ## IV. Coordination mechanics ### Inter-Node communication Nodes coordinate via the Internal Online Guild Platform (which today is the Rep workspace + admin surfaces; future revisions may add inter-Rep messaging within the platform). Until then: - Each Node has a designated Liaison (rotating quarterly) - Liaisons coordinate cross-Node issues that affect more than one Node - A Liaison is not a higher authority — just a contact point ### Cross-Node Arbitration When a violation report or dispute crosses Nodes (Rep from Node A, Person served in Node B): - Per Living Book § Termination Policy & Process, an Arbitration Council of ≥3 uninvolved Reps/Guardians forms - For cross-Node cases, "uninvolved" means the Council members are not from EITHER Node directly affected. A third Node provides the Council. If only two Nodes exist, an external trusted ally (per pre-arranged Liaison agreement) may be consulted, but the Council decision remains internal. ### Treasury reconciliation - All inflows go to the single Guild Treasury - Per-Node allocations from Betterment Fund (when activated) are tracked via existing SCAS columns - A new Node receives its SCAS allocation per Guildmaster (during Seed Phase) or per § Consensus Practices ratification (steady state) - Annual reconciliation: per-Node summary in the Annual Comprehensive Synthesis ### Node de-recognition Per § Node Recognition & Attestation: a Node may be de-recognized via cross-Node Arbitration Council if: - The Node has been inactive for ≥2 quarters - The Node has knowingly violated the Living Book and refused remediation - The Node has misappropriated Guild resources De-recognition is rare and grave. The default is dialogue, mediation, and rehabilitation; de-recognition is the last resort. --- ## V. Database surface (already in place) The `nodes` table in `db/db.js` has the canonical Node columns: ```sql nodes ( id, name, area_description, recognition_path, declaration_text, status, formed_at, recorded_at ) ``` The `node_attestations` table records each formal attestation: ```sql node_attestations ( id, node_id, attestor_rep_id, attestation_text, attested_at ) ``` A `nodes.parent_federation_id` column may be added in the future if multi-tier federation (e.g., regional federations of Nodes) becomes necessary. Not anticipated soon. The `proposals.scope` field already includes `'regional' | 'guild_wide'` for proposals that cross Node boundaries; the consensus workflow supports both. --- ## VI. Failure modes anticipated 1. **Node domination** — one Node grows much larger than others and begins acting as a de-facto headquarters. Counter: rotating Liaisons; § Consensus Across Scales requires Guild-wide votes for any guild-wide change; per-Node Treasury reporting makes asymmetric resource concentration visible. 2. **Node fragmentation** — Nodes drift into divergent local interpretations of the Living Book. Counter: the Book is one Book; cross-Node Operational Reviews surface divergence early; § Amendments Process is the only way to legitimately update doctrine. 3. **Trust collapse between Nodes** — historical or interpersonal grievance poisons cooperation. Counter: cross-Node Arbitration with members from a third Node; Liaison rotation reduces single-relationship dependency. 4. **Legal complications** — a Node operates in a jurisdiction with restrictive rules. Counter: Per § Compliance Clarification, each Node ensures compliance with its local jurisdiction; Guild-wide structure (WA UNA) does not automatically apply elsewhere. New Nodes outside WA may need supplemental local entity formation; Trustees + legal counsel consulted. 5. **Vault location risk** — the Perpetuity Vault is held in some jurisdiction. If that jurisdiction becomes hostile, Vault may need to migrate. § Asset Irreversibility is preserved (principal not spent); the migration itself is an operational concern not a doctrinal one. --- ## VII. When to revisit this protocol - **Before Node #2 forms** — review and update with then-current realities - **After Node #2 has operated for 12 months** — first real-world reconciliation - **Whenever a cross-Node dispute reveals a gap** — close the gap, document - **Whenever Living Book § Federated Structure is amended** — sync --- ## VIII. Open questions (intentionally unsettled) These are flagged for later Reps/Guardians to settle when there are enough humans to settle them well: - **Do Node Liaisons get any structural authority?** Default no — they are contact points only. Future Reps may decide otherwise. - **What's the minimum viable Node size?** 1 Rep technically; in practice ≥3 Reps seems healthier. Not codified. - **Can a Node leave the Guild?** Per § Termination Policy & Process, a Node may dissolve. A Node leaving and continuing under a different name without violating the Living Book is unclear — Living Book is silent. Decide when needed. - **International Nodes — language of canonical authority?** Living Book PDF is in English. International Nodes would presumably operate in local language. The English Book remains the canonical source for ambiguity resolution; translation discipline (Wolf's i18n rule, 2026-05-10) applies. --- *Drafted 2026-05-16 by Claude (Opus 4.7) during the Tier-4 federation infrastructure build. Inert until a second Node forms; serves as the ready-to-use protocol when needed.*