Foundational
Companion to:
This document defines the capability model used throughout the Pancakes ecosystem.
Capabilities are the primary mechanism by which Pancakes nodes acquire new behavior.
Rather than continually expanding the responsibilities of the node itself, Pancakes grows by composing reusable capabilities that model human activities, institutions, services, and integrations.
This document defines:
It does not define individual products, user interfaces, deployment models, or application-specific behavior.
Nodes govern.
Capabilities provide behavior.
Reference services describe the world.
Information sources observe the world.
Pitchfork accounts.
Products compose capabilities.
Clients present experiences.
The node should remain stable while capabilities evolve.
Human life continuously develops new needs.
Communities invent new institutions.
Technology introduces new possibilities.
Future generations will almost certainly discover new forms of flourishing that cannot be anticipated today.
Rather than redesigning Pancakes whenever this occurs, new domains should normally appear as new capabilities.
Capabilities are therefore the primary extension mechanism for the ecosystem.
The architecture should require:
new capability
rather than:
new node architecture
when new domains emerge.
This is the architectural motivation behind the Sneeds principle.
A capability is a reusable, discoverable service that extends the behavior of a Pancakes node.
Capabilities may:
Capabilities are reusable.
They are not complete applications.
Nodes provide governance.
Nodes determine:
Capabilities operate within those boundaries.
Capabilities do not replace node governance.
They extend node behavior.
Products are compositions of capabilities.
For example:
Household Management
↓
Household
Recipes
Calendar
Inventory
Notifications
Pitchfork
Another product may reuse many of the same capabilities.
Capabilities are intended to be shared across products whenever practical.
Clients provide interfaces.
Capabilities provide behavior.
Multiple clients may consume the same capability.
Examples include:
Clients should avoid duplicating capability logic.
Pitchfork provides settlement, contracts, symbolic accounting, recipes, projections, and economic infrastructure.
Capabilities may submit events to Pitchfork.
Capabilities may consume projections.
Capabilities should not create independent accounting systems.
Pitchfork remains the shared accounting substrate.
Capabilities fall into three broad architectural categories.
These categories describe responsibility rather than implementation.
Infrastructure capabilities provide reusable platform services.
They make the node itself useful.
Examples include:
Infrastructure capabilities generally do not model human activities.
They provide services used by other capabilities.
Example:
Identity
↓
Permission Check
↓
Storage
↓
Audit
Most nodes require many infrastructure capabilities regardless of which products they host.
Domain capabilities model human activities, institutions, and forms of stewardship.
Most Pancakes functionality belongs here.
Examples include:
Domain capabilities represent meaningful areas of human life.
They should remain reusable across products.
Example:
Garden
plant()
harvest()
water()
observe()
maintain()
Integration capabilities connect Pancakes nodes to external systems.
Examples include:
Integration capabilities translate between Pancakes and external systems.
They should avoid embedding external assumptions into the core architecture.
External technologies should remain replaceable.
The three capability categories naturally depend upon one another.
Infrastructure
↓
Domain
↓
Integration
Infrastructure capabilities provide reusable services.
Domain capabilities model human activities.
Integration capabilities connect those activities to the outside world.
The preferred dependency direction is downward.
Infrastructure capabilities should not depend upon domain-specific behavior.
Capabilities should be discoverable.
Nodes should advertise:
Clients should discover capabilities rather than assuming every node provides identical functionality.
This allows different nodes to expose different feature sets while preserving compatibility.
Capabilities expose reusable domain APIs.
Example:
Inventory
record_item()
consume_item()
transfer_item()
search_items()
Example:
Calendar
create_event()
cancel_event()
schedule_recurring()
list_events()
Example:
Garden
plant()
harvest()
water()
record_observation()
Products consume these APIs rather than reimplementing them.
Capabilities may depend upon:
Dependencies should be explicit.
A capability should declare:
Required capabilities.
Optional capabilities.
Required reference services.
Required information sources.
Required permission scopes.
This allows graceful degradation when optional services are unavailable.
Capabilities are intended to be composed.
Example:
Household Management
Household
Recipes
Inventory
Calendar
Notifications
Quality of Life
Pitchfork
Example:
Pitchfork RPG
Questing
Inventory
Crafting
Recipes
Projection
Pitchfork
Example:
Service Exchange
Contracts
Scheduling
Messaging
Payments
Pitchfork
Products compose capabilities.
Capabilities remain reusable.
Reference services provide public knowledge.
Capabilities consume that knowledge.
Examples include:
Capabilities interpret reference information within their own domains.
Reference services remain application-independent.
Information sources produce observations.
Capabilities consume observations.
Examples include:
Capabilities determine whether observations are relevant to their domain.
Observations do not automatically become meaningful events.
Capabilities often produce events.
Examples include:
meal_prepared
loop_completed
garden_watered
tool_checked_out
service_completed
story_recorded
Events may later be submitted to Pitchfork for settlement.
Not every internal operation requires a Pitchfork event.
Capabilities operate within node governance.
Capabilities should declare:
Nodes determine whether those permissions are granted.
Capabilities should never bypass node governance.
Capabilities normally progress through the following lifecycle.
Design
↓
Installation
↓
Discovery
↓
Configuration
↓
Permission
↓
Operation
↓
Upgrade
↓
Deprecation
↓
Removal
Nodes should support capability evolution without disrupting unrelated capabilities.
Capabilities evolve independently.
Nodes should support:
Products should discover capability versions rather than assuming a particular implementation.
Every capability should expose a declarative description of its requirements and behavior.
Example:
capability: garden
category: domain
depends_on:
- identity
- permissions
- storage
- pitchfork
optional:
- notifications
- place
reference_services:
- species
- weather
information_sources:
- rainfall
- soil_moisture
events:
- plant_seeded
- harvest_completed
projections:
- stewardship
The manifest allows nodes to validate compatibility before installation.
Capabilities should be:
Capabilities should prefer cooperation over duplication.
The capability architecture should remain adaptable.
When a new domain emerges, the preferred response should be:
Add a new Domain capability.
When a new external system appears:
Add a new Integration capability.
When new reusable platform services become necessary:
Add a new Infrastructure capability.
The architecture should rarely require changes to the node itself.
A healthy architecture grows through capabilities rather than structural redesign.
Capabilities are not:
Those concepts remain separate architectural responsibilities.
Pancakes Node Architecture defines governance and runtime boundaries.
Pancakes Product Composition explains how capabilities are assembled into complete products.
Pancakes Reference Services defines shared public knowledge consumed by capabilities.
Pancakes Information Sources defines observations consumed by capabilities.
Pancakes Appliance Design defines physical and virtual deployment units that host or extend nodes.
Pitchfork provides settlement, contracts, recipes, resources, and projections used by capabilities.
A Pancakes node should remain small, stable, and governable.
Everything that changes rapidly—new domains, new institutions, new services, new integrations, and new forms of flourishing—should emerge through reusable capabilities.
The ecosystem should grow by composition rather than by continually expanding the responsibilities of the node itself.