This document defines the design direction for Pancakes appliances.
A Pancakes appliance is a physical or virtual device that runs, extends, or feeds a Pancakes node.
The purpose of the appliance model is to make Pancakes infrastructure tangible, local, understandable, and governable.
Pancakes should not exist only as a cloud app or a collection of client interfaces. It should also be able to exist as physical infrastructure in homes, clinics, schools, communities, workshops, gardens, commons, and institutions.
The appliance model gives Pancakes a concrete deployment pattern:
Pancakes Node Software
+
Pitchfork Accounting Substrate
+
Physical or Virtual Appliances
+
Client Applications
This document distinguishes node software, client applications, and appliances.
Pancakes appliances are local infrastructure for humane life computing.
They should support:
They should not become:
The appliance model exists to make Pancakes more local, not more invasive.
Pancakes is organized around the distinction between:
Nodes
Clients
Appliances
A Pancakes node is the governance, identity, permission, storage, and policy boundary.
A node may be:
Nodes govern records, permissions, retention, exports, audits, and local policy.
A client is an interface.
Examples:
Clients interpret node state.
They do not own the whole system.
An appliance is a physical or virtual deployment unit that either:
Examples:
Appliances are not necessarily user-facing apps.
They are infrastructure.
A Pancakes appliance is a local, governable hardware or virtual device that runs or extends a Pancakes node by capturing, storing, processing, projecting, or displaying consented life, community, and stewardship records.
Every appliance must belong to a node.
An appliance must declare:
node_id
appliance_id
appliance_type
owner
custodian
policy_version
data_classes
permission_scopes
retention_policy
audit_policy
No appliance should operate as an ungoverned data collector.
Appliances may observe.
Appliances may remember.
Appliances may infer.
Appliances may recommend.
Appliances must not make significant decisions about people by themselves.
This is the Bacon Computer Rule:
Sensors may observe.
Nodes may remember.
AI may recommend.
Humans govern.
Forbidden pattern:
sensor
→ inference
→ automatic restriction
Allowed pattern:
sensor
→ node record
→ visible interpretation
→ human or governance decision
Raw records and AI inferences must both be governed.
The system must not treat summaries, classifications, risk scores, relationship estimates, mood estimates, or social graphs as harmless metadata.
If an inference is about an identifiable person, it is governed personal information.
Every generated inference must have:
inference_id
source_record_refs
subject_refs
purpose
model_or_rule_version
confidence
created_at
retention_policy
visibility_scope
challenge_status
deleted_at
Every appliance must state what it is for.
Acceptable purposes:
Unacceptable purposes:
Appliances should process data locally where possible.
Preferred pattern:
sensor input
→ local processing
→ minimized node record
→ optional projection
Avoid:
sensor input
→ cloud upload
→ remote AI processing
→ opaque result
Local processing is especially important for:
People should know when an appliance is recording or sensing.
Visible signals may include:
Hidden capture is prohibited except for narrow, explicitly governed safety cases.
A person should be able to ask:
What does this node know about me?
What records came from this appliance?
What inferences were generated about me?
Who accessed them?
Can I correct this?
Can I challenge this?
Can I delete or suppress this?
Appliances must support node-level workflows for:
Different appliances should know different things.
A BLE lap mat does not need audio.
A workshop station does not need health records.
A memory booth does not need background surveillance.
A clinic appliance does not need RPG projections.
Capability separation is a core design requirement.
Appliances feed records into nodes.
Clients decide how to interpret those records.
Example:
BLE lap timing mat
→ loop_completed event
→ Pitchfork movement settlement
→ Wellness Notebook: "You completed a loop."
→ RPG: "You gathered Ember Moss."
→ Ambient client: "The woodland paths are well traveled."
The appliance does not own all meanings of the event.
People must be able to live near or around Pancakes appliances without being forced into full participation.
For example:
Participation must not become coercion.
Node appliances run the Pancakes node itself.
They are the core local infrastructure.
Examples:
They provide:
Capture appliances produce records or events.
Examples:
They should minimize what they collect.
They should produce structured records with clear purpose and scope.
Sensor appliances observe environmental, spatial, or activity signals.
Examples:
Sensor appliances must distinguish between:
place-level state
and:
person-level state
Place-level state is generally safer.
Person-level state requires stronger consent and governance.
Memory appliances collect narrative artifacts.
Examples:
They produce records such as:
Memory appliances are not surveillance cameras.
They are voluntary contribution devices.
Projection appliances display or spatialize node state.
Examples:
Projection appliances must obey visibility scopes.
They should prefer aggregate, symbolic, or place-level projections over personal exposure.
Backup appliances preserve node continuity.
Examples:
They should support:
The household node appliance is the basic Pancakes home server.
It may run on:
Primary functions:
Default posture:
private by default
household sharing by explicit scope
sensitive records local-first
AI disabled unless enabled by purpose
The clinic node appliance is an institutional node for sensitive health-adjacent or clinical environments.
Primary functions:
Default posture:
least privilege
role-based access
sensitive by default
audited access
no casual browsing
no secondary use without consent
The clinic node should not expose sensitive data to game, ambient, or public clients unless a separate, explicit, minimized projection is approved.
The Speakers’ Corner booth is a memory capture appliance.
It is inspired by public-access video booths, oral history stations, and civic feedback kiosks.
Primary functions:
Possible modes:
private
household
node_local
trusted_participants
public_symbolic
public_record
Example session flow:
person enters booth
→ booth displays purpose and privacy options
→ person chooses scope
→ recording starts visibly
→ person records story or feedback
→ local transcript generated
→ person reviews transcript and summary
→ person accepts, edits, or deletes
→ record enters node archive
Forbidden uses:
The BLE lap timing mat is a movement ritual appliance.
In Woodland Commons, it may sit on or near the 400 m loop trail.
Primary functions:
Preferred event:
loop_completed
loop_id
timestamp
actor_id optional
tag_id
attestation_method = device_observed
Privacy posture:
Client projections:
Wellness Notebook: "You completed a woodland loop."
Pitchfork RPG: "You gathered Ember Moss."
Nexus: "Ley Road activity increased."
Ambient World: "Paths have grown clearer."
Community Dashboard: "The loop was used 312 times this week."
The workshop station is a tool, project, and craft-memory appliance.
Primary functions:
Preferred records:
tool_checked_out
tool_returned
tool_maintenance_logged
project_created
project_completed
material_used
workshop_stewardship_event
Forbidden uses:
The garden station is a stewardship appliance.
Primary functions:
Preferred posture:
Example projection:
Garden bed 4 has been watered.
Tomatoes harvested this week: 12 kg.
Three residents contributed to the herb garden.
Avoid:
Resident A failed to water plants.
Resident B is less committed than Resident C.
A community display is a projection appliance.
It may appear in:
Allowed outputs:
Forbidden outputs:
Appliance
- appliance_id
- node_id
- appliance_type
- display_name
- physical_location
- owner_ref
- custodian_ref
- firmware_version
- software_version
- policy_version
- status
- created_at
- updated_at
- retired_at
ApplianceCapability
- capability_id
- appliance_id
- capability_type
- data_classes_allowed
- event_types_allowed
- projection_types_allowed
- sensors_enabled
- ai_enabled
- network_required
- offline_supported
- created_at
- revoked_at
ApplianceEvent
- event_id
- appliance_id
- node_id
- actor_id optional
- event_type
- occurred_at
- data_class
- permission_scope
- attestation_method
- source_sensor
- client_record_ref
- measures
- idempotency_key
- retention_policy_id
- created_at
MemoryArtifact
- artifact_id
- node_id
- appliance_id
- contributor_actor_id
- artifact_type
- title optional
- recording_ref optional
- transcript_ref optional
- summary_ref optional
- data_class
- permission_scope
- consent_grant_id
- publication_scope
- retention_policy_id
- created_at
- updated_at
- deleted_at
InferenceRecord
- inference_id
- node_id
- appliance_id optional
- subject_actor_id optional
- subject_group_id optional
- source_record_refs
- inference_type
- inference_body
- confidence
- model_or_rule_version
- purpose
- data_class
- permission_scope
- retention_policy_id
- challenge_status
- created_at
- updated_at
- deleted_at
ApplianceAuditLog
- audit_id
- node_id
- appliance_id
- actor_id optional
- action_type
- target_record_ref optional
- data_class
- permission_grant_id optional
- occurred_at
- result
- admin_override
- reason
Every appliance operation should resolve to one of these patterns:
Example:
stream_flow_sensor
No actor identity required.
Still requires node governance.
Example:
trail_counter incremented
No direct actor identity.
Must avoid re-identification.
Example:
resident used BLE tag to record loop completion
Requires consent or active participation.
Example:
resident records a Speakers' Corner story
Requires explicit consent and publication scope.
Example:
health-adjacent clinic record
Requires elevated safeguards, purpose limitation, and stricter access control.
Example:
AI summary identifies recurring theme in a person's recordings
Requires discoverability, challenge rights, retention policy, and purpose binding.
Pancakes appliances should be designed to support Canadian PIPEDA and EU GDPR-style privacy obligations.
This document is not legal advice, but it defines product requirements aligned with those regimes.
Appliances must support:
Product implication:
An appliance cannot collect data first and invent a purpose later.
Appliances must support:
Product implication:
AI inference and profiling are governed processing activities.
The following require elevated protection:
Appliances must not infer or expose these casually.
AI may be useful in appliances, especially for:
AI must not become ambient surveillance.
Do not build:
Approved AI pattern:
explicit record
→ scoped AI processing
→ visible output
→ user or steward review
→ correction/challenge path
Forbidden AI pattern:
ambient capture
→ hidden analysis
→ secret profile
→ automated consequence
The Bacon Computer Rule is named after the dystopian pattern in which a biosensor detects a bodily condition and an institution automatically restricts a person’s food choice.
Pancakes appliances must not reproduce that pattern.
urinalysis
→ sodium inference
→ automatic cafeteria restriction
mood inference
→ automatic meeting exclusion
relationship inference
→ automatic housing decision
movement score
→ automatic benefit reduction
health signal
→ private note
→ user-visible recommendation
→ user decision
aggregate concern themes
→ steward review
→ community governance process
movement event
→ private ritual reward
→ optional symbolic projection
Appliances should support:
For capture appliances:
For institutional appliances:
Appliances should tolerate network interruptions.
Preferred pattern:
local capture
→ local queue
→ node sync
→ idempotent settlement
→ audit record
Events must include idempotency keys.
Offline devices must preserve:
If consent cannot be verified, sensitive capture should not proceed.
Pancakes appliances should feel understandable and trustworthy.
Physical design should prefer:
Avoid:
A household appliance should feel like a domestic commons device.
A clinic appliance should feel professional and safe.
A memory booth should feel voluntary and ceremonial.
A workshop station should feel practical and durable.
The appliance model suggests separating repositories by responsibility.
Possible repository structure:
pitchfork-core
pancakes-node
pancakes-appliance-sdk
pancakes-clients
pancakes-hardware-kits
pancakes-docs
Contains:
Contains:
Contains:
Contains:
Contains hardware reference designs for:
Contains:
Deliverables:
Build a software-only appliance simulator.
Capabilities:
This proves the appliance contract before hardware.
Build a local node appliance using commodity hardware.
Minimum capabilities:
Build the simplest physical event appliance.
Minimum capabilities:
Build a memory capture appliance.
Minimum capabilities:
Adapt the node appliance for clinics, schools, co-ops, and community institutions.
Minimum capabilities:
Woodland Commons can serve as a conceptual reference deployment.
Possible appliance set:
Household Node Appliances
- One per residence or household cluster.
Commons Node
- Shared node for community-level records.
BLE Loop Timing Mat
- 400 m woodland loop movement events.
Speakers' Corner Booth
- Oral history and community memory.
Workshop Station
- Tool checkout and project archive.
Garden Station
- Planting, harvest, and stewardship records.
Community Display
- Aggregate commons state and announcements.
Ambient Projection System
- Symbolic environmental or Nexus-style projections.
Backup Vault
- Encrypted local backups and continuity.
The key principle:
The technology supports the commons.
It does not dominate the commons.
Visitors should notice:
Only later should they discover the node infrastructure beneath the surface.
pancakes-node vs pancakes-appliance-sdk?Before adding any Pancakes appliance, answer:
What node owns it?
What purpose does it serve?
What data does it collect?
What inferences can it generate?
Who can access the records?
Who can challenge or delete them?
What happens offline?
What happens if the appliance is stolen?
What happens when the appliance is retired?
Can people opt out?
Can this work with less data?
Can this work without identifying people?
Can this be symbolic or aggregate instead?
Can this ever make decisions about people?
If the appliance cannot answer these questions, it is not ready for implementation.
Pancakes appliances should make communities more capable of remembering, caring, coordinating, and governing themselves.
They should not make communities more capable of surveilling, ranking, controlling, or extracting from their members.
The appliance model is successful only if it makes local life more humane.