Summary
Think through how the observation that “we make specifications for the purpose of being able to measure the specified thing” connects into the broader semiotic framework — semiotic-endeavor, the three-level pattern, closure dynamics, and the operational machinery we’re building.
Motivation
We often write specifications not just to describe something but to enable its measurement, so that measurements can be encoded and used as inputs to procedures, functions, skills, and scripts. The specs tell us how things are shaped so we can run them through the machinery.
This observation, if followed through, has implications for:
- How we prioritize what to specify (measure-needed-first, not describe-important-first)
- How we understand the role of the specification level in the three-level pattern (term → semiotic-term → specification)
- How the spec-measure-gap-pressure-work loop relates to closure dynamics
- Whether “the spec IS the test” is literally true in our system
Programmability and human intuition
emsenn observed that planning files should be more machine-readable via frontmatter — not just human-readable prose. The frontmatter fields on plans (status, priority, depends-on, goal, appetite) already encode some structure, but human intuition (“this feels like the fruitful angle”) has no encoding yet.
This connects to the measurement theme: if specs tell us how things are shaped so we can run them through machinery, then plan frontmatter tells us how plans are shaped so assessment skills can score them. The gap is: human intuition about a plan’s promise, fruitfulness, or strategic angle has no frontmatter encoding. It lives only in conversation, which is ephemeral.
Question to think through: can human intuition be encoded as frontmatter without destroying what makes it intuition? Or does the encoding necessarily operationalize it into something else — which may be fine, but should be acknowledged?
Steps
- Trace the connections between this observation and existing concepts: semiotic-endeavor-specification §1 (method component outputs), semiotic-project-management §1.2 (satisfaction deficit as measurement), policy 001 (progressive automation requires measurement), the three-level pattern (specification as the operationalization level).
- Check whether analogues exist in established disciplines: operationalization in social science, conformance testing in software, instrumentation in experimental science.
- Think through the programmability question: how far can plan
frontmatter go in encoding human judgment? What fields would
capture “human intuition on a fruitful angle of attack”? Consider:
emsenn-notes,strategic-angle,intuition-score, or freeformannotationsfields that assessment skills could read but not override. - Write a text capturing the result — either as an addition to semiotic-endeavor or semiotic-endeavor-specification, or as a standalone text if the idea is large enough.
- If the result implies changes to how we prioritize specifications (e.g., “specify what you need to measure first”), capture that as a decision or policy proposal.
- If the result implies new frontmatter fields for plans, propose them as additions to semiotic-project-management.
Done when
- A text exists that articulates the relationship between specification and measurement in the semiotic framework
- The text connects to at least 3 existing concepts in the repo
- If the conclusion implies a priority reordering for specification work, that implication is stated explicitly
Dependencies
None.
Log
2026-03-08 — Created. Originated from emsenn’s observation during plan review discussion. Initially captured as a question; converted to a plan because “think about X” is a legitimate plan type — it follows planning procedure and produces normal outcomes (texts, terms, decisions).
2026-03-08 — Added emsenn’s programmability point: planning files should be more machine-readable via frontmatter, and human intuition about plans (fruitful angles, strategic notes) needs an encoding path. Added steps 3 and 6 to address this dimension.