Clippy

Business Evolution

A framework for AI-assisted collaboration.

Developers are using AI to write code. Operators are using AI to run their businesses. Teams are using AI to draft plans, write policies, and make decisions. Almost none of it is structured, reviewed, or visible to the rest of the team. Business Evolution is how p6k closes that gap — a universal, structured process for how people and AI collaborate to produce pluggable, reviewable output.

The promise

Something fundamental is happening in how work gets done. People are using Claude, ChatGPT, and Copilot to do the actual job — and the output of that work lives in chat logs nobody can see, track, approve, or improve. Collaboration is missing. Visibility is missing. Review and approval are missing.

This is not just a software development problem. It is a structured collaboration problem. Whenever multiple people work with AI to produce something — code, configuration, documentation, or compliance forms — the same gaps appear. Business Evolution is the answer.

The flow

Seven stages. One universal loop.

Every cycle runs the same shape. Only the output changes.

Business Evolution as a loop — conversation, knowledge, plan, spec, generate, publish, evolve — with review gates on the transitions between stages.

The stages

Inside the loop.

Each stage produces a specific artifact. Review happens on the edges between them.

  1. Stage 1 of 7 — Conversation. Two stick figures sit across from each other; one asks "but why?" while the other takes notes. A side panel lists what it is (a real talk to find out what you actually need), what you bring (a fuzzy idea or a real pain), what you leave with (what matters and what is still unclear), and an example ("claim intake takes forever" → a list of bottlenecks).

    AI-driven, multi-person information capture. The system asks questions. The people who run the work answer them. The conversation exposes the business process, requirements, or design — not in a documentation sprint, but at the point of work.

  2. Stage 2 of 7 — Knowledge. A stick figure draws a diagram of CLAIMS, CLAIMIES, POLICIES, and PEOPLE on a board while another holds a "How We Work" book. The side panel: writing down how your business actually works; you bring how you really do the job today; you leave with a simple picture of the moving parts; example links Claim ↔ Claimant ↔ Policy ↔ Adjuster.

    The captured information is organized into a model of the domain — root objects, relationships, ontology. Descriptive and long-lived: the world as it is. The raw material of the conversation becomes something a machine, and the rest of the team, can reason about.

  3. Stage 3 of 7 — Plan. A stick figure holds a clipboard reading "What we'll build first" with two checked items and one unchecked. The side panel: deciding what we'll actually build first; you bring your priorities and your "not yet"s; you leave with a short list small enough to finish this week; example: "intake form. Email the adjuster. Skip the portal."

    Knowledge plus new conversation is scoped into a changeset — which units we will change this iteration, in what order, why now. Not the per-unit prescription yet; the slice of work the next pass will operate on.

  4. Stage 4 of 7 — Spec. A stick figure writes a precise contract for one unit in the changeset — inputs, outputs, edge cases, acceptance criteria. One Plan fans out to one-or-many Specs.

    For each unit in the changeset, write the precise prescription — the contract Generate will consume. The artifact’s name is process-defined: a Playbook for a p6k app, a SPEC.md for source code, an SOP draft for compliance.

  5. Stage 5 of 7 — Generate. p6k turns each Spec into actual artifacts: configs today, code and documents tomorrow.

    Each Spec is rendered into artifacts. Configurations today. Code, documents, compliance forms tomorrow. The output type is pluggable — defined by the process itself, not hardcoded into the platform.

  6. Stage 6 of 7 — Publish. Generated artifacts move from draft to canonical: configs deployed, code merged, documents published.

    Artifacts go live. Configs get deployed, code gets merged, documents get published. Work moves from draft to canonical with a single, shared process — no matter what the output is.

  7. Stage 7 of 7 — Evolve. A wide panel: at left, a stick figure stares at a wall of sticky notes labeled WORKS, BROKE, WEIRD, WHY?, then a bold "FOREVER" arrow loops back toward step 1. In the middle, the info card. At right, a horizontal timeline — MONTH 1, MONTH 3, MONTH 6, YEAR 2 — showing the same business app getting better each pass.

    Business Evolution is a loop, not a project. Every pass — new conversation, new knowledge, new plan, new spec — produces the next version of how the business runs. The platform keeps up with you as you grow, as regulations change, as the team learns the job better. Snapshots go stale the day they are written; living systems do not. The Evolve stage is what turns a single round of work into a permanent capability: the operation never has to be reconstructed, only refined. Month after month, year after year, the same loop produces a sharper, more accurate, more useful version of how your business actually works.

Review is a gate, not a stage

The stages describe states of an artifact. Review is what happens between stages — a gate that verifies the outgoing artifact before the next stage begins. Every transition passes through one: Conversation → Knowledge, Knowledge → Plan, Plan → Spec, Spec → Generate, Generate → Publish. Same approval discipline, same sign-off by the right people — located in the edges of the flow, not its stages. The upshot: governance is continuous, not a stop at the end.

Same flow. Different output.

One pattern. Every kind of structured work.

The Business Evolution process is universal. Three things are process-defined: the Plan’s changeset shape, the Spec artifact (Playbook, SPEC.md, SOP draft), and the Generate output (configs, code, documents). That is what makes it a platform, not a feature.

Same box, different day: humans feed the loop, and out come four kinds of artifacts — insurance app config, p6k's own code, biotech SOPs, and FDA paperwork.

Plan · the iteration’s scope (which processes, in what order)

Spec · a Playbook per business process

Output · p6k app configurations

A specialty insurance brokerage

An owner-operator has a conversation with p6k about how his business runs. His team contributes answers and fills in gaps. He then scopes a Plan for this round — renewal first, quote intake and commissions next. p6k co-authors a Playbook for each process in scope. Out the other side come tables, workflows, pages, and business rules — software tailored to his company without a consultant in the room.

Plan · the iteration’s ITIL process scope

Spec · ITIL-shaped Playbooks

Output · p6k app configurations

A managed services provider

Same Business Evolution flow, different context. The Plan scopes which ITIL processes to model this iteration. Specs are ITIL-shaped Playbooks — incident, change, problem, request — customized to the MSP’s operational model. The output is still p6k configurations.

Plan · a changeset log of which modules change this iteration

Spec · SPEC.md per module

Output · Source code

The p6k team building p6k

Same conversation → knowledge → plan → spec → generate loop. The Plan records what is changing this iteration and why now. For each module in scope, the Spec is a co-located SPEC.md describing the contract, edge cases, and acceptance criteria. The output is TypeScript. Architecture decisions are captured collaboratively, reviewed at every gate, and turned into a working codebase.

Plan · audit-finding-driven changeset (which SOPs, why now)

Spec · SOP / regulatory submission drafts

Output · SOPs, PDFs, compliance forms

A biotech operations team

p6k converses with stakeholders. Process knowledge is organized into a domain model. When an audit finding or regulatory change demands action, the team scopes a Plan — which SOPs to revise, in what order. Each SOP draft is co-authored as a Spec, then generated into published documents and regulatory submissions. Reviewers approve before publication.

The pitch, in one paragraph

Business Evolution is the framework the industry needs but does not yet have a name for. A structured process with defined roles, versioned artifacts, review ceremonies, and continuous improvement. Not ad-hoc prompting, but a shared vocabulary for teams working through AI. This is not a feature of p6k. It might be p6k.

Proof points

  • Universal process. Pluggable output. Configs, code, documents, compliance — same flow, different artifact.
  • Multi-person by design. Contributors, reviewers, and approvers each have clear roles and visibility.
  • Governance built in. Every artifact is versioned, reviewed, and traceable — not buried in a chat log.
  • Continuous improvement. The evolve step means the system gets better every time the business runs it.

The bet

The operating system for AI-native teamwork.

Most AI companies are building features. p6k is building the platform whose core primitive is structured AI-assisted collaboration. If Business Evolution is right, it changes what a business operating system can be.