Operator stewardship handbook · v1.0 · 2026

E-UBI Operator Handbook

The technical stack only stays autonomous if people know who can approve changes, who can restore service, who holds recovery material, and how escalation works when trust, uptime, or stewardship continuity is under pressure.

👥 named stewards🧭 clear authority🔁 handoff discipline🚨 escalation ladder🔐 custody boundaries
Community Networking / Local Infrastructure Nodes expansion and future network systems work: Caleb Bott. This handbook turns the infrastructure stack into an operable community system by naming steward roles, escalation ladders, approval boundaries, and the real-world handoff model around TheEtherNet’s current auth and moderation constraints.
Section 01 — Steward Roles

Use a small set of named stewardship roles

The safest community system is not the one with the most titles. It is the one where a second person can explain who covers daily checks, who owns a service boundary, who can approve risky changes, and who can help recover the site if one steward disappears.

Shift steward
Daily observation + first response
Checks uptime, dashboard health, storage headroom, WAN condition, and obvious user-facing failures. Opens the log, does not improvise structural changes alone.
Service steward
Owns one technical lane
Holds the working knowledge for a bounded class such as identity, mirrors, relays, or backup jobs. Responsible for drills, documentation, and known-failure notes.
Custody pair
Two-person recovery control
Named people who can retrieve sealed recovery material, verify break-glass procedure, and witness rotations when a credential or trust event is serious enough.
Incident lead
Temporary coordination role
For active outages or trust disputes, one steward coordinates timeline, decisions, and communication so the technical work and the public narrative do not fragment.
Community approver
Change boundary for material moves
Approves major locality, trust, or service-placement changes that alter who controls data, recovery, or publication scope. This can be a council, board, or named local process.
Section 02 — System Boundary

Map authority to the actual implementation, not a fantasy one

The handbook should follow the current TheEtherNet code, not an imagined future platform. Right now the social layer is username-first, JWT-based, refresh-token backed, and moderation-light at the data model level. That means some authority lives in procedures, operator custody, and documented human boundaries.

🧭 Current authority chain

👤 Username-first account
primary login key, email optional
→
🎟️ JWT session boundary
15m access, 7d refresh persisted in Postgres
→
🔌 REST + Socket.IO auth
same bearer-token trust path
→
👥 Steward process boundary
moderation and escalation live here today
Primary identity
Username is canonical
Current registration and login use `username` as the sole unique login key. Email is optional in Prisma and not required for the auth flow.
Session model
15m access / 7d refresh
Access tokens are short-lived JWTs. Refresh tokens are stored server-side in PostgreSQL through Prisma and rotated during refresh.
Guest mode
`ghost_` accounts, 24h life
Guest accounts are explicitly ephemeral and cannot use the normal password login route. Their access and refresh windows both last one day.
Realtime auth
Socket.IO verifies the same JWT
Socket connection middleware reads `socket.handshake.auth.token`, verifies it, and binds the socket to the authenticated user identity.
Role enforcement
No Prisma role field today
There is no backend role enum or moderator column in the current schema. Stewardship, moderation, and emergency authority must therefore be documented as process boundaries.
# Stewardship policy sketch grounded in the current implementation [resident_access] auth = username + password session = JWT access token + persisted refresh token [guest_access] auth = generated ghost_ account only session = 24h access + 24h refresh [operator_authority] implemented_in_code = bearer auth only implemented_in_process = steward approval, rotation, moderation, recovery [peer_trust] scope = explicit and documented default = least privilege + local-first control
Section 03 — Escalation Ladder

Escalate by blast radius and custody impact

Not every issue deserves the same response. The handbook should distinguish between routine drift, user-facing service failure, credential uncertainty, and major trust events. The purpose of the ladder is not bureaucracy. It is to stop panicked, irreversible changes by tired volunteers.

1
Observe and classify
Decide whether the event is routine maintenance, service outage, suspected credential problem, peer-trust problem, or full recovery situation. Log time, scope, and current operator immediately.
2
Stabilize the local service first
Prefer keeping local docs, dashboards, and bounded local functions alive over rushing to restore every federation or public-facing lane simultaneously.
3
Call the relevant service steward
The steward who owns identity, mirrors, relays, or backup lanes decides whether this is still within routine change authority or must escalate into custody and community approval.
4
Activate the custody pair for secret or trust events
If keys, refresh tokens, device access, or peer trust are in question, move out of solo-operator mode. Two-person verification and written steps are the safety boundary.
5
Escalate material governance changes outward
If the fix changes what is mirrored, what stays local, who holds authority, or which peer is trusted, route it through the community approver path instead of calling it “just an ops tweak.”

Routine drift

Disk filling, stale cache, backup retry, or dashboard noise. Service steward can usually handle with logged change notes.

User-visible outage

Homepage, docs, login, or posting path degraded. Incident lead coordinates; keep communications and timeline explicit.

Credential event

Lost admin device, leaked token, expired recovery path, or suspicious refresh failures. Custody pair and identity steward engage together.

Trust dispute

Peer mirror concern, moderation dispute, or unclear authority boundary. Pause external trust lanes before widening the problem.

Section 04 — Handoff & Operator Packet

A node is durable only if a second steward can take over without folklore

The handoff model is where community infrastructure either becomes real or collapses into hero culture. Each site should keep a current operator packet, a recovery packet, and a drill history that proves the documentation is usable by somebody other than the original builder.

Operator packet
Topology, hostnames, service list, escalation contacts
This is the daily-use packet for current stewards. It should explain the live environment, not just the ideal design.
Recovery packet
Break-glass steps + custody instructions
Store separately, restrict access, and verify that it reflects current secrets, tokens, tunnel names, restore media, and peer contacts.
Drill cadence
Shadow, restore, rotate, hand off
A healthy steward pipeline includes at least one documented restore drill and one rotation drill before a new operator is treated as fully independent.
Departure procedure
Same-day review and rotation
When a steward leaves, review remote access, rotate exposed material, verify packet ownership, and make sure no trust lane still assumes their presence.
Operations layer

Pair this with the Operations Runbook

The runbook gives the daily, weekly, and incident maintenance rhythm. This page decides who owns each class of response and approval.

Open Operations Runbook
Service-class drills

Move from role boundaries into runbooks

The service runbooks translate this steward model into identity, mirror, relay, and backup procedures tied to the current TheEtherNet implementation.

Open Service Runbooks
Identity & trust

Ground authority in credential custody

The identity guide defines who holds secrets, peer trust, and recovery shares. This handbook defines who is allowed to use those paths.

Open Identity & Trust Guide
Service governance

Connect steward approval to locality policy

The service matrix makes it clear which moves count as material governance changes rather than routine operator work.

Open Service Matrix
Regional layer

Use it with Federation

Peer relationships, mirrors, and regional recovery are only safe when stewardship authority is named instead of implied.

Open Federation Guide
Social layer

Bridge back into TheEtherNet

TheEtherNet currently provides auth boundaries, not a complete governance system. This handbook documents the human boundary that keeps that manageable.

Open TheEtherNet