Semiotic Project Management

This specification defines project management interpreted as semiotic interaction. It is a model interpretation in the same sense as semiotic-git and semiotic-markdown: it takes conventional project management structures and shows how they instantiate the semiotic universe’s semantic carrier, modality, trace, and closure operators.

The result is not a metaphor. A plan is a sign. A goal is a closure condition. A backlog is a semantic gap. Progress is monotone increase in satisfaction. These identifications are formal and carry operational consequences: the predicate graph computes the backlog, the satisfaction relation measures progress, and closure pressure generates goals.

Specification category: convention specification (per semiotic-specification). Canonicalization and wire-format determinism sections do not apply.

0. Grounding

0.1 Why not conventional project management

Conventional project management assumes a principal-agent structure: a principal (manager, stakeholder, product owner) defines objectives, and agents (developers, workers) execute them. Planning tools (Gantt charts, sprint backlogs, roadmaps) serve the principal’s need for visibility and control.

This structure is hierarchical by construction. Even frameworks that claim to flatten hierarchy (Scrum’s “self-organizing teams,” Kanban’s “pull-based flow”) operate within an imposed goal structure: someone external to the work decides what is worth doing. The team decides how; the principal decides what and whether.

A semiotic project management system rejects this structure. Goals are not imposed by a principal; they arise from the system’s own failure to close. Work is not assigned by authority; it is identified by closure pressure and selected by the agents who can address it. The governance structure is prefigurative: it embodies the non-hierarchical relations it theorizes, rather than deferring them to a post-revolutionary future.

0.2 Relational grounding

Relationality holds that relations are ontologically prior to entities. If there are no fixed entities, there are no fixed rules. What appear as stable structures (plans, policies, governance) are stabilized relations — habits that persist through continued practice and dissolve when the relational dynamics that sustain them change.

This is not a claim that rules are unnecessary. It is a claim about where rules come from: not from authority imposing structure on passive material, but from relational activity generating patterns that stabilize under their own closure pressure. Policies are the repository-level reflection of the modal closure operator j — habit-formation in the semiotic universe.

0.3 Indigenous governance

Many Indigenous governance systems enact the principles described here — consensus, direct participation, non-hierarchy, regeneration of practices — without deriving from European anarchist tradition. The convergence between Indigenous governance and anarchist analysis is itself evidence that hierarchical management is provincial, not universal.

This specification draws on Indigenous resurgence (Simpson, 2017; Coulthard, 2014): the regeneration of governance practices on their own terms, not as performances for external audiences. The emsemioverse’s governance is not “decolonized project management” — decolonization is not a metaphor. It is a system whose mathematical structure generates governance through closure pressure, and whose philosophical grounding in Lakota epistemologies precedes and does not require European validation.

1. Semantic carrier

1.1 The project graph

The semantic carrier H for project management is the predicate graph restricted to project-relevant predicates. The full predicate graph contains 8,130+ triplets across all content; the project subgraph contains those triplets whose predicates are project-structural: status, goal, depends-on, priority, milestone, horizon.

Elements of H are not individual plans or tasks. They are closure-bounded subsets of the project graph: sets of plans, goals, and dependencies that form a coherent unit of work. A milestone, for instance, is an element of H — a set of plans whose collective completion constitutes a named state.

1.2 Satisfaction as progress

The predicate graph already defines a satisfaction relation: a page satisfies its type’s theory when every axiom evaluates to true against the page’s interaction surface.

Progress in project management is monotone increase in satisfaction. A plan is completed when its acceptance criteria (axioms) are satisfied with evidence. A goal is achieved when its key results (a conjunction of axioms across multiple plans) are satisfied. The total number of unsatisfied axioms across all pages is a monotone-decreasing measure under closure — the distance to the fixed point X*.

This replaces “percent complete” (which measures activity) with satisfaction deficit (which measures how far the system is from closure). The distinction matters: a team can be 90% complete on tasks and 0% closer to closure if the tasks do not address the actual gaps.

2. Modality and trace

2.1 Stability (j)

The modal closure operator j identifies what is stable — what has been committed and will not be retracted. In project management:

• Decision records are stable. Once a decision passes through j (is accepted and recorded), it persists. Decision records are append-only; supersession creates a new record, it does not modify the old one.
• Completed plans are stable. A plan that has met its acceptance criteria with evidence has passed through j. Its outcome is part of the system’s committed state.
• Policies are stable habits. They persist until closure pressure forces revision — at which point a new policy supersedes the old.
• Draft and active plans are not stable. They are partial structures that may change, be abandoned, or be superseded.

The stable fragment H^st is the set of decisions, completed plans, and active policies. This is what the system has committed to. It grows monotonically.

2.2 Trace (G)

The trace operator G tracks provenance: why a commitment exists, what interactions produced it. In project management:

• Each plan’s log section is its trace — dated entries recording what happened and what was learned.
• Decision records carry context, alternatives considered, and consequences — the derivation that produced the decision.
• Goal key results carry evidence — the observations that establish whether the result was achieved.

Trace is intensional: two plans that achieve the same outcome may have different traces (different paths through the work). The trace records the path, not just the destination.

3. Project structures

3.1 Goals as closure conditions

A goal is a named closure condition: a description of what the system looks like when certain gaps in the predicate graph are resolved. Goals are not imposed by external stakeholders; they arise from the system’s own unsatisfied closures.

When the predicate graph reports 40 MUST errors and 417 SHOULD warnings, those gaps generate closure pressure. The pressure produces goals: “resolve all MUST errors in the sociology domain” is a goal that the system’s own mathematics identifies.

Goal format: see goals.

Horizons are not deadlines but distances from current closure:

• near: closure conditions that current tools and knowledge can address in 1-3 sessions
• mid: closure conditions that require building new tools or acquiring new knowledge (1-4 weeks)
• far: closure conditions that require structural changes to the system itself (months+)

3.2 Plans as partial closures

A plan is a sign whose body claims describe a path to partial closure. Its interaction surface (frontmatter) declares:

• goal: — which closure condition it serves
• status: — its lifecycle state
• priority: — its relative urgency
• depends-on: — which other partial closures must complete first
• milestone: — which named state it contributes to
• appetite: — how much attention this is worth (not how long it will take)

The appetite field (Singer, 2019) replaces estimation. An estimate asks “how long will this take?” — a question the system cannot answer reliably. An appetite asks “how much attention is this worth?” — a question the system can answer by evaluating the closure pressure the plan addresses.

Appetite values: small (1 session), medium (2-3 sessions), large (4-6 sessions). Work that exceeds its appetite triggers the circuit breaker: stop, reassess whether the approach is right, reshape or abandon. This prevents plans from consuming unbounded attention.

Plan format: see index.md.

3.3 Milestones as named partial closures

A milestone is a named state where a set of closure conditions are simultaneously met. It represents a meaningful intermediate closure — a state where enough gaps have been resolved that a new capability exists.

Milestones are declared as milestone: values on plans. Plans that share a milestone value form a coherent group whose collective completion constitutes the named state.

Example: a milestone “predicate-graph-via-mcp” groups plans 0015 (MCP tooling) and the predicate graph MCP integration work. When all plans in the milestone are completed, the named capability (querying the predicate graph through MCP) exists.

Milestones are not deadlines. They are descriptions of closure states, ordered by dependency, not by calendar.

3.4 Backlog as semantic gap

The backlog is not an arbitrary list of tasks. It is the semantic gap: the set of all known axiom violations in the predicate graph. Every MUST error is a backlog item. Every SHOULD warning is a backlog item at lower priority.

The predicate graph satisfaction report (predicate-graph.py --satisfy-all) generates the backlog. This is computable: the system can identify its own gaps without human intervention. Each gap names a specific predicate that a specific page needs — a concrete, actionable item.

This means the backlog is derived, not curated. The system’s mathematics generates the work list. Agents select from it based on leverage (policy 009) and appetite, not on managerial assignment.

Unplanned work (TODO.md items, session discoveries, emsenn’s requests) enters the backlog through the encoding loop: the request becomes a plan, the plan declares a goal, the goal names a closure condition. This ensures that ad hoc work is connected to the system’s closure trajectory, not floating loose.

3.5 Board as flow of closure

A board is a projection of the project graph onto lifecycle states: backlog, shaped, active, done. The board shows how closure flows through the system.

WIP limit: at most 2-3 plans in the Active column at any time. This is not arbitrary — it reflects the concurrency bound on closure. Too many simultaneous partial closures means none of them complete. Energy disperses. The system thrashes without making progress.

The review-plans skill should generate this board view from plan frontmatter.

3.6 Cycles as bounded interaction sequences

A cycle is a bounded sequence of sessions with a declared scope and a circuit breaker. Cycles are not sprints (fixed-length iterations on a regular cadence); they are appetite-bounded work periods.

A cycle begins when a plan moves to active. The cycle’s scope is the plan’s acceptance criteria. The cycle’s budget is the plan’s appetite. When the appetite is exhausted without completion, the circuit breaker fires: stop, reassess, reshape or abandon.

Between cycles: cool-down. Cool-down is unstructured time for the encoding loop to run without pressure — processing triage, enriching frontmatter, running mechanical improvements. Cool-down is where progressive automation (policy 001) produces its returns: Ollama handles enrichment, scripts handle validation, agents handle gap-filling.

3.7 Retrospective as categorical review

A retrospective is the system questioning whether its own categories still fit.

A conventional retrospective asks: what worked? what didn’t? what will we change? A semiotic retrospective asks:

• Semantic: Do our categories (plan, goal, policy, milestone) still describe the work we are doing? If a category has no instances, it may be unnecessary. If work keeps escaping our categories, we are missing one.
• Syntactic: Do our operations (skills, scripts, MCP tools) cover the work we need to do? If agents keep doing manual work that could be automated, the operator algebra is incomplete.
• Fusion: Are there operations that produce identical results? If two skills do the same thing, fuse them. If a manual process and an automated process coexist, the manual one should dissolve.

The question is not “did we hit our targets?” but “do our targets still make sense?”

Retrospectives happen at cycle boundaries and at monthly review cadence.

4. System health

Project health is assessed across three dimensions:

4.1 Substrate

The persistent foundation: repository content, specifications, formalized mathematics, decision records. Measured by:

• Predicate graph size (pages, triplets, handle edges)
• Satisfaction rate (what percentage of typed pages meet their axioms)
• Stable fragment size (completed plans, accepted decisions, active policies)

Substrate grows through accretion (policy 005). It does not shrink except by deliberate deprecation.

4.2 Activity

The operational flow: sessions, agent work, script runs, MCP tool invocations. Measured by:

• Plans moving through lifecycle states
• Axiom violations being resolved
• Frontmatter enrichment (Ollama inference, manual addition)
• New content created and connected to the predicate graph

Activity without direction is waste. Activity that does not reduce the satisfaction deficit is not flowing toward closure.

4.3 Reflexivity

The system’s capacity to question its own categories. Measured by:

• Retrospectives conducted and acted on
• Policies revised or superseded
• Categories added or removed from the type vocabulary
• Questions raised and addressed
• Decision records that supersede prior decisions

Reflexivity cannot be produced by adding more activity. More activity does not produce more awareness. Reflexivity requires settling — cool-down periods, reflective review, the space to notice that categories no longer fit.

A project with strong substrate and activity but no reflexivity is productive but blind. It completes tasks without learning.

5. Governance

5.1 Anarchic structure

No project manager. No product owner. No scrum master. Governance is distributed:

• Closure pressure generates goals. The system’s mathematics identifies gaps; agents identify which gaps to address.
• Policies constrain work. They are habits, not rules — they emerge from practice and dissolve when circumstances change.
• emsenn reviews and accepts plans, sets strategic direction, and exercises final judgment. This is not a hierarchy — it is the project owner’s relationship to the work. emsenn does not assign tasks; agents select tasks by leverage (policy 009).
• Agents identify, plan, and execute work. They read the satisfaction report, select the highest-leverage gap, and work toward closure.

5.2 Decision-making

Decisions follow the decision record format. The process:

1. An agent or emsenn identifies a decision point
2. The agent writes a decision record (context, decision, consequences, alternatives)
3. emsenn reviews and accepts or rejects
4. Accepted decisions enter the stable fragment

This is not consensus decision-making (which requires unanimity) or majority rule (which requires voting). It is review-based governance: agents propose, the project owner reviews, the mathematics constrains.

5.3 Plan lifecycle as evidence accumulation

The plan lifecycle (draft → proposed → accepted → active → completed) is not an authority chain. It is an evidence chain:

• Draft → Proposed (agent gate): the plan has enough evidence (clear steps, measurable criteria, identified goal) to evaluate
• Proposed → Accepted (emsenn gate): the goal is worth pursuing and the approach is reasonable
• Accepted → Active (agent gate): dependencies are met, the agent has context and tools
• Active → Completed (evidence gate): acceptance criteria are met with evidence, outcome is assessed

Each gate requires evidence, not authority. The gates prevent plans from progressing without substance — but they do not require permission from a hierarchy.

6. Relationship to conventional practices

This specification draws on established practices and reinterprets them through semiotic structure:

The reinterpretation is not cosmetic. Each conventional concept gains precision from its semiotic grounding: a “backlog” is no longer a list that someone curates — it is a computable set derived from the satisfaction relation. A “milestone” is no longer a calendar date — it is a named closure state. A “retrospective” is no longer a process-improvement exercise — it is a categorical review.

7. Implementation

7.1 Frontmatter additions

Plans gain two new fields:

appetite: small | medium | large
milestone: "milestone-name"

The goal: field (already specified) connects plans to closure conditions. The appetite field bounds effort. The milestone field groups plans into named closure states.

7.2 Review-plans skill extensions

The review-plans skill should produce:

1. Board view: plans grouped by lifecycle state (gap, shaped, active, closed) with WIP limit check
2. Milestone view: milestones with completion percentage (completed plans / total plans per milestone)
3. Satisfaction deficit: current predicate graph error and warning counts as a progress metric
4. Constraint report: which single gap, if resolved, would unblock the most other work

7.3 Predicate graph integration

The predicate graph’s satisfaction report is the backlog generator. The MCP server should expose:

• satisfaction_report: current errors and warnings
• satisfaction_deficit: total unsatisfied axioms as a single number
• weakest_files: files with the most axiom violations

These tools allow agents to identify their own next task without human direction.

8. What this specification does not do

• It does not impose a calendar cadence. Sessions happen when they happen. Cycles are appetite-bounded, not time-bounded.
• It does not assign roles. There is no scrum master, no product owner beyond emsenn’s project-owner relationship.
• It does not estimate. Appetites declare how much attention work is worth, not how long it will take.
• It does not require consensus. Decision-making is review-based, not unanimity-based.
• It does not claim to “decolonize” project management. It is a system whose mathematical structure generates governance through closure pressure, grounded in Lakota epistemologies that precede and do not require European validation.

Glossary

• Appetite: how much attention a plan is worth (small, medium, large). Replaces estimation. (Singer, 2019)
• Board: a projection of the project graph onto lifecycle states, showing how closure flows through the system.
• Circuit breaker: the mechanism that stops work when appetite is exhausted without completion, forcing reassessment.
• Closure condition: what a goal describes — a state where specific gaps in the predicate graph are resolved.
• Convention specification: a specification that defines organizational practices or interpretive models (not serializable artifacts).
• Cool-down: unstructured time between cycles for the encoding loop to run without pressure.
• Cycle: an appetite-bounded work period tied to a single active plan.
• Milestone: a named state where a set of closure conditions are simultaneously met.
• Plan lifecycle: the evidence chain draft → proposed → accepted → active → completed, where each transition requires evidence.
• Satisfaction deficit: the total number of unsatisfied axioms across all pages — a monotone-decreasing measure of distance to closure.
• Semantic gap: the set of all known axiom violations in the predicate graph — the computable backlog.
• Retrospective (categorical review): a review that questions whether the system’s categories still fit, not just whether processes worked.
• WIP limit: the concurrency bound on closure — at most 2-3 plans active simultaneously.

Rationale (non-normative)

This specification exists because the emsemioverse had researched twelve project management practices across seven research texts and applied zero of them. The gap was not lack of knowledge but lack of integration: conventional PM concepts did not connect to the semiotic structures that organize the repository.

The semiotic reinterpretation resolves this. A backlog is not a list someone maintains — it is the computable output of the predicate graph’s satisfaction checker. A goal is not an aspiration someone writes down — it is a closure condition the system’s mathematics identifies. Progress is not a percentage someone estimates — it is a satisfaction deficit that monotonically decreases under closure.

The anarchic governance structure is not an ideological preference imposed on the tools. It is what the mathematics produces: closure pressure generates goals, agents select by leverage, policies stabilize through practice. No principal-agent hierarchy is required because the system itself identifies what needs doing.

The grounding in Indigenous governance and relational philosophy is not decorative framing. Relationality (relations prior to entities) is the ontological position that makes this interpretation coherent. If entities were fixed, management could be hierarchical. Because relations are prior, governance must emerge from relational dynamics — which is exactly what closure pressure does.

Relationship to other specs

• Follows: semiotic-specification (this is a convention specification and follows spec-spec conventions).
• Requires: semiotic-markdown (all project artifacts are markdown files).
• Requires: predicate graph (the backlog, satisfaction deficit, and progress measurement depend on it).
• Requires: closure pressure (the mechanism that generates goals).
• Extends: semiotic-markdown (plans, goals, and decisions are markdown files with typed frontmatter).