The Authoring/Knowledge Door (Funnel Re-Architected to Four) and the Content–Vehicle Convergence Membrane
Accepted
Context
The difusión vestibule (ADR-057) declared a marketing funnel of THREE doors in `.ontoref/positioning/spine.ncl`: developer, infrastructure, personal — a curated audience partition with a three-beat rhetorical architecture (the sub_hero triad "Tu proyecto, tu infra, tu vida", the A–E narrative).
The CLI-domain catalog (`code/domains/`, ADR-012) is a different axis: five domains (framework, personal, provisioning, knowledge-works/librosys, rustelo), each activated when a project's repo_kind matches. Mapping the five domains' audiences onto the doors, four are covered (framework→developer, rustelo→developer, provisioning→infrastructure, personal→personal). ONE is not: knowledge-works' — authors, editors and knowledge-workers who diffuse an authored Work.
That audience is real and distinct: not a developer (a developer BUILDS the publishing vehicle, an author AUTHORS the content), not private PKM (the personal door). It deserves a front door of its own. Adding it is not a data append: the funnel's rhetoric is built on three beats, so a fourth door re-architects the hero/sub_hero/narrative to four — a deliberate positioning-surface change.
Two further facts shape the edges. rustelo is NOT a door (its audience is developer) and is moreover the publishing/diffusion VEHICLE while knowledge-works is the CONTENT — they converge at "publish & diffuse". And a developer can also be an author, so the developer and authoring audiences overlap at a seam rather than partition cleanly.
Decision
The marketing funnel is re-architected to FOUR doors: developer · infrastructure · authoring · personal.
The fourth door — authoring/knowledge — is added to `spine.ncl`, with the funnel rhetoric updated to four beats (sub_hero "Tu proyecto, tu infra, tu obra, tu vida"; the narrative's door table and headings). The door references a real audience (`audiences/audience-authoring-knowledge.ncl`, status 'Hypothesis) and value-prop (`value-props/vp-009-the-whole-work-everywhere.ncl`, status 'Draft), with the same `live_view` / `graph_focus` reveal rungs as the other doors (ADR-057). Its domain is knowledge-works (librosys).
rustelo does NOT get a door. A RusteloApp builder is a developer and enters through the developer door; a rustelo door would duplicate the developer audience.
The rustelo↔knowledge-works convergence (vehicle↔content) is modeled as the `content-vehicle-convergence` gate membrane in `.ontoref/ontology/gate.ncl` (permeability 'High, protocol 'Absorb). The membrane HOLDS both poles (developer/author, vehicle/content) and favors the developer-author crossing rather than collapsing the doors into one or denying the synergy — the ondaod non-collapse, and the synergy axis distinct from the audience (door) axis.
Result: four marketing doors, five domains, one membrane. No shipped protocol surface changes (positioning + project ontology only) — no migration.
Constraints
- Hard The difusión funnel in spine.ncl MUST include the authoring/knowledge door as a first-class audience entry (four doors total: developer, infrastructure, authoring, personal), referencing a real audience id and value-prop id. The funnel rhetoric (sub_hero, narrative) MUST be coherent at four — no 3-in-prose / 4-in-data split.
- Hard The rustelo↔knowledge-works convergence (vehicle↔content) MUST be modeled as a gate membrane in gate.ncl. It MUST NOT be expressed by opening a rustelo door nor by merging the developer and authoring doors.
- Soft The authoring door SHOULD route to a real value-prop (vp-009) and reveal rungs, never argue the core — the same reach-vs-qualification discipline as the other three doors.
Alternatives considered
- Keep the funnel at three; treat authoring as audience+value-prop only, not a door — rejected: The authoring audience is genuinely uncovered and distinct (not developer, not PKM); leaving it doorless routes it nowhere. A front door is the honest answer for a real audience — the funnel is re-architected to four to carry it.
- Open a fifth door for rustelo too (one door per domain) — rejected: rustelo's audience IS developer; a rustelo door duplicates it and inflates the funnel. Doors track uncovered audiences, not the domain count.
- Merge developer and authoring into one 'builder/author' door — rejected: Collapses the developer↔author / vehicle↔content Spiral toward one pole and loses routing precision. The convergence is better expressed as a membrane between two doors than as one fused door.
- Model the rustelo↔knowledge-works synergy as a door or as prose — rejected: A door mis-models a synergy on the audience axis; prose drifts and is not queryable. The gate membrane is the typed mechanism for controlled cross-boundary exchange.
Anti-patterns
- Bolting a Fourth Door onto a Three-Beat Funnel — The authoring door is appended to the doors array as data while the funnel rhetoric (sub_hero triad, narrative, comments) stays at three — leaving the spine internally inconsistent (4 in data, 3 in prose). A door is added without re-architecting the rhetoric to four.
- The Authoring Door Arguing the Core — The authoring door is filled with what knowledge-works can DO (commands, formats) instead of routing the author audience to a value-prop — the reach-vs-qualification trap, now on a fourth door.
- Modeling the Synergy as a Door Instead of a Membrane — The rustelo↔knowledge-works convergence is expressed by opening a rustelo door, or by merging the developer and authoring doors — collapsing the developer↔author / vehicle↔content Spiral onto the audience axis instead of holding it as a controlled exchange.