This document defines the architectural relationship between:
It consolidates the current direction for the Pancakes/Pitchfork ecosystem into a single implementation-oriented reference suitable for engineering, systems design, and product planning.
This document should be read alongside:
Pancakes and Pitchfork are not a single centralized app.
They are:
A node-oriented ecosystem
with multiple clients
sharing one accounting substrate.
The system must support:
Hosted infrastructure is important, but it must not become the sole valid deployment model.
The first official hosted nodes are:
| Domain | Role |
|---|---|
pancakes.ca |
Stable public Pancakes experience |
pancakes.love |
Experimental, cooperative, RPG, or blockchain-connected environment |
These are official Pancakes nodes, not “the platform itself.”
The architecture must treat them as:
official hosted deployments
inside a broader node ecosystem
not:
the irreplaceable central authority
This principle preserves:
Reference: Pancakes Node Infrastructure
The core system principle is:
Clients bind to node context.
Clients do not care whether the node is:
- official hosted,
- self-hosted,
- virtual,
- mobile-local,
- or federated.
The same client code should work against:
pancakes.ca
pancakes.love
localhost
household node
guild node
mobile virtual node
future federated node
This applies especially to:
A Pancakes node is:
a deployment boundary
+
a governance boundary
+
a permission boundary
+
an identity boundary
Reference: Pitchfork System Overview
A node may be:
| Node Type | Purpose |
|---|---|
| personal_local | Local-first personal archive |
| household_local | Shared family/chosen-family stewardship |
| guild_local | Cooperative or group infrastructure |
| institutional_local | Clinics, schools, nonprofits |
| official_hosted | pancakes.ca / pancakes.love |
| virtual_hosted | Lightweight hosted abstraction |
| virtual_mobile | Mobile-local node state |
| virtual_offline | Offline-first temporary node |
Mobile apps and lightweight web clients need a simpler operational model than full server deployment.
The system should therefore support:
virtual nodes
A virtual node is:
a node abstraction
with the same external contract
as a full node
but backed by:
A virtual node must expose the same conceptual interfaces as a full node:
node_id
node_type
policy_version
identity claims
permission grants
Pitchfork accounting
audit surfaces
export/import
retention rules
projection permissions
This preserves:
Clients should target:
Node Interface
not:
specific deployment environments
The architecture should look like:
Client
→ Node Resolver
→ Active Node Context
→ Identity Layer
→ Permission Layer
→ Pitchfork API
→ Projection Systems
→ Client UX
The Node Resolver determines:
Example flows:
User opens RPG client
→ selects pancakes.ca
→ authenticates
→ receives node session
→ accesses Pitchfork resources
User opens Wellness Notebook
→ selects household node
→ authenticates locally
→ accesses household-scoped rituals and covenants
User opens mobile client offline
→ virtual_mobile node activates
→ local events recorded
→ sync occurs later
Pitchfork is the shared accounting substrate.
Reference: Pitchfork System Overview
Pitchfork should remain:
Pitchfork should not assume:
The core event flow remains:
real-world action
→ client record
→ node permission check
→ Pitchfork event
→ settlement and caps
→ derived state
→ client-specific projection
Reference: Pitchfork System Overview
Example:
User logs a walk
↓
Node policy approves movement event
↓
Pitchfork settles capped participation
↓
RPG client grants Ember Moss
↓
Nexus updates Ley Road vendors
↓
Ambient client grows pathways
Different clients interpret the same accounting event differently.
Example:
| Layer | Interpretation |
|---|---|
| Pancakes | “You logged a walk.” |
| RPG | “You gathered Ember Moss.” |
| Nexus | “Ley Road activity increased.” |
| Ambient Client | “Paths emerged through the grass.” |
| Ledger | “Movement event settled under cap.” |
Reference: Pitchfork System Overview
Ambient symbolic clients should operate through:
permissioned symbolic projection
not:
diagnostic metric exposure
Reference: Ambient Symbolic Clients and Environmental Projection
Example:
private emotional or cycle state
↓
permissioned symbolic event
↓
environmental modifier
↓
red moon
↓
wildlife changes
↓
dream ecology shifts
Not:
explicit reproductive or emotional metrics
Sensitive systems require stronger boundaries.
Relevant systems:
Relevant references:
Sensitive domains must default to:
The system should distinguish:
| Classification | Meaning |
|---|---|
| private | visible only to actor |
| local_client | client-only use |
| node_local | available within node policy |
| household | visible to household participants |
| guild | cooperative visibility |
| trusted_participants | explicitly shared |
| public_symbolic | symbolic/aggregate only |
| economic_settlement | covenant settlement only |
Reference: Pitchfork Client API Spec
Web and mobile clients must work through:
virtual nodes
or equivalent abstractions
This is required because:
Mobile clients should eventually support:
local event queue
→ local permissions
→ deferred synchronization
→ bounded settlement replay
This allows:
The long-term architecture should support:
Reference: Pancakes Node Infrastructure
Potential appliance direction:
small low-power node
+
preconfigured Pancakes software
+
local dashboard
+
automatic updates
+
backup/export tools
Federation should come later.
Early architecture should prioritize:
Initial federation candidates:
Not:
Pancakes service exchange systems should also be node-aware.
Reference: Pancakes Service Exchange
Service systems should support:
Important principle:
tasks are not automatically services
Private household activity must not automatically become marketplace labor.
The Pitchfork RPG client is:
one optional interface
over Pitchfork accounting
not:
the whole platform
Reference: Pitchfork RPG Client Product Concept
The RPG should:
The near-term implementation can remain simple.
Recommended early stack:
Python accounting module
+
Flask/Gunicorn web apps
+
local database
+
node-local APIs
+
shared event model
Reference: Pitchfork System Overview
Avoid premature:
The first successful integration should prove:
one event
→ one accounting settlement
→ multiple node-aware projections
Example:
User logs a walk
↓
Pancakes records event
↓
Pitchfork settles movement participation
↓
RPG grants Ember Moss
↓
Nexus updates vendor inventory
↓
Ambient world grows paths
Reference: Pitchfork System Overview
Every client must operate through node context.
pancakes.ca and pancakes.love are official nodes.
They are not the sole legitimate deployments.
Sensitive state should become symbolic projection, not exposed metrics.
Pitchfork accounts. Clients interpret. Nodes govern. Identity authorizes.
Self-hosting cannot become a second-class citizen.
Stabilize permissions and exports before distributed systems.
Mobile/web abstractions must preserve the node contract.
The ecosystem should ultimately feel like:
many humane interfaces
sharing one coherent symbolic substrate
across locally governed nodes
not:
one centralized app
extracting behavioral data
through mandatory hosting