Semiotic Policy

This specification defines what a policy is, what a policy document MUST contain, how policies are created and revised, and how they relate to other governance structures in an endeavor.

This is a convention specification (per semiotic-specification §0). Sections on canonicalization and wire-format determinism do not apply.

0. Scope

This specification applies to all files that function as policies within an endeavor’s governance structure. A file is a policy if it declares a standing commitment that constrains how work is done, regardless of its frontmatter type field.

In the emsemioverse, policies live at personal/projects/emsemioverse/policies/. Other endeavors may place policies elsewhere, but the structural requirements in this specification apply regardless of location.

1. What a policy is

A policy is a standing commitment that constrains how work is done within an endeavor. Policies are:

• Standing: they persist until explicitly superseded. A policy is not a one-time decision but a durable constraint that applies across sessions, agents, and contexts.
• Commitments: they carry normative force. An agent that violates a policy is not merely choosing differently — it is failing to honor a commitment.
• Constraints on work: they shape how things are done, not what things are done. Policies do not set goals or define tasks; they constrain the manner of execution.

Policies are not rules. A rule is an external imposition; a policy is an internal commitment that emerged from the endeavor’s own practice and stabilized through use. See the policy concept for the formal relationship between policies and habit-formation (j).

Policies are not specifications. A specification declares what something IS and what implementations MUST do. A policy declares how work SHOULD be done. Specifications have conformance tests; policies have practice alignment. A policy may reference specifications (“follow semiotic-markdown”) but is not itself a specification of an artifact.

2. Policy document structure

Every policy document MUST contain:

1. Title: a short name for the policy (used for reference).

2. Statement: a single sentence or short paragraph stating the commitment. The statement MUST be actionable — an agent reading only the statement should understand what the policy requires.

3. Operational explanation: one or more paragraphs explaining what the policy means in practice. The operational explanation SHOULD include concrete examples of compliant and non-compliant behavior.

Every policy document SHOULD additionally contain:

4. Source rationale: why this policy exists. The rationale connects the commitment to the endeavor’s goals, philosophy, or past experience. A policy without a rationale is an assertion without evidence.

Policy documents MUST be individual files (one policy per file), following the one-concept-per-file principle. An index file MAY list all policies for navigability.

2.1 Frontmatter

Policy files MUST declare frontmatter conforming to semiotic-markdown. The following frontmatter fields are RECOMMENDED for policies:

3. Policy identity and numbering

Policies MUST have stable identifiers. The identifier scheme is an implementation choice; this specification does not mandate a particular format. Common schemes include:

• Sequential numbering: 001, 002, 003, … (used by the emsemioverse). Simple, stable, unambiguous.
• Namespaced identifiers: governance.accretion, automation.progressive. More descriptive but less stable under renames.

The identifier MUST NOT change after the policy is published. References to policies (from decision records, specifications, plan logs) use the identifier.

4. Policy lifecycle

4.1 Creation

A policy is created when the endeavor recognizes a standing commitment. Creation sources include:

• Practice observation: a recurring pattern in practice is recognized as something that should always be done. The pattern has already stabilized as habit; the policy codifies it.
• Decision record: a decision about how to handle a class of situations is elevated to a standing commitment.
• Correction: an error or failure reveals a constraint that should have been in place. The correction becomes a policy to prevent recurrence.
• Directive from endeavor owner: the endeavor owner declares a commitment based on values, philosophy, or external requirements.

A policy MUST be recorded as a durable artifact in the repository before it takes effect. Policies that exist only in conversation or memory are not policies — they are uncodified habits.

4.2 Revision

Policies are append-only: they MUST NOT be silently edited to change their meaning. When a policy needs revision:

1. Create a new policy that supersedes the old one. The new policy MUST reference the old one (via the supersedes field or in-text reference).
2. Mark the old policy as superseded. The old policy MUST remain readable for historical reference.
3. Record the revision as a decision record documenting why the policy changed.

Minor clarifications (fixing typos, improving examples) that do not change the commitment MAY be made directly. The distinction between clarification and revision is: if the set of compliant behaviors changes, it is a revision.

4.3 Retirement

A policy is retired when the commitment it encodes is no longer appropriate. Retirement follows the revision process: create a decision record documenting why the commitment is no longer held, mark the policy as superseded (with no successor), and retain the original for historical reference.

Policies MUST NOT be deleted. The append-only principle applies.

5. Policy enforcement

Policies constrain work through multiple enforcement mechanisms:

5.1 Agent instruction loading

Policies SHOULD be loadable into agent context at session start. Mechanisms include:

• Automatic rules (e.g., .claude/rules/policies/ directory)
• Session initialization procedures that read policy files
• Skill instructions that reference policies

The goal is: an agent entering a session should be aware of all active policies without needing to discover them manually.

5.2 Practice alignment checking

Policies do not have conformance test suites in the way specifications do. Instead, policies are checked through practice alignment:

• Situational assessments (the method-practice gap analysis) check whether policies are being followed.
• Retrospectives review recent work against standing policies.
• Decision records cite policies that constrained the decision.

5.3 Automated enforcement

Where a policy’s commitment can be mechanized, it SHOULD be encoded as a hook, script, or validation check. Examples:

• A policy requiring frontmatter validation → a pre-commit hook
• A policy requiring one concept per file → a lint script
• A policy requiring constructive reasoning → a specification constraint

Automated enforcement is a progressive automation target (per the progressive automation policy itself): policies begin as standing commitments enforced by practice alignment, and over time some are mechanized as scripts or tools.

6. Policy scope

6.1 What policies govern

Policies govern the manner of work: how tasks are executed, what principles constrain choices, what patterns are preferred or forbidden. Policies apply across all work in the endeavor unless explicitly scoped.

6.2 Scoped policies

A policy MAY declare a scope that limits its applicability:

• Discipline-scoped: applies only within a specific discipline
• Agent-scoped: applies only to agents of a certain type
• Phase-scoped: applies only during certain endeavor phases

When a policy does not declare a scope, it applies globally within the endeavor.

6.3 What policies do not govern

Policies do not:

• Set goals (use the goals system)
• Define tasks (use plans)
• Specify artifact formats (use specifications)
• Record one-time decisions (use decision records)

7. Policy interactions

7.1 Policy consistency

All active policies MUST be jointly satisfiable. Two policies that contradict each other — where following one necessarily violates the other — constitute a governance error. The resolution is: revise one or both policies, or create a precedence declaration.

7.2 Policy and specification relationship

Policies may reference specifications (“follow semiotic-markdown when creating files”), but policies and specifications operate at different levels:

• Specifications are normative about artifacts (what they MUST look like and how they MUST behave).
• Policies are normative about conduct (how work SHOULD be done).

When a policy and a specification address the same concern, the specification’s MUST-level requirements take precedence over the policy’s SHOULD-level preferences. Policies constrain the space of choices within what specifications permit.

7.3 Policy and decision record relationship

Decision records document specific choices. Policies document standing commitments. A decision record may elevate a specific choice to a policy (“from now on, we always do X”). A policy may be cited in a decision record as the constraint that shaped the decision.

Glossary

• Policy: a standing commitment constraining how work is done
• Standing: persisting until explicitly superseded
• Commitment: a normative constraint honored by all agents
• Practice alignment: checking that actual work conforms to policy
• Supersession: replacing a policy with a new one while retaining the original for reference

Rationale (non-normative)

This specification exists because the emsemioverse has 9 active policies that follow a consistent pattern but had no specification governing their structure. The governance interface (semiotic-endeavor-specification §6) requires policies but does not define what they are or how they work. This specification fills that gap.

The append-only requirement for policies follows from the general accretion principle (policy 005) and from the endeavor identity requirement that governance maintains continuity through change. Deleting a policy erases governance history; superseding it preserves the evolution.

The distinction between policies and rules (§1) follows from the anarchist governance model described in personal/projects/emsemioverse/texts/emsemioverse-and-anarchism.md: policies emerge from practice, not from authority. The distinction between policies and specifications (§1) prevents scope creep — policies should not try to be specifications.

Relationship to other specs

• Requires: semiotic-specification (this is a specification and follows its conventions), semiotic-markdown (policy files are markdown), semiotic-endeavor (policies are part of an endeavor’s governance).
• Required by: semiotic-endeavor-specification §6 (governance interface requires policies).
• Informed by: policy concept (formal relationship to j operator), triage/specifications/policy.md (simulation spec for policy enforcement).