ARCHITECTURE DIAGRAMS
Flows, gates, and transitions
Connected diagrams taken directly from the library architecture. Follow the arrows: from map and state to the agent slice, deterministic checking, and result.
Module map
Each file depends only on the previous one in the chain — no circular dependencies, no hidden couplings.
primitives.py
10 primitives, 5 floorsstate.py
binding + active state + sliceguards.py + logic.py
12 guards, 6 operatorstraversal.py
step engine, 11 declared outcomesOn top of that sit examples.py (8 shipped scenarios) and verify.py (35 automated checks) — not claims, but code you run yourself:
python -m fpf_thinking_map.verify
python -m fpf_thinking_map.examplesSemantic floors and their expiry
Nothing is "memory" with no limit except the structural layer at floor 0. Everything else has its own clock, and the rate is not the same everywhere.
ContextPrimitive, ContextBridge, RolePrimitive, TransitionPrimitive, gate definition
TTL: ∞ — never expiresRole assignment, commitment, work plan
TTL: 10 stepsEvidence, trust tuple (fidelity × relevance)
TTL: max 1, F×R×8 stepsSpeech act, work, gate evaluation
TTL: 2 stepsPublication
TTL: inherited from sourceEleven declared outcomes, nine live
The engine declares 11 outcome types. 9 are live — reachable through code, directly verified, most of them from step() alone. BRIDGE is "live" only as a declaration — the real execution (attempt_bridge()) is a separate, separately licensed call.
CONTINUEliveABSTAINliveCOLLECT_EVIDENCEliveCHANGE_FRAMEliveIDLEliveESCALATEliveREVISE_PLANliveAWAITliveBRIDGEadvisory onlyASKdeclared, unreachablePUBLISHdeclared, unreachableASK and PUBLISH are declared in OutcomeKind and named in the module docstring — but no code returns them yet. This is not a hidden bug: it is checked directly in code, not merely inferred from docs, and we say so plainly.