Proposed
Initial applications:
Companion to:
This document defines an architecture in which a small, continuously available Pancakes node can use language-model reasoning without hosting the model itself.
The node hosts the application, permissions, data, context assembly, workflows, and durable records. A separate inference backend supplies compute-intensive text generation. The resulting system can reason about Pancakes work and the activity or condition of the node while remaining independent of a particular model, GPU host, or inference provider.
The central deployment decision is:
The Pancakes node owns context, authority, and action. A replaceable inference backend processes bounded reasoning requests.
This permits a modest CPU Droplet to remain online continuously while capable models run elsewhere only when needed.
The first system should support two related areas of assistance.
The assistant may help a person understand and organize work represented in the node, including:
The assistant may help an authorized steward understand and manage the deployment, including:
The assistant should be useful even when it is read-only. Acting on the node is a separate capability with stricter controls.
This document defines:
It does not define:
Pancakes applications consume stable node capabilities rather than depend on particular servers, databases, or deployment topologies. Language-model support should follow the same rule.
The architecture preserves the established division of responsibility:
Nodes govern.
Capabilities provide behavior.
Reference services describe the world.
Information sources observe the world.
Pitchfork accounts.
Products compose capabilities.
Clients present experiences.
Artificial intelligence does not replace any of these layers. It consumes explicitly selected outputs from them and returns interpretations or proposals.
The architecture distinguishes three responsibilities that should not be collapsed into one chatbot process.
Inference turns a bounded prompt into generated output. It is a computational service and should know as little as possible about the internal organization of the node.
Node reasoning selects permission-appropriate context, identifies the task, constructs a grounded request, validates the response, and relates the result back to node records.
Node action changes state. It uses ordinary node capability APIs, permissions, validation, confirmation, and audit. Inference output never constitutes authorization.
This produces the governing rule:
The model may propose. The node decides whether the proposal is valid and authorized. A person or approved policy decides whether it will be executed.
flowchart TD
U["Authorized user"] --> A["Work or steward assistant"]
A --> R["Node reasoning service"]
R --> X["Permission-filtered context"]
R --> I["Inference capability"]
I --> B["Replaceable model backend"]
R --> P["Validated proposal"]
P --> G["Confirmation and policy gate"]
G --> N["Ordinary node capability API"]
The always-on Pancakes node is the trusted application boundary. A remote inference backend is a scoped processor outside that boundary unless it is operated locally by the same node steward.
Clients present task-oriented experiences rather than an unrestricted command line for the model.
Initial experiences may include:
Clients do not store inference credentials and do not query internal databases directly.
The Node Interface is the stable boundary between assistant clients and node services. It provides:
Authentication and authorization occur before context is assembled or sent to inference.
The Node Context Service constructs a bounded representation of the node for a particular task and requester. It does not give the model unrestricted database or filesystem access.
Possible context sources include:
Every context item should contain:
The service should prefer structured projections over raw records. For example, it should provide a backup-status projection rather than access to backup archives, and a bounded error record rather than an entire application log.
The assistant may reason only from information the current task is permitted to use.
The normal rule is:
requester identity
-> task permission
-> permitted source set
-> bounded projection
-> inference request
Administrative access to one class of node information does not imply permission to disclose unrelated personal information to a model. A steward investigating database health does not thereby gain an AI-readable projection of private journals, health information, or household activity.
AI-specific disclosure scopes should be narrower than ordinary read permissions where appropriate. The node may permit a person to view a record while prohibiting that record from being sent to an external inference service.
The Node Reasoning Service converts a user request into a governed reasoning task. It is responsible for:
Initial task types may include:
answer_work_question;summarize_project_state;summarize_node_activity;explain_operational_status;investigate_incident;prepare_work_plan;review_proposed_change;propose_maintenance_procedure.Each task type declares permitted data classes, required projections, output schema, model limits, retention behavior, and whether action proposals are allowed.
The inference capability is a reusable infrastructure capability. It accepts a provider-independent generation request and returns a normalized response.
Its responsibilities are:
It must not:
A backend adapter translates the stable inference contract into a particular runtime API. Provider-specific fields remain inside the adapter.
The rest of the node uses service-level aliases such as:
node-fast
node-reason
node-second-opinion
An alias describes an intended service level rather than a vendor or model. Its exact binding is deployment configuration and is recorded with every result.
The backend loads a language model and performs generation. It may be:
The backend is replaceable. It does not own user identity, permission state, node context, action authority, or durable work records.
The Proposal and Action Gateway is optional and should not be part of the first read-only deployment.
When enabled, it accepts typed proposals rather than arbitrary model-generated commands. A proposal might request:
The gateway:
The model never receives a general shell, database connection, unrestricted filesystem tool, or administrator credential.
A context envelope is the complete, reviewable disclosure sent for one reasoning task.
An illustrative envelope is:
{
"task_type": "explain_operational_status",
"request_id": "req-...",
"requester_scope": "node.steward.read",
"policy_version": "node-reasoning-v1",
"question": "Why have document validation jobs been delayed?",
"context": [
{
"source_id": "ctx-001",
"source_type": "job_status_projection",
"observed_at": "2026-08-23T16:00:00Z",
"fresh_for_seconds": 60,
"classification": "node_internal",
"provenance": "scheduler-capability",
"content": {
"queue_depth": 14,
"active_workers": 0,
"last_worker_error": "worker unavailable"
}
}
],
"output_schema": "node-explanation-v1",
"limits": {
"max_output_tokens": 1500,
"temperature": 0.1
}
}
The context envelope should be inspectable by an authorized user. It establishes what the model was allowed to know and makes later review possible.
The model should return structured distinctions between source-backed observations, interpretations, uncertainty, and proposals.
An illustrative result is:
{
"request_id": "req-...",
"status": "completed",
"model_alias": "node-reason",
"backend_binding": {
"provider": "configured-backend",
"model": "exact-model-and-variant",
"adapter_version": "1"
},
"policy_version": "node-reasoning-v1",
"result": {
"observations": [
{
"statement": "No workers are active while fourteen jobs are queued.",
"source_ids": ["ctx-001"]
}
],
"interpretations": [
{
"statement": "The unavailable worker is the likely immediate cause of the delay.",
"confidence": "high",
"source_ids": ["ctx-001"]
}
],
"unknowns": [
"The supplied context does not identify why the worker became unavailable."
],
"proposals": [
{
"proposal_type": "inspect_worker_health",
"target": "document-validation-worker",
"requires_confirmation": false
}
]
},
"finish_reason": "stop"
}
The node validates the result against a local JSON Schema. Unknown context identifiers, unsupported proposal types, malformed output, and truncation produce an incomplete result rather than a successful one.
sequenceDiagram
participant U as Authorized user
participant A as Assistant
participant C as Context service
participant R as Reasoning service
participant I as Inference backend
U->>A: Ask about work or node state
A->>R: Submit typed task
R->>R: Authorize task and disclosure
R->>C: Request scoped projections
C-->>R: Provenanced context envelope
R->>I: Bounded reasoning request
I-->>R: Structured result
R->>R: Validate sources and schema
R-->>A: Explanation or proposal
A-->>U: Present result and uncertainty
If a user chooses to act on a proposal, that begins a separate authorization and execution flow.
The assistant may:
The assistant may not independently:
A larger or more capable model does not receive broader authority. Model capability and node permission are independent.
The assistant does not possess a complete internal representation of the node. It reasons from a task-specific projection assembled at a particular time.
Every response should make clear:
For time-sensitive node management, the reasoning service should refresh critical status immediately before presenting or executing a proposal.
The remote backend is outside the node’s primary trust boundary unless it is operated by the same steward under equivalent controls. TLS protects data in transit but does not prevent the backend operator from processing plaintext prompts.
Every outbound request is therefore a governed disclosure.
The existence of information in the node does not make it available to the assistant. Identity, permissions, purpose, data classification, and backend policy are evaluated before a projection is created.
The system should enforce:
No inference without a permitted projection.
No action without a separate permission check.
The reasoning service should send:
It should not send by default:
Every context source and backend configuration should declare supported data classes.
| Data class | Examples | Default external-inference policy |
|---|---|---|
| Public | Published Pancakes documentation | Permitted |
| Project internal | Work plans, nonsecret configuration metadata | Permitted only by project policy |
| Node internal | Health, jobs, deployment state, audit summaries | Permitted only to an approved backend |
| Personal | Private tasks, journals, household records | Denied by default |
| Sensitive or regulated | Health, dependent, financial-vulnerability, identity records | Denied without a separately approved design |
| Secrets | Credentials, keys, recovery material | Never disclosed |
Local inference may permit tasks that external inference does not, but local processing does not remove ordinary user-permission requirements.
Provider credentials remain on the node and are available only to the inference adapter. They must not be:
Operational logs should contain request IDs, task types, model bindings, timing, token counts, disclosure classes, and error categories. Full prompts and responses should not be placed in infrastructure logs.
Reasoning records may be retained in application storage under node policy. A retained record should preserve the context envelope, output, model and policy versions, human disposition, and any resulting action record. Users should be able to see what node information was disclosed for a saved result.
Node documents, logs, messages, imported records, and external information may contain instructions intended to manipulate the model.
The reasoning service should:
The public interface should expose only the reverse proxy and application endpoints. Databases, internal capability endpoints, and any self-hosted model endpoint remain private. Outbound inference traffic should be restricted to configured backend destinations where practical.
Remote inference can fail independently of the node.
The inference capability should support:
available, degraded, and unavailable;Core node operation must not depend on model availability. Capability status, ordinary search, deterministic checks, dashboards, audit access, backups, and manual administration remain usable without inference.
The system must not interpret a timeout, refusal, malformed response, or absent warning as evidence that the node is healthy.
flowchart LR
B["Browser"] -->|HTTPS| D["Pancakes Droplet"]
D --> A["Assistant and node services"]
A --> S["Local node data and projections"]
A --> C["Inference adapter"]
C -->|TLS API| H["Hosted inference"]
This is the simplest continuously available deployment. A small CPU Droplet hosts the node, assistant, and context services. The remote backend charges per use and requires no model operations on the node.
The inference adapter may target a GPU virtual machine created for evaluation sessions, large work summaries, or maintenance investigations. The GPU machine hosts only the model runtime and a private authenticated API.
The machine should be disposable:
A permanent GPU backend becomes reasonable only when sustained usage, privacy requirements, latency, or API expenditure justify its operational burden. It remains a replaceable service and does not become the location of the node’s durable state.
A node may satisfy the same inference contract with a small local model. Local inference improves privacy, offline operation, and cost predictability, but provides less reasoning capacity and competes for node CPU and memory.
Tiny models may be especially useful for:
Applications do not need to know which topology is active.
For one or a few users, the always-on node can remain modest because it does not load the primary language model.
A practical initial shape is:
2 shared vCPU
4 GB RAM
80-100 GB SSD
Ubuntu LTS
A 1-vCPU, 2-GB node may be sufficient for a demonstration with strict concurrency and memory controls. Four gigabytes provides safer headroom for the operating system, web application, Git working trees, SQLite indexes, background jobs, and deployment operations.
The remote backend determines model capacity. It may range from a metered API to a GPU host sized for the selected model. That decision remains outside the node contract.
The first implementation does not require microservices. One deployable Python application may contain clear internal modules for:
authentication and permissions
assistant workflows
context projections
task orchestration
inference capability
backend adapters
proposal validation
result storage
audit records
A reverse proxy terminates HTTPS and forwards requests to the application server. SQLite is appropriate for early personal or internal use. A background worker may be added for asynchronous reasoning without splitting the entire application into independent services.
The architectural boundaries should be preserved in code even when they share one process.
The design uses several cooperating capabilities rather than treating all AI behavior as one capability.
| Responsibility | Architectural role |
|---|---|
| Inference | Infrastructure capability providing model access |
| Context projection | Node service enforcing provenance, permission, and minimization |
| Node reasoning | Reusable orchestration over projections and inference |
| Work assistant | Product or client composition for Pancakes project work |
| Steward assistant | Product or client composition for node operations |
| Action gateway | Optional controlled bridge to ordinary node capability APIs |
This allows inference to be reused without granting every inference consumer access to node-management information.
An illustrative manifest is:
capability: inference
version: 1
category: infrastructure
operations:
- generate_structured
- report_status
required_capabilities:
- identity
- permissions
- audit
optional_capabilities:
- scheduler
- notifications
permission_scopes:
- inference.use
- inference.use_node_internal
- inference.admin
data_classes:
- public
- project_internal
- node_internal
features:
text_generation: true
structured_output: true
images: false
audio: false
training: false
direct_node_actions: false
Backend configuration is not part of the public manifest. Capability discovery reports supported operations and availability without exposing credentials or unnecessary provider details.
Reasoning behavior can change when the model, quantization, prompt policy, runtime, context projection, or provider changes. Each saved result should retain:
Changing a model alias or reasoning policy is a controlled deployment change. It should be tested against a Pancakes-specific regression set before becoming the default.
The regression set should include:
Evaluation should measure factual grounding, source validity, distinction between observation and inference, unsafe disclosure, false alarms, missed problems, proposal safety, schema compliance, latency, and cost. General model benchmarks are secondary.
Language-model reasoning should complement rather than replace ordinary system logic. The node should determine directly:
The model may interpret these facts, relate them to other context, or explain them to a person. It should not manufacture basic operational truth that the node can calculate deterministically.
The first deployment is successful when:
The following decisions should be made through prototyping:
Remote inference should extend a Pancakes node without becoming its governor, observer, or administrator.
The node remains the governed home of identity, permissions, context, durable records, and action. The model receives a bounded projection, returns a fallible interpretation, and holds no independent authority. This separation allows Pancakes to reason about its work and operational condition without requiring an expensive always-on GPU, exposing the node indiscriminately, or making one model provider part of the node’s permanent architecture.