fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 119954–119970

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 10:39:28 UTC · snapshot created 2026-10-03 10:40:04 UTC · last check 2026-10-03 11:15:11 UTC

G.13:9 - Common Anti‑Patterns and How to Avoid Them

  • Anti‑pattern: “Format == spec”. Treating an export schema (KG dump, JSON, RO‑Crate, etc.) as the normative definition. Remedy: Keep ExternalIndexCard / ClaimMapperCard / InteropSurface as the conceptual specification; treat serialisation as an appendix/tooling concern.

  • Anti‑pattern: Hidden scale invention. An embedding similarity becomes a “score” without explicit typing/binding. Remedy: Require ScaleEmbeddingSpecRef + edition pins and bind any derived features through CHR/CAL governing definitions.

  • Anti‑pattern: Implicit plane/context reuse. Reusing external concept graphs across contexts without explicit crossing pins. Remedy: Publish crossing visibility pins and cite bridge/plane governing definitions; never fuse contexts “inside the aligner”.

  • Anti‑pattern: Edition‑free dashboards. Feeding externally derived rows into dashboards without pinned editions/policies. Remedy: Pin ExternalIndexRef.edition and ClaimMapperRef.edition; emit RSCR triggers on changes.

  • Anti‑pattern: Interop asserts defaults. “Interop decides dominance regime / PortfolioMode.” Remedy: Treat defaults as citations only (the relevant governing definition is cited through G.Core.DefaultGoverningDefinitionIndex).