Business Evolution

The continuous, collaborative process by which a business defines and evolves how it operates. Business Evolution is p6k’s answer to a gap nobody has filled yet: how an organization, working together and through AI, turns operational knowledge into living, executable systems that are reviewed, approved, and continuously improved. It is the most load-bearing idea in p6k.

Business Evolution is the continuous process through which an organization collaboratively defines, operationalizes, improves, and evolves how the business works — through human and AI collaboration.

The Shift

Businesses evolve constantly — new products, new hires, new regulations, new ways of working. But the operational systems meant to support them stay static. How a business actually runs lives in people’s heads, in scattered documents, in chat logs, or nowhere at all. When that knowledge does get captured, it’s a snapshot that’s stale the moment it’s written.

AI changes what’s possible — but the tooling around AI-assisted work hasn’t caught up. The gaps are visible whenever a team tries to work through AI to define how the business operates:

• Collaboration is missing — people use AI tools independently. There’s no structured way to work together through AI on a shared operational model.
• Visibility is missing — when someone has an AI-assisted conversation about how the business works, the knowledge captured is invisible to everyone else. It lives in a chat log, or nowhere at all.
• Review and approval are missing — operational knowledge needs to be verified, reviewed, and approved before it becomes canonical. Current tools have no process for this.
• Evolution is missing — even when knowledge is captured once, nothing keeps it alive as the business changes.

This isn’t a software-development problem — it’s a structured collaboration problem. Whenever people work with AI to define and operationalize how a business runs — whether the output is configuration, code, documentation, or compliance forms — the same gaps appear.

The Evolution Loop

Business Evolution is p6k’s answer to these gaps. It’s a universal, continuous, structured process where an organization and its AI collaborate to turn how the business works into living operational systems. It runs as a loop of seven stages.

Each stage carries two names: an internal name used in architecture and contributor docs (and as folder and table names), and a public label used in product UI and outward-facing material.

1. Conversation — Discover. AI-driven, multi-person information capture. p6k asks questions, multiple people contribute answers, and the conversation exposes the business process, requirements, or design. (Renamed from “Interview” 2026-05-12 for vocabulary consistency with the unit-of-work table s_ai_conversation. The shape is unchanged — structured Q&A driving toward enough captured context to move forward.)
2. Knowledge — Align. The captured information is organized into a model of the domain — root objects, relationships, ontology, the world as it is. Descriptive, long-lived, ambient: read more than written. The team aligns on a shared understanding of the domain before anything is prescribed. (Renamed from “Structure” 2026-05-14 — structure read passive next to the verbs around it; knowledge/ is more self-explanatory as a folder, and the work is honestly understanding the domain, not just imposing structure on it.)
3. Plan — Design. The organized knowledge plus new conversational input is scoped into a changeset — which units we’ll change this iteration, in what order, why now. One Plan fans out to one-or-many Specs. The Plan artifact’s shape is process-defined — in dev it’s an entry in p6k-playbook/plan/plan-details.md; in p6k apps it’s the iteration’s scope (a s_builder_artifact change record); in compliance it’s the audit-finding-driven scope. (Split out of the old “Plan” stage on 2026-05-19 — what used to be one stage was doing two jobs; this is the upper half, the changeset.)
4. Spec — Specify. For each unit in the changeset, write the precise prescription — the contract Generate will consume. The Spec artifact’s name is process-defined — in dev it’s a SPEC.md, in p6k apps it’s a Playbook, in compliance it’s an SOP draft, in an MSP it’s a process playbook. Different processes produce differently-named Specs; they all play the same structural role. (Renamed from “Plan” 2026-05-19 — this is the lower half, the per-unit contract.)
5. Generate — Operationalize. Each Spec is rendered into executable artifacts. The output type is pluggable — it’s defined by the process itself, not hardcoded into the platform.
6. Publish — Run. Artifacts go live. Configs get deployed, code gets merged, documents get published — the operational system is now running.
7. Evolve — Improve. This is a continuous loop, not a one-time event. Business Evolution runs again as the business grows, requirements change, or the team learns more.

Steps 3–5 are where the extensibility lives. The Plan’s changeset shape, the Spec artifact’s name, and the Generate output’s type are all process-defined. The process is universal; the vocabulary and outputs are variable.

The loop fans out and fans in, it isn’t 1:1. Many Conversations feed one-or-many Knowledge docs; accumulated Knowledge plus new conversation triggers one Plan when there’s enough to scope a change; one Plan creates, updates, or splits across one-or-many Specs; each Spec drives one-or-many Generate outputs. This shape is universal — every concrete instance below is some flavor of fan-out/fan-in, never a conveyor belt.

Internal stage names and public labels

The internal names are load-bearing — they are folder names (conversation/, knowledge/, plan/, generate/, evolve/), table and column values (s_ai_conversation, s_knowledge, stage), and the vocabulary every contributor doc uses. The public labels are for product UI and outward-facing material, where “Discover → Align → Design → Specify → Operationalize → Run → Improve” reads as the business process it is. Both name the same seven stages.

Review Is a Gate, Not a Stage

The six forward stages describe states of the artifact — Conversation, Knowledge, Plan, Spec, Generate, Publish — with Evolve looping back. Review is what happens between states: a gate that verifies the outgoing artifact before the next stage begins. Every stage transition passes through a gate:

• Conversation → Knowledge gate — “is the captured information complete enough to organize into a domain model?”
• Knowledge → Plan gate — “is our understanding of the domain right before we scope a change?”
• Plan → Spec gate — “is the changeset right before we draft per-unit contracts?”
• Spec → Generate gate — “is each unit’s contract correct before we spend cycles rendering it?”
• Generate → Publish gate — “is the artifact ready to go live?”

The two review passes we run in dev practice — reviewing a SPEC.md, then generating code, then reviewing the code — are the Spec→Generate gate (the SPEC awaiting sign-off) followed by the Generate→Publish gate (the produced code awaiting sign-off). Today’s build command formalizes both via status: needs_review (Spec gate) and status: needs_code_review (Generate gate). The earlier gates (Conversation→Knowledge, Knowledge→Plan, Plan→Spec) are implicit today; the Plan→Spec gate is enforced softly in dev by Claude Code’s plan-mode approval (ExitPlanMode) and could be formalized via a status: field on changeset entries later.

Because review is a gate rather than a stage, gate state is tracked with the stage being gated — each Plan artifact carries its own status field, and aggregate dashboards (progress, WIP) live inside generate/ because they track what’s moving through the generation pipeline. There is no separate review/ folder in the canonical playbook shape.

Root Objects: The Backbone of Knowledge

The Evolution Loop’s stages become dramatically more powerful — and more reliable — when the Knowledge stage has a universal ontology to map into. That ontology is p6k’s root objects: eight foundational entity types that every business application is built on. See root-objects for the full vision.

Without root objects, the Knowledge step is an open-ended modeling problem: the AI converses with a business owner, captures information, and then has to invent a data model from scratch. This is error-prone, inconsistent, and produces wildly different results for similar businesses.

With root objects, the AI’s job in the Knowledge stage shifts from invention to recognition — mapping what was captured onto root objects (“your clients are Organizations, your policies are Things, your claims are Work items, your premium payments are Transactions”) and adding domain-specific columns, relationships, and behaviors to each. This is the body of work the Knowledge stage does when root objects are in play; it’s not a separate stage, and the platform doesn’t model it as a sub-status — the LLM that recognizes a clients-are-Organizations mapping usually proposes the insurance-specific columns in the same pass, with no human checkpoint between them. (A formal “Classify” + “Specialize” sub-activity pair was retired on 2026-05-19 along with the broader Plan/Spec split — it was never load-bearing and only applied when root objects were in play.)

This recognition+specialization work is what separates p6k from a blank page (Notion, Airtable) and from a pre-baked domain (ServiceNow’s ITSM, Salesforce’s CRM). The root objects are universal enough to model any business, but structured enough that the AI always has a starting point. And because root objects are base tables with built-in platform capabilities (workflow for Work, timeline for Events, hierarchy for Organizations), every generated application inherits enterprise-grade features from day one.

This is Business Evolution’s secret weapon: the conversation feels natural — because it IS a conversation — but behind the scenes the AI is mapping everything onto a proven universal structure. The business owner gets a tailored application; the platform gets consistent, well-structured data.

Output Is Process-Defined

Business Evolution follows p6k’s core principles: consistency, extensibility, and reuse. The same conversation → knowledge → plan → spec → generate → publish → evolve flow applies regardless of what you’re building, with review as the gate between each pair of stages. Three things are process-defined: the Plan’s changeset shape, the Spec artifact’s name (SPEC.md in dev, Playbook in p6k apps, SOP draft in compliance), and the Generate output’s type (code, configs, PDFs, …).

This maps cleanly to the engine pattern that runs through the entire platform. The Business Evolution output is just another engine. Configs go through ConfigEngine, code goes through a CodeEngine, documents through a DocumentEngine. The CRUD+ interface still applies.

It also maps to the self-describing principle. The process itself describes what its Plan artifact is called and what its Generate output should be. The metadata drives both, just like table metadata drives the UI today.

And it maps to “apps all the way down.” The Business Evolution process for an insurance company is an app; the Business Evolution process for p6k development is an app. The output renderer is a component within that app.

Concrete Examples

The same Evolution Loop, different outputs:

Matt’s Insurance Company → p6k Configs

Matt runs a group insurance/benefits company. He currently uses a bunch of glued-together apps — Salesforce, QuickBooks, commission calculators — to run his business. In p6k, Matt signs in and p6k asks: “What does your company do?” From there, p6k has a conversation with him to expose his business processes. Other people in his org contribute answers and fill in gaps. The captured information becomes a Knowledge model of his domain (clients, policies, claims, commissions mapped onto root objects). Matt then scopes a Plan for the iteration (“this round we operationalize the renewal process; quote intake and commissions come next”) — the changeset. From the Plan, Matt and p6k co-author a Playbook for each business process in scope — quote intake, renewal, commission calculation — as Specs that prescribe exactly what should happen. Matt verifies and approves each Playbook. Those Playbooks then drive generation of p6k configurations — tables, workflows, pages, business rules.

Plan artifact: the iteration’s scope (which processes, in what order). Spec artifact: a Playbook per business process. Output: p6k app configurations.

MSP Company → p6k Configs (ITIL-flavored)

A managed services provider wants to follow ITIL but has their own way of doing things. Same Business Evolution process — conversation, knowledge, plan, spec, generate — but the context is IT service management. The Plan scopes which ITIL processes to model this iteration; the Spec artifacts are ITIL-shaped process Playbooks (incident, change, problem, request) customized to the MSP’s operational model. The output is still p6k configurations, but shaped by ITIL best practices and the company’s specifics.

Plan artifact: the iteration’s ITIL process scope. Spec artifact: ITIL-shaped Playbooks. Output: p6k app configurations.

p6k Building p6k → Source Code

The p6k team uses the same process to build p6k itself. The conversation captures architecture decisions, design requirements, and implementation needs. The Knowledge stage produces platform-level contracts (auth, data engine, UI shell). The Plan stage records each changeset in p6k-playbook/plan/plan-details.md — what’s changing this iteration, which modules it touches, why now (often the artifact of a Claude Code plan-mode approval). For each module in the changeset, the Spec stage produces a co-located SPEC.md describing the contract, edge cases, and acceptance criteria. The Generate stage takes the SPEC and produces TypeScript. Multiple engineers and designers contribute; reviewers gate each transition.

Plan artifact: p6k-playbook/plan/plan-details.md (changeset log). Spec artifact: SPEC.md per module. Output: Source code.

Illumina → Process Documents and PDFs

A biotech company needs to define, document, and maintain complex operational processes — SOPs, compliance documentation, regulatory submissions. Same Evolution Loop: converse with stakeholders, build Knowledge of their operational domain, scope a Plan when an audit finding or regulatory change demands action (which SOPs to revise, in what order), draft each SOP as a Spec, then generate the final document (PDFs, regulatory forms). Multiple people contribute domain expertise. Reviewers approve before publication.

Plan artifact: the audit-finding-driven changeset (which SOPs, why now). Spec artifact: SOP draft / regulatory submission draft. Output: Published SOPs, PDFs, compliance forms.

Multi-Person Collaboration

Business Evolution isn’t a solo activity. It’s designed for teams:

• Assignment — different people are responsible for different parts of the conversation. A CFO answers finance questions, an ops manager answers operations questions, a developer answers technical questions.
• Contribution — multiple people fill in depth across sub-topics. Not everyone needs to be in the same session.
• Review — the right people verify and approve the generated output before it goes live.
• Approval workflows — decisions get signed off by stakeholders. A configuration change that affects billing needs finance approval. A code change needs engineering review.
• Visibility — everyone can see what’s been captured, what’s been generated, and what’s pending review.

This is where the current state of AI-assisted work falls short. Most AI tools are single-user experiences. Business Evolution adds the collaboration, process, and governance layer.

What Business Evolution Provides

Business Evolution is the missing framework for humans coordinating with AI, and with each other through AI:

• Structured process — not ad-hoc prompting, but a defined flow with stages
• Defined roles — contributors, reviewers, approvers, each with clear responsibilities
• Artifacts — the generated output, versioned and traceable, not buried in chat logs
• Ceremonies — review cycles, approval gates, evolution checkpoints
• Continuous improvement — the Evolve stage ensures the operational system keeps getting better

This is not a feature of p6k. It might be p6k. The platform is a structured AI collaboration engine where the artifact type is pluggable — the operating system for AI-native teamwork.

Agentic Engineering

The industry has converged on a name for the discipline this document describes, applied to software: agentic engineering — building software with AI agents as first-class collaborators rather than as autocomplete. Business Evolution, applied to source code, is p6k’s expression of agentic engineering. Most agentic-engineering practice today is solo — a single developer with their AI. Business Evolution is what turns it into a team discipline: shared specs, shared review gates, shared artifacts, multi-person contribution at every stage.

A term-collision worth flagging. “Agentic” already appears throughout p6k with a runtime meaning — the agentic loop (internal), agent chat, tool-use, the agent test page. That’s AI behavior at execution time. Agentic engineering is a different concept: the build-time discipline of producing software with AI in the loop. Both involve agents, but they solve different problems. When this doc says “agentic engineering,” it means the discipline; when other docs say “agentic loop” or “agentic mode,” they mean the runtime feature.

Proof: We’re Already Living It

There’s an irony worth noting. These architecture docs — the conversations, the decisions captured in markdown, the iterative refinement sessions with Claude — are Business Evolution running manually. The founder converses with an AI, information becomes Knowledge in p6k-playbook/knowledge/, changesets get scoped and logged in p6k-playbook/plan/plan-details.md as Plan artifacts, each Plan fans out to per-module SPEC.md Spec artifacts, and the SPECs drive code generation. The output renderer just happens to be “markdown files plus TypeScript in a git repo.”

The platform doesn’t exist yet, and the process is already working. That’s the strongest possible signal that the idea is real. The vision is to bring this process into p6k itself, where it gains multi-person collaboration, visibility, review workflows, and the ability to generate any output type the process defines.

The bootstrapping phase produces the documentation that describes the platform that will eventually host the process that produced the documentation. That is not a bug. That is the proof.

Relationship to Existing Concepts

Business Evolution doesn’t replace anything in the current architecture. It’s a vision-level concept that frames why the architecture exists:

• AI Build Mode (ai-build-mode.md) describes the current technical design for how AI configures apps. Business Evolution is the broader vision — AI Build Mode is one output renderer within it.
• Onboarding (onboarding.md) describes the first-run experience. Onboarding is the first iteration of the Evolution Loop for a new workspace.
• Continuous Improvement (the weekly scheduler in onboarding.md) is the Evolve stage of Business Evolution.
• Workflows and Actions provide the review and approval mechanics.
• Apps All the Way Down means the Business Evolution process itself is an app, and different Business Evolution apps produce different output types.

The architecture docs describe the “what.” This document describes the “why it matters more than we initially thought.”