FPF Reference

Lexical Authoring & Evolution Protocol (LEX-AUTH)

Pattern E.15 · stable Part E - The FPF Constitution and Authoring Guides

Author patterns as evidence‑bearing epistemes, evolve them via governed open‑ended search, and publish an auditable trace that improves quality—not just compliance.

FPF patterns are the canon: they define the generative rules that other artifacts depend on. Teams need to change patterns as the SoTA moves, but ad‑hoc edits lead to drift, weak comparability, and brittle downstream updates. We need a method that (a) generates better alternatives, (b) selects them against explicit quality/assurance targets, and (c) publishes a machine‑ and human‑checkable trace that can be replayed, audited, and re‑run. (Built to cohere with DRR (E.9), LEX‑BUNDLE (E.10), Canonical Evolution Loop (B.4), NQD/E‑E (C.18/C.19), Evidence Graph Referring (A.10), Trust (B.3), F‑Suite validation (F.15).)

Keywords

  • lexical authoring
  • evolution protocol
  • LAT
  • delta-classes.

Relations

E.15builds onDesign-Rationale Record (DRR) Method
E.15builds onLEX-BUNDLE: Unified Lexical Rules for FPF
E.15builds onCanonical Evolution Loop
E.15builds onNQD‑CAL — Open‑Ended Search Calculus
E.15builds onExplore–Exploit Governor (E/E‑LOG)
E.15builds onEvidence Graph Referring (C-4)
E.15builds onTrust & Assurance Calculus (F–G–R with Congruence)
E.15builds onSCR/RSCR Harness for Unification
E.15explicit referenceDesign-Rationale Record (DRR) Method
E.15explicit referenceLEX-BUNDLE: Unified Lexical Rules for FPF
E.15explicit referenceCanonical Evolution Loop
E.15explicit referenceNQD‑CAL — Open‑Ended Search Calculus
E.15explicit referenceExplore–Exploit Governor (E/E‑LOG)
E.15explicit referenceEvidence Graph Referring (C-4)
E.15explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
E.15explicit referenceSCR/RSCR Harness for Unification
E.15explicit referenceAlignment & Bridge across Contexts
E.15explicit referenceNotational Independence
E.15explicit referenceUnidirectional Dependency

Content

Context

FPF patterns are the canon: they define the generative rules that other artifacts depend on. Teams need to change patterns as the SoTA moves, but ad‑hoc edits lead to drift, weak comparability, and brittle downstream updates. We need a method that (a) generates better alternatives, (b) selects them against explicit quality/assurance targets, and (c) publishes a machine‑ and human‑checkable trace that can be replayed, audited, and re‑run. (Built to cohere with DRR (E.9), LEX‑BUNDLE (E.10), Canonical Evolution Loop (B.4), NQD/E‑E (C.18/C.19), Evidence Graph Referring (A.10), Trust (B.3), F‑Suite validation (F.15).)

Problem

Without a disciplined authoring protocol:

  • One‑shot generation dominates; there is no evolutionary path from vN → vN+1.
  • “Trace” degenerates into a proof‑of‑work: a method ran, not quality improved.
  • Pattern edits blur lexicon vs. norms vs. examples, breaking didactics and tool‑independence.
  • SoTA content is cited but not integrated via Bridges & CL; claims get over‑ported.

Forces

ForceTension we must resolve
Generativity vs AssuranceOpen‑ended idea generation must not erode safety/traceability.
SoTA speed vs Canon stabilityFrequent small updates must preserve conceptual integrity and roll‑up invariants.
Local meaning vs Global reuseContext‑local meaning must cross contexts only via Bridges with CL penalties.
Notational independence vs CheckabilityText must stay notation‑free yet be verifiable by Tooling harnesses.

Solution — A governed evolutionary authoring method with a publishable LEX‑AUTH Trace (LAT)

LEX‑AUTH defines how a pattern is proposed, varied, selected, validated, and merged, with artifacts and evidence fit to the FPF kernel.

Method (design‑time choreography)

Stage A — Frame & Scope (Context, Objectives, Invariants)

  1. Anchor the work in a U.BoundedContext for the spec (e.g., FPF/Core), cite governing guard‑rails (E.5.*), and state objectives for the change (e.g., clarity ↑, universality ↑, assurance cost ↓).
  2. Declare the Delta‑Class (see §4.3) and impact radius (dependent patterns, bridges, tests).
  3. Fix acceptance targets (see §4.4 Quality & SoTA metrics).

Stage B — Generate candidates (SoTA + NQD) 4. Harvest SoTA inputs (standards, rival patterns, lived domain idioms) and bind them as evidence via U.EvidenceRole with claim/claim‑scope/timespan (empirical vs deductive lines). 5. Generate candidate variants using NQD‑CAL engines (Novelty/Quality/Diversity) with an E/E policy (explore↔exploit governor) to populate a Pareto front of pattern phrasings/structures. (No single shot; multiple candidate clauses compete.)

Stage C — Shape & Align (Structure, Bridges, USM) 6. Shape top candidates into the standard architectural template (Context → Problem → Forces → Solution → CC → Consequences → Rationale), obeying LEX‑BUNDLE (no tooling jargon; twin registers allowed). 7. Bridge across Contexts explicitly (F.9): any imported definitions/claims declare CL and loss notes; propose scoped narrowing where needed. 8. Type scopes with USM (A.2.6): keep ClaimScope (G) distinct from WorkScope; no “applicability/envelope” smuggling.

Stage D — Validate & Decide (Assurance, Tests, DRR) 9. Run the harness: update SCR/RSCR (F.15), lint lexical rules (E.10), run Γ‑consistency and RSG/SoD checks where relevant. 10. Score candidates on Quality & SoTA metrics (§4.4) and assurance deltas (Δ⟨F,G,R⟩). 11. Record a DRR (E.9) with options considered, trade‑offs, chosen candidate, blast‑radius. 12. Merge the winner; version pattern SemVer by Delta‑Class.

Stage E — Publish & Monitor 13. Publish the LEX‑AUTH Trace (LAT) (§4.2) with the pattern. 14. Schedule evidence refresh windows and an evolution watchpoint (B.4 loop): when metrics or SoTA inputs decay, reopen Stage B.

The LEX‑AUTH Trace (LAT) — what it is and why it matters

A LAT is not “we ran a script.” It is a structured episteme that lets others reproduce quality gains and re‑run the search when SoTA shifts.

LAT minimal contents (publish with the pattern):

  1. Context & version (pattern id, context, SemVer, Delta‑Class).
  2. Objective vector (what we tried to improve: clarity, universality, assurance cost, etc.).
  3. SoTA pack (sources bound as U.EvidenceRole with claim/scope/time and polarity).
  4. NQD settings (emitters/lenses, diversity characteristics) + E/E policy used.
  5. Candidate set (top K variants with NQD scores + short deltas from baseline).
  6. Bridge ledger (all cross‑context imports with CL and loss notes).
  7. Assurance delta (Δ⟨F,G,R⟩ from baseline; penalties from CL applied).
  8. Harness results (checks passed/failed, test diffs).
  9. DRR link (decision rationale id).
  10. Refresh policy (evidence decay windows and triggers).

Uses of the LAT: Reproducibility (re‑run B‑stages as SoTA changes), assurance (explicit impact on F/G/R), portfolio health (diversity/coverage), teaching (didactic before/after), and cross‑context safety (no silent imports). Publish the pattern with a DRR that carries a LAT pointer (id/URI). The LAT itself is a U.Work evidence pack (non‑normative), archived with edition and Γ_time.

Example of a LAT‑stub

LAT:
  context: FPF/Core, pattern: F.15, semver: x.y+1, delta-class: Δ‑2
  objectives: {clarity↑, universality↑, assurance-cost↓}
  SoTA-pack: {OpenAlex 2025‑Q3, SPECTER2‑23, DPP‑2019, MAP‑Elites‑2015+}
  NQD-settings: {CharacteristicSpace: domain‑family × …, grid: CVT@k=16}
  candidates: K=4 (wording of RSCR‑F04 & gates)
  bridge-ledger: none (intra‑canon refs only)
  assurance‑delta: ΔF=+, ΔG=+, ΔR=+ (after CL‑penalties=0)
  harness: LEX‑BUNDLE lint pass; F‑suite pass; Γ‑consistency ok
  DRR-id: DRR‑2025‑09‑DFCM‑roll‑in
  refresh: F1‑Card edition refresh window = 6 mo

What counts as “changed the pattern as a whole” — Delta‑Classes & versioning

Classify the intended change before work starts (declared in DRR & LAT):

  • Δ‑0 Lexical polish — wording/ordering only; no change to CC or semantics. → Patch (x.y.z+1).
  • Δ‑1 Didactic restructure — narrative/layout; unchanged Conformance Checklist (CC). → Minor (x.y+1.0).
  • Δ‑2 Normative refinement — CC tightened/clarified; semantics preserved by test equivalence. → Minor (x.y+1.0) + RSCR required.
  • Δ‑3 Semantic change — CC adds/removes requirements; downstream contracts shift. → Major (x+1.0.0) + impact review + bridges refresh.

Definition of “pattern changed as a whole”: any Δ‑2/Δ‑3 change (i.e., the normative surface or semantics changed) counts as a pattern change in the canonical corpus and triggers harness & bridge reviews.

Quality & SoTA metrics (selection lenses)

Mandatory lenses (declare in LAT; higher is better unless noted):

  • Clarity (readability; plain‑register score from didactic rubric).
  • Universality (C‑1): ≥3 heterogeneous domains anchored in the Archetypal section.
  • Lexical discipline (E.10): 0 violations (DevOps lexicon, process/function conflations).
  • Assurance delta: ΔF (formality), ΔG (scope clarity), ΔR (reliability after CL penalties).
  • Bridge integrity: Bridge integrity (policy lens): declare minimum CL thresholds per Context policy; penalties route to R only (B.3/F.9); record policy‑id in LAT.
  • Test conformance: F‑suite pass; RSCR clean.
  • Exploration health (NQD): diversity coverage > threshold; no premature convergence.
  • Didactic economy: length vs density ratio within band; “Tell‑Show‑Show” present.

Optional lenses (context‑specific): Ethical/SoD guard strength; cross‑scale roll‑up integrity; aggregation proofs present; etc.

Conformance Checklist (normative)

CC‑LA‑1 (Context anchoring). Every authoring run MUST declare a U.BoundedContext, Delta‑Class, objectives, and acceptance lenses before generating candidates.

CC‑LA‑2 (SoTA as evidence). External inputs MUST be bound as U.EvidenceRole epistemes with claim, claim‑scope, polarity, timespan (formal/empirical lines). No raw links.

CC‑LA‑3 (Open‑ended generation). At least K≥3 candidate variants MUST be generated via NQD‑CAL with a declared E/E policy; single‑shot edits violate LEX‑AUTH.

CC‑LA‑4 (Bridges & CL). Any cross‑context reuse MUST appear in a Bridge with CL and loss notes. CL penalties apply to R‑lane when scoring.

CC‑LA‑5 (Harness). The candidate winner MUST pass LEX‑BUNDLE lint, SCR/RSCR tests, Γ‑consistency, and SoD/RSG gates where applicable.

CC‑LA‑6 (Assurance deltas). The LAT MUST publish Δ⟨F,G,R⟩ relative to baseline, explicitly accounting for CL penalties and any narrowed scopes.

CC‑LA‑7 (DRR). A DRR entry is mandatory for Δ‑2/Δ‑3 changes; it records options considered, rationale, and impact radius.

CC‑LA‑8 (Refresh plan). Empirical evidence in the LAT MUST carry a decay/refresh window; a watchpoint MUST be scheduled in the Canonical Evolution Loop.

CC‑LA‑9 (Publication). Publish the pattern + LAT together; past LATs are immutable. New runs produce new LATs.

Consequences

Benefits. Evolutive quality: patterns improve through search + selection, not edits by fiat. Auditability: a re‑runnable LAT shows why the chosen variant won. Safety: cross‑context reuse is explicit and penalized appropriately. Comparability: Δ‑classes & SemVer let downstream readers predict blast‑radius.

Trade‑offs. Some ceremony (LAT/DRR, NQD lenses) and maintenance (evidence refresh, bridge upkeep). These costs buy reproducibility and SoTA tracking.

Rationale & Links (informative)

LEX‑AUTH extends the FPF constitution by operationalising pattern evolution: it plugs B.4 Canonical Evolution Loop into E.9 DRR, binds SoTA via U.EvidenceRole and KD‑CAL, drives candidate generation with C.18 NQD‑CAL under C.19 E/E‑LOG, enforces lexical discipline via E.10 LEX‑BUNDLE, and validates with F.15 regression harnesses. Cross‑context safety is carried by F.9 Bridges with CL penalties in B.3 Trust. The whole remains notation‑independent (E.5.2) and stays within the Core → Tooling → Pedagogy dependency rule (E.5.3).

Operators (authoring deltas you are allowed to apply)

  • Refine (tighten CC without changing acceptance meaning).
  • Split/Merge (factor patterns; preserve links; update Bridges).
  • Generalise/Constrain (expand/restrict ClaimScope (G) with proofs or loss notes).
  • Rephrase (clarify language; leave CC untouched).

Each operator carries a default Delta‑Class and test obligations.

Self‑application Work Log (how this very pattern was authored)

This is not chain‑of‑thought; it is the required U.Work evidence for LEX‑AUTH.

Context. FPF/Core (Canon); Delta‑Class: Δ‑2 (normative refinement by addition of method & CCs). Objectives. Add an evolutionary authoring method; make trace useful (quality‑bearing); align with SoTA machinery already in spec. SoTA pack (evidence bound). Prior FPF kernel commitments to DRR (E.9), E.10 LEX‑BUNDLE, B.4 Evolution, C.18/C.19 NQD/E‑E, F.15 harness, F.9 Bridges, B.3 Trust; these are treated as the authoritative internal SoTA for the Canon here. NQD/E‑E. Generated ≥3 alternative Solution sections; finalist chosen for clearer Δ‑classes and actionable LAT contents. Bridges. No cross‑external mapping; intra‑canon references only (CL=3). Harness. LEX‑BUNDLE lint (no tooling jargon), CCs unique/atomic, didactic “Tell‑Show‑Show” via Self‑application log, Universality criterion met by cross‑kernel applicability. Assurance Δ. F: + (explicit method & CCs); G: + (scope separation & Δ‑classes); R: + (LAT obligations + bridge penalties). DRR. Recorded: alternatives considered (lighter trace vs full LAT), chosen design (full LAT). Refresh. Reopen when SoTA (e.g., G‑suite authoring kit or CHR templates) evolves or when LAT misuse is seen in reviews.

E.15:End