fpf-thinking-map 1.2.1__py3-none-any.whl

fpf_thinking_map/REJECTED_C32_CANDIDATE_SYNTHESIS.md

@@ -0,0 +1,62 @@
+# Rejected: C.32 Candidate-Synthesis Logic
+
+**Status**: Rejected — will not be added to this package.
+**Date**: 2026-06-24
+**Decision by**: igareosh (prichindel.com)
+**FPF source**: [ailev/FPF commit 10cd224](https://github.com/ailev/FPF/commit/10cd224cef9c92043fb6821e165decd6ea05073f)
+
+---
+
+## What C.32 is
+
+C.32 in the FPF spec introduces candidate-synthesis logic: structured option generation, variant racing, tradeoff-seeking, and candidate-multiplying patterns for decision-making under uncertainty.
+
+## Why it is rejected
+
+This package is a **neutral semantic scaffold** — a thinking map that constrains an LLM's per-move reasoning within bounded semantics. C.32 material would break that neutrality.
+
+### The core problem: activation bias
+
+The base models (GPT, Claude, Gemini, etc.) already contain strong priors for option generation. They are trained to branch, propose alternatives, weigh tradeoffs, and multiply candidates. These are deep model habits, not learned from FPF.
+
+If the thinking map encodes C.32 patterns — even lightly — it stops being a neutral scaffold and becomes a **behavioral trigger**. The model does not just "have access" to candidate-synthesis logic. It starts to feel **invited to branch**, because the map mirrors priors the model already over-selects for.
+
+The result:
+- The map amplifies existing model habits instead of constraining them
+- The model over-selects "variant racing" even when the scope is narrow and the move is clear
+- The map stops preserving source semantics and becomes a **remapping layer** that biases toward generative branching
+
+### C.32 material is especially dangerous for a thinking map because it is:
+
+- **Generative** — it produces options, not constraints
+- **Branch-friendly** — it rewards divergence, not convergence
+- **Tradeoff-seeking** — it opens evaluation dimensions instead of closing them
+- **Candidate-multiplying** — it expands the decision space instead of narrowing it
+
+These are **motion patterns**, not neutral semantic relations. They are the opposite of what a per-move guard-constrained thinking map should contain.
+
+### The design rule applies
+
+> Only add structure when a missing relation changes what the agent does on a single move.
+
+C.32 does not constrain a move. It multiplies moves. That is the wrong direction for this package.
+
+### What belongs here vs what does not
+
+| This package | C.32 material |
+|-------------|--------------|
+| One move at a time | Many candidates at once |
+| Guards constrain invalid moves | Synthesis generates more moves |
+| Slice narrows the decision space | Variant racing widens it |
+| Deterministic checks | Generative exploration |
+| Convergent | Divergent |
+
+The thinking map's value is that it makes each step **smaller and more bounded**. C.32 makes each step **larger and more open**. These are incompatible directions.
+
+## What to do instead
+
+If candidate-synthesis is needed for a specific domain, it belongs in the **LLM prompt layer** or in a separate **strategy module** that runs outside the thinking map. The thinking map evaluates and constrains moves that have already been proposed — it does not propose them.
+
+---
+
+prichindel.com | 2026-06-24 | v1.0.0

fpf_thinking_map/REJECTED_NQD_OEE_CULTURAL_EVOLUTION.md

@@ -0,0 +1,64 @@
+# Rejected: NQD / OEE / Cultural Evolution patterns
+
+**Status**: Rejected — will not be added to this package.
+**Date**: 2026-06-24 (evaluation on 2026-06-22)
+**Decision by**: igareosh (prichindel.com)
+**FPF source sections**: C.17 (Creativity-CHR), C.18 (NQD-CAL), C.19 (E/E-LOG), A.4 (Open-Ended Evolution), B.5.2.1 (Creative Abduction with NQD)
+**FPF repo**: [ailev/FPF](https://github.com/ailev/FPF)
+
+---
+
+## What these patterns are
+
+- **NQD-CAL (C.18)**: Novelty–Quality–Diversity open-ended search calculus. Structured brainstorming, illumination-style emitters, portfolio coverage maps.
+- **E/E-LOG (C.19)**: Explore–Exploit governor. Policy for balancing exploration and exploitation, exploration quotas, selection lenses.
+- **OEE / Open-Ended Evolution (A.4, P-10)**: The principle that any holon is perpetually incomplete and can be improved. Design-time vs run-time evolution.
+- **Creativity-CHR (C.17)**: Characterizing generative novelty and value — Novelty, Use-Value, Surprise, Constraint-Fit scoring.
+- **Creative Abduction (B.5.2.1)**: Hypothesis generation bound to NQD search with diversity maintenance.
+
+These are interesting in FPF-land. They are not current-core for this thinking map.
+
+## Why they are rejected
+
+Same class of risk as C.32 (candidate-synthesis), documented in `REJECTED_C32_CANDIDATE_SYNTHESIS.md`. The reasoning applies identically:
+
+### These patterns are bias injectors
+
+NQD/OEE/cultural evolution material is:
+- **Search-front expanding** — it widens the space of considered options
+- **Novelty-seeking** — it rewards divergence from known paths
+- **Diversity-maintaining** — it resists convergence toward a single answer
+- **Portfolio-multiplying** — it turns one decision into a set of tracked alternatives
+
+Base LLMs already over-index on these behaviors. They generate options readily, branch eagerly, and resist committing to a single path. These are deep training priors, not learned from FPF.
+
+If the thinking map encodes NQD/OEE patterns, it does not add neutral semantic structure. It **amplifies existing model habits** toward exploration, divergence, and candidate multiplication — exactly the behaviors a per-move constrained map should not encourage.
+
+### The thinking map is convergent, not divergent
+
+| This package | NQD/OEE/cultural evolution |
+|-------------|---------------------------|
+| Narrows to one move | Expands to a search front |
+| Guards block invalid moves | Exploration quotas keep options open |
+| Evidence must be present | Novelty is rewarded for being new |
+| Transitions are bounded | Evolution is open-ended |
+| Convergent per step | Divergent by design |
+
+### The design rule
+
+> Only add structure when a missing relation changes what the agent does on a single move.
+
+NQD/OEE patterns do not constrain a move. They generate and maintain alternative moves. They expand the per-step chew instead of reducing it. Wrong direction.
+
+## What to do instead
+
+If novelty/diversity/search-front behavior is explicitly needed for a domain:
+- It belongs in a **separate strategy module** outside the thinking map
+- The thinking map evaluates and constrains moves that arrive from that module
+- The map itself stays neutral — it does not invite the model to explore
+
+The map is a **guard rail**, not a **search engine**.
+
+---
+
+prichindel.com | 2026-06-24 | v1.0.0

fpf_thinking_map/SOURCES.md

@@ -0,0 +1,73 @@
+# Sources and attribution
+
+This package was built from two academic sources. Nothing was invented. Everything traces back to one of these.
+
+## Source 1: FPF (First Principles Framework)
+
+A transdisciplinary specification for reasoning, assurance, and evolution — an "operating system for thought."
+
+- **Author**: Anatoly Levenchuk (with LLM assistance)
+- **Repository**: [github.com/ailev/FPF](https://github.com/ailev/FPF)
+- **Spec**: `FPF-Spec.md` (~51,000 lines) — not included in this repository; see the original repo
+- **Status**: Normative kernel, "eternal alpha" — used in working projects
+- **Prior Python model**: `py-fpf` in the original repo (basic graph model with CSV artifacts — not used directly, but informed the design)
+
+### What we took from FPF and where it is in the spec
+
+| What we built | FPF spec section(s) | What the spec section defines |
+|--------------|---------------------|------------------------------|
+| `ContextPrimitive` | A.1.1 U.BoundedContext | A bounded area where words have specific local meanings. Cross-context use requires explicit bridges with declared translation loss. |
+| `ContextBridge` | A.6.9 CrossContextSamenessDisambiguation | How to connect two contexts: direction, mapping, substitution license, loss notes. |
+| `RolePrimitive` | A.2 Role Taxonomy, A.2.1 U.RoleAssignment, A.2.7 U.RoleAlgebra, A.13 AgentialRole | Roles as assignments (not identities). Specialization (≤), incompatibility (⊥), bundles (⊗). Agency as a spectrum (passive → deliberative). |
+| `WorkPrimitive` | A.15 U.Planning, A.15.1 U.Work, A.15.2 U.WorkPlan | The strict distinction between a plan (intent) and an enactment (what actually happened). A plan is NOT done work. |
+| `CommitmentPrimitive` | A.2.8 U.Commitment | Deontic obligations: MUST, SHOULD, MAY, MUST_NOT, SHOULD_NOT. Scoped, with validity windows and evidence refs. Separate from gates (deontic vs structural). |
+| `GatePrimitive` | A.21 GateProfilization, A.19.UNM (tri-state guard) | Operational gates that aggregate checks. Four outcomes: abstain, pass, degrade, block. Fail-closed by default. |
+| `EvidencePrimitive` | A.10 Evidence Graph, A.2.4 U.EvidenceRole, B.3 Trust & Assurance (F-G-R), B.3.4 Evidence Decay | Evidence with provenance. Trust is a computed tuple: Formality (how rigorous), scope (how broad), Reliability (how dependable). Evidence can go stale. |
+| `TransitionPrimitive` | A.3.3 U.Dynamics, B.4 Canonical Evolution Loop, A.2.5 U.RoleStateGraph | State transitions with optional gate requirements and required evidence. The canonical loop: Run → Observe → Refine → Deploy. |
+| `PublicationPrimitive` | E.17 MVPK Multi-View Publication Kit | Same content, different audiences: plain, technical, interop, assurance. Views do not add new semantics. |
+| Guard: commitment evidence | A.2.8 + A.10 | Binding commitments (MUST/MUST_NOT) require evidence refs to be present. |
+| Guard: plan ≠ enactment | A.4 Temporal Duality, A.7 Strict Distinction | Having a plan does not mean the work is done. Cannot transition to "done" without enactment records. |
+| Guard: role conflict | A.2.7 U.RoleAlgebra (⊥) | Incompatible roles cannot be active at the same time. |
+| Guard: gate pass | A.21 GateProfilization | Gate must pass (or at least degrade, not abstain/block) before a guarded transition fires. |
+| Guard: scope check | A.2.6 USM (Unified Scope Mechanism) | Actions must stay within the active context. Cross-context action requires a bridge. |
+| Guard: evidence freshness | B.3.4 Evidence Decay | Stale or expired evidence triggers a warning before decisions. |
+
+### What we did NOT take from FPF
+
+The full FPF spec is ~51,000 lines covering dozens of patterns across 7 parts (A through G). We extracted 10 objects and 9 guard rules. Everything else in the spec (the full ontology, the mathematical formalism, the publication kit details, the SoTA harvesting, the ethics framework, the explore-exploit calculus) was left out intentionally. This package is a distillation, not a port.
+
+## Source 2: Computational logic lectures (Mitev L.)
+
+A university lecture series on propositional logic. We took the 6 basic logic operators and the Wumpus World pattern for agent navigation.
+
+- **Title**: "Bazele programarii logice" (Fundamentals of Logic Programming)
+- **Author**: Mitev L.
+- **Format**: 5 lecture PDFs (c1p through c5p)
+
+### What each lecture covers and what we used
+
+| Lecture | Topics | What we took |
+|---------|--------|-------------|
+| c1p | Propositions, 6 operators (NOT, AND, OR, XOR, IMPLIES, IFF), truth tables, operator precedence | All 6 operators as Python classes (`NotProp`, `AndProp`, `OrProp`, `XorProp`, `ImpliesProp`, `IffProp`). Truth table behavior is verified in `verify.py`. |
+| c2p | Validity (tautology), satisfiability, unsatisfiability, contingency, consistency of proposition sets, system specifications | Consistency check in `LogicLayer.consistency_check()` — verifying that the set of fired rules does not contain contradictory actions. |
+| c3p | Logical equivalences, De Morgan's laws, contrapositives, minimum connective sets | Informed the design that any complex condition can be built from NOT + one binary operator. We kept all 6 for readability. |
+| c4p | Natural deduction (introduction/elimination rules for each operator), replacement rules | Not directly used in code, but informed the understanding of how each operator introduces or eliminates knowledge. |
+| c5p | Semantic reasoning with truth tables, Wumpus World (propositional logic for AI agent navigation) | The core design pattern: an agent navigates a space, evaluates propositions about its surroundings at each step, and uses logic to determine safe/valid moves. Our "cells" = semantic states, "moves" = transitions, "percepts" = evidence/gate/commitment facts. |
+
+### The Wumpus World pattern (from lecture 5)
+
+In the Wumpus World, an agent explores a 4x4 grid. Each cell may contain a pit or a monster. The agent perceives clues (breeze = adjacent pit, stench = adjacent wumpus) and uses propositional logic to deduce which cells are safe before moving.
+
+We applied the same pattern:
+- The semantic map is the grid
+- Evidence, gates, and commitments are the percepts
+- Logic operators compose percepts into safety checks
+- Guards are the hard constraints (like "don't walk into a known pit")
+- The model picks moves from the safe set
+
+## Package authorship
+
+- **Adaptation**: prichindel.com
+- **Created**: 2026-06-24
+- **Purpose**: Semi-encode FPF into an agentic thinking map with propositional logic glue
+- **Repository**: [github.com/igareosh/prichindel.com-agentic-thinking-map](https://github.com/igareosh/prichindel.com-agentic-thinking-map)

fpf_thinking_map/WHY_THIS_EXISTS.md

@@ -0,0 +1,92 @@
+# Why this exists — compiled FPF vs raw FPF
+
+This document explains why this package exists adjacent to the original FPF specification, and why feeding the raw spec text to a model is a fundamentally different (and worse) operation than feeding it the compiled thinking map.
+
+This is not a critique of FPF itself. As a human-readable transdisciplinary framework, FPF is strong and well-structured. The problem is not the framework — it is the assumption that a language model can absorb a 51,000-line specification and then apply it the way a human reader would.
+
+## The triple tax: what happens when a model reads raw FPF
+
+When you give a language model the FPF specification text and ask it to make a decision, three things happen in sequence. Each one costs tokens, time, and accuracy.
+
+### Pass 1 — Parse
+
+The model reads the FPF text and activates attention on terms like "U.BoundedContext", "holon", "meta-holon", "ontic", "episteme." These are high-entropy tokens — rare words that pull attention strongly. The model spends capacity figuring out what the text MEANS before it can use it.
+
+This is not how the model processes familiar concepts. When the model sees "test results passed," it maps that to a decision in one attention step. When it sees "the epistemic holon satisfies the F-G-R assurance calculus under the bounded context's invariant constitution," it spends multiple attention layers parsing syntax, resolving references, and building an internal representation of what the sentence is saying. The actual meaning ("the evidence is good enough") is the same, but the computational cost is higher.
+
+### Pass 2 — Aggregate
+
+Now the model tries to map the FPF concepts onto the actual question. "The user asked about deploying. FPF says deployment requires a U.Work enacted under a U.RoleAssignment within a U.BoundedContext with evidence satisfying B.3 F-G-R..." The model is translating between two vocabularies — the FPF vocabulary and the task vocabulary. Every translation is a re-reasoning step.
+
+This pass is where the model burns the most tokens for the least value. It is not solving the problem. It is translating the problem into FPF terms and then back into task terms. The translation adds nothing — the original question already contained everything the model needs. But the FPF text forces the model to route through the framework's terminology.
+
+### Pass 3 — Generate
+
+Now the model answers. But it is answering through the FPF lens, which means every sentence is hedged with FPF terminology: "According to the holon-based epistemic framework, the role-assignment binding suggests..." The output is the model performing FPF, not solving the problem.
+
+The generated text sounds rigorous. It uses the right FPF terms. It follows the right FPF structure. But it is not a better answer than the model would have given without FPF — it is the same answer wrapped in framework-flavored prose that the human reader must then unwrap to extract the actual decision.
+
+### The tax adds up
+
+Reason about the framework → reason about the mapping → reason about the answer. Three passes where one should suffice. And each pass activates the same attention patterns (the FPF vocabulary), which means the model's prior biases about those scientific-sounding terms get amplified. "Holon" sounds important, so the model treats it as important, and spends more tokens on it.
+
+On a multi-step traversal, the tax compounds. Each step re-reads the framework, re-maps the vocabulary, re-generates the FPF-flavored output. By step 5, the context is full of the model arguing with itself about whether a "U.RoleAssignment" is the same as an "actor binding" and whether "epistemic" means "evidential" in this context. The actual decision — should we deploy? — is buried under layers of framework self-interpretation.
+
+## What this package does instead
+
+We compiled 51,000 lines into 10 dataclasses, 9 guards, and 6 logic operators. The FPF thinking happened once, at compile time, when we wrote the code. At runtime, the model never sees "holon" or "episteme" or "ontic." It sees:
+
+```json
+{
+  "can_fire": false,
+  "blockers": ["missing evidence: ['owner_approval']"],
+  "response_contract": {
+    "basis": [{"id": "test_results", "freshness": "current", "ttl_remaining": 6}],
+    "modality": [{"commitment": "No deployment without evidence", "force": "must"}],
+    "canonical_terms": {"deploy": "push artefact to production environment"}
+  }
+}
+```
+
+One pass. No translation. No re-reasoning. The code already did the FPF thinking and handed the model a JSON with the answer pre-computed.
+
+The model's job shrinks from "understand this 51k-line philosophy of reasoning and then apply it" to "read this small JSON, fill in the claim field, pick the next move."
+
+## Three problems with feeding raw FPF to a model
+
+### 1. It makes the model re-reason N times
+
+Once per FPF concept layer (context → role → commitment → gate → evidence → transition). Each layer is a re-reasoning pass because the model has to carry forward all prior layers. On a 6-step traversal with 6 concept layers, the model performs 36 reasoning passes where 6 would suffice (one per step, each reading a pre-computed slice).
+
+### 2. It feeds the model biased activations
+
+FPF uses terms like "agency spectrum", "candidate synthesis", "novelty-quality-diversity" that are already strong priors in the training data. The model sees these and shifts into "academic reasoning mode" — verbose, hedge-heavy, option-multiplying. Exactly the opposite of what a per-step decision map needs.
+
+This is why we rejected FPF patterns like C.32 (candidate-synthesis logic) and NQD/OEE (novelty-quality-diversity). These patterns amplify existing LLM biases instead of constraining them. See [REJECTED_C32_CANDIDATE_SYNTHESIS.md](REJECTED_C32_CANDIDATE_SYNTHESIS.md) and [REJECTED_NQD_OEE_CULTURAL_EVOLUTION.md](REJECTED_NQD_OEE_CULTURAL_EVOLUTION.md).
+
+### 3. It is a word blob organized for human readers, not machine consumption
+
+The 51k lines are structured as sections, subsections, cross-references, normative statements, and examples — a format designed for a human reader who can skim, jump between sections, and build a mental model over multiple readings. A model reading this does what it does with any large text: skims, activates on familiar patterns, and generates text that sounds like the input. The output is FPF-flavored prose, not decisions.
+
+## What FPF gets right (for humans)
+
+None of this means FPF is wrong. For a human practitioner:
+
+- The bounded context discipline is genuinely useful — it stops people from conflating terms across domains.
+- The role/method/work separation catches real organizational confusion.
+- The evidence-based gate system maps directly to how decisions should be made in engineering.
+- The deontic commitment framework (MUST/SHOULD/MAY) prevents the common mistake of treating guidelines as requirements or vice versa.
+
+These insights are strong. We extracted them. We compiled them into code that a model can use without re-deriving them from first principles on every step.
+
+## The fundamental misunderstanding
+
+Treating an LLM like a human reader who can absorb a framework and then apply it. An LLM is a pattern completer. Give it a framework, it completes the framework's patterns. Give it a structured template with precomputed values, it fills the template. The second one is useful.
+
+FPF as a human-readable specification: strong.
+FPF as raw input to a language model: triple tax.
+FPF compiled into a thinking map with precomputed state: what this package does.
+
+---
+
+prichindel.com | 2026-06-27 | v1.1.3

fpf_thinking_map/__init__.py

@@ -0,0 +1,81 @@
+"""FPF Thinking Map — compiled semantic substrate for agentic traversal.
+
+A structured board for LLM reasoning: the model navigates a pre-shaped
+semantic field with deterministic guards and propositional logic constraints.
+Evidence decays via TTL hop counter. The model reads small JSON slices and
+picks moves — no re-reasoning about state the code already computed.
+
+Modules:
+  primitives  — 10 semantic objects + 5 semantic floors from FPF spec
+  state       — runtime binding, active state, TTL tracking, per-move slices
+  guards      — 9 deterministic guards (hard constraints, not LLM judgments)
+  logic       — 6 propositional operators + freshness-aware decision rules
+  traversal   — step engine with 10 lawful outcomes
+  examples    — deploy decision scenarios demonstrating the full system
+  verify      — 18-check self-verification harness
+"""
+
+# --- Primitives: the semantic field ---
+from fpf_thinking_map.primitives import (
+    ContextPrimitive,
+    ContextBridge,
+    RolePrimitive,
+    AgencyLevel,
+    RoleAssignment,
+    WorkPrimitive,
+    WorkPlanPrimitive,
+    SpeechActPrimitive,
+    SpeechActType,
+    CommitmentPrimitive,
+    DeonticModality,
+    GatePrimitive,
+    GateCheck,
+    GateDecision,
+    EvidencePrimitive,
+    FGR,
+    Freshness,
+    SemanticFloor,
+    FLOOR_BASE_TTL,
+    TransitionPrimitive,
+    PublicationPrimitive,
+    PublicationFace,
+)
+
+# --- State: binding + active state + slicing ---
+from fpf_thinking_map.state import (
+    RuntimeBinding,
+    SemanticMap,
+    ActiveState,
+    MoveTrace,
+)
+
+# --- Guards: deterministic hard constraints ---
+from fpf_thinking_map.guards import (
+    GuardEngine,
+    GuardVerdict,
+    GuardScope,
+    Guard,
+    GuardResult,
+)
+
+# --- Logic: propositional decision glue ---
+from fpf_thinking_map.logic import (
+    LogicLayer,
+    DecisionRule,
+    RuleKind,
+    Prop,
+    EvidencePresent,
+    EvidenceFresh,
+    GatePasses,
+    GateBlocked,
+    RoleActive,
+    InState,
+    CommitmentMet,
+    HasMissingEvidence,
+    RiskAbove,
+    TransitionAvailable,
+    CustomProp,
+)
+
+# --- Traversal: the step engine ---
+from fpf_thinking_map.traversal import ThinkingMapTraversal, Outcome, OutcomeKind