FPF Reference

Conceptual Prefixes (policy & registry)

E.10.P · Stable · Part E - The FPF Constitution and Authoring Guides

About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a fpf-memory product feature page.

How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Intent. Provide a compact, notation‑neutral registry and minting policy for conceptual prefixes — short shorthands that signal cognitive namespaces used throughout the Core.

Policy (normative).

  1. Purpose. A conceptual prefix exists to aid reasoning, not to name files, serialisations, or APIs. It labels a role in thought (e.g., meta‑type, calculus operator, relation family).
  2. Anchoring. Every prefix MUST be anchored to a Core extension patterns (CAL/LOG/CHR) or Kernel construct and documented in its Relations.
  3. No tool lock‑in. A prefix MUST NOT imply a particular notation or machine binding (see E.5.1–E.5.2).
  4. Minting rule. New prefixes are introduced by a DRR (E.9) that demonstrates (a) cross‑pattern need, (b) non‑overlap with existing prefixes, (c) alignment with Pillars P‑1/P‑5.
  5. Scope. Prefixes are globally reserved within the Core; domain patterns MAY mint local shorthands only inside their Contexts and MUST NOT collide with this registry.

Registered conceptual prefixes (Core).

  • U. — U.Types meta‑namespace (holons & primitives). Anchor: Kernel Part A.
  • Γ_ — Calculus operator family (by flavour: Γ_sys, Γ_epist, …). Anchor: Part B umbrella on Γ.
  • ut: — Universal relation family (e.g., PartOf sub‑relations). Anchor: A.14 (Mereology) — informative alias vocabulary.
  • tv: — Trace & Validation vocabulary (CT2R‑LOG): tv:AliasOf, tv:groundedBy. Anchor: B.3 (Trust & Assurance, LOG‑use).
  • ev: — Evidence hooks (bindings/roles). Anchor: A.10 / B.3 (Evidence Graph Referring).
  • mero: — Mereology trace types (internal labels: SumTrace / SetTrace / SliceTrace) used informatively in examples. Anchor: B.1 (Γ‑aggregation).

Conformance Checklist (E.10.P).

  • CC‑LEX‑P.1 New Core text SHALL NOT introduce an unregistered conceptual prefix.
  • CC‑LEX‑P.2 Each occurrence of a registered prefix SHALL cite its anchor pattern on first use in a section.
  • CC‑LEX‑P.3 Examples that expand a prefix into a concrete URI or syntax MUST mark the expansion informative and locate it in Tooling/Pedagogy.

Relations. Constrains E.5.1 (Lexical Firewall) & E.5.2 (Notational Independence); Depends on E.9 (DRR).

Keywords

  • prefixes
  • U.
  • Γ_
  • ut:
  • tv:
  • namespace
  • registry.

Relations

E.10.PconstrainsDevOps Lexical Firewall
E.10.PconstrainsNotational Independence
E.10.Poutline parentLEX-BUNDLE: Unified Lexical Rules for FPF
E.10.Poutline next siblingLexical Discipline for “Context” (D.CTX)
E.10.Pexplicit referenceDevOps Lexical Firewall
E.10.Pexplicit referenceNotational Independence
E.10.Pexplicit referenceEvidence Graph Referring (C-4)
E.10.Pexplicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
E.10.Pexplicit referenceDesign-Rationale Record (DRR) Method

Content

E.10.P:End