Architecture
How information should move through a business.
What does the Architecture category cover?
Single source of truth, event-driven operations, workflow ownership, and why information should never change hands manually.
What Architecture covers
Architecture is the shape of how information moves through a business: what gets recorded first, which system owns each fact, how a record travels from lead to job to invoice, and what is supposed to happen when two systems disagree.
Most operational pain that gets blamed on staff is actually architectural. Information changes hands too many times, the same fact is stored in three places, and reconciling them becomes somebody's unofficial job. These pages describe the patterns that avoid that — single ownership, event-driven handoffs, immutable identifiers, and soft deletes rather than destructive ones.
The category is written for owners and operators, not engineers. You do not need to implement any of it yourself, but you do need to recognize when a proposed setup guarantees future cleanup work.
What you'll learn
- Why information should never change hands manually
- What single ownership of a fact means in a multi-system stack
- How stable identifiers keep history intact through a lifecycle
- Why deleting data destructively is almost always the wrong default
Pages in Architecture
Single Source of Truth
A single source of truth means every fact has one authoritative home. Copies are views, never originals — which is what ends version arguments.
ReadInformation Should Never Change Hands
Every manual handoff is a chance to lose information. Well-built systems move the record forward instead of re-entering it.
ReadEvent-Driven Business Systems
In an event-driven business, something happening triggers what happens next — instead of relying on someone remembering to start it.
ReadHuman → Automation → AI
The correct order for building operations: define the human process, automate the deterministic parts, then apply AI to what remains.
ReadWhy AI Needs Structured Data
Structured data gives AI something to be right about. Without stable records, identifiers and relationships, output is confident guesswork.
ReadWorkflow State vs Business State
Business state is what is true. Workflow state is where work has reached. Confusing the two is why status fields lie and reports disagree.
ReadWhy Context Matters
Context is the surrounding information that makes a single fact meaningful. Without it, software shows data and AI produces plausible but wrong answers.
ReadAI Permissions and Tenant Boundaries
Operational AI must inherit the signed-in user's permissions and stay inside one organization's data. How tenant boundaries and role checks are enforced.
ReadAI Audit Evidence and Persisted Results
How to prove an AI action really happened: persisted records, actor attribution, step-level execution traces and logged failures — not chat transcripts.
ReadAuthentication vs Authorization
Authentication proves who someone is. Authorization decides what they may do. Why conflating the two is the most common access-control failure in business software.
ReadWhat Is Multi-Tenant Isolation?
Multi-tenant isolation is the guarantee that one organization's records can never surface inside another's. How it is enforced and how to verify it.
ReadServer-Derived Organization Identity
A client can claim any organization it likes. Why the organization on a write must be resolved from a verified token or signed provider identity, never from the request.
ReadRoles vs Capabilities
A role is who someone is in the organization. A capability is a specific thing that may be done. Why mature permission systems keep the two separate.
ReadNavigation Visibility Is Not Authorization
Removing a link from the sidebar changes what a user sees, not what they can do. Why interface visibility and backend permission must be enforced separately.
ReadWhat Is Row Level Security?
Row Level Security moves the access decision into the database, so a forgotten filter in application code returns nothing instead of everything.
ReadBuilder Plane vs Runtime Plane
The plane that configures a system and the plane that runs a business are different security domains. Why they should never share a permission model.
ReadHuman Actors vs Machine Actors
When AI agents, webhooks and scheduled jobs write to your records, 'who did this' stops being obvious. How to model machine actors without losing accountability.
ReadAudit Attribution and Correlation IDs
An audit trail that records what changed but not who caused it, or that cannot connect related writes, is a list of events rather than an explanation.
ReadFrequently asked questions
Why does data end up duplicated across systems?
Because no system was designated as the owner of that fact. When two systems can both create a customer, both eventually will, and neither knows which record is correct.
What is a single source of truth in practice?
One system holds the authoritative version of each fact; every other system reads from it rather than keeping its own editable copy.
Why do good architectures avoid hard deletes?
Because deleted records take history, references and financial context with them. Marking a record inactive preserves the trail while removing it from daily use.