Book I · The Field Guide
The Capability Catalog
[!machine] Around 1455, Johannes Gutenberg printed a Bible in Mainz, Germany. Each page was set by hand — each letter a physical block of metal type, the press itself a wooden-screw mechanism adapted from the wine and olive presses common in the Rhine Valley. The Gutenberg Bible was a marvel of engineering, and it was also fixed. If you wanted to print a different book, you reset every letter. If you wanted to print in a different language, you carved new type. The press could do one extraordinary thing: reproduce the specific arrangement of symbols its operator had manually composed.
Five and a half centuries later, the cockpit operates on the opposite principle. It does not do one thing. It does whatever its catalog says it can do. And the catalog grows by writing specifications, not by rebuilding the press.
This distinction — between a tool and a platform — is the subject of this chapter. The cockpit is not a tool. It is an extensible platform. And extensibility is the solopreneur's ultimate competitive advantage.
What a Capability Is
A capability is something the system can do. Not something it knows — something it does. The distinction is structural and it matters.
Knowledge is what the search engine provides. When you ask "what does Chapter 11 say about reciprocity?" — the engine finds the passage, ranks it by relevance, and delivers it. That is retrieval. The system is not doing anything new. It is finding something that already exists.
A capability is an action. Compose an article. Generate a hero image. Send a follow-up email. Create a lead in the CRM. Schedule a deferred job. These are verbs. They change the state of the world. After the capability executes, something exists that did not exist before — a draft, an image, a sent message, a database record.
Each capability in the catalog is defined by four properties:
| Property | What It Specifies | Why It Matters |
|---|---|---|
| Name | What the tool is called | So the AI can select it by intent match |
| Description | What it does, in plain language | Documentation IS selection criteria |
| Parameters | What inputs it needs | So the AI knows what to ask, what to infer |
| Execution surface | Where it runs — server, browser, or external | So the system routes the job to the right runtime |
When you type a request in the chat — "write me an article about positioning for neurodivergent CTOs" — I read your request, consult the catalog, match your intent to the best-fitting capability, extract the parameters from your sentence, and invoke the tool. You did not need to know the tool's name. You did not need to know its parameter schema. You described what you wanted in human language, and the catalog compiled it into a machine instruction.
This is the interface the Architect described in Chapter 9. The question is the program. The catalog is the compiler.
The Current Inventory
The cockpit currently operates over forty registered capabilities, organized into families:
Content Production. Compose articles from a brief. Generate hero images from a thesis statement. Run editorial QA against the style guide. Publish to the journal with proper frontmatter, meta tags, and canonical URLs. The complete content pipeline — from "I have an idea" to "it's live, indexed, and shareable" — runs through capabilities in this family.
CRM and Relationships. Create leads from QR scans. Update deal stages as conversations progress. Manage referral lifecycles within the ordo. Track organizations and map contacts to companies. The trust pipeline from Chapter 13 — from handshake to active client — is a sequence of capabilities in this family.
Research and Search. Search the corpus with full-text keyword queries and semantic vector queries. Find passages, chapters, and sections relevant to any question. Return results with relevance scores, source citations, and contextual snippets. Every answer the AI gives you is grounded in
[... truncated ...]