Engineering Principles for Non-Engineers
12 System Design Patterns from the Second Brain Architecture
Category 1: Human-Centric Design
Principle 1: Reduce Human's Job to One Reliable Behavior
The Rule: If your system requires three behaviors, you don't have a system—you have a self-improvement program.
Application:
Human does: Capture to Slack (1 behavior)
System does: Classification, filing, surfacing, review generation
Anti-pattern: Requiring users to capture AND categorize AND tag AND review regularly. Each additional behavior reduces adoption probability multiplicatively.
Design Test: Can you describe the user's responsibility in one sentence with one verb?
Principle 2: Default to Safe Behavior When Uncertain
The Rule: A real system must know how to fail gracefully.
Application:
if confidence < 0.6:
log_to_review_queue() # Safe: no pollution
ask_for_clarification() # Safe: human decides
else:
file_to_database() # Only when confident
Anti-pattern: Filing everything regardless of confidence, then requiring cleanup.
Design Test: What happens when the system isn't sure? If the answer involves polluting the database, redesign.
Principle 3: Design for Restart, Not Perfection
The Rule: Assume users will fall off. Life happens.
Application:
- No guilt-inducing backlog accumulation
- "Don't catch up, just restart" as explicit policy
- 10-minute brain dump re-engagement path
- System continues functioning during user absence
Anti-pattern: Systems that create cleanup debt, making restart feel overwhelming.
Design Test: If a user disappears for 2 weeks, what's the re-engagement friction? Should be < 15 minutes.
Category 2: Architectural Separation
Principle 4: Separate Memory from Compute from Interface
The Rule: Each layer has one job. They connect through clear boundaries.
Application:
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ INTERFACE │ → │ COMPUTE │ → │ MEMORY │
│ (Slack) │ │(Zapier+AI) │ │ (Notion) │
└──────────────┘ └──────────────┘ └──────────────┘
Swappable: Swappable: Swappable:
- Teams - Make - Airtable
- Discord - n8n - Coda
- Custom UI - Different LLM - Supabase
Benefits:
- Portability: Change one layer without rebuilding
- Testing: Verify each layer independently
- Vendor flexibility: Avoid lock-in
Anti-pattern: Obsidian for non-engineers (local files require sync plumbing that breaks abstraction).
Principle 5: Build One Workflow, Then Attach Modules
The Rule: Core loop first. Optional capabilities later.
Core Loop (build this first):
Capture → Classify → File → Daily Digest → Weekly Review
Modules (add after trust established):
- Voice capture integration
- Calendar-based meeting prep
- Email forwarding to inbox
- Birthday/anniversary reminders
- Project deadline alerts
Anti-pattern: Building all features before validating the core loop works.
Design Test: Can you draw the minimum viable loop in 5 boxes? If not, you're over-engineering.
Category 3: Data & Schema Design
Principle 6: Keep Categories and Fields Painfully Small
The Rule: Richness creates friction. Friction kills adoption.
Application:
| Database | Recommended Fields | Not More Than |
|---|---|---|
| People | 5 fields | 7 fields |
| Projects | 5 fields | 6 fields |
| Ideas | 4 fields | 5 fields |
| Admin | 4 fields | 5 fields |
Categories: 4 total (People, Projects, Ideas, Admin). Resist expansion.
Anti-pattern: Starting with 10 categories because "my work is complex."
Design Test: Can a 5-year-old understand your category names?
Principle 7: Use Next Action as the Unit of Execution
The Rule: Store actions, not intentions.
Good vs Bad:
| Intention (Bad) | Action (Good) |
|---|---|
| "Work on website" | "Email Sarah to confirm copy deadline by EOD Friday" |
| "Finish proposal" | "Draft executive summary section (30 min block)" |
| "Handle client feedback" | "Schedule 30-min call with Alex to review revision 3" |
Application: Classification prompt must extract concrete, executable next actions from vague inputs.
Design Test: Could you do this action in the next 30 minutes if you had to? If not, decompose further.
Principle 8: Prefer Routing Over Organizing
The Rule: Humans hate organizing. AI is good at routing.
Traditional Approach (fails):
Human captures → Human decides folder → Human maintains hierarchy
Routing Approach (works):
Human captures → AI routes to stable bucket → Human never organizes
Application: Fixed 4-bucket taxonomy. AI decides routing. User just captures.
Anti-pattern: Giving users a tagging system and expecting them to use it consistently.
Category 4: Trust Engineering
Principle 9: Build Trust Mechanisms, Not Just Capabilities
The Rule: Capability = "it does X." Trust = "I believe it does X correctly because Y."
Trust Mechanisms:
| Mechanism | Purpose |
|---|---|
| Inbox Log | Shows what happened (transparency) |
| Confidence scores | Shows certainty level (calibration) |
| Fix button | Shows corrections are easy (control) |
| Confirmation replies | Shows what was filed (verification) |
Capability Without Trust: System files notes automatically. Capability With Trust: System files notes, logs every action, shows confidence, makes fixes trivial.
Design Test: If something goes wrong, can the user trace what happened and fix it in < 2 minutes?
Principle 10: Treat Prompts Like APIs, Not Creative Writing
The Rule: Reliable beats creative in automated systems.
API-Style Prompt:
You are a classification system. Given input text, return JSON only.
Schema:
{
"category": "people" | "projects" | "ideas" | "admin",
"title": "string (max 50 chars)",
"confidence": 0.0-1.0,
"extracted_fields": { ... }
}
Rules:
- Return ONLY valid JSON
- No explanation, no markdown
- If uncertain, set confidence < 0.6
Input: {user_message}
Anti-pattern: "Please help me categorize this thoughtfully and explain your reasoning..."
Design Test: Is your prompt output parseable by JSON.parse() without any cleanup?
Category 5: Output Design
Principle 11: Make Outputs Small, Frequent, and Actionable
The Rule: Non-engineers want a top-3 list that fits on a phone screen.
Constraints:
| Output | Word Limit | Frequency | Format |
|---|---|---|---|
| Daily digest | ~150 words | Every morning | 3 actions + 1 insight |
| Weekly review | ~250 words | Every Sunday | Summary + 3 next-week actions |
| Confirmation | ~30 words | Per capture | Filed to X, confidence Y |
Why Small:
- Reduces cognitive load
- Increases read-through rate
- Improves follow-through
- Builds trust through consistent delivery
Anti-pattern: Weekly 2,000-word analysis that no one reads.
Principle 12: Optimize for Maintainability Over Cleverness
The Rule: Moving parts are failure points.
Maintainability Checklist:
- Fewer tools (4 max in the stack)
- Clear logs (every action visible)
- Easy reconnects (5-minute fix for auth issues)
- Minimal custom code (prefer no-code where possible)
- Documented workflows (someone else could fix it)
Anti-pattern: Beautiful, elegant system with 12 integrations that breaks mysteriously.
Design Test: If your Slack token expires, how long to fix? Target: < 5 minutes.
Principle Summary Matrix
| # | Principle | Category | Key Metric |
|---|---|---|---|
| 1 | One reliable behavior | Human-Centric | User actions ≤ 1 |
| 2 | Safe defaults when uncertain | Human-Centric | Low-confidence → queue |
| 3 | Design for restart | Human-Centric | Re-engagement < 15 min |
| 4 | Separate memory/compute/interface | Architecture | Layers independently swappable |
| 5 | Core loop → modules | Architecture | MVP = 5 components |
| 6 | Minimal categories and fields | Data | Categories ≤ 4, fields ≤ 6 |
| 7 | Next action as execution unit | Data | All actions executable |
| 8 | Route, don't organize | Data | Zero user taxonomy decisions |
| 9 | Trust mechanisms | Trust | Errors traceable in < 2 min |
| 10 | Prompts as APIs | Trust | Output = valid JSON |
| 11 | Small, frequent outputs | Output | Daily ≤ 150 words |
| 12 | Maintainability > cleverness | Output | Auth fix < 5 min |
Application to Other Systems
These principles generalize beyond second brains to any human-AI workflow system:
CRM Automation: Principles 1, 4, 6, 8, 10 Meeting Notes Processing: Principles 1, 5, 7, 11, 12 Email Triage: Principles 2, 3, 8, 9, 10 Task Management: Principles 3, 6, 7, 11, 12 Knowledge Base Maintenance: Principles 4, 5, 6, 8, 9