product-domain-engine

What this skill does

# Product Domain Engine

The meta-system. Every product tied to a domain is an instance of the same operation: formalize informal knowledge into computable structure, then express that structure through four independent rhetorical channels.

This skill does not invent new patterns. It names a system that was already running across four products (`public-record-data-scrapper`, `styx`, `sovereign-systems--elevate-align`, `hokage-chess`) and was being re-derived every time. Naming it converts re-derivation into composition.

## What This Is

A **conductor**, not a monolith. The PDE sequences seven existing skills through a five-phase protocol, adds the rhetorical-mode framework that none of them carries, and provides the composition matrix that selects which output blends which mode.

You invoke this skill when the work to be done is *building a new product tied to a domain* — chess improvement, public records, behavioral economics, wellness, anything where lived knowledge needs to become computable structure.

## The Five-Phase Formalization Protocol

Every domain receives the same treatment. Phases are sequential within a single pass and recursive across product lifecycle.

### Phase 1 — IDENTIFY: the domain's agents

Who acts in this space? Their roles, incentives, constraints. The agent census is the first ontological move; it forces the domain to reveal itself as a graph of actors rather than a topic.

Drives the *systemic-product-analyst* skill (Lane A). Agents map onto users, opponents, intermediaries, gatekeepers, ledgers.

### Phase 2 — MAP: the domain's structures

Real relationships, hierarchies, flows, constraints. What binds the agents into a system? What can break or limit the system in reality (the constraint-domain pillars)?

Drives *market-gap-analysis* (competitive structure) and *research-synthesis-workflow* (causal structure).

### Phase 3 — ENCODE: structures as computable objects

Not concepts. Not documents. **Types, functions, schemas, tests.** The formalization becomes executable.

Drives *product-requirements-designer*. Output: typed interfaces, algorithm implementations, data schemas, deployable test suites.

This is the gate. A domain that cannot produce computable objects has not been formalized — it has only been described.

### Phase 4 — EXPRESS: through four rhetorical modes

The encoded structure speaks through four independent registers. They are not communication styles; they are independent output classes from the same underlying truth. See `references/rhetorical-modes.md`.

Drives *brand-guidelines* (pathos), *pitch-deck-patterns* (pathos+ethos), *content-distribution* (kairos+pathos).

### Phase 5 — DEPLOY: let density create gravity

The `public-record-data-scrapper` principle: a sufficiently dense, sufficiently real formalization attracts its own audience. The 4,455-word README, the 60+ collection agents, the 2,055 tests — that mass *was* the marketing.

Density is gravitational. Promotion only matters at low mass.

### The autopoietic loop

The protocol is not linear. Phase 5's output (deployment metrics, audience behavior, community questions) feeds back into Phase 1 (which agents matter most? which constraints are real?). The system makes itself.

```
IDENTIFY → MAP → ENCODE → EXPRESS → DEPLOY → OBSERVE
   ↑                                              │
   └──────────────────────────────────────────────┘
        observation refines the formalization
```

The OBSERVE step is implemented through analytics modules (e.g. hokage-chess `analytics.ts`, `growth.ts`). They are the observation instruments, not afterthoughts.

## The Four Rhetorical Modes

Classical rhetoric has four modes. Earlier internal drafts of this engine carried only three — the omitted fourth, **kairos**, is the most strategic, and we restore it here. See `references/rhetorical-modes.md` for the full treatment.

| Mode | Greek | Internal/External | Question it answers | Generation method |
|------|-------|------------------|---------------------|-------------------|
| Logos | λόγος | Internal | What is structurally true? | Engineering — types, proofs, algorithms |
| Ethos | ἦθος | External | Why should this be trusted? | Academic density — research, tests, citations |
| Pathos | πάθος | External | Why does this matter to a human? | Social/media content — community, voice, narrative |
| Kairos | καιρός | Strategic | When is the right moment? | Market-timing analysis, zeitgeist alignment |

**Logos is never customer-facing on its own.** It always expresses through ethos (the audience sees that proofs *exist* and trusts the source) or pathos (the audience feels the formalization through narrative). The customer never consumes types directly; they consume credibility or feeling.

**Ethos is built through scholarly density.** Research papers, source lists, test counts, deployment URLs, PROVENANCE files. The depth of the research is the raw material that ethos is forged from.

**Pathos is built through social/media volume.** YouTube, Discord, email sequences, landing pages, brand voice, naming systems, physical objects. The authenticity and volume of the media is the raw material.

**Kairos is built through market-timing observation.** When is the wave arriving, peaking, fading? Each domain rides a zeitgeist; kairos is the choice of when to enter and when to hold.

## The Composition Matrix

Every product output is a specific blend of the four modes. The blend ratio determines what the output *is*. See `references/composition-matrix.md` for the full table; the abridged version:

| Output | Logos | Ethos | Pathos | Kairos |
|--------|:-----:|:-----:|:------:|:------:|
| Technical spec | ■■■ | — | — | — |
| Test suite | ■■■ | ■■ ext | — | — |
| Academic study | ■■■ | ■■■ ext | — | ■ |
| README (flagship) | ■■ | ■■■ ext | — | — |
| Source list | ■■■ | ■■■ ext | — | — |
| Financial model | ■■■ | ■■ ext | — | ■ |
| Pitch deck | ■ | ■■ ext | ■■ ext | ■ |
| Landing page | ■ | ■ | ■■■ ext | ■■ |
| YouTube content | ■ | — | ■■■ ext | ■■ |
| Community (Discord) | — | — | ■■■ ext | ■ |
| Physical product | — | — | ■■■ ext | ■ |
| Email sequence | — | — | ■■ ext | ■■ |
| Launch announcement | — | — | ■■ ext | ■■■ |
| Roadmap | ■ | ■ | — | ■■■ |

`ext` = the mode's *external function* (what the audience consumes), distinct from its internal mass.

## The Prompt Sequence

Universal build commands, ordered per domain stage. See `references/prompt-sequence.md` for the full sequence with example invocations. Five tiers:

1. **Foundation** — what is this domain? (`$MODE`, `$DEPTH`, Natural Center, constraint-domain pillars)
2. **Research** — scholarly study (`$RESEARCH_ATLAS_V3`, peer-reviewed sources, methodological pillars)
3. **Architecture** — how does it become a system? (`$REPO_ARCHITECTURE_CME_FULL`, brand embedding structure, algorithms)
4. **Product Expression** — logos→ethos→pathos outputs (one-pager, landing page, pitch deck, experiment design pack)
5. **Deployment & Scaling** — service scaffolds, multi-tenant SaaS, orchestration

**Order varies by stage:**

| Stage | Sequence |
|-------|----------|
| New domain (e.g. hokage-chess at session start) | 1 → 2 (light) → 3 → 4 → 5 |
| Theory-heavy (e.g. styx) | 1 → 2 (deep) → 3 → 4 → 5 |
| Already-deployed (e.g. public-record-data-scrapper) | 3 → 4 → 5 (1 and 2 already done) |
| Client-driven (e.g. elevate-align) | 1 → 4 → 3 → 5 (pathos first, architecture follows brand) |

## Organ Chain Traversal

Every domain selects which ORGANVM organs it must cross. Not every domain crosses all seven.

| Organ | Function | Logos role | Output kind |
|-------|----------|-----------|-------------|
| I — Theoria | Formalize the domain's truth | types, proofs, research | research papers, theory documents |
| II — Poiesis | Express it aesthetically | brand, visual identity | brand voice, visual system, narrative |
| III — Ergon | Derive revenue | products, pricing, funnel | landing page, course, SaaS |
| IV — Taxis | Orchestr