{"database": "pub10", "table": "documents", "rows": [["codebook.md", "# pub-10 capability codebook \u2014 v0.1 (iteration 0, nothing confirmed yet)\n\n> The machine-readable twin is [codebook.json](codebook.json). `tools/business-apps/records.ts` rejects any coded feature whose capability code is not listed there.\n>\n> **Rule zero:** no SQ5 vocabulary. Capability names describe what an application offers its users, in domain-neutral language. They never use the names of any platform's primitives (SQ5's node types included), because the later coverage study (pub-9) measures SQ5 *against* this taxonomy.\n\n## 1. Meta-characteristic\n\n*The functional capability an application offers its users, independent of business domain and of implementation technology.*\n\nA capability is something a user can make the application **do** (record, route, schedule, compute, show, notify, exchange, expose). Excluded: qualities (fast, secure, scalable), deployment and licensing facts, and the business domain itself (\"for dentists\").\n\n## 2. Unit of analysis: the feature statement\n\nOne user-observable capability, in one of two forms:\n\n> **The system lets** \u27e8actor\u27e9 \u27e8action\u27e9 \u27e8object\u27e9 [\u27e8condition\u27e9] \u2014 something a user does\n>\n> **The system automatically** \u27e8action\u27e9 \u27e8object\u27e9 **when** \u27e8event\u27e9 \u2014 an automation\n\nThe pilot showed automations are common (29 of 224 statements had to be rewritten into the second form) and are a capability in their own right, so they get their own form instead of being forced into \"lets\".\n\n| Rule | Example source text | Statement(s) |\n|---|---|---|\n| One capability per statement; split conjunctions | \"Create, send and track quotes\" | lets a salesperson create a quote \u00b7 send a quote to a customer \u00b7 see a quote's status |\n| Keep conditions; they are often the capability | \"Invoices above the limit need manager approval\" | lets a manager approve an invoice whose amount exceeds a threshold |\n| The actor is a role, not a person; use \"a user\" if unstated | \"Track your inventory\" | lets a user see stock levels per item |\n| Drop marketing qualifiers | \"Blazing-fast, beautiful reports\" | lets a user view a report |\n| Not a capability \u2192 no statement (record it as a skipped excerpt) | \"Trusted by 10,000 teams\", \"GDPR compliant\", \"Self-hosted\" | \u2014 |\n| Integrations name the *kind* of exchange, not the vendor | \"Sync with QuickBooks\" | lets a user exchange accounting records with an external accounting system |\n| Automations use the second form; the actor is the system | \"Jobber automatically sends visit reminders\" | automatically sends a visit reminder to a client before a scheduled visit |\n| One capability is recorded **once per application**; keep the first excerpt | A page that lists every feature twice | one statement |\n| **Testimonials, case studies and customer stories are never evidence** | \"Acme runs multi-state payroll in under 1 hour\" | \u2014 (skip, reason `testimonial`) |\n| Claims about the **platform an app is built on** are not the app's capabilities | Template page: \"fully customizable with a drag-and-drop builder\" | \u2014 (skip, reason `platform`) |\n| IT-infrastructure administration that no business role uses | \"Access to root shell\", \"SNMP monitoring\", \"server clustering\" | \u2014 (skip, reason `deployment`) |\n| User-facing sign-in and access features **are** capabilities | \"Two-factor authentication\", \"single sign-on\" | lets a user sign in with a second factor |\n| Do not infer beyond the excerpt | \"device logging\" | \u2014 not \"lets an administrator see login devices\" |\n\nSkip reasons: `quality`, `compliance`, `deployment`, `pricing`, `social-proof`, `testimonial`, `platform`, `other`.\n\n## 3. Coding rules\n\n- A statement gets **one or more** capability codes. Use more than one only when the statement genuinely needs both (e.g. an approval that also notifies).\n- Code what the statement **says**, not what an implementation would need.\n- If no code fits, write a **memo** proposing a new capability with a definition and the statement as its anchor. New codes are added only at the end of an iteration, never mid-batch.\n- Every change to this file is logged in \u00a76 with the iteration number and the reason.\n\n## 4. Ending conditions (Kundisch et al. 2022, after Nickerson et al. 2013)\n\n**Objective:**\n- every statement in the build set is coded;\n- the last iteration added, merged or split no capability or family;\n- every capability has at least one statement;\n- every family has at least two capabilities.\n\n**Subjective:** concise, robust, comprehensive, extendible, explanatory. These are assessed by the authors and then by the expert panel.\n\n## 5. Families: deductive candidates (iteration 0)\n\nThese are **hypotheses from established frameworks**, to be confirmed, merged, split or dropped by the first empirical iteration. None has capabilities yet. That is deliberate: capabilities come from the data.\n\n| Code | Family | Seed source |\n|---|---|---|\n| REC | Records and their lifecycle | Business archetypes (party, product, order, inventory: Arlow & Neustadt); CRUD |\n| PROC | Process and workflow | Workflow patterns (van der Aalst et al.) |\n| ACC | Access and accountability | RBAC/ABAC; audit trails |\n| TIME | Time, scheduling and recurrence | Booking and scheduling prominence in the seed scan |\n| CALC | Calculation and money | Archetypes (quantity, money) |\n| INFO | Presentation, reporting and documents | Platform literature |\n| COMM | Communication and notification | Platform literature |\n| INT | Integration and data exchange | Platform literature |\n| EXT | External parties and self-service | Portals, public forms, e-signature |\n\n## 6. Change log\n\n| Version | Iteration | Change | Reason |\n|---|---|---|---|\n| 0.0 | 0 | Families seeded as candidates; no capabilities | Conceptual-to-empirical start (Kundisch et al.) |\n| 0.1 | 0 | Automation statement form; once-per-app rule; testimonial, platform and IT-operations skip rules; sign-in features count; no inference | Pilot (17.10.2026), see `pilot/README.md` and `pilot/verification/` |\n"]], "columns": ["name", "text"], "primary_keys": ["name"], "primary_key_values": ["codebook.md"], "units": {}, "query_ms": 3.166304901242256, "source": "Ahmed ElBatanony, Innopolis University", "license": "Not yet licensed \u2014 internal review only"}