Foundational
Companion to:
This document defines how complete Pancakes products are assembled from reusable architectural components.
Pancakes is not a collection of unrelated applications.
It is a compositional platform.
Products emerge through the composition of reusable capabilities operating within a governed node.
This document defines:
It does not define individual product behavior or user interfaces.
Nodes govern.
Capabilities provide behavior.
Reference services describe the world.
Information sources observe the world.
Pitchfork accounts.
Products compose capabilities.
Clients present experiences.
Every layer has a distinct responsibility.
Products exist to assemble those responsibilities into coherent experiences.
Capabilities are intentionally small.
Each capability models a reusable area of behavior.
Users, however, interact with complete experiences.
A household does not install “Inventory.”
A household installs Household Management.
A cooperative does not install “Contracts.”
A cooperative installs Service Exchange.
Products provide coherent human-centered experiences by composing reusable capabilities.
A Pancakes product is a coherent composition of:
Products define user-facing domains.
Nodes define governance.
Capabilities define behavior.
Clients provide interfaces.
Products occupy a specific position within the architecture.
Clients
↓
Products
↓
Capabilities
↓
Pitchfork
↓
Node
↓
Infrastructure
Each layer should remain independent.
Changes at one layer should rarely require redesign of another.
Products are composed from reusable architectural elements.
Every product operates within a node.
The node provides:
The node owns governance.
Products never replace it.
Capabilities provide reusable behavior.
Examples include:
Products compose capabilities.
Capabilities remain reusable.
Pitchfork provides shared accounting.
Products may use:
Products should avoid creating independent accounting systems.
Reference services provide public knowledge.
Examples include:
Products consume reference knowledge when appropriate.
Reference services remain application-independent.
Information sources provide observations.
Examples include:
Products consume observations through capabilities.
Observations remain distinct from meaning.
Appliances are optional deployment units.
Examples include:
Products may support appliances.
Products are not appliances.
Clients provide user interfaces.
Examples include:
Multiple clients may expose the same product.
Products are primarily compositions of capabilities.
Example:
Household Management
Household
Inventory
Recipes
Calendar
Notifications
Quality of Life
Pitchfork
Example:
Service Exchange
Contracts
Scheduling
Messaging
Payments
Pitchfork
Example:
Pitchfork RPG
Questing
Crafting
Inventory
Recipes
Projection
Pitchfork
The product owns the composition.
The capabilities remain reusable.
Products typically initialize using the following sequence.
Resolve Node
↓
Establish Identity
↓
Load Node Policy
↓
Discover Capabilities
↓
Discover Reference Services
↓
Discover Information Sources
↓
Obtain Permissions
↓
Begin Operation
Products should adapt to the capabilities available on the active node.
Several common composition patterns exist.
A lightweight composition.
Usually:
The most common pattern.
Several reusable capabilities cooperate to create one experience.
Examples include:
Designed for cooperatives and communities.
Typically includes:
Designed for clinics, schools, libraries, and organizations.
Often emphasizes:
The underlying capability model remains unchanged.
A product may expose multiple interfaces.
Example:
Household Management
├── Mobile App
├── Kitchen Display
├── Desktop Dashboard
├── Ambient Display
└── Administration Console
These remain one product.
They consume the same capabilities.
Products should discover capabilities rather than assuming every node provides identical functionality.
Some capabilities may be required.
Others may be optional.
Example:
Household Management
Required
Household
Calendar
Optional
Weather
Notifications
GIS
Graceful degradation should be preferred whenever possible.
Products should describe themselves declaratively.
Example:
product: household-management
requires:
capabilities:
- household
- inventory
- recipes
- calendar
optional:
capabilities:
- notifications
- qol
reference_services:
- place
- products
information_sources:
- weather
clients:
- mobile
- dashboard
projections:
- wellness
- symbolic
The composition manifest allows nodes to determine whether a product can operate.
Deployment and composition should remain separate concepts.
For example:
Woodland Commons
↓
Household Node
Commons Node
↓
Products
↓
Clients
↓
Appliances
Woodland Commons is not a product.
It is a deployment containing many products.
Similarly, a clinic may deploy:
The deployment contains products.
The products remain independently composable.
Products should not duplicate:
Those responsibilities belong elsewhere.
Products assemble.
They do not redefine.
Products should be:
Products should express human purposes rather than technical layers.
Suppose society discovers a completely new domain.
The preferred solution should be:
New capability
↓
Existing product composition
or
New capability
↓
New product
The architecture should rarely require redesigning the node.
Products should evolve through composition.
Pancakes Node Architecture defines governance boundaries.
Pancakes Node Capabilities defines reusable behavioral services.
Pancakes Reference Services defines reusable public knowledge.
Pancakes Information Sources defines observations.
Pancakes Appliance Design defines deployment hardware and virtual infrastructure.
Pitchfork defines settlement, contracts, resources, recipes, and projections.
This document explains how those architectural components become complete Pancakes products.
Pancakes grows by composition.
Nodes provide governance.
Capabilities provide reusable behavior.
Pitchfork provides shared accounting.
Reference services provide public knowledge.
Information sources provide observations.
Appliances provide deployment infrastructure.
Clients provide interfaces.
Products bring these elements together to support coherent areas of human life.
As new needs emerge, the ecosystem should grow by creating new capabilities and new product compositions rather than continually expanding the responsibilities of the node itself.