Core Concepts

The mental model for p6k in seven concepts. Read this before anything else in the architecture or product docs — everything downstream assumes these terms.

Workspace

A workspace is an isolated environment for a single business or organization. When a user signs up, they get a workspace. Everything — playbooks, data, users, configuration, integrations — lives within it. Workspaces are tenant-grade isolated: one company’s data never touches another’s.

A workspace is provisioned in under two minutes after signup. No sales call. No implementation kickoff. No consultant.

Business Plan

A business plan in p6k is not a pitch deck or an investor document. It is the top-level playbook for the organization — the root of a tree of playbooks. Every playbook below it (a department, a role, a process) is structurally the same kind of thing. The business plan is just the one at the top. See playbooks (internal) for the full hierarchy model.

When a user first signs up, p6k determines the right starting point:

• OOB (Out-of-the-Box) Business Plan — a pre-built plan for common business types (e.g., “marketing agency,” “plumbing company,” “SaaS startup”). Ready to use immediately, no configuration required.
• Customized Business Plan — an OOB plan with modifications based on the user’s specific answers (size, industry nuances, existing tools, regional differences).
• Guided Custom Plan — for businesses that don’t fit a template, p6k guides the user through building a plan from scratch using AI-assisted discovery. Business Evolution, running for the first time in a new workspace.

Playbook

A playbook is the core unit of p6k. It represents a structured, evolving area of work that a team owns and improves over time. Most often this is a function or role within a business (Sales, Customer Success, Marketing, Finance), but the same primitive covers sustained projects and initiatives — building a product, launching a go-to-market plan, running a long-term operational change. Anything a team owns end-to-end and refines as they learn fits here.

A playbook is not a static document. It is:

• Structured — organized into clear steps, responsibilities, and outcomes
• Executable — connected to workflows, tasks, and automations that make it actionable
• Adaptive — evolves as the business grows and learns
• AI-powered — generated, refined, and assisted by LLMs and agentic AI

Examples of playbooks:

• Sales Playbook — lead qualification, pipeline management, deal stages, follow-up cadences
• Onboarding Playbook — new hire onboarding steps, systems access, first-week checklist
• Incident Response Playbook — how to handle outages, escalation paths, communication templates
• Marketing Playbook — campaign planning, content calendar, channel strategy
• Finance Playbook — invoicing, expense management, monthly close process

Each role in the organization may have one or more playbooks. A business plan is the collection of all playbooks across the organization.

Onboarding Flow

The onboarding flow is the first experience a user has with p6k. It’s designed to be fast and frictionless:

1. Sign Up — Google Login or phone number (no lengthy forms)
2. Workspace Creation — provisioned automatically
3. Business Discovery — a short, conversational set of questions:
   • What type of business do you have?
   • How large is your team?
   • How do you plan to use p6k?
   • (Additional questions as needed based on answers)
4. Plan Selection — based on discovery, p6k recommends one of:
   • Load an OOB business plan
   • Customize an OOB plan
   • Guide through custom plan creation
5. Playbook Delivery — the user’s workspace is populated with their playbooks, ready to execute

Business Evolution

Business Evolution is p6k’s universal, continuous process for collaboratively defining and evolving how a business operates. It’s how things get created and evolved on the platform — whether that’s app configurations for a customer’s business, source code for p6k itself, or compliance documents for a biotech company.

Business Evolution runs as a six-stage loop, with Review as a gate between stages rather than a stage itself. Each stage has an internal name (used across architecture and contributor docs) and a public label (used in product and outward-facing material):

1. Conversation (Discover) — AI-driven, multi-person information capture
2. Knowledge (Align) — organize captured information into a domain model (descriptive: the world as it is)
3. Plan (Design) — turn knowledge into a prescriptive artifact for the change to make (Playbook in p6k apps, SPEC.md in dev, SOP draft in compliance — name varies by process)
4. Generate (Operationalize) — render the Plan into executable artifacts (output type is pluggable)
5. Publish (Run) — artifacts go live
6. Evolve (Improve) — continuous loop back to Conversation as the business grows, requirements change, or the team learns more

Review is what happens between stages — humans verify and approve the outgoing artifact before the next stage begins. Every stage transition passes through a review gate. See business-evolution.md — Review Is a Gate, Not a Stage.

Business Evolution is not a feature — it’s the central process pattern of the platform. The onboarding flow is the first Business Evolution cycle for a new workspace. The continuous improvement agent triggers ongoing cycles. Different Business Evolution apps produce different output types (configs, code, documents), but they all follow the same flow.

See business-evolution for the full vision.

Root Objects

Every business application, in every industry, manages the same eight foundational entities: Organizations, People, Locations, Things, Work, Events, Transactions, and Relationships. In p6k, these are not abstract categories — they are base tables that ship with the platform. Application tables extend them, inheriting common columns and platform capabilities (workflow for Work, timeline for Events, hierarchy for Organizations, and so on).

Root objects are what make p6k industry-agnostic and intelligent. When p6k interviews a business owner, the AI maps what it hears onto root objects and specializes from there — it never starts from a blank page. This is the universal data ontology behind the aiPaaS model. See root-objects for the full vision.

Roles & People

Playbooks are tied to roles, and roles are filled by people. A single person may hold multiple roles (especially in smaller organizations), and a single role may have multiple playbooks attached to it.

This separation matters because:

• As the business grows, one person’s job can be split across multiple hires without rewriting a thing
• Playbooks stay consistent even as the people filling roles come and go
• The platform can recommend when it’s time to split a role or hire for a new one
• When someone leaves, their knowledge doesn’t leave with them — it’s already in the playbook