#FPF Authoring Conventions & Style Guide

E.8 · Stable · Architectural (A) · Normative (unless explicitly marked informative) · 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 Reference 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.

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative)

Use E.8 when you are writing, revising, or reviewing one FPF pattern and need to know what shape, voice, reader-recognition role, and assurance material the pattern must carry before it can be treated as mature FPF text.

#Relations

#Content

#Use this when

Use E.8 when you are writing, revising, or reviewing one FPF pattern and need to know what shape, voice, reader-recognition role, and assurance material the pattern must carry before it can be treated as mature FPF text.

Use it especially when a draft is technically correct but hard to use: the cold reader cannot tell when to apply it, what action to take, what mistake that action prevents, which related pattern defines or constrains a specific outside claim, or which assurance material is informative rather than the first user-facing guidance.

Not this pattern when. Use E.9 when the main work is deciding why FPF should change and how that decision is distributed across patterns. Use E.19 when the main work is an admission or refresh review. Use the local domain pattern when the question is what FPF says inside that domain rather than how a pattern should be authored.

#What goes wrong if missed

A pattern can satisfy a checklist and still be practically unreadable. It may open with package architecture instead of a recognisable working moment, bury its payoff, hide the pattern that defines or constrains a specific outside claim, or let assurance prose silently replace the reader-facing claim. The result is a formally neat text that authors can defend but practitioners cannot reliably use.

#What this buys

E.8 gives FPF authors one shared pattern shape and one shared authoring discipline: recognition text first, assurance text second, canonical sections present, terminology kept stable, SoTA used as current practice grounding rather than decoration, and practical consequences visible before a reader has to reconstruct the architecture.

First useful move. Put the working situation, first action-guiding move, practical payoff, ordinary boundary, and nearest heavier assurance condition into the recognition text before tightening template details or conformance material.

Move wording in pattern prose. In E.8, phrases such as first useful move, action-guiding move, or working move are reader-facing guidance phrases. They do not create a root U.Move or a local pattern-application ontology. When the phrase itself becomes load-bearing, recover the governed value: usually PatternUseRecommendation@Context; when one named PatternUseCoordination@Context has orderingMode=totalOrder, its bounded specialization may be called PatternUseSequence@Context under E.11.PUR. Otherwise recover the direct work, plan, gate, transformation, publication, architecture, source, or language-state relation under its exact definition or constraint. When a pattern supplies that content, state its concrete contribution and cite its id. Use E.10.MOVE when the text cannot tell which value is current.

Cheap stop. If the draft already gives a cold reader the working situation, first useful move, practical payoff, ordinary boundary, and nearest heavier assurance condition, do not add more authoring apparatus just to look mature. Use conformance material to verify that guidance; do not let it replace the guidance.

FPF-governed wording extension. Add heavier assurance, conformance, SoTA grounding, relation material, or related-pattern material only when the light recognition text would leave a false claim, unstable primary EntityOfConcern, missing definition, constraint, test, method, or other concrete contribution for a specific claim, relation, or boundary, unbacked practical payoff, or misleading admissible use.

When an authoring pass claims quality improvement rather than ordinary drafting, keep these pattern responsibilities distinct: E.22 frames the improvement-oriented quality-evaluation question, the object-under-improvement evaluation such as E.21 or E.9.DA supplies value meanings and stop meanings, C.16.Q repairs overloaded quality and evaluative-characterization wording, C.25 carries engineering quality-family endpoints when those endpoints are claimed, and E.23 governs any repeated quality-improvement method. Closing checklist rows or satisfying a review profile is not by itself quality improvement.

When a pattern claims practical payoff or uses a score, coordinate value, checklist result, benchmark, projection signal, review result, or release posture as evidence of value, name the intended value and the visible proxy relation. If the visible proxy is being treated as the value itself, apply E.13 and repair the proxy-to-value substitution before the payoff claim is admitted.

Quality or projection evidence placement. Pattern-quality status, corpus projection, README, ToC, E.11, and I.2 alignment, card or retrieval evidence, cold-reader evidence, monolith parity, landing evidence, developer, reviewer, and executor correspondence, and other quality-carrier facts belong in the evaluation result, review run record, projection carrier, or release or landing evidence carrier. They do not belong anywhere in the pattern itself, including notes, appendices, Relations, Rationale, SoTA-Echoing, examples, tables, and checklist rows, unless the pattern's own EntityOfConcern and intended-reader use are that evaluation or projection work. Part E patterns may govern FPF-pattern authoring, review, evaluation, entry, or publication when that is their declared EntityOfConcern; that authoring scope does not admit rules or rationale about developing that same pattern version. This is a role test, not a lexical test: the same word may be user-facing content in an evaluation pattern and carrier leakage when it reports quality, landing, projection, or role-turn state for this pattern.

Pattern roles across coupled flows. In authoring guidance, speak at the pattern level. One pattern may be the pattern of concern for different roles in different flows: an author repairs it, E.21 evaluates it, E.19 admits or refreshes it, a practitioner selects and uses it, and a later evaluator may reopen it. Those flows may be joined in one TransformationFlowStructure through transfer, feedback, return, projection, landing, edition-change, or repair relations, but their roles and EntityOfConcern assignments stay distinct. The pattern itself also carries its own primary EntityOfConcern: the subject its Problem, Solution, or guidance is about. Development-flow evidence may cause rewrites, but reviewer and executor exchange, status, projection proof, landing proof, and use-found evidence remain in their carriers rather than entering the pattern as if they were guidance for the intended reader. This is the pattern-authoring instance of the broader transformation-flow and P2W coupled-flow rule: a publication, principle scheme, work plan, or self-evolving specification flow may help create or govern later work without becoming the performed work, project evidence, gate passage, assurance, edition bump, or applied-edition content.

Maturity rule. Section completeness is not pattern maturity. A pattern matures when its Problem frame, Solution, worked cases, boundaries, source/SoTA use, relations, consequences, and conformance checks all point to the same usable action guidance for the declared reader and use. If the reader still needs the DRR, source notes, campaign handoff, or author memory to know what to do, the pattern is not mature for that use.

Primary EntityOfConcern in plain terms. The primary EntityOfConcern of E.8 is the authored FPF pattern: its canonical sections, reader-recognition role, wording discipline, examples, rationale, anti-patterns, SoTA-Echoing, and relations.

Primary working reader. The first reader is an FPF author or reviewer shaping pattern prose for later practitioners and managers. The downstream practitioner is the reader the pattern must ultimately serve, so the authoring guide must model the same recognition discipline it requires.

#Pattern Kind In Plain Terms

An FPF pattern supplies action- or judgement-guiding content for a recurring working situation. “Use this pattern” and “apply this pattern” are valid shorthand for a person or another capable system using that content to choose an action or judgement. The pattern episteme itself does not act, decide, perform U.Work, or cause a U.Transformation. State that its content is a U.MethodDescription only when the A.3.2 membership conditions are established and that membership matters to the current claim; then name the admitted U.Method, capable system, role assignment, dated U.Work, result, or U.Transformation only when those further identities or relations also change the claim.

When a method-bearing Solution prescribes actual work or world-side change, it must also distinguish the intended reader from the admitted U.System that can perform that work and from the current role assignment under which that system performs the work, and distinguish the method episteme, dated U.Work, and problem-facing result. The intended reader and performer may coincide in one person-system, but the positions remain different. A pattern episteme, checklist, reader role, plan, or prose cannot perform the prescribed work. Do not invent a fictive performer or work occurrence when the pattern only guides a judgment or another episteme-side use.

Pattern application is metonymic shorthand for this user-side use: the user or another capable system recognizes the working situation and uses the pattern content and its Solution to shape the next admissible action or judgement. If that claim depends on method-bearing content, establish U.MethodDescription membership under A.3.2 and identify the admitted U.Method; when actual work is claimed, name the acting system, admitted Method, role assignment, dated U.Work, problem-facing result, and independent U.Transformation when one obtains. Problem frame, Problem, Forces, Solution, Consequences, worked slices, and anti-patterns provide the description-side guidance. A Conformance Checklist checks the authored description and the separately evidenced use; it must not replace the Solution, manufacture Work, or turn the pattern into a control form.

The primary content-bearing job is constructive action or judgement guidance: the pattern description must say what the user should do or decide so the recurring error does not arise. Error prevention, auditability, and conformance checks are evidence that the guidance is usable; they are not the pattern's center. The first substantive content in the opening Problem frame and Solution must be positive subject and action guidance: the primary EntityOfConcern kind, the first admissible action-guiding move, the practical delta, and the few boundaries needed for that first move. The text must not replace subject content with repeated guards, distinctions, related-pattern mappings, references, mini-rules, definitions, caveats, architecture rationale, or quality or projection evidence unless the repetition adds a new local action, case, evidence value for the user, or first-reading recognition need. Copying distinctions from another pattern's defining or constraining content into this pattern as repeated "do not confuse our EoC with their EoC" prose is the same repetition problem. Boundary doctrine is pattern content like any other doctrine: if an exact distinction, non-use condition, ToC navigation cue, or cited pattern already states it, do not repeat it locally. Cite the short pattern id; identify an exact claim-bearing episteme or ClaimGraph only when that identity matters to the receiving use. Add local boundary prose only when it states a documented local confusion and exact stop condition that the existing content does not already state. The repair is to say clearly what this pattern's own EntityOfConcern is, not to enumerate the unbounded set of other things it is not.

The same rule blocks pattern-use drift for any FPF object. Name the object by its FPF kind when the kind is known, and do not let “acts”, “routes”, “receives”, “decides”, or an ownership word hide a different relation. For an ordinary neighboring-pattern reference, state what the cited content contributes here—for example, defines a kind, constrains a relation, supplies a test or method, or provides a locator—and cite the pattern id. Identify an exact claim-bearing episteme, ClaimGraph, edition, or relation assertion only when that identity changes interpretation, migration, conflict, publication, or reuse. A genuine stop needs no receiver; a reconsideration states its condition and the candidate guidance to consult. Relations are positive claims, not catalogs of absent relations. Detailed discoverability belongs in README, ToC query cues, E.11, I.2, or retrieval or projection carriers; compact related-pattern statements belong late in Relations after the positive subject and action guidance. Ordinary references use ordinary reference forms: a pattern id in prose, a citation, Builds on, Coordinates with, Relations, ToC, README, E.11, I.2, or a retrieval or projection carrier. Do not repeat them as many conditional sentences or small variants when one compact definition, boundary, table, Relations, ToC, README, E.11, I.2, or retrieval or projection locus already carries the same content family.

Treat precision-restoration problems in pattern prose as one profile with five layers: word, head, and use precision; phrase apparatus; repetition and distribution; role and carrier separation; and pattern application. Do not add a local row for each new symptom. E.8 requires the author to keep positive subject and action guidance first; F.19 repairs phrase-level apparatus; E.10, E.10.ARCH, F.18, or the pattern that defines or constrains the relevant kind, relation, or use repairs remaining word, head, and use precision; E.21 measures the collapsed effect on pattern quality.

A wording cleanup is kind-preserving by default. Before an author accepts a changed FPF-governed phrase as a repair, the pre-repair and post-repair EntityOfConcern, kind, relation or claim kind, current ontic slot, relation position, use relation, or claim kind, admissible use, and scope must be recoverable when those items are live. This is a bounded complete preservation check, not an order to formalize ordinary prose or unchanged text and not permission to choose "no edit" as the easy minimum. Leaving text unchanged closes only when the phrase is not triggered, ordinary prose, or already satisfied by value with loci; otherwise the finding remains open. Removing a trigger word or replacing a generic head is not a repair when it changes the ontology: for example, a graph-shaped method cue must not be narrowed into a work sequence unless an accepted decision explicitly changes the kind and consequences. If a relation, signature, mathematical-lens, role, method, work, or evidence position is live, cite the pattern that defines or constrains that position instead of restating its ontology in E.8. If the phrase hides several kinds, split them or assign the decision to that exact pattern or DRR; do not flatten them into one cleaner-looking word.

Authoring repairs also have an MG-DA cold-reader closure. A phrase is not mature merely because it avoids a trigger word or uses an FPF-looking abstraction. A reader who has not read the DRR, campaign notes, or author memory must still be able to recover the object being named, its FPF kind or ordinary status, the relation or claim kind, the admissible use, and what any cited pattern contributes to the claim. Identify an exact claim-bearing episteme or ClaimGraph only when its identity changes interpretation, migration, conflict, publication, or reuse. If authoring uses object, item, value, relation, record, condition, basis, material, or another broad head, name the specific object and position or keep the phrase ordinary. If authoring uses specialization, state what object is specialized, what relation makes it a specialization, what inherited or changed slots or uses matter, and which pattern defines or constrains it; require an exact ClaimGraph only when the receiving use depends on that exact claim-bearing content. Otherwise the edit is bureaucratic abstraction, not an improvement.

For boilerplate overwrap, use the Method described at F.19. E.8 adds only the pattern-authoring placement rule: after boilerplate is removed or moved and remaining content is precision-restored using the Methods described at E.10, E.10.ARCH, F.18, or the relevant pattern that defines or constrains the kind, relation, or use, pattern prose keeps only the intended user's admissible move and boundary. Process, architecture, review, quality, projection, and release evidence stay in their own carriers unless they are rewritten as that user-facing move.

When an action-adjacent pattern classifies wording, a name, a publication face, an explanation class, a comparison unit, or another semio-facing object, that classification is only useful if it connects back to action guidance. The pattern must say what use or action is admissible now, what related use or action is not admissible under the current pattern, and which FPF pattern defines or constrains the case when the claim is a work, evidence, gate, decision, assurance, engineering-justification, release, or reliance claim.

Semio-Echoing is admissible only as a trigger-controlled auxiliary placement. Use it when E.10, C.2.P, or E.10.ARCH has exposed a wording-use overread whose EntityOfConcern, episteme/publication stack, alignment basis, and remaining admissible reader use are recoverable by value. Do not add it as a generic warning block. In non-semio patterns the primary content remains the pattern's own EntityOfConcern and admissible use; semio material stays as a thin cue, related-pattern relation named by value, local recovery line, or named description and publication-use boundary section unless it changes that use or blocks a documented overread. If the material mainly says that a description, view, publication, record, card, diagram, source, or file is not a permission, promise, prescription, evidence item, assurance verdict, decision, gate passage, release, work occurrence, or authority source, keep it out of the subject Solution and put it in that boundary section or in the exact description-publication pattern.

#Problem frame

FPF grows through patterns written and revised by authors from many disciplines. Without a shared structure, practitioner-facing use order, and semantic writing discipline, the framework would fracture or become formally uniform but harder to use, violating Pillars P‑1 Cognitive Elegance and P‑2 Didactic Primacy.

#Problem

Structural drift, stylistic fragmentation, and revision by visible proxies rather than working use threaten five qualities:

1. Comparability – readers cannot align patterns lacking common headings.
2. Narrative cohesion – prose swings from dry jargon to informal blog style.
3. Practitioner use across revisions – cleanup can erase the recognizable situation, first action or judgement, first useful result, ordinary boundary, or affordable stop while leaving a tidier-looking text.
4. Semantic and relation clarity – generic heads, false agency, imprecise neighboring-pattern contributions, and drifting package or relation words can change what the prose asserts or what a reader may do.
5. Reviewability after guidance – missing or misplaced grounding, boundary, SoTA, conformance, assurance, and publication-reference material can hide a defect or replace the positive guidance it is meant to verify.

#Forces

#Solution — One template, enriched by style principles

#Canonical Pattern Template

Within each pattern, the canonical section headings SHALL appear in the order below. For each canonical content section heading (1–12), the <Title> component (after the heading separator, e.g. -) MUST start with the canonical section title (case-insensitive match; canonical capitalisation preferred); an optional clarifier after an em dash is allowed (e.g., Solution — …). The Footer marker (section 13, if present) is a sentinel and is governed by H-9 rather than the standard <FullId> - <Title> shape.

Extensibility. Authors MAY add additional sections. Prefer expressing them as subsections under the nearest canonical section (e.g., 4.1, 4.1.1 under Solution). If an additional pattern-level section is necessary, it MUST NOT delete or reorder the canonical sections and its title MUST NOT shadow a canonical title.

Mandatory vs optional.

• Canonical sections 1–13 are mandatory in every pattern.
• Canonical sections carry content. Authors must not use omission placeholders as section substitutes; when a section is intrinsically small, write the smallest content-bearing grounding, misuse, boundary, or reduced-case statement that preserves the section's role.
• First substantive authoring seed. The first non-empty authored body of a pattern SHALL already instantiate the canonical section frame by value: title line, header block, canonical sections 1–13, and the footer marker.
• Seed is not maturity. The canonical frame is a minimum authoring seed, not a mature pattern claim. Before a pattern is used for public, teaching, enterprise, reliance-bearing, landing-input, release-input, or ordinary practitioner guidance, each canonical section must carry enough recognition, action guidance, worked material, source/SoTA use, boundary, consequence, and relation content for the declared use, and the pattern-quality claim is checked through E.21. A file with correct headings, thin bullets, scenario labels, or compressed DRR recap remains a pattern seed until that content is present or the package explicitly marks it as seedOnly.
• Recognition-role openings and first-minute working guidance belong inside that canonical frame. Any retained pre-template entry material must also stay inside that same canonical frame rather than appearing as one pre-template opening memo. Authors MUST NOT seed one pre-template opening memo and postpone canonical sectioning, Conformance Checklist, or footer-marker installation to one separate E.19, assembly, or review-repair pass.

Template:

• Title line: Hashes + FullId + - + Pattern Title; optional (informative) note.
• Header block: Type, Status; optional Normativity override.

1. Problem frame
2. Problem
3. Forces
4. Solution
5. Archetypal Grounding (Tell-Show-Show; at least one content-bearing grounding slice, reduced grounding case, or ordinary/non-use boundary)
6. Bias‑Annotation
7. Conformance Checklist
8. Common Anti‑Patterns and How to Avoid Them (at least one local misuse, overread, or exact boundary case; no placeholder)
9. Consequences
10. Rationale
11. SoTA-Echoing (post-2015 practice alignment; terminology drift and deltas; full comparison or reduced SoTA required whenever external or internal practice changes the Solution)
12. Relations
13. Footer marker

Footer marker. End each pattern with a single visible sentinel heading line by itself: ### <PatternId>:End. This makes truncation detectable even when HTML comments are stripped or shown by editors. The footer marker is intentionally content-free: do not place prose under it.

Note. Pattern boundaries are still parseable by scanning for the next pattern heading (## …), but an explicit :End marker helps retrieval pipelines (and LLM prompts) distinguish “this chunk is the whole pattern” from “this chunk was cut mid‑pattern”.

#Heading & ID discipline (human tooling + retrieval)

FPF is often consumed through full‑text search and retrieval (RAG). A reader or an LLM may see a subsection without its parent headings, so headings must be self‑identifying.

H-1 (Heading shape). Every pattern heading and every subsection heading inside a pattern SHALL follow: <hashes> <FullId> - <Title> (optional note of non‑normativity)

Exception. The Footer marker is a sentinel heading and is governed by H-9, not by the standard <FullId> - <Title> shape.

H-2 (Heading separator). The canonical separator between <FullId> and <Title> is - (ASCII, space-hyphen-space). Previously authored text may use Unicode dash variants such as – or — as separators; tooling SHOULD treat those variants as migration candidates, and authors SHOULD migrate touched headings to -.

H-3 (FullId). FullId is the full hierarchical address. For a pattern heading it is the pattern ID (e.g., A.2, E.10.D1). For headings inside a pattern, append dot‑separated ordinal section numbers after the colon (:) (e.g., A.2:4.4, E.10.D2:3). Exception: the Footer marker uses the reserved sentinel token :End as defined in H-9. The colon (:) is reserved for section paths and MUST NOT appear in pattern IDs.

H-4 (Ordinals). Ordinals in section paths SHOULD track the canonical template numbering (1 = Problem frame, …, 13 = Footer marker) to maximise cross‑pattern comparability. During refactors or in previously authored patterns, ordinals MAY be local. In that case, the canonical section title at the start of <Title> is the semantic key; readers and tools MUST NOT infer section semantics from the ordinal alone. Note: the Footer marker itself is exempt from ordinal encoding; it uses the reserved token :End (see H-9).

H-5 (Where kind and normativity are declared). Pattern kind (for example, Architectural or Definitional) MUST be declared in the Header block, not encoded into the heading text. Normativity (normative or informative) MUST also be declared in the Header block when it deviates from the default. If a reminder is needed for readers, authors MAY add a short parenthetical note at the end of the heading, for example (informative) or (non‑normative), but headings MUST NOT use square‑bracket tags.

H-6 (Heading levels). Heading levels MUST preserve a fixed offset between structural layers (Part or Cluster (flat) → Pattern → Pattern sections):

• Part and Cluster headings MUST use # (level 1) across the file.
• A Pattern heading MUST use ## (level 2).
• Inside a pattern, each nested section MUST add exactly one # per level (e.g., ## A.2 - …, ### A.2:2 - …, #### A.2:2.1 - …).

H-7 (Ellipsis discipline). Authors MUST NOT use three consecutive full stops/dots (...) as punctuation in headings or narrative prose. Authors MUST use the Unicode ellipsis … (U+2026) instead. For editorial elisions in quotations, authors SHOULD prefer […] to make the omission explicit and distinguish it from retrieval truncation. Exception: literal three‑dot sequences that are part of an external language’s syntax MAY appear only inside code spans or fenced code blocks.

H-8 (Normative keywords). The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119, as clarified by RFC 8174 (only when capitalised). Authors SHOULD avoid informal deontic phrasing (“need to”, “is required to”) in normative clauses.

Deontics vs admissibility. Use RFC keywords only for deontic obligations (requirements on authors, reviewers, implementers/tooling, or published pattern or companion texts) — i.e., things an agent can choose to do or omit. Do not use RFC keywords to state definitions, structural invariants, typing rules, or other admissibility conditions of the modeled world.

When you need an enforceable constraint that is mathematical rather than deontic, express it as a non‑deontic predicate using one of: Definition:, Invariant:, or Well‑formedness constraint: (optionally with formal quantifiers). Prefer mathematical terms like cardinality 1..1 (total), 0..1 (partial), or 0..n over deontic adjectives like “mandatory or optional” when the intent is cardinality, not duty.

Admissibility predicate discipline (recommended shape). When expressing admissibility or validity constraints as predicates (Definition:, Invariant:, or Well‑formedness constraint:):

• Authors MUST NOT use RFC keywords inside the predicate block.
• Authors SHOULD give each predicate a stable identifier and short name (e.g., RA‑1 (Locality), RE‑3 (Method gate)), so that Conformance Checklist items can reference it without re‑authoring the rule.
• Authors SHOULD write the constraint as a declarative predicate (optionally quantified), e.g., role ∈ Roles(context), rather than as “X MUST …”.
• If the constraint needs to be checked as part of pattern conformance, authors SHOULD reference the predicate identifier from the Conformance Checklist, and call out validator behaviour when relevant, rather than duplicating the predicate with RFC keywords.

H-9 (Footer marker sentinel). Footer marker SHALL be a single heading line whose FullId is the pattern ID followed by the reserved sentinel token :End (no ordinals, no title, no square‑bracket tags): ### <PatternId>:End It is the only allowed heading inside a pattern whose section token is non‑numeric. It MUST be the final line of the pattern and MUST NOT carry any prose. Tooling and readers MUST treat it as a boundary sentinel, not as a semantic section.

H-10 (Publication-token classification and addressability). Before emitting an FPF-governed token as a reference, authors MUST classify it under exactly one of these seven E.8-local publication-token classes and use the matching form:

• PatternRef names one exact current pattern body. It is addressable only when the assembled publication carries one complete H2 body, one matching :End, and a truthful current ToC status for the same PatternID; a structural checker may verify and report that conformance but does not supply the status or normative authority.
• PlannedCatalogEntry names an explicit future catalogue commitment. It has no current pattern semantics, governing force, prerequisite force, or addressable body; a useful prose mention MUST say planned or future, and a current semantic dependency MUST cite existing content that supplies the needed definition, constraint, test, method, or other rule, or state the current gap.
• SectionRef names one exact heading path inside one current pattern. Authors and tooling MUST read the complete section identifier before examining any substring.
• LocalDeclaredId names an exact declaration within one pattern, such as a conformance clause, component, interface row, or predicate. Its scope is local unless an explicit stable anchor or a separate promotion decision establishes wider use.
• LocalAlias names an explicitly declared compatibility alias and resolves to its declared canonical local target.
• PatternFamilySelector selects a navigable pattern family using canonical spelling <base>.*. It requires a current base pattern and at least one current matching member and MUST NOT stand in for one exact governing target.
• NonReferenceToken classifies a schematic example or ordinary local prose/code that neither occupies a reference-bearing position nor declares a local public ID. It explicitly denotes no reference; key-like typography or backticks alone do not change that class.

Resolution and checking are declaration-first and context-sensitive. Authors and tooling MUST NOT split complete SectionRefs, strip a local-ID prefix, promote a local symbol by visual resemblance, or replace these classes with an ignore list. An unresolved token in a reference-bearing authoring form is an error; ordinary code or local wording is not silently upgraded to a reference.

H-11 (Assembled Part boundaries and title agreement). In the assembled publication, every compact ToC Part label MUST be a bold separator with a blank line on both sides, not a duplicate structural Part heading. Its title and ASCII - separator MUST agree exactly with the corresponding # Part <letter> - <title> body heading. A reserved body Part that has no compact ToC table, including current Part H, does not require an empty compact label or table.

Unification note: historic A‑ and D‑templates differed only by the presence/absence of Bias‑Annotation and Relations; the unified template keeps the headings everywhere and requires every heading to carry content-bearing grounding, boundary, consequence, rationale, source-use, relation, or reduced-case material rather than an omission placeholder. The Alexandrian pattern canon historically calls Problem frame “Context”. FPF avoids that label because Context is already overloaded in FPF (e.g., U.BoundedContext and its Plain‑register label).

#Preserve Pattern Use Value Across Material Revisions

A revision is material when the actual change can alter what a working reader recognizes, does, obtains, or must stop doing, regardless of whether the change is labelled as cleanup, clarification, terminology repair, or ontology alignment. Treat the revision as material when it can change at least one of these values:

• the primary EntityOfConcern, governed kind, direct relation, claim kind, or scope;
• the recurring situation or practical question that lets a reader recognize the use;
• a Solution action, action condition, result kind, first useful result, stop, return, risk disclosure, or stronger-neighbor handoff;
• the definition, constraint, test, method, cited-pattern contribution, split, merge, relocation, or source/SoTA stance that changes what the reader may do;
• the asserted commonality, member set, membership rule, order, or governing premise of a list; or
• ordinary first-use affordability.

A formatting correction, spelling repair, citation repair, exact mechanical rendering, or wording change is not triggered only when the smallest comparison of the actual predecessor and proposed text shows that all these values are preserved. A clean comparison needs no additional positive ledger, evidence table, or pattern section. Physical line count, file size, section count, inventory rows, and the author's label for the change do not establish materiality.

Use one bounded material-revision loop over the actual prose. Before treating a materially revised pattern as authored:

1. Recover the useful predecessor use at idea level: the recognizable situation and intended reader, first admissible action or judgement, first useful result, action-changing boundary or stop, and any domain claim, example, or relation needed to perform that move. Classify a changing or disappearing predecessor use only as retained, a valid outcome whose defective mechanism is repaired, an explicitly authorized retirement with a corrected action or boundary, or unsupported residue.
2. Draft the candidate's positive practitioner path in domain-recognizable language before guards: governed subject, recurring problem, action the reader can take, first useful result, and next action-changing condition or stop.
3. Compare the actual predecessor and proposed text at comparable application effort. Preserve every useful predecessor move or deliberately replace it with an at-least-equally-usable action, result, or boundary; admit a candidate-only use only from an exact accepted decision, source/SoTA stance, finding, or working need.
4. Remove exactness intensifiers, negative catalogues, role/process wrappers, formal identities, and assurance apparatus that do not change the truth, action, boundary, or reliance claim. Keep ordinary “use this pattern” or “apply this pattern” wording; open the fuller pattern-application ontology only under E.8:0.3 when its identities matter.
5. Check that recognition, first action, and first useful result still precede optional modeling, evidence, conformance, and assurance work. Use F.19 or E.10 only for a residual phrase or word/head/use problem, not as a wrapper around the whole authoring path.
6. For every changed public or consumed interface—entry wording, input or result, field or position meaning, action order, stop, return, or reconsideration condition—repair each determinate stale ToC or README cue, example, relation, and true direct consumer in the same authoring increment. Find consumers by the meaning they teach or use; a shared word, identifier, or nearby reference is not enough.

Prior-edition and candidate-only uses remain different bases, and both may be present in one revision. Compare the exact predecessor and candidate editions. A prior-edition use keeps its predecessor basis and one of the four classifications above; a candidate-only use keeps its exact accepted basis and receives no old-use class or fabricated history. Treat a selected use as required when its loss changes action or boundary, and as optional when it demonstrates breadth only. Backward compatibility alone is not improvement, and a candidate-only promise is not improvement until the text supports its executable use. Use desk replay by default and escalate to a cold reader, AI-agent, or observed-work check only when ambiguity or consequence justifies it. If later independent review needs a recoverable note, use the smallest existing authoring source; do not create a card, score, universal schema, or one written row per idea.

Test first-use affordability by checking whether the positive Solution supports this short rendering:

recognizable situation -> proposed action or judgement -> first useful result -> next action-changing condition or stop

This rendering explains the pattern; it does not claim that actual work is linear. Use an optional local mantra only when it improves recall and an ordinary walkthrough only when several rows materially improve explanation; choose the smallest form that keeps the action, result, and boundary recoverable. Explanatory rows may fade as competence or task demand permits, but an independently action-changing condition or boundary may not. Use DemonstrativeUnfoldingSlice@Context only after independent [A.22.CGUS](/generated/patterns/A.22.CGUS) admission. Put a subject-side check immediately before the continuation it changes, and keep authoring, review, quality, and release checks outside the subject Solution.

Resolve triggered enumerations semantically. A list is triggered when wording or grammar asserts or implies one common kind, predicate, relation position, authority, action, or result; when its member set or membership rule changes; or when a noun sequence hides a claim or action. A locator or visual scan may find candidates but cannot close the judgment. Give every triggered list one of these resolutions:

Treat one triggered list as a small attention series. A member is a separate unit when its membership can fail independently or require a different subject predicate. A genuinely small closed set may remain one predicate-level unit only when one explicit membership rule decides every member and none has an independent disposition. Nearby nouns that assert no common membership, and unchanged declared closed sets or named-kind example lists still covered by their exact rule, take the cheap positive-control path. A blanket claim that all lists are coherent is not evidence. [E.10](/generated/patterns/E.10) detects enumeration-as-kind and vague heads, [E.10.ARCH](/generated/patterns/E.10.ARCH) requires exact predicates for recovered claims, and [F.18](/generated/patterns/F.18) settles durable names; this authoring method does not duplicate their recognition or naming architecture.

#Stylistic Principles (S-0 ... S-19)

Authors use the principles as a scaffold, not a straitjacket: the goal is coherent, engaging insight. Engagement remains subordinate to semantic discipline: hooks, quotable lines, Plain restatements, and didactic images may improve recognition, but any ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility claim kind or admissible-use boundary they carry must be recoverable through the governed Tech reading or named neighboring pattern. Ordinary Plain prose without that claim kind or admissible-use boundary stays ordinary prose.

S-0 (Narrative Flow Seven-Step Heuristic) — explanation Narrative flow is recommended to follow these steps: Hook -> Frame -> Weave -> Ground -> Bridge -> Flow -> Close.

Brief explanations:

Narrative Flow Heuristic also operationalises S-1 (Density w/o Jargon), S-2 (Internal Cohesion), S-4 (Contextualisation), and S-6 (Quotable Closers).

#Recognition text and assurance text

Every canonical pattern SHALL stabilise one primary EntityOfConcern, relation record, or claim record early enough that a cold reader can tell what kind of thing the pattern is actually governing. If ordinary forms vary (note, sheet, guided UI, rendering, review aid), the text must make explicit which of those are merely presentation forms of one primary selected EntityOfConcern, relation, or claim and which would instead name a different act, process, work-result record, or governing companion. Recognition and assurance texts may refine that selected item differently, but they must not silently swap the central kind.

If a pattern uses a broad umbrella or head together with a narrower operative branch, the text must also make the stack explicit early enough for first reading: what the broad head names, what the current narrowed branch is, what primary EntityOfConcern, relation record, or claim record is actually in play, what exact action assertion and predicate are current, and what wider work or process remains outside the pattern. A qualifier alone does not restore that stack.

Under F.18 local-first naming, the canonical pair here is recognition text and assurance text. The earlier provisional recognition shell and assurance shell wording is retired. These names refer to two reading-order roles carried by existing sections or projections inside one pattern; they do not mint new authoritySourceRef targets, generic neighboring-pattern relations, publication-form/face kinds, publication-face kinds, or a second face family. A third didactic-content role remains optional and is justified only when the family is especially easy to misuse, easy to over-read, or hard to teach without extra scaffolding.

The recognition text is the first-reading text. It is the part of the pattern that lets a cold working reader recognise the situation quickly enough to decide whether to keep reading. It should start from a subject-domain or practice moment before internal taxonomy whenever the pattern is meant to help real work rather than only internal canon maintenance. In practice it usually appears in an early Use this when line or equivalent opening, plus the upper parts of Problem frame, Problem, Solution, Consequences, and nearby worked slices. Its job is to make visible:

• what ordinary working situation this pattern is for;
• what goes wrong if the pattern is missed;
• what the pattern buys the reader in practice;
• when this is not the right pattern;
• what primary EntityOfConcern, relation record, or claim record is actually being kept stable;
• and, when technical terms must appear early, a pairwise plain gloss for each early FPF-governed technical term.

The assurance text is the second-reading text. It carries the heavier FPF-governed material that makes the pattern reviewable and auditable:

• declaration blocks and typed fields when those are part of the pattern's declared conformance or boundary claim;
• representation ontology, EntityOfConcern discipline, or primary-EntityOfConcern discipline;
• any minimal modeling or mathematical lens that keeps the primary EntityOfConcern, relation record, or claim record stable;
• guidance or check material, invariants, admissibility, and stop or neighbouring-pattern conditions;
• SoTA-Echoing when it carries explanatory work;
• and the review hooks that let a broader or more consequential interpretation or use be checked explicitly.

The assurance text may sharpen, justify, and discipline the recognition text. It must not silently replace, strengthen, or universalize the claim that the recognition text made visible. If the recognition text says “this pattern helps with a bounded working situation”, the assurance text must not quietly turn that into an unbacked carrier claim, unbacked guarantee, or broader universality claim.

If a pattern claims universal or transdisciplinary status, that claim must already be visible in the recognition text. It is not enough for universality to appear only later in a guidance or check sheet, declaration block, or SoTA-Echoing rationale. A broad claim should therefore be demonstrated in the recognition text through at least three heterogeneous reader or domain situations. When a compact matrix helps, F.16 is the preferred template for showing that breadth. If SoTA-Echoing carries an FPF-governed claim, the practical implication of those rows should be recoverable from the recognition text and case bank rather than remaining a late-only justification layer.

A third didactic-content role means enough didactic and operational content that the pattern survives without nearby project documents. Typical indicators include:

• at least one concrete source and resulting-publication slice in Archetypal Grounding when the pattern defines or constrains transforms or publication change;
• at least one boundary-heavy example or anti-example when nearby patterns or other governing companion roles are easy to confuse;
• reviewer guidance that tells what to inspect first and which neighboring FPF pattern defines or constrains the failure mode and which project-side FPF kind and reference named by value carries the claim or effect;
• local mini-definitions or glossary material for recurring terms that would otherwise be recovered only from project context.

Pattern density is therefore not “more metadata” and not “longer tag lists”. It is the presence of enough recognition, assurance, and, when needed, extra didactic material that a reader can understand the pattern, apply it lightly in ordinary cases, and recognise when a heavier review profile is required.

#Package-form and neighboring-pattern reference discipline

FPF pattern prose is not free-form descriptive English. Package-form words and references to nearby patterns must keep stable semantic intent without inventing a generic relation in which a pattern contains the defining content for, governs, receives, or acts on content.

For an ordinary neighboring-pattern reference, state the concrete contribution—for example, defines a kind, constrains a relation, supplies a test or method, or provides a useful lookup—and cite the pattern id. An id, heading, file, or locator field merely helps find content; it is not a semantic owner, authority, actor, participant, or evidence that a claim is true. Identify an exact subject assertion, claim-bearing episteme, ClaimGraph, edition, or relation assertion only when the named receiving use depends on that identity, such as interpretation, comparison, migration, conflict, publication, or reuse.

A local ...PatternLocator field may remain where an existing schema already uses it as a non-semantic convenience, but ordinary prose and entry cues do not require one. It never substitutes for the cited content's concrete contribution or, when the stronger identity branch is active, for the exact claim-bearing content. Changing only a locator without changing what it resolves is a representation change; changing the defining content or exact assertion may reopen the semantic object whose receiving use depends on it.

Keep the following package and relation words distinct:

• pattern reference = an ordinary citation to content whose concrete contribution is stated in the current sentence;
• specialization = an exact relation in which the child carries the required parent content plus an explicit child delta and use boundary;
• overlay = a cross-cutting reading or review projection over stated source content; it adds no authority or obtaining relation by name;
• profile = a declarative bounded-use or review projection from stated source content, not a replacement pattern or actor;
• family = a recurring class of cases under an explicit membership rule, not a hidden common owner;
• bundle = a packaged set of defaults, allowances, or coordinated members whose actual relations remain explicit;
• cluster = a navigation or reading-order grouping, with no semantic relation by grouping alone;
• suite = a coordinated set whose suite-level membership and coordination semantics are explicitly stated;
• pack = an editorial, source, review, or delivery grouping, not semantic authority;
• kit = a reusable coordinated publication or boundary-description package with exact kit-level membership and use;
• record = a case, report, assertion, representation, or review record under its own identity;
• umbrella = a provisional review head spanning possible subfamilies before an exact membership rule and the relevant claims and relations are settled.

These words are not interchangeable and do not stand in for a missing relation. Say specialization of ... with delta ..., profile projecting ... for use ..., overlay reading ..., bundle containing ... under membership rule ..., or another exact formulation. A pattern-native role word may be reused when the cited source content defines that role and the current assertion uses it in that sense; otherwise do not improvise near-synonyms for stylistic variety. The preceding receiving-use discriminator decides whether exact claim-bearing content must also be identified.

#Precision-restoration placement discipline

When a pattern or companion text is drafted from E.10 or E.10.ARCH, distinguish two authoring objects:

• semanticArea is the Part-F semantic unit for a wording-use restoration row: one Concept-Set row, one UTS row, or an explicitly bounded row-set. It is declared with semanticAreaBaseConcept and semanticAreaSenseFamily.
• ontologicalNeighborhood is the applicability neighborhood around that named semanticArea: nearby primary EntityOfConcern kinds, relation kinds, claim records, content that defines or constrains the current use, non-use boundaries, and remaining reader use that can carry the recovered meaning after the wording is repaired.
• pattern nest is the publication and specialization placement of a pattern under a declared family or membership relation.

These are not synonyms. A precision-restoration pattern is placed in the pattern nest whose primary EntityOfConcern, relation record, or claim record it repairs. Its semanticArea states the Part-F semantic unit it repairs, while its ontologicalNeighborhood may name several direct relations and pattern content that defines or constrains the asserted uses. For example, quality-term repair lives in the C.16 characterization nest, even though its neighbouring relations can include relation construction, action invitation, evidence, assurance, source-use assignment, engineering quality bundles, pattern-quality evaluation, or mathematical-lens use.

Affected patterns should use a thin pointer when the first-stage wording repair belongs elsewhere. The pointer names the selected restoration pattern and the condition that triggers it; it does not copy the trigger registry, the full E.10.ARCH recovery algorithm, or a second local architecture for the same repair. The affected pattern then keeps its own subject matter: the characteristic, structure, view, episteme, relation, evidence, assurance, gate, work, decision, or adequacy question it already governs.

If a draft proposes a new precision-restoration pattern, the authoring claim must show the repeated wording failure, semanticAreaBaseConcept, semanticArea, semanticAreaSenseFamily, the recovered primary EntityOfConcern kind or relation/claim record, the intended pattern nest, the neighboring governing relations, and the admissible action left after repair. A new pattern is not justified merely because a word appears often, because a local checklist wants a bucket, or because a campaign needs a tidy grouping.

#Reader-role discipline for pattern prose

A pattern is written for its intended FPF user: the person who will use the pattern to organise thought, inspect a case, publish a note, or review a result under that pattern. Its FPF-governed sections therefore explain what the pattern lets that user do, what it forbids, what it costs, and how it relates to neighbouring patterns in user terms. When neighbouring patterns or other governing companion roles are named, the prose should answer one user question such as which neighboring FPF pattern applies, which project-side FPF kind and reference named by value carries the claim, which nearby pattern is easy to confuse, or what must stay coordinated here; it should not read as one explanatory aside about why the package architecture was split that way. E.8 reader and reviewer wording is FPF pattern-authoring wording. Project-side publication readers, explanation readers, comparative review units, and participants in named project-side review relations are governed by the publication or project-side patterns that name those publication units, explanation-use relations, comparative review units, evidence paths, work records, or gate records, such as E.17, E.17.ID.CR, E.17.EFP, A.10, A.15.4, A.20, or A.21.

Authors must keep FPF-development or package-architecture material separate from that user-facing body. In particular, Problem, Solution, Consequences, Rationale, worked slices, and ordinary-vs-FPF-governed wording guidance must not do the work of:

• arguing that the material is worth isolating;
• justifying overlay, profile, family, membership, or authority-reference choice as a package decision;
• discussing authority-reference freeze, naming freeze, merge state, blast radius, or safest landing form;
• or narrating future package promotion or defer decisions.

If architecture-placement commentary is still helpful, the default place is a separate companion note or ADR-like architecture note. A pattern may include a short optional informative subsection such as Architectural placement note (informative) only when that placement materially helps users avoid misuse; even then, it must stay clearly separated from the user-facing solution and rationale rather than replacing them.

#Human-facing fit beyond role correctness

Human-facing fit is also subject-domain fit. A recognition text that starts from internal taxonomy, pattern-placement convenience, or package-architecture wording before the problem-domain moment is still under-authored even if its later guidance or check text is correct. When a broader umbrella name and a narrower operative branch are both used, the recognition text should also tell the reader which stack is actually active rather than leaving that reconstruction to a later declaration block or companion note.

A pattern can already be role-clean, boundary-clean, and reader-role-clean, yet still fail the first minute of use for a cold working reader. That failure usually appears when the text is admissible but does not yet make the working situation, practical payoff, primary EntityOfConcern, non-use boundary, or first action-guiding move visible enough.

P-2 epistemic precision check. When E.10 selects epistemic precision restoration for pattern prose, the first admissible action-guiding move must survive as remaining admissible reader use or be replaced by a neighboring FPF pattern whose content now defines or constrains that claim application. This is a direct E.2 P-2 and E.12 requirement, not an optional style preference. Intentional didactic metaphors and vivid Plain recognition lines are admissible when they are ordinary recognition aids or when their claim kind or admissible-use boundary maps back to Tech under E.10:6.2. A precision-corrected rewrite that leaves the recognition text inert is still under-authored.

For canonical patterns, the first-reading text should behave as a recognition text and the heavier review/check scope should remain in an assurance text.

When a pattern claims practice guidance or is meant to be used by engineers, managers, researchers, or other working readers, authors should make the following visible before the heavier harness takes over:

• a recognisable Use this when or equivalent first-minute recognition cue;
• a concrete working situation in Problem frame, not only taxonomic or pattern-placement language;
• a short statement of what goes wrong if the pattern is missed or misread;
• a short statement of what this pattern buys the reader in practice;
• the first admissible action-guiding move the user should take in that situation;
• a short Not this pattern when boundary for ordinary nearby non-use cases;
• one minimally viable worked case or use slice that shows what changes in practice;
• when a typed declaration block, formal lens, or other compact modeling material is FPF-governed, a short user-facing statement of what kind of object the pattern is governing and what minimal lens keeps that object reviewable;
• pairwise plain glosses for any FPF-governed technical terms that must appear before the heavier declaration role arrives;
• when SoTA-Echoing carries explanatory work, a short working-reader implication for each row or cluster of rows and a visible link back to the case bank or worked slices that those rows discipline;
• a visible split between the recognition text and the heavier assurance text or companion material;
• and, if the draft implicitly serves several working-reader situations, an explicit primary working reader, primary concern, or primary viewpoint.

Problem-frame recognition signature (informative). A canonical pattern should expose the working situation through its Problem frame, not through one separate navigation block. When an E.11 pattern-entry discoverability problem is present, the same Problem frame may also carry candidate-pattern and tempting-wrong-pattern cues; otherwise it should stay with action guidance rather than becoming a local catalogue row.

The local recognition signature should make recoverable:

• the concrete working situation;
• the primary EntityOfConcern, relation named by value, claim record, or stabilized concern;
• what goes wrong if the pattern is missed or misread;
• the first admissible action-guiding move and what that move buys;
• the ordinary not-this-pattern boundary;
• the first admissible action-guiding result; when an E.11 discoverability problem is present, the first admissible entry stop or entry-stabilizing result.

Use this pattern when, This pattern applies when, or equivalent Problem frame prose may be used as the first sentence or compact cue of this signature. It is not one separate required section.

Entry-cue authoring rule. When a pattern needs a reader-facing entry cue, begin with one ordinary question about the user's actual current object and claim, before any PatternID, card, template label, or internal taxonomy. In the same compact cue, state what any cited content contributes and cite the pattern id; name the smallest exact result kind usable now, the stop or return condition, and one tempting overread that remains non-admissible. Add an exact subject assertion, claim-bearing episteme, ClaimGraph, or edition only when the cue's named receiving use depends on that identity. The cue is reading guidance, not a section schema, method, plan, work occurrence, structure, or relation; it neither constitutes the result nor makes a routed relation obtain.

Resolve the current head before coarsening it. Keep an actual holon under the A.1 kind-admission rule and each direct relation under the predicate and occurrence test supplied by A.6.REL or the relevant relation pattern; an independently selected U.Structure under A.22; a boundary-description episteme, its effective ReferenceScheme, and any separately obtaining empirical-grounding relation under C.2.1, with the grounding holon separately admitted under A.1; a U.View under E.17.0; a U.ClaimScope under A.2.6; a U.WorkPlan under A.15.2; dated U.Work under A.15.1; architecture and architecture-description assertions under C.30 and C.30.AD; and a publication occurrence under E.24.PUB. Keep an FPF Map and a decision occurrence under the patterns that define or constrain those values. In an ordinary cue, state those concrete contributions and cite the ids. Identify exact predicate-definition content, a claim-bearing episteme, or a ClaimGraph only when its identity changes interpretation, comparison, migration, conflict, publication, or reuse. Actual, intended, selected, expected, described, viewed, mapped, grounded, published, and performed objects remain distinct. A cue, diagram, description, file, card, suffix, template label, or public coarsening creates none of them and establishes none of their relations.

Compact candidate-pattern comparison belongs in E.11-distributed entry material; expanded entry-disambiguation cases belong in I.2.

If the prose points to neighbouring patterns or companion content, state whether that content defines a kind, constrains a relation, supplies a test or method, provides a project-side FPF kind and reference named by value, or supplies an E.11 entry-recognition reclassification; do not present a citation as a hidden co-authority of the current pattern.

If the pattern claims broad, universal, or transdisciplinary usefulness, that breadth should already be visible in the recognition text. At minimum the recognition text should show at least three heterogeneous reader or domain situations rather than one narrow case family with a later broad claim attached. When a compact matrix helps, F.16 is the preferred template for making that breadth legible.

This is not a request to flatten the pattern into plain language only. It is a rule about ordering, assurance depth, and text consistency: the recognition text must help a working reader recognise the pattern early, while the assurance text continues to carry the full claim kind or admissible-use boundary. If the pattern uses technical lexicon, ontological distinctions, or a mathematical lens, those structures must remain recoverable, but the first-reading text should not require the reader to decode that full stack before recognising the working situation. The assurance text may tighten or discipline the recognition text; it must not silently shift what the recognition text claimed.

Illustrative migration example (informative).

Old pre-template top:

Start here when the dominant question is API, protocol, SLA, published boundary, or compliance wording.
First output: Claim Register.
Neighboring pattern relations and entry-recognition reclassifications: A.6.B, A.6.C.

Repaired Problem-frame recognition signature:

Use this pattern when boundary-facing language - API, protocol, SLO/SLA, compliance clause, or other published boundary description - mixes guidance or check clauses, admissibility gates, duties, and evidence into one sentence or published boundary description.

If missed, the text becomes boundary-claim soup: runtime behavior, governance, and evidence are treated as one undifferentiated promise.

Do not use this pattern merely because the text mentions an API or boundary description. If the question is still one unstable cue, preserve it through the admissible cue-preservation line first.

First admissible action-guiding result: one `A.6.B`-governed atomic claim set or one Claim Register whose claim/use questions are explicit enough for the pattern content that defines or constrains the claim, or for a named project-side FPF kind and reference, to inspect.

#Design-time and run-time referents stay separated in pattern prose

Pattern prose must keep its referent index explicit. In ordinary body sections, the default truth-makers are run-time or governed-domain objects, states, moves, boundaries, consequences, and user-facing practical effects. Normative-standard wording is still admissible when the sentence is explicitly about the standard as a normative publication, for example in marked migration navigation examples, marked informative notes, or conformance/checklist clauses.

Design-time and development-state referents are different objects. The current draft, current body, current pass, author, reviewer, handoff, packet, governing companion, landing choice, or other writing-process objects must not be smuggled in as the hidden truth-condition of pattern prose. A quick test is: what makes this sentence true? If the sentence is true because the current text is arranged a certain way, because the author or reviewer must do something next, or because the current development state says so, then it is design-time residue, not pattern content.

Move that material to the authored-slice carrier, handoff, DRR, or companion architecture note. If a sentence is kept in the pattern, rewrite it so that its truth depends on the governed run-time/domain object or on the standard's declared normative claim set rather than on the current writing pass. If a pattern or example claims autonomy for any Role, Method, or Service:

1. Add a subsection “Autonomy (RoC‑E.16)” that lists:
   • AutonomyBudgetDeclRef (id, version, Scope (G), Γ_time),
   • Aut-Guard policy-id (PolicyIdRef),
   • OverrideProtocolRef (SpeechAct names, SoD),
   • pointer to where Green‑Gate applies in the Method steps,
   • where AutonomyLedgerEntry is recorded on U.Work.
2. Include one Tell‑Show‑Show vignette that demonstrates depletion and override handling.
3. Use LEX‑BUNDLE terms (Scope (G), Γ_time, Role, Method, and Work). Avoid “validity”, “process”, “actor”, “system”, “mechanism” unless mapped to admitted U-kinds or to the concrete definitions or constraints supplied by cited patterns.

#Archetypal Grounding (System and Episteme)

Note: Prefer examples that reuse FPF characteristics vocabulary (e.g., F (Formality) rather than “F‑score”) unless you explicitly mean an external metric and name it as such.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for the authoring conventions in this pattern. This guidance biases toward Did (readability, narrative flow) and Arch (template regularity) by design; the mitigation is content-bearing reduced sections and justification through the smallest grounding, misuse, boundary, or reduced-case statement, not omission placeholders.

#Conformance Checklist

CC style (canonical). Conformance Checklist items are authoring checks: they test whether the pattern guidance has been applied and written correctly in a pattern or companion text that claims conformance. They do not replace Solution, do not make the pattern a control form, and do not state deontic obligations about the modeled world. A CC clause of the form “X SHALL ...” is to be read as “In a conforming pattern or companion text, X SHALL ...”.

Preferred wording for new or edited CC items: start with an explicit conformance subject (e.g., “Authors ...”, “Reviewers ...”, “A conforming implementation ...”, “A validator ...”). If a CC item is enforcing an admissibility predicate, it SHOULD cite the predicate’s identifier (from a Definition: / Invariant: / Well-formedness constraint: block) rather than restating the predicate as “X MUST ...”. For boundary/interface/protocol/declaration patterns, prefer A.6.B-scoped claim IDs (L/A/D/E) or cite an existing Claim Register (A.6.B:7) instead of restating mixed prose.

#Common Anti-Patterns and How to Avoid Them

These failure modes recur in drafts and in downstream application. They are predictable ways the Forces in this pattern get violated.

#Consequences

#Rationale

Structure and style function as FPF’s grammar. By unifying what were once separate “template” and “style guide” patterns, authors face a single reference point that satisfies:

• P‑1 Cognitive Elegance – uniform, minimal surprises.
• P‑2 Didactic Primacy – narrative flow, dual archetype examples.
• Guard‑Rails 1 & 2 – no tool jargon, no notation lock‑in inside prose.

A unified template also improves retrieval: a chunk containing A.2:<n> - Bias‑Annotation remains self‑identifying even when parent headings are missing, and the recommended footer marker makes truncation detectable.

International and industry standards often speak in terms of conformance criteria. FPF uses the label Conformance Checklist to make adoption easier for engineers and managers.

#SoTA-Echoing (normative; lineage and deltas to contemporary State-of-the-Art)

Purpose. Make each pattern's relationship to contemporary best-known problem-solving practice explicit and comparable without importing tooling or data governance. This section is prose-first and notation-independent. It does not mint an independent second rule source, but it is an FPF-governed alignment section: the Solution, Conformance Checklist, Relations, worked cases, and other FPF-governed sections must reflect the stance stated here or explicitly justify divergence.

SoTA definition. In FPF, SoTA names the best-known currently defensible problem-solving practice for the named practice question in the relevant domain or practice tradition. It is not official status, a recent edition, broad popularity, citation volume, institutional adoption, reputation, or familiar terminology. A standard, book, paper, benchmark, or practice report carries SoTA only when it states or justifies the current best-known answer for the named practice question; otherwise it is lineage, current-standard reference, rationale-only material, or rejected-popular-practice material.

Two-part SoTA test. A row must pass both tests. First, the source family must be SoTA-bearing: it must represent the current best-known answer for the named practice question or a clearly named current branch of that answer. Second, the pattern must incorporate that answer by value: the adopted, adapted, or rejected stance must change Solution, boundary, anti-pattern, rationale, checklist, relation, worked case, evidence requirement, stop/reopen condition, or another FPF-governed pattern locus. A current best-known source that changes no FPF locus is uncaptured SoTA; a citation that changes wording without being current best-known practice is not SoTA.

Incorporation test. A SoTA row is accepted as pattern grounding only when it changes what the pattern lets a working user do, what the pattern forbids them to over-read, which neighbouring FPF pattern must apply, which evidence or validation requirement remains applicable, or how the Solution and neighbouring FPF-governed sections are written. A citation that only decorates the pattern or proves that the author has read a tradition does not carry E.8.

Minimum contents (authoring requirements).

1. Evidence binding (no duplicate SoTA). If a SoTA Synthesis Pack exists (G.2), this section SHALL cite its ClaimSheet IDs, CorpusLedger entries, and BridgeMatrix rows as the governing evidence source for claims and report adopt, adapt, or reject consistent with those IDs. Avoid forking an untracked SoTA narrative. 1a) Accepted decision and source material set, not DRR-only narrowing. When a pattern is drafted under an accepted DRR and other accepted decision or source materials also exist by value, the DRR remains the decision and placement record, but SoTA-Echoing, neighboring-pattern relations, and any minimal modeling or mathematical lens MAY and SHOULD inherit non-conflicting material from that accepted material set.
2. Sources (current problem-solving source refs, not prestige refs). For Architectural patterns, cite at least 3 primary SoTA source refs that carry current best-known answers for the named practice question, with at least two independent Traditions when more than one serious tradition currently answers that question. For Definitional patterns, cite at least 1 current source or practice ref for the reduced issue being governed: terminology work, ambiguity or sense recovery, separation between constraint and ontology, controlled-vocabulary caution, or a comparable definitional problem. If the best source is older but still current, mark why it still answers the named practice question rather than treating source age, standard status, or popularity as SoTA by itself.
3. Best-known, not merely popular. Authors SHALL distinguish best-known currently defensible practice from merely widespread or fashionable defaults. If the pattern adopts, adapts, or rejects a popular but less defensible practice, that divergence MUST be stated explicitly. 3a) Currentness and lineage status. Older standards, early papers, and historically important examples may be cited as lineage only when later practice has materially changed the answer. They may carry a SoTA row only when the pattern states why the source ref is still current for the named practice question or pairs it with a current source that supplies the current practice. 3b) Problem-domain and practice answerability. The selected SoTA source family MUST answer the governed working problem and the relevant domain or practice tradition. It MUST NOT be selected only because it makes package placement, naming neatness, or pattern clustering easier to justify.
4. Practice alignment. For each cited item, state what is adopted, adapted, or rejected and why in 2 to 4 sentences.
5. Scale admissibility. If numeric operations are implied, bind to ComparatorSet or CG-Spec and declare partial-order stance with no hidden scalarization.
6. Cross-Context reuse. Any reuse across U.BoundedContext must expose Bridge id plus CL and, if ReferencePlanes differ, Phi policy ids; penalties affect only R_eff.
7. Lexical hygiene. Avoid “mapping” unless you mean an explicit Bridge, translation relation, or other named relation with loss notes.

Writing guidance (readability). Write short paragraphs, not tag lists. For each Tradition, provide one sentence naming the practice, one sentence comparing it to the pattern's Solution, and one sentence giving adoption status with reason. Where helpful, add one System and one Episteme micro-example (Tell-Show-Show).

Format: human-first. A small table is allowed, but each row MUST be accompanied by 1 to 2 sentences as above. Vendor tokens, tool tokens, file formats, or data schemas are out of scope unless the named practice question under discussion makes them have FPF-governed use.

#SoTA alignment for this pattern (E.8 self-echo)

#Relations

• Coordinates with: E.9.DA when an authored pattern body is drafted from a concrete DRR and the blocker is whether the DRR selected, distributed, carried source use, carried accepted decisions, or supplied a first drafting action sufficiently for that authoring use. E.8 still governs the pattern body; E.9.DA is not a mandatory authoring section, review card, or substitute for writing the Solution.

• Builds on: E.6, E.7

• Constrained by: Guard‑Rails E.5.1–E.5.4 (lexical firewall, notation independence, etc.)

• Coordinates with: E.21 when one authored FPF pattern version is evaluated as a scoped pattern-quality claim. E.8 governs authoring shape, recognition text, action guidance, worked cases, SoTA grounding, and conformance material; E.21 governs the pattern-quality evaluation, required coordinate values, PatternQualityStatus, and stop condition. Do not import E.21 as a mandatory authoring section or full review card.

• Coordinates with: E.23 when an authored FPF pattern body is being improved through repeated passes. E.8 still governs the authored pattern body; E.23 governs the repeated quality-improvement method; the object-under-improvement evaluation such as E.21 or E.9.DA supplies value meanings and stop meanings.

• Coordinates with: E.13 when an authored pattern claims practical payoff or uses a visible quality value, metric, checklist result, review result, or release posture as if it were the intended value. E.8 keeps the payoff in user-facing prose; E.13 repairs proxy-to-value substitution.

• Coordinates with: E.11.PUR, which supplies the recommended-pattern-use decision for a current concern, and E.10.MOVE, which disambiguates whether move-like wording names pattern-use recommendation, direct work, plan, gate, transformation, publication, source, architecture, call-planning, or language-state material. These references state concrete contributions; an exact assertion, claim-bearing episteme, or ClaimGraph is added only when the named receiving use depends on that identity.

• Constrains: All patterns; the DRR template references the same section order.

#E.8:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)