CCOS Charter Template: Regional Exchange Corridor Charter

(NeighborNet Network Layer) Version: 1.0 Status: Draft / Proposed / Active (choose one) Effective Date: {{YYYY-MM-DD}} Review Date: {{YYYY-MM-DD}} Corridor Name: {{CorridorName}} Participating Nodes: {{VillageA}}, {{VillageB}} (add more only after pilot)

---

1) Purpose

This charter establishes a bounded, consent-based exchange lane between participating villages (“Nodes”) so we can share support, skills, and resources across the region without exporting chaos. A Regional Exchange Corridor exists to:

• expand resilience beyond one node
• share surplus and specialized skills safely
• build interoperable “New Earth exchange” pathways step-by-step
• protect helpers, protect privacy, and keep closure clean

Non-goal: This corridor is not an open market or an unlimited support channel. It is a governed lane with guardrails.

---

2) Scope

2.1 Corridor Level

Select one (do not combine during pilot):

• Level 1: Mutual Support Lane (rides, tools, small repairs)
• Level 2: Skill Exchange Lane (training, facilitation, tech support)
• Level 3: Goods + Surplus Lane (produce, materials, inventory)
• Level 4: Credit / Asset-Backed Lane (advanced; requires legal + mature stewardship)

Selected Level: {{Level}}

2.2 Domains Allowed (Pilot Rule)

During pilot, activate 1 domain only:

• {{CorridorDomain1}}

Optional future domains (inactive during pilot):

• {{CorridorDomain2}}
• {{CorridorDomain3}}

2.3 Out of Scope (Always)

• requests that require professional licensure unless explicitly verified and insured
• high emotional load “therapy-by-proxy” routed through operational matching
• requests involving minors without explicit policy alignment and designated safeguards
• anything illegal, unsafe, or coercive

---

3) Participation Requirements

A node is corridor-ready only if it meets internal hygiene gates:

• triage occurs within 24 hours (typical)
• closure rate is consistently high (no hanging matches)
• domains can be paused without drama
• stewards are not overloaded
• operations occur in VT360, not the Mighty feed

Each node affirms readiness at activation and at each review.

---

4) Roles and Accountabilities

4.1 Per Node Roles (Required)

Each participating node assigns:

A) Corridor Steward (Required)

Accountabilities

• receives corridor candidates from local triage
• coordinates cross-node matching
• enforces corridor caps and pause rules
• participates in weekly corridor review
• ensures closure and settlement logging happen

Authority

• may pause corridor matching immediately if risk rises

Assigned:

• {{VillageA_CorridorSteward}}
• {{VillageB_CorridorSteward}}

B) Domain Steward (Required for the active corridor domain)

Accountabilities

• validates requests are truly in-domain
• enforces request size limits
• ensures done definition is present
• prevents scope creep

Assigned:

• {{VillageA_DomainSteward}}
• {{VillageB_DomainSteward}}

C) Care/Risk Steward (Required)

Accountabilities

• reviews overload signals and capacity constraints (locally)
• flags risk patterns to corridor steward privately
• ensures emotional load is routed to the correct container

Assigned:

• {{VillageA_CareSteward}}
• {{VillageB_CareSteward}}

4.2 Shared Roles (Pilot)

Corridor Anchor Council (2–4 people total)

Accountabilities

• holds the corridor charter and updates
• resolves disputes escalated beyond a single node
• approves corridor expansion (domains/nodes/caps)
• runs weekly review during pilot

Members: {{Names}} Optional (later):

• Corridor Ledger Steward (for settlement consistency)

---

5) Operating Flow

All corridor exchange follows this sequence:

1. Request created in local VT360 and tagged CorridorCandidate = Yes
2. Local triage confirms it is matchable (NeedsInfo resolved)
3. Corridor Steward publishes it to the corridor queue (shared view or shared database)
4. Receiving node reviews capacity and accepts/declines
5. Match is created with:
6. Work occurs
7. Closure is logged (request + match)
8. Settlement is recorded (if applicable)
9. Weekly corridor review adjusts caps and policies

---

6) Matching Standards

6.1 Request Quality Minimums (Required)

A corridor request must include:

• domain
• time window
• location
• scope size (Small/Medium/Large)
• emotional load (Low/Medium/High)
• done definition
• logistics notes (travel, pickup/drop-off)

Requests missing any minimum are set to NeedsInfo and are not published corridor-wide.

6.2 Timeboxing (Required)

All corridor matches must be timeboxed. Default limits during pilot:

• Small: ≤ 90 minutes
• Medium: ≤ 3 hours
• Large: not permitted during pilot (unless explicitly approved)

6.3 No Scope Creep (Required)

New needs require a new request. “While you’re here…” does not apply across nodes.

---

7) Capacity Caps and Limits

7.1 Pilot Caps (Required)

Choose one cap model: A) Matches cap

• Max corridor matches per week: {{#}} total
• Max per node per week: {{#}}

B) Hours cap

• Max corridor hours per week: {{#}} total
• Max per node per week: {{#}}

Selected cap model: {{A or B}}

7.2 Capacity Overrides (Safety)

Corridor stewards may decline matches at any time due to:

• overload signals
• logistical risk
• mismatch in emotional load
• insufficient clarity
• domain capacity reached

Declining is a normal function, not a moral judgment.

---

8) Pause and Repair Process

8.1 Immediate Pause Authority

Any Corridor Steward may pause matching immediately if:

• closure decays
• capacity bleed appears
• safety risk rises
• policy drift occurs
• conflicts escalate beyond containment

8.2 Pause Protocol

When paused:

• corridor status set to Paused
• reason is recorded in the corridor log
• review date is scheduled within 14 days
• affected requests are closed or deferred cleanly

8.3 Repair Steps

During pause, the council identifies:

• root cause
• policy or workflow adjustment
• cap adjustment
• staffing adjustment
• reactivation criteria

No reactivation without explicit criteria.

---

9) Privacy and Data Rules

9.1 Non-Negotiable Privacy Boundaries

• PulseChecks are local and private
• Contribution patterns are local and private
• No public scoreboards
• No cross-node gossip about individuals

9.2 Corridor Reporting (Allowed)

Only aggregated signals may be shared:

• total matches/hours
• closure rate
• domain pressure
• pause events (without naming individuals)

---

10) Settlement Method

Pick one method for the pilot.

Option 1: Learning-only pilot (recommended)

• Track counts/hours only
• No balancing during pilot

Option 2: Time-based mutual credit (node-level)

• 1 credit = 1 hour
• Balance tracked by node, not person
• Monthly balancing actions agreed (service day, surplus delivery)

Option 3: Fiat/stablecoin settlement

• payments handled per match with clear terms
• still requires closure logging

Selected settlement method: {{Option}}

---

11) Dispute and Escalation Routing

Level 1: Match-level (within 72 hours)

Corridor Steward attempts resolution with involved parties.

Level 2: Node-level

Care/Risk Steward supports containment; may close corridor participation for individuals if needed.

Level 3: Corridor Anchor Council

Council resolves governance-level disputes, updates policy if required. Rule: Conflicts do not get processed in public feeds. They go into the correct container.

---

12) Review Cadence and Success Metrics

12.1 Pilot Review Cadence

• Weekly: 30-minute corridor review call during pilot
• Biweekly: cap and domain review
• Day 14: pilot evaluation and decision to continue/expand
• Day 30: stability check
• Day 90: maturity evaluation

12.2 Success Metrics (Pilot)

• closure rate remains high
• backlog stays low
• no chronic capacity bleed
• pausing works without drama
• participants report “safe and clear”

---

13) Expansion Rules (After Pilot Only)

Expansion requires explicit approval by the Corridor Anchor Council. Expansion types:

• add a second domain
• add a third node
• increase weekly caps
• introduce settlement beyond learning-only
• move toward asset-backed credit (requires separate charter + legal review)

---

14) Sign-off

By signing, participating nodes agree to uphold:

• bounded scope
• consent and capacity
• privacy boundaries
• closure requirements
• pause as a safety feature

Node Signatories

• {{VillageA}}: {{Name}}, {{Role}}, {{Date}}
• {{VillageB}}: {{Name}}, {{Role}}, {{Date}}

Corridor Anchor Council

• {{Name}}, {{Role}}, {{Date}}
• {{Name}}, {{Role}}, {{Date}}

---

Appendix: VT360 Fields to Support This Charter (minimal)

Recommended properties (add if missing):

• CorridorCandidate (Checkbox) on ExchangeRequests
• Corridor (Relation to Corridors) on ExchangeRequests and ExchangeMatches
• RequestingNode (Relation to Nodes)
• HelpingNode (Relation to Nodes)
• CorridorStatus (Status or Select) on Corridors
• WeeklyCapMatches and/or WeeklyCapHours on Corridors
• PauseReason (Text) + ReviewDate (Date) on Corridors

If you want next, I can translate this charter into Notion-ready ledger entries (Decision + PolicyAgreement + Dependencies + Accountability) so every corridor activation becomes auditable CCOS governance memory inside VT360.