Summary
Document the general procedure by which work moves through the endeavor — from input (research, request, discovery) to output (specification, skill, script, text) — with embedded decision protocols at each fork point. Currently this flow is implicit and handled ad hoc.
Motivation
The endeavor has a recognizable but undocumented flow:
input → research → encode as concepts/terms → compose into texts →
develop into method (specs) or practice (skills/scripts)
Policy 003 describes a research cadence. Policy 006 says research produces texts. Policy 008 says prompts become artifacts. But no single procedure describes the full path from input to output, and critically, no procedure describes the decision points where the path forks.
Examples of undocumented forks:
- When does something become a specification vs. a skill? (Specs describe structure; skills describe capability. But when does a capability warrant its own spec?)
- When does research produce a term file vs. a text? (Policy 002 says one concept per file, but when is something a concept vs. an observation within a text?)
- When does a practice get formalized vs. left as convention? (The three-level pattern says term → semiotic-term → specification, but what triggers the move from one level to the next?)
- When does a gap warrant its own plan vs. being handled inline? (Policy 007 says fill gaps when they block work, but at what scale does a gap need its own plan?)
Without documented decision protocols, each of these forks is resolved by inference (“what would emsenn probably want?”) — which is exactly the vibes failure mode that semiotic-endeavor §Aspects warns against.
Steps
- Inventory the implicit procedures that currently exist: the research cadence (policy 003), the encoding loop (interpret-message skill), the plan lifecycle (plans/index.md), the review process (review-plans skill). These are fragments of a larger procedure.
- Map the full flow from input to output, identifying every fork point. A fork point is where the procedure could go in more than one direction.
- For each fork, write a decision protocol: what conditions to check, what each branch means, and how to choose. Decision protocols should be evaluable — not “use judgment” but “check X; if X then branch A because Y.”
- Document the procedure as a text (not a skill — it’s too complex for a single skill, and it governs how skills are invoked). Place it in the semiotic-project-management spec or as a standalone text within semiotic-endeavor.
- Identify which decision protocols can themselves be encoded as skills or frontmatter conventions (per policy 001, progressive automation). Not all can — some require judgment — but those that can should be flagged for future automation.
Done when
- A documented work procedure exists, covering the full path from input to output
- At least 5 fork points are identified with explicit decision protocols
- Each decision protocol specifies conditions, branches, and rationale (not “use judgment”)
- The procedure is tested: apply it to a recent piece of work and check whether it would have produced the same (or better) routing
Dependencies
None, but benefits from plan 0038 (situational assessment gives the procedure a “where are we?” input).
Log
2026-03-08 — Created. Prompted by recognizing that the research → method → practice → specification flow is implicit and ad hoc. Different work units develop toward different outputs (specs vs. skills vs. scripts) with no documented procedure for deciding which path to take. Subsumes the need for “proceduralized decision-making protocols” — the decision protocols are embedded in the work procedure, not a separate artifact.