emsenn

Complete semiotic-endeavor-specification

4 min read

Summary

Fill the 4 open conformance gaps in semiotic-endeavor-specification (v0.1.0) identified in the gap analysis text. This completes the level 3 description: what an implementation MUST do.

Motivation

semiotic-endeavor-specification currently covers: method component interface, normative scope, aspect interoperability, shared carriers, method component lifecycle, error semantics, and repository conformance. But §4 explicitly lists 4 gaps:

  1. Aspect registration
  2. Method coherence verification
  3. Governance interface
  4. Lifecycle transition procedures

These are “not yet covered” per the spec’s own admission. Completing them advances goal 006 (specify the endeavor) and makes the specification usable as a conformance target.

Steps

  1. Aspect registration (§ new): how a new aspect specification is added to an endeavor’s method. Define: the registration process, compatibility checking (do the new aspect’s invariants conflict with existing ones?), and the shared carrier update protocol.
  2. Method coherence verification (§ new): concrete procedures for checking that an endeavor’s method is internally consistent. Currently just “invariants must be jointly satisfiable.” Need: what to check, how to check it, what constitutes a failure.
  3. Governance interface (§ new): what governance structures an endeavor MUST have. semiotic-project-management describes governance for THIS endeavor; the specification should say what ANY endeavor implementation must provide. Include: the primacy principle (a concrete endeavor’s practice can override abstract specification governance; see emsemioverse-endeavor-primacy.md).
  4. Lifecycle transition procedures (§ new): not just guards (when) but procedures (how). For each lifecycle transition (draft → candidate → stable → deprecated → superseded), what steps must be taken?
  5. Skills specification (§ new): the skill system (manifests, triggers, runtime types, composition, the progressive automation trajectory from inference to script to tool) is practiced extensively but exists only in ASR theory documents, not as a normative specification. Semiotic-skills belongs WITHIN the semiotic-endeavor-specification as a method component, not as a separate spec — skills are how an endeavor’s method is executed.
  6. Skill specification interface (§ new): what a skill specification (SKILL.md) MUST contain — the normative requirements for skill manifests. Currently documented descriptively in theory/skill-manifests.md; this step promotes it to normative.

Done when

  • Each gap has its own section in semiotic-endeavor-specification
  • §4 is updated to remove addressed gaps
  • Each section is concrete enough that an agent could check conformance against it
  • Skills specification section defines what skills ARE at the endeavor level (not ASR-specific)
  • Skill manifest requirements are normative (not just descriptive)

Dependencies

None, but benefits from plan 0041 (theory completion informs what the spec requires).

Log

2026-03-08 — Created from gap analysis. §4 of the spec itself lists these as “identified but not yet specified.” Per emsenn: plan unplanned work before doing it.

2026-03-08 — Added steps 5-6 (skills specification, skill manifest requirements). emsenn confirmed that semiotic-skills and semiotic-skill-specification are parts of the semiotic-endeavor- specification, not separate specs. The skill system’s “practice without specification” gap (from assessment 2026-03-08-4) is resolved within this plan’s scope. Also added primacy principle reference to step 3 (governance interface).

2026-03-08 — Completed. All 6 sections written as §4-§9 of semiotic-endeavor-specification v0.2.0:

  • §4 Aspect registration: registration preconditions, compatibility checking (invariant, type, dependency), shared carrier update protocol
  • §5 Method coherence verification: what to check (joint satisfiability, carrier consistency, DAG acyclicity, scope disjointness), how to check (enumerate/pair/compose/graph/report), failure criteria
  • §6 Governance interface: required structures (policies, decision records, evidence-gated transitions, ownership), governance evolution, primacy of concrete endeavor (with override procedure)
  • §7 Lifecycle transition procedures: draft→candidate, candidate→stable, stable→deprecated, deprecated→superseded — each with guard recap and detailed procedure steps
  • §8 Skills specification: skill as method component, kinds (operational/ learn/meta), runtime types and progressive automation trajectory, skill composition (dependencies + pipelines), skill-specification relationship
  • §9 Skill specification interface: required fields (description, id), recommended fields (10 fields with types/defaults), region declarations, trigger requirements, versioning constraints, validation requirements Old §4 (gaps) → new §10 with updated gap list (4 new gaps replacing 4 resolved ones). Sources: semiotic-endeavor v0.8.0 (theory), theory/skill-manifests.md (formal model), emsemioverse-endeavor- primacy.md (primacy principle).

Graph View