fpf-thinking-map 1.4.3__tar.gz → 1.4.4__tar.gz

{fpf_thinking_map-1.4.3 → fpf_thinking_map-1.4.4}/PKG-INFO

@@ -1,13 +1,13 @@
 Metadata-Version: 2.4
 Name: fpf-thinking-map
-Version: 1.4.3
-Summary: Agentic thinking map — structured reasoning constraints for LLMs with TTL evidence decay, deterministic guards, and propositional logic glue. Compiled from FPF (First Principles Framework).
+Version: 1.4.4
+Summary: Agentic thinking map for bounded LLM traversal, with TTL evidence decay, deterministic guards, and propositional logic. Compiled from FPF (First Principles Framework).
 Author-email: "prichindel.com" <igareosh@igareosh.com>
 License-Expression: MIT
-Project-URL: Homepage, https://github.com/igareosh/prichindel.com-agentic-thinking-map
-Project-URL: Repository, https://github.com/igareosh/prichindel.com-agentic-thinking-map
-Project-URL: Documentation, https://github.com/igareosh/prichindel.com-agentic-thinking-map#readme
-Project-URL: Issues, https://github.com/igareosh/prichindel.com-agentic-thinking-map/issues
+Project-URL: Homepage, https://github.com/igareosh/fpf-agentic-thinking-map
+Project-URL: Repository, https://github.com/igareosh/fpf-agentic-thinking-map
+Project-URL: Documentation, https://github.com/igareosh/fpf-agentic-thinking-map#readme
+Project-URL: Issues, https://github.com/igareosh/fpf-agentic-thinking-map/issues
 Keywords: agentic,thinking-map,llm,reasoning,propositional-logic,evidence-decay,ttl,guards,gates,semantic-map,fpf
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Developers
@@ -34,9 +34,9 @@ A Python package that gives a model a bounded move board instead of a giant fram
 
 ## Why this exists
 
-FPF is valuable, but it is large, clumsy at runtime, and poorly shaped for direct model consumption. A human can read a 51k-line framework, understand its distinctions, and apply them carefully. A model usually does something else: it absorbs the vocabulary, performs the tone of the framework, and still drifts on the actual task.
+FPF is valuable, but it is large at runtime and not well shaped for direct model consumption. A human can read a 51k-line framework, understand its distinctions, and apply them carefully. A model often does something narrower: it absorbs the vocabulary, mirrors the posture of rigor, and still drifts on the actual task.
 
-This package exists because the useful part is not making the model sound more scientific. The useful part is compiling the parts of FPF that help operational decisions into something small, explicit, and inspectable. We took what mattered for bounded traversal, left out what would bloat or bias the model, and evolved the result as publishers of a practical library rather than trying to reproduce the whole upstream framework inside another AI mega-system.
+This package exists because the useful part is not making the model sound more scientific. The useful part is compiling the parts of FPF that help operational decisions into something small, explicit, and inspectable. We kept the parts that matter for bounded traversal, left out parts that would bloat or bias the model, and published the result as a practical library rather than as a reproduction of the full upstream framework.
 
 The goal is simple: give the model enough structure to behave understandably, without building a cage so elaborate that it becomes another source of drift.
 
@@ -53,7 +53,7 @@ In practice this does two useful things:
 - it reduces unexplained drift by moving state tracking and hard checks out of freeform model reasoning
 - it gives the model simple, understandable outcomes such as `CONTINUE`, `COLLECT_EVIDENCE`, `BRIDGE`, `IDLE`, `ESCALATE`, instead of making it reconstruct its own epistemic condition from scratch
 
-This is not a panacea. Models still miss information. They still drift. But with a bounded traversal map, the failure mode becomes much easier to explain: missing evidence, wrong context, blocked move, stale basis, unlicensed bridge. The weirdness gets smaller because the state is smaller.
+This is not a panacea. Models still miss information. They still drift. With a bounded traversal map, however, the failure mode becomes easier to explain: missing evidence, wrong context, blocked move, stale basis, unlicensed bridge. The state is smaller, so the failure surface is easier to inspect.
 
 ## Provable practical gains
 
@@ -65,7 +65,7 @@ The improvements here are intentionally simple and operational:
 - smaller runtime payload, because the model gets a slice, not a corpus
 - easier debugging, because outcomes are discrete and inspectable
 
-That is the whole point: practical gain, not intellectual theater.
+That is the whole point: practical gain, stated plainly and checked in code.
 
 ## Quick start
 
@@ -105,7 +105,7 @@ fpf_thinking_map/
 
 `verify.py` proves the engine's own logic is internally consistent. It doesn't prove the compiled map covers the breadth of the original FPF spec — `examples.py` has one domain, five scenarios. `dev_mcp/` is an MCP server for constructing scenarios ad hoc and driving them against the documents that already ground FPF semantics in this repo: `SOURCES.md` (which spec section each primitive is supposed to enforce), `FPF_SOURCE_TO_CODE_RELATION_AUDIT.md` (a cited 50-item gap backlog), and `ADVISORIES.md` (deliberate-minimalism findings for integrators — not defects, but real defaults you should know about before assuming they match your domain).
 
-Not shipped in the package — `pyproject.toml` only builds `fpf_thinking_map*`, so this stays a repo-only dev tool by construction, for whoever's interested enough to dig past `pip install`. `run_scenario` requires a `scope`: `"core"` for testing this library's own shipped primitives (our responsibility, our tracking), `"user-extension"` for testing a domain map built on top (your responsibility, your repo). Full docs, install steps, self-test, worked example: [dev_mcp/README.md](dev_mcp/README.md).
+Not shipped in the package — `pyproject.toml` only builds `fpf_thinking_map*`, so this stays a repo-only development tool by construction. `run_scenario` requires a `scope`: `"core"` for testing this library's own shipped primitives (publisher tracking in this repo), `"user-extension"` for testing a domain map built on top (consumer tracking in the integrating repo). Full docs, install steps, self-test, and a worked example are in [dev_mcp/README.md](dev_mcp/README.md).
 
 ## Relationship to ailev/FPF
 
@@ -164,7 +164,7 @@ fpf does not ship better reasoning. It ships **inspectability**: did the agent f
 
 Take the stagnation counter as the concrete case. It bounds repetition — but only if the integration maps one real attempt to one `step()` call, and only adds evidence when something genuinely new was found. Whether that actually catches a real LLM thrashing depends entirely on whether the calling harness wires evidence honestly, not just "a tool returned something." That wiring discipline lives outside this library, in whatever integrates it — an agent loop, an MCP server, application code. fpf can't verify that discipline was followed; it can only guarantee that if it was, repetition is bounded.
 
-That boundary is the correct seam, not a gap to apologize for. Judging whether a piece of evidence is actually meaningful is a semantic question, and semantic questions need prompting, an LLM judge, or domain logic to answer — which is exactly where that belongs: outside fpf, at the evidence-wiring layer, not folded into a library whose entire value is staying small and deterministic. If you want semantics and clever prompting, that's the plug-in point.
+That boundary is the correct seam. Judging whether a piece of evidence is actually meaningful is a semantic question, and semantic questions need prompting, an LLM judge, or domain logic to answer. That work belongs outside `fpf`, at the evidence-wiring layer, not inside a library whose value comes from staying small and deterministic. If a project needs richer semantics, add them at that integration point.
 
 **This is also why Memory-Augmented Generation (MAG) is rejected as fpf's own architecture, deliberately and permanently.** MAG — retrieval, embeddings, cross-session recall — solves a different problem (what did we discuss three sessions ago) than fpf solves (is this move lawful right now), and it needs exactly the dependency profile this library rules out by design. That is a scope boundary, not a verdict on MAG as a technique: a MAG system is a legitimate thing to run *upstream* of fpf. Whatever it retrieves becomes an evidence_id in `RuntimeBinding.current_evidence` like any other — fpf doesn't care how evidence was produced, only whether it's present, fresh, and licensed. Memory belongs at the evidence-wiring layer, alongside every other semantic judgment this library deliberately doesn't make.
 
@@ -181,7 +181,7 @@ The core advantage is not "more theory." It is less runtime burden.
 
 Without a compiled map, the model keeps re-addressing its own run: am I allowed to move, did I already satisfy the gate, am I missing evidence, am I in the wrong context, am I done or blocked? That self-management loop is where a lot of bad agent behavior comes from.
 
-This package turns that loop into a small stateful instrument panel. The model sees what can fire, what cannot, and why. That is enough of an operating surface for many practical agent tasks. Not a panacea, not a grand theory of intelligence, just enough window and file-handles for the model to open the right thing without smashing the house.
+This package turns that loop into a small stateful instrument panel. The model sees what can fire, what cannot, and why. That is enough of an operating surface for many practical agent tasks: not a grand theory of intelligence, just a narrow surface that helps the model choose the next lawful move.
 
 The bottleneck was never raw model capability — it's self-management overhead eating the capability that's already there. Most orgs running these models, at any scale, hit that ceiling: infra and process that never actually asked the model for full capacity, so upgrading the model changes nothing. This library doesn't make the model smarter. It shrinks what the model has to hold in its head at any one step, so whatever capability is actually there gets spent on the real problem instead of on self-management overhead.
 
@@ -215,7 +215,7 @@ The model's job shrinks from "figure out the entire epistemic state of your own
 
 - **Bridge crossing is enforced, not just advertised** — `ActiveState.cross_bridge()` / `ThinkingMapTraversal.attempt_bridge()` actually perform a cross-context hop and check `substitution_license` against `risk_level` before mutating state. An unlicensed bridge under `high`/`critical` risk is refused (`ESCALATE`), not silently allowed. Before this, `bridge_options()` was advisory metadata only — the model decided for itself whether a lossy translation was acceptable.
 - **`include_full_state=False`** — `step()` can now ship the scoped `slice()` alone, without the whole board bolted on. Default stays `True`; opt in when the caller already knows its `transition_id` and wants the lean payload.
-- 21/21 self-verification checks (`python -m fpf_thinking_map.verify`), two new: bridge crossing and lean-slice payload shape.
+- 21/21 self-verification checks at release time (`python -m fpf_thinking_map.verify`), two new: bridge crossing and lean-slice payload shape.
 
 ## v1.4.0 changes
 
@@ -313,7 +313,7 @@ Built with Claude Code (Anthropic claude-sonnet-4-6). Tested and verified to wor
 | **OpenAI GPT** (GPT-4o, o1, o3) | Works | Used for the 50-item source-to-code relation audit. Reads the primitives, logic rules, and prompt state correctly. |
 | **Any model that reads JSON and follows structured constraints** | Should work | The package outputs plain dicts. No model-specific prompting. |
 
-This is not a compliance seal. It means: we used these models against this package and they produced correct, usable results. The per-move slice is small enough for mid-tier models. The logic and guard outputs are plain JSON — no special tokenization or prompt format required.
+This is not a compliance certification. It means the package was exercised against these model families in this repo and produced correct, usable results. The per-move slice is small enough for mid-tier models. The logic and guard outputs are plain JSON, with no model-specific prompt format required.
 
 ## Why release this
 
@@ -321,8 +321,8 @@ We release this because it is useful beyond our own stack.
 
 - It captures a practical subset of FPF in a form models can actually use.
 - It gives agent builders a small constraint surface instead of another giant AI framework.
-- It helps turn model failure from mystical drift into inspectable state.
-- It stays intentionally narrow, so it can remain legible instead of becoming another overbuilt "agent platform."
+- It helps turn model failure from opaque drift into inspectable state.
+- It stays intentionally narrow so the package remains legible and easy to audit.
 
 ## Credits
 

{fpf_thinking_map-1.4.3 → fpf_thinking_map-1.4.4}/README.md

@@ -8,9 +8,9 @@ A Python package that gives a model a bounded move board instead of a giant fram
 
 ## Why this exists
 
-FPF is valuable, but it is large, clumsy at runtime, and poorly shaped for direct model consumption. A human can read a 51k-line framework, understand its distinctions, and apply them carefully. A model usually does something else: it absorbs the vocabulary, performs the tone of the framework, and still drifts on the actual task.
+FPF is valuable, but it is large at runtime and not well shaped for direct model consumption. A human can read a 51k-line framework, understand its distinctions, and apply them carefully. A model often does something narrower: it absorbs the vocabulary, mirrors the posture of rigor, and still drifts on the actual task.
 
-This package exists because the useful part is not making the model sound more scientific. The useful part is compiling the parts of FPF that help operational decisions into something small, explicit, and inspectable. We took what mattered for bounded traversal, left out what would bloat or bias the model, and evolved the result as publishers of a practical library rather than trying to reproduce the whole upstream framework inside another AI mega-system.
+This package exists because the useful part is not making the model sound more scientific. The useful part is compiling the parts of FPF that help operational decisions into something small, explicit, and inspectable. We kept the parts that matter for bounded traversal, left out parts that would bloat or bias the model, and published the result as a practical library rather than as a reproduction of the full upstream framework.
 
 The goal is simple: give the model enough structure to behave understandably, without building a cage so elaborate that it becomes another source of drift.
 
@@ -27,7 +27,7 @@ In practice this does two useful things:
 - it reduces unexplained drift by moving state tracking and hard checks out of freeform model reasoning
 - it gives the model simple, understandable outcomes such as `CONTINUE`, `COLLECT_EVIDENCE`, `BRIDGE`, `IDLE`, `ESCALATE`, instead of making it reconstruct its own epistemic condition from scratch
 
-This is not a panacea. Models still miss information. They still drift. But with a bounded traversal map, the failure mode becomes much easier to explain: missing evidence, wrong context, blocked move, stale basis, unlicensed bridge. The weirdness gets smaller because the state is smaller.
+This is not a panacea. Models still miss information. They still drift. With a bounded traversal map, however, the failure mode becomes easier to explain: missing evidence, wrong context, blocked move, stale basis, unlicensed bridge. The state is smaller, so the failure surface is easier to inspect.
 
 ## Provable practical gains
 
@@ -39,7 +39,7 @@ The improvements here are intentionally simple and operational:
 - smaller runtime payload, because the model gets a slice, not a corpus
 - easier debugging, because outcomes are discrete and inspectable
 
-That is the whole point: practical gain, not intellectual theater.
+That is the whole point: practical gain, stated plainly and checked in code.
 
 ## Quick start
 
@@ -79,7 +79,7 @@ fpf_thinking_map/
 
 `verify.py` proves the engine's own logic is internally consistent. It doesn't prove the compiled map covers the breadth of the original FPF spec — `examples.py` has one domain, five scenarios. `dev_mcp/` is an MCP server for constructing scenarios ad hoc and driving them against the documents that already ground FPF semantics in this repo: `SOURCES.md` (which spec section each primitive is supposed to enforce), `FPF_SOURCE_TO_CODE_RELATION_AUDIT.md` (a cited 50-item gap backlog), and `ADVISORIES.md` (deliberate-minimalism findings for integrators — not defects, but real defaults you should know about before assuming they match your domain).
 
-Not shipped in the package — `pyproject.toml` only builds `fpf_thinking_map*`, so this stays a repo-only dev tool by construction, for whoever's interested enough to dig past `pip install`. `run_scenario` requires a `scope`: `"core"` for testing this library's own shipped primitives (our responsibility, our tracking), `"user-extension"` for testing a domain map built on top (your responsibility, your repo). Full docs, install steps, self-test, worked example: [dev_mcp/README.md](dev_mcp/README.md).
+Not shipped in the package — `pyproject.toml` only builds `fpf_thinking_map*`, so this stays a repo-only development tool by construction. `run_scenario` requires a `scope`: `"core"` for testing this library's own shipped primitives (publisher tracking in this repo), `"user-extension"` for testing a domain map built on top (consumer tracking in the integrating repo). Full docs, install steps, self-test, and a worked example are in [dev_mcp/README.md](dev_mcp/README.md).
 
 ## Relationship to ailev/FPF
 
@@ -138,7 +138,7 @@ fpf does not ship better reasoning. It ships **inspectability**: did the agent f
 
 Take the stagnation counter as the concrete case. It bounds repetition — but only if the integration maps one real attempt to one `step()` call, and only adds evidence when something genuinely new was found. Whether that actually catches a real LLM thrashing depends entirely on whether the calling harness wires evidence honestly, not just "a tool returned something." That wiring discipline lives outside this library, in whatever integrates it — an agent loop, an MCP server, application code. fpf can't verify that discipline was followed; it can only guarantee that if it was, repetition is bounded.
 
-That boundary is the correct seam, not a gap to apologize for. Judging whether a piece of evidence is actually meaningful is a semantic question, and semantic questions need prompting, an LLM judge, or domain logic to answer — which is exactly where that belongs: outside fpf, at the evidence-wiring layer, not folded into a library whose entire value is staying small and deterministic. If you want semantics and clever prompting, that's the plug-in point.
+That boundary is the correct seam. Judging whether a piece of evidence is actually meaningful is a semantic question, and semantic questions need prompting, an LLM judge, or domain logic to answer. That work belongs outside `fpf`, at the evidence-wiring layer, not inside a library whose value comes from staying small and deterministic. If a project needs richer semantics, add them at that integration point.
 
 **This is also why Memory-Augmented Generation (MAG) is rejected as fpf's own architecture, deliberately and permanently.** MAG — retrieval, embeddings, cross-session recall — solves a different problem (what did we discuss three sessions ago) than fpf solves (is this move lawful right now), and it needs exactly the dependency profile this library rules out by design. That is a scope boundary, not a verdict on MAG as a technique: a MAG system is a legitimate thing to run *upstream* of fpf. Whatever it retrieves becomes an evidence_id in `RuntimeBinding.current_evidence` like any other — fpf doesn't care how evidence was produced, only whether it's present, fresh, and licensed. Memory belongs at the evidence-wiring layer, alongside every other semantic judgment this library deliberately doesn't make.
 
@@ -155,7 +155,7 @@ The core advantage is not "more theory." It is less runtime burden.
 
 Without a compiled map, the model keeps re-addressing its own run: am I allowed to move, did I already satisfy the gate, am I missing evidence, am I in the wrong context, am I done or blocked? That self-management loop is where a lot of bad agent behavior comes from.
 
-This package turns that loop into a small stateful instrument panel. The model sees what can fire, what cannot, and why. That is enough of an operating surface for many practical agent tasks. Not a panacea, not a grand theory of intelligence, just enough window and file-handles for the model to open the right thing without smashing the house.
+This package turns that loop into a small stateful instrument panel. The model sees what can fire, what cannot, and why. That is enough of an operating surface for many practical agent tasks: not a grand theory of intelligence, just a narrow surface that helps the model choose the next lawful move.
 
 The bottleneck was never raw model capability — it's self-management overhead eating the capability that's already there. Most orgs running these models, at any scale, hit that ceiling: infra and process that never actually asked the model for full capacity, so upgrading the model changes nothing. This library doesn't make the model smarter. It shrinks what the model has to hold in its head at any one step, so whatever capability is actually there gets spent on the real problem instead of on self-management overhead.
 
@@ -189,7 +189,7 @@ The model's job shrinks from "figure out the entire epistemic state of your own
 
 - **Bridge crossing is enforced, not just advertised** — `ActiveState.cross_bridge()` / `ThinkingMapTraversal.attempt_bridge()` actually perform a cross-context hop and check `substitution_license` against `risk_level` before mutating state. An unlicensed bridge under `high`/`critical` risk is refused (`ESCALATE`), not silently allowed. Before this, `bridge_options()` was advisory metadata only — the model decided for itself whether a lossy translation was acceptable.
 - **`include_full_state=False`** — `step()` can now ship the scoped `slice()` alone, without the whole board bolted on. Default stays `True`; opt in when the caller already knows its `transition_id` and wants the lean payload.
-- 21/21 self-verification checks (`python -m fpf_thinking_map.verify`), two new: bridge crossing and lean-slice payload shape.
+- 21/21 self-verification checks at release time (`python -m fpf_thinking_map.verify`), two new: bridge crossing and lean-slice payload shape.
 
 ## v1.4.0 changes
 
@@ -287,7 +287,7 @@ Built with Claude Code (Anthropic claude-sonnet-4-6). Tested and verified to wor
 | **OpenAI GPT** (GPT-4o, o1, o3) | Works | Used for the 50-item source-to-code relation audit. Reads the primitives, logic rules, and prompt state correctly. |
 | **Any model that reads JSON and follows structured constraints** | Should work | The package outputs plain dicts. No model-specific prompting. |
 
-This is not a compliance seal. It means: we used these models against this package and they produced correct, usable results. The per-move slice is small enough for mid-tier models. The logic and guard outputs are plain JSON — no special tokenization or prompt format required.
+This is not a compliance certification. It means the package was exercised against these model families in this repo and produced correct, usable results. The per-move slice is small enough for mid-tier models. The logic and guard outputs are plain JSON, with no model-specific prompt format required.
 
 ## Why release this
 
@@ -295,8 +295,8 @@ We release this because it is useful beyond our own stack.
 
 - It captures a practical subset of FPF in a form models can actually use.
 - It gives agent builders a small constraint surface instead of another giant AI framework.
-- It helps turn model failure from mystical drift into inspectable state.
-- It stays intentionally narrow, so it can remain legible instead of becoming another overbuilt "agent platform."
+- It helps turn model failure from opaque drift into inspectable state.
+- It stays intentionally narrow so the package remains legible and easy to audit.
 
 ## Credits
 

{fpf_thinking_map-1.4.3 → fpf_thinking_map-1.4.4}/fpf_thinking_map/README.md

@@ -1,6 +1,6 @@
 # FPF Thinking Map
 
-This folder contains a Python package that helps an AI model make bounded decisions step by step. It combines a compiled subset of FPF with basic logic operations from computer science so the model can read a small move board instead of digesting a giant framework at runtime.
+This folder contains a Python package that helps an AI model make bounded decisions step by step. It combines a compiled subset of FPF with basic logic operations from computer science so the model can read a small move board instead of digesting a large framework at runtime.
 
 No external dependencies. Pure Python 3.12+. No pip install needed.
 
@@ -15,11 +15,11 @@ This package gives the model a small, structured board to reason on. The board h
 
 The model reads the board, then picks from a fixed set of moves: continue, ask, abstain, escalate, collect evidence, etc.
 
-The point is not to make the model "more intelligent." The point is to make its behavior smaller, more understandable, and less likely to drift for stupid reasons.
+The point is not to make the model "more intelligent." The point is to make its behavior smaller, more understandable, and less likely to drift for ordinary, inspectable reasons.
 
 ## Why this package exists next to FPF
 
-FPF is strong material for humans, but too big and too clumsy to hand to a model raw and expect clean operational behavior. A model tends to absorb the vocabulary, imitate the posture of rigor, and still miss the simple thing it needed to do.
+FPF is strong material for humans, but too large to hand to a model raw and expect clean operational behavior. A model tends to absorb the vocabulary, imitate the posture of rigor, and still miss the simple thing it needed to do.
 
 So we did not port the whole framework. We extracted what was useful for bounded traversal, made it executable, and left out the parts that would inflate runtime payload or trigger open-ended academic-pattern generation. This package is not "FPF but more." It is "the part of FPF that helps agents behave better, compiled into something they can actually use."
 
@@ -50,7 +50,7 @@ fpf_thinking_map/
 ├── guards.py                9 deterministic guards the model cannot break
 ├── logic.py                 6 logic operators + EvidenceFresh + decision rules
 ├── traversal.py             Step engine with 10 lawful outcomes (incl. IDLE, BRIDGE)
-├── verify.py                Self-test: run it, if 21/21 pass, package works
+├── verify.py                Self-test: run it, if 22/22 pass, package works
 │
 ├── examples.py              5 deploy decision scenarios (all features in action)
 │
@@ -264,7 +264,7 @@ outcome = engine.step(state, transition_id="start_to_reviewed")
 - Not a replacement for the full FPF spec
 - Not a symbolic AI / expert system (the LLM interprets; logic + guards constrain)
 - Not a framework to build on top of — it is a small self-contained package
-- Not a panacea for agent drift; it reduces and explains drift, it does not eliminate it
+- Not a panacea for agent drift; it reduces and explains drift, but it does not eliminate it
 
 ## Known design decisions
 
@@ -272,4 +272,4 @@ outcome = engine.step(state, transition_id="start_to_reviewed")
 - `demo_walk()` auto-fires the first available transition. It is for testing and examples only, not for operational use. In real use, the LLM calls `step()` and `attempt_transition()` with explicit choices.
 - Publications are registered on the map but stay out of the step/guard/logic path. They are for publish-type moves only.
 
-prichindel.com | 2026-06-26 | v1.1.2
+prichindel.com | 2026-07-08 | v1.4.3

{fpf_thinking_map-1.4.3 → fpf_thinking_map-1.4.4}/fpf_thinking_map/SOURCES.md

@@ -70,4 +70,4 @@ We applied the same pattern:
 - **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)
+- **Repository**: [github.com/igareosh/fpf-agentic-thinking-map](https://github.com/igareosh/fpf-agentic-thinking-map)

{fpf_thinking_map-1.4.3 → fpf_thinking_map-1.4.4}/fpf_thinking_map.egg-info/PKG-INFO

@@ -1,13 +1,13 @@
 Metadata-Version: 2.4
 Name: fpf-thinking-map
-Version: 1.4.3
-Summary: Agentic thinking map — structured reasoning constraints for LLMs with TTL evidence decay, deterministic guards, and propositional logic glue. Compiled from FPF (First Principles Framework).
+Version: 1.4.4
+Summary: Agentic thinking map for bounded LLM traversal, with TTL evidence decay, deterministic guards, and propositional logic. Compiled from FPF (First Principles Framework).
 Author-email: "prichindel.com" <igareosh@igareosh.com>
 License-Expression: MIT
-Project-URL: Homepage, https://github.com/igareosh/prichindel.com-agentic-thinking-map
-Project-URL: Repository, https://github.com/igareosh/prichindel.com-agentic-thinking-map
-Project-URL: Documentation, https://github.com/igareosh/prichindel.com-agentic-thinking-map#readme
-Project-URL: Issues, https://github.com/igareosh/prichindel.com-agentic-thinking-map/issues
+Project-URL: Homepage, https://github.com/igareosh/fpf-agentic-thinking-map
+Project-URL: Repository, https://github.com/igareosh/fpf-agentic-thinking-map
+Project-URL: Documentation, https://github.com/igareosh/fpf-agentic-thinking-map#readme
+Project-URL: Issues, https://github.com/igareosh/fpf-agentic-thinking-map/issues
 Keywords: agentic,thinking-map,llm,reasoning,propositional-logic,evidence-decay,ttl,guards,gates,semantic-map,fpf
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Developers
@@ -34,9 +34,9 @@ A Python package that gives a model a bounded move board instead of a giant fram
 
 ## Why this exists
 
-FPF is valuable, but it is large, clumsy at runtime, and poorly shaped for direct model consumption. A human can read a 51k-line framework, understand its distinctions, and apply them carefully. A model usually does something else: it absorbs the vocabulary, performs the tone of the framework, and still drifts on the actual task.
+FPF is valuable, but it is large at runtime and not well shaped for direct model consumption. A human can read a 51k-line framework, understand its distinctions, and apply them carefully. A model often does something narrower: it absorbs the vocabulary, mirrors the posture of rigor, and still drifts on the actual task.
 
-This package exists because the useful part is not making the model sound more scientific. The useful part is compiling the parts of FPF that help operational decisions into something small, explicit, and inspectable. We took what mattered for bounded traversal, left out what would bloat or bias the model, and evolved the result as publishers of a practical library rather than trying to reproduce the whole upstream framework inside another AI mega-system.
+This package exists because the useful part is not making the model sound more scientific. The useful part is compiling the parts of FPF that help operational decisions into something small, explicit, and inspectable. We kept the parts that matter for bounded traversal, left out parts that would bloat or bias the model, and published the result as a practical library rather than as a reproduction of the full upstream framework.
 
 The goal is simple: give the model enough structure to behave understandably, without building a cage so elaborate that it becomes another source of drift.
 
@@ -53,7 +53,7 @@ In practice this does two useful things:
 - it reduces unexplained drift by moving state tracking and hard checks out of freeform model reasoning
 - it gives the model simple, understandable outcomes such as `CONTINUE`, `COLLECT_EVIDENCE`, `BRIDGE`, `IDLE`, `ESCALATE`, instead of making it reconstruct its own epistemic condition from scratch
 
-This is not a panacea. Models still miss information. They still drift. But with a bounded traversal map, the failure mode becomes much easier to explain: missing evidence, wrong context, blocked move, stale basis, unlicensed bridge. The weirdness gets smaller because the state is smaller.
+This is not a panacea. Models still miss information. They still drift. With a bounded traversal map, however, the failure mode becomes easier to explain: missing evidence, wrong context, blocked move, stale basis, unlicensed bridge. The state is smaller, so the failure surface is easier to inspect.
 
 ## Provable practical gains
 
@@ -65,7 +65,7 @@ The improvements here are intentionally simple and operational:
 - smaller runtime payload, because the model gets a slice, not a corpus
 - easier debugging, because outcomes are discrete and inspectable
 
-That is the whole point: practical gain, not intellectual theater.
+That is the whole point: practical gain, stated plainly and checked in code.
 
 ## Quick start
 
@@ -105,7 +105,7 @@ fpf_thinking_map/
 
 `verify.py` proves the engine's own logic is internally consistent. It doesn't prove the compiled map covers the breadth of the original FPF spec — `examples.py` has one domain, five scenarios. `dev_mcp/` is an MCP server for constructing scenarios ad hoc and driving them against the documents that already ground FPF semantics in this repo: `SOURCES.md` (which spec section each primitive is supposed to enforce), `FPF_SOURCE_TO_CODE_RELATION_AUDIT.md` (a cited 50-item gap backlog), and `ADVISORIES.md` (deliberate-minimalism findings for integrators — not defects, but real defaults you should know about before assuming they match your domain).
 
-Not shipped in the package — `pyproject.toml` only builds `fpf_thinking_map*`, so this stays a repo-only dev tool by construction, for whoever's interested enough to dig past `pip install`. `run_scenario` requires a `scope`: `"core"` for testing this library's own shipped primitives (our responsibility, our tracking), `"user-extension"` for testing a domain map built on top (your responsibility, your repo). Full docs, install steps, self-test, worked example: [dev_mcp/README.md](dev_mcp/README.md).
+Not shipped in the package — `pyproject.toml` only builds `fpf_thinking_map*`, so this stays a repo-only development tool by construction. `run_scenario` requires a `scope`: `"core"` for testing this library's own shipped primitives (publisher tracking in this repo), `"user-extension"` for testing a domain map built on top (consumer tracking in the integrating repo). Full docs, install steps, self-test, and a worked example are in [dev_mcp/README.md](dev_mcp/README.md).
 
 ## Relationship to ailev/FPF
 
@@ -164,7 +164,7 @@ fpf does not ship better reasoning. It ships **inspectability**: did the agent f
 
 Take the stagnation counter as the concrete case. It bounds repetition — but only if the integration maps one real attempt to one `step()` call, and only adds evidence when something genuinely new was found. Whether that actually catches a real LLM thrashing depends entirely on whether the calling harness wires evidence honestly, not just "a tool returned something." That wiring discipline lives outside this library, in whatever integrates it — an agent loop, an MCP server, application code. fpf can't verify that discipline was followed; it can only guarantee that if it was, repetition is bounded.
 
-That boundary is the correct seam, not a gap to apologize for. Judging whether a piece of evidence is actually meaningful is a semantic question, and semantic questions need prompting, an LLM judge, or domain logic to answer — which is exactly where that belongs: outside fpf, at the evidence-wiring layer, not folded into a library whose entire value is staying small and deterministic. If you want semantics and clever prompting, that's the plug-in point.
+That boundary is the correct seam. Judging whether a piece of evidence is actually meaningful is a semantic question, and semantic questions need prompting, an LLM judge, or domain logic to answer. That work belongs outside `fpf`, at the evidence-wiring layer, not inside a library whose value comes from staying small and deterministic. If a project needs richer semantics, add them at that integration point.
 
 **This is also why Memory-Augmented Generation (MAG) is rejected as fpf's own architecture, deliberately and permanently.** MAG — retrieval, embeddings, cross-session recall — solves a different problem (what did we discuss three sessions ago) than fpf solves (is this move lawful right now), and it needs exactly the dependency profile this library rules out by design. That is a scope boundary, not a verdict on MAG as a technique: a MAG system is a legitimate thing to run *upstream* of fpf. Whatever it retrieves becomes an evidence_id in `RuntimeBinding.current_evidence` like any other — fpf doesn't care how evidence was produced, only whether it's present, fresh, and licensed. Memory belongs at the evidence-wiring layer, alongside every other semantic judgment this library deliberately doesn't make.
 
@@ -181,7 +181,7 @@ The core advantage is not "more theory." It is less runtime burden.
 
 Without a compiled map, the model keeps re-addressing its own run: am I allowed to move, did I already satisfy the gate, am I missing evidence, am I in the wrong context, am I done or blocked? That self-management loop is where a lot of bad agent behavior comes from.
 
-This package turns that loop into a small stateful instrument panel. The model sees what can fire, what cannot, and why. That is enough of an operating surface for many practical agent tasks. Not a panacea, not a grand theory of intelligence, just enough window and file-handles for the model to open the right thing without smashing the house.
+This package turns that loop into a small stateful instrument panel. The model sees what can fire, what cannot, and why. That is enough of an operating surface for many practical agent tasks: not a grand theory of intelligence, just a narrow surface that helps the model choose the next lawful move.
 
 The bottleneck was never raw model capability — it's self-management overhead eating the capability that's already there. Most orgs running these models, at any scale, hit that ceiling: infra and process that never actually asked the model for full capacity, so upgrading the model changes nothing. This library doesn't make the model smarter. It shrinks what the model has to hold in its head at any one step, so whatever capability is actually there gets spent on the real problem instead of on self-management overhead.
 
@@ -215,7 +215,7 @@ The model's job shrinks from "figure out the entire epistemic state of your own
 
 - **Bridge crossing is enforced, not just advertised** — `ActiveState.cross_bridge()` / `ThinkingMapTraversal.attempt_bridge()` actually perform a cross-context hop and check `substitution_license` against `risk_level` before mutating state. An unlicensed bridge under `high`/`critical` risk is refused (`ESCALATE`), not silently allowed. Before this, `bridge_options()` was advisory metadata only — the model decided for itself whether a lossy translation was acceptable.
 - **`include_full_state=False`** — `step()` can now ship the scoped `slice()` alone, without the whole board bolted on. Default stays `True`; opt in when the caller already knows its `transition_id` and wants the lean payload.
-- 21/21 self-verification checks (`python -m fpf_thinking_map.verify`), two new: bridge crossing and lean-slice payload shape.
+- 21/21 self-verification checks at release time (`python -m fpf_thinking_map.verify`), two new: bridge crossing and lean-slice payload shape.
 
 ## v1.4.0 changes
 
@@ -313,7 +313,7 @@ Built with Claude Code (Anthropic claude-sonnet-4-6). Tested and verified to wor
 | **OpenAI GPT** (GPT-4o, o1, o3) | Works | Used for the 50-item source-to-code relation audit. Reads the primitives, logic rules, and prompt state correctly. |
 | **Any model that reads JSON and follows structured constraints** | Should work | The package outputs plain dicts. No model-specific prompting. |
 
-This is not a compliance seal. It means: we used these models against this package and they produced correct, usable results. The per-move slice is small enough for mid-tier models. The logic and guard outputs are plain JSON — no special tokenization or prompt format required.
+This is not a compliance certification. It means the package was exercised against these model families in this repo and produced correct, usable results. The per-move slice is small enough for mid-tier models. The logic and guard outputs are plain JSON, with no model-specific prompt format required.
 
 ## Why release this
 
@@ -321,8 +321,8 @@ We release this because it is useful beyond our own stack.
 
 - It captures a practical subset of FPF in a form models can actually use.
 - It gives agent builders a small constraint surface instead of another giant AI framework.
-- It helps turn model failure from mystical drift into inspectable state.
-- It stays intentionally narrow, so it can remain legible instead of becoming another overbuilt "agent platform."
+- It helps turn model failure from opaque drift into inspectable state.
+- It stays intentionally narrow so the package remains legible and easy to audit.
 
 ## Credits
 

{fpf_thinking_map-1.4.3 → fpf_thinking_map-1.4.4}/pyproject.toml

@@ -1,7 +1,7 @@
 [project]
 name = "fpf-thinking-map"
-version = "1.4.3"
-description = "Agentic thinking map — structured reasoning constraints for LLMs with TTL evidence decay, deterministic guards, and propositional logic glue. Compiled from FPF (First Principles Framework)."
+version = "1.4.4"
+description = "Agentic thinking map for bounded LLM traversal, with TTL evidence decay, deterministic guards, and propositional logic. Compiled from FPF (First Principles Framework)."
 readme = "README.md"
 license = "MIT"
 requires-python = ">=3.12"
@@ -27,10 +27,10 @@ classifiers = [
 ]
 
 [project.urls]
-Homepage = "https://github.com/igareosh/prichindel.com-agentic-thinking-map"
-Repository = "https://github.com/igareosh/prichindel.com-agentic-thinking-map"
-Documentation = "https://github.com/igareosh/prichindel.com-agentic-thinking-map#readme"
-Issues = "https://github.com/igareosh/prichindel.com-agentic-thinking-map/issues"
+Homepage = "https://github.com/igareosh/fpf-agentic-thinking-map"
+Repository = "https://github.com/igareosh/fpf-agentic-thinking-map"
+Documentation = "https://github.com/igareosh/fpf-agentic-thinking-map#readme"
+Issues = "https://github.com/igareosh/fpf-agentic-thinking-map/issues"
 
 [build-system]
 requires = ["setuptools>=68.0"]