#Episteme-Publication Semantic Rewrite Discipline

E.10.SEMIO · Stable · Definitional (D), E.10 cluster specialization · Normative unless a section is explicitly 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-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.

Type: Definitional (D), E.10 cluster specialization Status: Stable Normativity: Normative unless a section is explicitly informative

Use E.10.SEMIO when semio-heavy conformant text relies on loose wording around epistemes, publications, views, publication forms, generic publication faces, governed MVPK faces, bounded publication units, carriers, records, relations, admissible uses, or pattern application.

#Relations

#Content

#Use this when

Use E.10.SEMIO when semio-heavy conformant text relies on loose wording around epistemes, publications, views, publication forms, generic publication faces, governed MVPK faces, bounded publication units, carriers, records, relations, admissible uses, or pattern application.

Use it especially when wording around claim-bearing epistemes, described entities, publication units, publication forms, admissible use, claim support, pattern application, placement wording, movement wording, or slash compounds seems convenient but may be carrying ontology, authority, evidence, or admissibility load.

Ordinary-language survival. Ordinary words remain admissible until the sentence gives them FPF-kind, relation, authority, evidence, admissibility, work, gate, decision, bridge, or reliance load. Source may stay ordinary when it only means where a quote came from; view may stay ordinary when it means what the reader sees and not U.View; route may stay ordinary navigation prose; support may stay ordinary help. Repair by load-bearing sentence function, not by trigger word alone.

Do not punish clarity. Prefer the clearest ordinary head that preserves kind, relation, and admissible use. Do not replace a clear plain phrase with a technical phrase unless the technical phrase blocks a live false reading or is needed for accepted stable FPF naming. In an ordinary case, reader help, source-pointer-only, or comparison only may be better than a more technical phrase.

Not this pattern when. E.10.SEMIO is not the governing pattern for every recovered construct. General lexical discipline stays under E.10; stable reusable naming under F.18; relation precision under A.6.P; A.6.B law-, admissibility-, deontic-, and effect-claim boundary splitting under A.6.B; object-description-carrier separation under A.7; view and publication discipline under E.17 and E.17.0; project work, evidence, gate, decision, method, action-invitation, assurance, and engineering-justification claims under their exact FPF patterns. When one of those claims is live, this pattern supplies only the semio trigger, recovery, and rewrite profile; the neighboring named pattern supplies its invariant.

First output. The ordinary first move is to repair one overloaded phrase, row, field, or sentence so the reader can tell which exact FPF kind, relation, publication construction, or project-side value is live. If that one local repair restores kind, relation, and admissible use without changing work, evidence, gate, release, policy, assurance, adjudication, or bridge use, stop there. Use a compact pattern-local SemioRewriteRecord or equivalent local rewrite note only when the phrase carries load that must remain inspectable after the repair.

When a load-bearing recovery note is needed, the final value is one exact FPF kind, relation record, relation phrase, tuple-like record, exact project-side FPF kind and reference when projectSourceLoad is live. The selected value is one live value, not the list: C.11 ChoiceResult; C.11 decision record; A.6.A action invitation; A.15 U.WorkPlan; A.15.1 dated U.Work occurrence; U.Method; U.MethodDescription; A.20 constraint or adjudication decision record; A.21 GateDecision; A.21 DecisionLogRef; A.10 evidence path; typed evidence record; B.3 assurance or engineering-justification record; typed status record whose FPF status pattern is named; carrier relation; front-end relation; or not-triggered alternative. Otherwise it is explicitly left as quote-only wording, reduced-use cue, understandable FPF extension candidate, or blocked current transfer.

#What goes wrong if missed

Semio-heavy text starts to build a parallel ontology. A generic publication face becomes a U.View, a file becomes an episteme, a dashboard tile becomes evidence, a pattern name becomes a procedure, a slash list becomes a group kind, or a broad word such as source hides whether the text means a pattern, a DRR, a publication, a document with named source-basis, evidence-basis, architecture-basis, or review-basis role, an exact project-side FPF kind and reference, or a relation.

The immediate cost is not only ugly terminology. Engineers and FPF authors start making action, evidence, gate, decision, or engineering-justification claims from the wrong object.

#What this buys

E.10.SEMIO gives authors and reviewers one small semantic-rewrite action: recover the FPF kind stack first, then write exact wording that preserves the needed distinction without adding another claim. It prevents string-replacement cleanup, keeps FPF-side and project-side episteme and publication work separate, and blocks unclear text from becoming current FPF content by author guesswork.

Successful repair condition. Semantic repair is not closed by type-correct wording alone. It is governed by E.2 Pillars, especially P-2 Didactic Primacy, together with E.12 and the register rule in E.10:6.2. It closes only when the repaired text preserves or restores one remaining admissible reader move: a usable action, a recognition reason that tells the working reader why the distinction matters, or a named neighboring-pattern handoff that now carries the live claim. When both Tech and Plain registers are live, the Tech reading must remain recoverable and any Plain or didactic line must map back to that Tech reading. A Plain, more expressive line, or intentional didactic metaphor may stay ordinary when it carries no FPF load; when it carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility load, that load must be recoverable through the Tech fields, exact FPF kind, recovered relation, project-side source reference, or disposition named by the repair. If a repair in a load-bearing Problem frame, Problem section, recognition text, example, or worked slice makes the text more exact but less able to show the working situation, why it matters, or what action remains, the repair is incomplete unless a named neighboring FPF pattern now carries that live claim. Overread removal is only half of semantic repair; the other half is surviving admissible action under the Pillars.

Governed object in plain terms. The governed object is one semio-heavy wording use inside conformant text: the word or phrase, the sentence function it carries, the FPF kind or relation it must recover, and the admissible remaining use after recovery.

Primary working reader. The first reader is an author or reviewer of conformant FPF-style text who must repair wording without losing ontology. The downstream reader is the engineer-manager using the resulting pattern or project text in a working situation.

Anti-overread payoff question. A repair is useful only if the pattern text can answer three things in ordinary prose: what false downstream reading is blocked; what useful admissible action remains; and when the reader must apply a neighboring FPF pattern because evidence, gate, decision, work, assurance, bridge, release, or reliance is live. If the repair blocks an overclaim but leaves no useful action, the text is probably becoming ceremony rather than guidance.

#Problem frame

FPF already has episteme, publication, view, carrier, presentation, relation, naming, and pattern-application concepts. Semioarchitecture work nevertheless created many convenient intermediate words while the architecture was being discovered. Those words were useful in chat, review, and drafts, but they are dangerous when they survive as final pattern or architecture prose.

The recurring situation is simple: a sentence is understandable enough to feel worth keeping, but its head kind is not recovered. If it is repaired by replacing one broad word with another broad word, the ontology gets worse while the text looks cleaner.

#Purpose Carried From The Glossary And Rules

This pattern gives the current glossary and rewrite rules for terms around epistemes, publications, views, publication forms, generic publication faces, governed MVPK faces, carriers, records, and bounded publication units.

It exists because semio-heavy texts can use locally convenient heads that collapse described entity, publication unit, publication face, carrier, record, source relation, and project-side value. Those words may be useful recognition handles, but they are not safe FPF heads when they carry ontology, authority, or authority-changing meaning.

The rewrite discipline here is semantic, not lexical:

• do not replace one broad token with one new broad token by string substitution;
• first recover the FPF kind stack, the claim-bearing status, the publication, view, carrier, or relation construction, and any work, action, or authority crossing;
• then choose the smallest exact wording that preserves the load-bearing distinction without creating a second ontology.

This pattern follows the E.10 style: head noun first, kind and relation discipline second, register, plain use, and tech use third, and only then canonical rewrites.

#Problem

Without a semantic-rewrite discipline for semio-heavy wording:

1. broad publication words hide whether the claim is about U.Episteme, U.View, publication form, generic publication face, governed MVPK face, PublicationUnit, carrier, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, review target, or exact project-side FPF kind and reference;
2. FPF pattern-application claims and project-side work-occurrence, work-plan, decision, action-invitation, method, record, carrier, or front-end claims get mixed in one sentence;
3. slash lists and heterogeneous rows become false group kinds;
4. unclear source meaning is guessed into FPF rather than blocked or promoted through an accepted FPF extension;
5. authors copy the same loose wording into DRRs, patterns, source-basis notes, or project texts.

#Forces

#Solution

Repair semio-heavy wording by semantic recovery, not by dictionary replacement.

A successful rewrite satisfies these field-validity constraints:

1. the head kind and sentence function are recoverable under E.10;
2. a stable reusable name has F.18 status;
3. a relation, comparison, dependency, support, sameness, grounding, mapping, or endpoint claim has A.6.P relation precision, with admissibility and project-side support questions split into their own fields;
4. a claim-bearing episteme, exact episteme species, episteme-lane view, or exact project-side FPF kind and reference has the needed C.2.1 or neighboring FPF reading;
5. publication, view, face, and carrier distinctions satisfy E.17.0, E.17, and MVPK;
6. the repaired text satisfies E.2 Pillars, especially P-2 Didactic Primacy, by preserving or restoring one remaining admissible reader move: a usable action, a recognition reason that tells the working reader why the distinction matters, or a named neighboring-pattern handoff that now carries the live claim; when both Tech and Plain registers are live, the Plain or didactic line maps back to the recovered Tech kind, relation, or neighboring-pattern handoff under E.10:6.2; ordinary Plain wording and intentional didactic metaphor stay light when they carry no FPF load, but ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility load in a more expressive Plain line must be recoverable through the repaired Tech fields; load-bearing Problem frames, Problem sections, recognition texts, examples, and worked slices must still show the broad working situation and first useful move, or the rewrite is incomplete;
7. the final phrase preserves the distinction without adding another claim;
8. unrecoverable meaning, kind, register mapping, or remaining reader move fails closed.

The detailed solution below carries the glossary and rewrite rules as ordinary pattern subsections. It is not an external container: these subsections are the pattern's detailed semantic-rewrite guidance.

#SemioRewriteRecord

For load-bearing cases, the recovery product is a compact pattern-local SemioRewriteRecord or an equivalent local rewrite note. Ordinary local phrase repair may end as the repaired sentence itself when kind, relation, and admissible use are now clear and no downstream reliance, cross-context reuse, grouped-kind risk, hidden authority claim, project-side overclaim, conflict among publication, describedEntity, and project-side action claims, or contested source meaning remains live. Prefer the plain names semantic rewrite note, compact semantic rewrite row, or local rewrite note when durable inspection does not require the code-like field name. The recovery note is a lightweight pattern-local author or reviewer product, not a new ontology, not a dispatch table, not a durable FPF record kind, and not a mandatory heavyweight project record. It becomes a durable FPF record only if another accepted pattern or accepted DRR explicitly admits it as one. It records only the trigger, the recovered FPF kind stack, the requirement from the exact governing FPF pattern, and the final rewrite disposition that must remain inspectable after the repair.

Minimum fields when load-bearing:

Recover by claim force, not word form. For words such as source, support, status, valid, ready, approved, and used, first ask what the sentence would let the reader do or rely on: source-finding only, source availability, source use, evidence support, gate passage, decision status, readiness threshold, work permission, assurance, engineering justification, or ordinary orientation. Then fill only the field whose exact FPF kind, relation, or project-side reference is live.

Use the short form when only one field is live. Use the full record when several fields are live or when the phrase might otherwise create a grouped kind, hidden authority claim, project-side overclaim, conflict among publication, describedEntity, and project-side action claims, contested source-meaning transfer, or procedure-like ordering of pattern applications.

#General Recovery Check

Use this recovery check whenever the text proposes a new term, repairs a semio-heavy term, or relies on wording around PublicationUnit, describedEntity, publication, view, face, carrier, source relation, target relation, publication face, described entity, or bounded publication-unit status.

1. E.10 head-kind and relation recovery. Decide what the head noun names before accepting the phrase: intension, description episteme or specification episteme, U.Episteme, U.View, publication form, generic publication face, governed MVPK face, carrier or rendering, exact project-side FPF kind and reference, A.15.1 dated U.Work occurrence, A.6.A action invitation, A.2.9 SpeechActRef, A.2.8 U.Commitment, U.Method, U.MethodDescription, or document with named source-basis, evidence-basis, architecture-basis, or review-basis role, or review target. Apply Intension, Description, and Specification, Context, Tech and Plain, and carrier humility rules before treating a word as meaning-bearing.

2. F.18 naming pass when a stable term is being chosen. If the phrase is becoming a reusable head, fill at least the lightweight Name Card facts: Context, Kind, purpose and use-domain, local sense, candidate head families, NQD-front reasoning, sense-seed read-through, and the lexical Q tuple {SemanticFidelity, CognitiveErgonomics, MorphologicalActionFit, AliasRisk}. Do not pick a label only because it is intuitive.

3. A.6.P relation-precision pass when a phrase carries relation, comparison, or action load. Restore generic head kind first, then endpoint facets and kinds, then relation kind, slots, qualifiers, scope, time, viewpoint, and hooks for admissibility, evidence, and work. If ambiguity remains, write a local Candidate-Set Note rather than debating synonyms.

4. C.2.1 episteme-slot pass when the object is claim-bearing. Name describedEntity, grounding, ClaimGraph, viewpoint and view, reference scheme, representation scheme, and bounded context as far as the claim needs. Do not use PublicationUnit or a carrier word as a substitute episteme.

5. E.17.0, E.17, MVPK publication pass when the object is published or reader-facing. Separate the underlying episteme or view, U.EpistemePublication, publication form, generic publication face, governed MVPK face, PublicationUnit, carrier or rendering, and the exact project-side FPF kind and reference when a project-side claim is live. A face, card, screen, or explanation can guide reading or source-finding without becoming evidence, work, gate passage, authority, or release permission. If those claims are live, fill admissibleUse and projectSourceLoad instead of treating the generic publication face or governed MVPK face as the source value.

6. Remaining admissible reader move. After the kind, relation, publication, and project-side splits are recovered, state the remaining admissible reader move in one short line: what the working reader can now do, why the distinction still matters, or which named neighboring FPF pattern now carries the live claim. If both Tech and Plain registers are live, keep the Tech reading recoverable and make the Plain or didactic line map back to the recovered Tech kind, relation, or named neighboring-pattern handoff under E.10:6.2. Do not make this a heavy form for ordinary prose: a Plain line that carries no FPF load may stay ordinary; a Plain line that carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility load must be recoverable through the repaired Tech fields. If the repaired wording only proves that an overclaim was removed, but leaves no usable action, recognition reason, or neighboring-pattern handoff, do not classify the repair as recovered by value.

7. Authority-changing rewrite boundary.

   If the result would rename an accepted FPF pattern, change an accepted FPF term, or mint a reusable FPF kind, this pattern only classifies the phrase as recovered by value or as an understandable FPF extension candidate. It does not make the authority change by itself. Use the accepted source that already carries the decision by value; do not add a second decision source merely to restate the same content.

Fail closed:

• if the kind stack cannot be recovered, keep the term as plain or informative prose;
• if the relation kind cannot be recovered, keep the statement as a cue or split alternatives;
• if the publication construction cannot be recovered, do not use that publication, generic publication face, governed MVPK face, form, carrier, or rendered unit for work, evidence, gate, or authority claims. Fill relationLoad only when a relation claim is live, and fill admissibleUse plus projectSourceLoad when an admissibility or project-side support claim is live;
• if the recovered wording is type-correct but leaves no remaining admissible reader move, recognition reason, Tech-to-Plain mapping when both registers are live, or neighboring-pattern handoff, or if a Plain or didactic line supplies practical force through unrecovered ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility load, mark the rewrite incomplete or demote the phrase to quote-only wording, reduced-use cue, or blocked current transfer before using it as current pattern, architecture, DRR, or project text.

#Slash Discipline

In many standards, a slash can mark near-synonyms or parallel labels. In FPF-facing semioarchitecture, a slash is a recovery trigger before it is a synonym marker.

Before leaving a slash expression in current prose, classify the expression as one of these cases:

• an accepted token, formal notation, file path, URL, quoted source wording, or product name where the slash is part of the carrier syntax;
• a plain-language synonym pair with no ontology, authority, evidence, or admissibility load;
• a composite-kind candidate that needs F.18 and A.6.P recovery;
• a relation claim that needs a RelationKind, a QualifiedRelationRecord, or a multi-term relation phrase with typed endpoints, slots, qualifiers, scope, time, and viewpoint;
• a tuple-like record that needs a named record kind and named slot semantics;
• a failed ontology signal where the sentence lists unlike objects because the live FPF kind, relation record, relation phrase, tuple-like record, or not-triggered disposition has not yet been recovered.

If the expression is not one of the first two safe carrier or plain-language cases, do not keep the slash as final wording. Write the recovered FPF kind, relation record, relation phrase, tuple-like record, or not-triggered disposition by value.

#Unclear Source Meaning and FPF Extension Candidates

Sometimes the problem is not a bad word but one of two different cases:

• the intended claim cannot be determined from the surrounding source, current FPF kinds, or current semioarchitecture;
• the claim is understandable, but current FPF does not yet contain the kind, pattern, relation record, or method guidance needed to carry it.

Do not merge those cases. An unclear claim is not current architecture truth merely because deleting it feels risky, and it must not be rewritten by guessing a likely author intention. An understandable uncovered claim may be retained as a candidate FPF extension only when the problem situation, tempting overread, rejected current uses, current FPF gap, and the first user action that would improve are stated by value.

Classify the case explicitly:

• recovered by value: the text now names the exact U.Episteme, describedEntity, U.View, publication form, generic publication face, governed MVPK face, PublicationUnit, carrier relation, relation record, relation phrase, tuple-like record, FPF pattern, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, exact project-side FPF kind and reference when projectSourceLoad is live. The selected value is one live value, not the list: C.11 ChoiceResult; C.11 decision record; A.6.A action invitation; A.15 U.WorkPlan; A.15.1 dated U.Work occurrence; U.Method; U.MethodDescription; A.20 constraint or adjudication decision record; A.21 GateDecision; A.21 DecisionLogRef; A.10 evidence path; typed evidence record; B.3 assurance or engineering-justification record; typed status record whose FPF status pattern is named; carrier relation; front-end relation; or not-triggered alternative;
• understandable FPF extension candidate: the thought is clear enough to state as a candidate new or amended FPF kind, pattern, relation record, method guidance, DRR obligation, or campaign problem, but it does not carry current authority, evidence, or admissibility load until an accepted architecture decision, accepted DRR, or accepted FPF pattern supplies that authority;
• quote-only source wording: the phrase may remain only as quoted source wording or provenance, with no current authority, evidence, or admissibility load;
• reduced-use cue: the phrase is kept only as a recognition cue or anti-case, not as a claim-bearing architecture decision;
• blocked current transfer: the phrase is not admissible for claim-bearing architecture, DRR, pattern, or project text until a new source, author clarification, or accepted architecture decision supplies the missing meaning, kind, or relation.
• rewrite incomplete: the repaired wording may be kind-correct, but it does not yet state a remaining admissible reader move, recognition reason, Tech-to-Plain mapping when both registers are live, or neighboring-pattern handoff, or a Plain or didactic line carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility load that cannot be recovered from the Tech reading; continue repair or demote to a non-transfer disposition before treating the text as landed.

These dispositions are recovery results, not a meta-governance authority over all of FPF. When recovery names a neighboring FPF kind, the neighboring FPF pattern governs that kind, its admissible use, and its conformance checks. E.10.SEMIO may identify that A.10, A.15, A.15.4, A.20, A.21, B.3, C.11, F.9, E.17.EFP, E.17.ID.CR, or another neighboring FPF pattern is live. It does not govern the recovered kind after that identification. E.10.SEMIO only makes the live kind, relation, and use boundary explicit enough that the right governing pattern can be applied.

No other disposition is closed. In particular, "seems to mean", "probably about", a cleaner paraphrase, or a broad umbrella replacement is not a successful recovery.

#Core Glossary

#Cross-Side Fields That Must Stay Split

These fields are current semioarchitecture vocabulary for DRR, architecture, and pattern-drafting work. They exist to prevent one sentence from mixing FPF-side admissibility, project-side records, actual work or action, method selection, carrier access, and authority records. They are local recovery aids, not FPF kinds, not record kinds, and not a universal record ontology. Each field closes only by naming the exact FPF kind, relation record, relation phrase, exact project-side FPF kind and reference, or explicit non-transfer disposition that is live in the sentence. The same local-aid rule applies to neighboring field names such as sourceSupportPosture, explanationSourcePosture, comparativeRelationPosture, representationValiditySupportPosture, allowedUse, misuseRisk, and worldContactPolicy: they help record a local recovery or reader-use boundary, but they do not become kinds. Posture fields do not instantiate evidence, gate, assurance, work, commitment, speech act, decision, release, authority, representation kind, world-contact kind, or policy kind. Read allowedUse as a local reader-fit field under admissibleUse, not as permission, evidence support, or authority.

#Episteme, Publication, Carrier Stack

#FPF Text Trigger Lexicon

These trigger words are frequent in conformant FPF and FPF-facing project texts. Files carrying FPF pattern text are useful search examples, not the boundary of semantic cleanup: the same rule applies wherever the text under repair is claim-bearing FPF or FPF-facing project guidance. They are not banned words. They are words that must trigger kind recovery when they carry ontology, authority, evidence, or admissibility load. The table gives alternatives to recover from; it must not be copied as a group kind. The chosen rewrite may be a named kind, a relation record, a multi-term relation phrase with typed endpoints, slots, qualifiers, scope, time, and viewpoint, a tuple-like record, or an explicit not-triggered disposition.

#Current Preferred Vocabulary

Use PublicationUnit when the intended object is a bounded, human-inspected unit inside a publication. Do not use it for UI behavior, carrier behavior, front-end behavior, file identity, dashboard behavior, or export behavior; use A.7, carrier wording, front-end wording, or the exact neighboring FPF pattern instead.

Use the current cluster names directly: PublicationUnit Stability Discipline, Local Head Restoration, and PublicationUnit Primary Described-Entity Discipline. When the live object is a bounded unit inside a publication, use PublicationUnit; when the live object is authoring or editing work, name that work directly.

Use primary described entity, DescribedEntityRef when local wording means the described entity named by a claim-bearing episteme or episteme-lane view.

Use ordinary topic, subject, or local object only in non-normative explanatory prose where no episteme slot, publication construction or authority relation is being asserted.

Do not mint any other new reusable FPF name from this pattern alone. PublicationUnit is governed by the E.17.AUD cluster named PublicationUnit Stability Discipline; this pattern recovers bounded-publication-unit wording into that head when the object is live and points to that cluster for governance. Load-bearing uses keep the nearby definition or explicit publication stack.

#F.18 And A.6.P Admission Reading For PublicationUnit

This is the F.18 and A.6.P name reading that this pattern reflects from the selected E.17.AUD cluster correction. It records why PublicationUnit is the selected bounded publication-unit head for the E.17.AUD cluster, while E.10.SEMIO remains the semantic-rewrite profile.

F.18 and A.6.P admission reading:
  Context: conformant FPF authoring and review where bounded publication units must not be confused with epistemes, views, publication forms, generic publication faces, governed MVPK faces, carriers, authoring work, or review process.
  Kind: governed-object head for a bounded unit inside one publication.
  Purpose and use-domain: keep one human-inspected publication unit distinct from episteme, view, publication form, generic publication face, governed MVPK face, carrier, authoring work, and review process.
  Selected Tech label: PublicationUnit.
  Plain reading: bounded unit inside a publication that a person inspects as one unit.
  Candidate head families considered:
    - authoring-centered unit labels
    - reading-centered unit labels
    - mixed authoring-and-reading unit labels
    - PublicationReadingUnit
    - PublicationAuthoringUnit
    - PublicationUnit
    - ContentSpan
    - DocumentUnit
  F.18 result:
    - `PublicationUnit` has better SemanticFidelity than authoring-centered unit labels because the unit belongs to the publication lane, not to the authoring process.
    - `PublicationUnit` has better MorphologicalActionFit than mixed authoring-and-reading unit labels because it does not mix author, reader, and unit-boundary roles in one head.
    - `PublicationUnit` has lower AliasRisk than `content span` and `document unit` because `content` and `document` blur episteme, publication form, and carrier.
    - `PublicationUnit` still has nonzero AliasRisk because `publication` itself splits into act or occurrence of publishing, episteme publication, form, generic face, governed MVPK face, unit, and carrier; therefore load-bearing uses keep the nearby definition or explicit publication stack.
  Current status: admitted reusable FPF head for this pattern and its selected campaign scope; use a more specific already accepted head where one governs the text under repair.

#Rewrite Rules

#primary described entity and local topic wording

Do not replace every topic-like or object-like phrase with describedEntity. Classify the sentence first.

Required check:

described-entity rewrite:
  sentence under repair:
  claim-bearing episteme live? yes or no
  describedEntity, grounding, ClaimGraph, viewpoint slots triggered:
  PublicationUnit reading, if any:
  review-target reading, process-description reading, source-basis-document reading, if any:
  chosen replacement:
  distinction preserved:

#publication-unit wording that implies authoring or reading work

When a phrase makes the bounded unit sound like authoring work or reading work, split the sentence by live kind.

Do not make a permanent technical modifier by joining authoring, reading, and unit-boundary roles. That mix hides whether the sentence is about a publication unit, authoring work, reader inspection, or a carried claim.

#content

Do not use content as a governing head. Split it into:

• claim-bearing episteme content;
• publication-unit text;
• publication form;
• generic publication face;
• governed MVPK face;
• carrier data;
• record payload;
• pattern section;
• source-basis excerpt;
• review target.

Plain explanatory prose may use content only when the sentence does not carry ontology, authority, or admissibility.

#publication

Every load-bearing publication sentence must say which publication construction is live:

• act or occurrence of publishing, or publishing work;
• U.EpistemePublication;
• publication form;
• generic publication face;
• governed MVPK face;
• PublicationUnit;
• carrier or rendering;
• document with named source-basis, evidence-basis, architecture-basis, or review-basis role;
• external-standard publication;
• project record publication.

If the sentence says a publication "supports", "authorizes", "proves", "permits", or "makes admissible" something, split the basis: fill relationLoad when a relation claim is live, fill admissibleUse when a boundary-use claim is live, and fill projectSourceLoad when project-side records, evidence paths, gate decisions, constraint or adjudication decisions, assurance records, work, action invitations, speech acts, commitments, methods, or carriers are live. If either side is not triggered, say so explicitly rather than filling it with generic support.

#surface, view, face

Do not treat these as synonyms.

If the sentence can survive only because these are blurred, the sentence is not ready.

#source, target

These are relation words, not final kinds.

Split source into source U.Episteme, source U.EpistemePublication, U.View over a source U.Episteme, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, A.10 evidence path, authority-reference relation, named FPF pattern cited as source, file carrier, source frame, source context, relation slot on the source side of a named relation, or exact project-side FPF kind and reference.

Split target into described entity, target U.Episteme, review target, receiving FPF pattern, project target, work target, target publication form, exact project-side FPF kind and reference, target frame, target context, or relation slot on the target side of a named relation.

Do not publish "source and target" if the selected relation needs the actual FPF kind.

#artifact, material, output, deliverable

These are high-risk umbrella words. Before accepting them, test publication-related and record-related readings first:

• U.Episteme;
• U.View, U.EpistemeView;
• publication form;
• generic publication face;
• governed MVPK face;
• PublicationUnit;
• carrier, front-end, or rendering;
• exact project-side FPF kind and reference;
• work result, work-occurrence output, or project record named by the governing FPF pattern;
• evidence carrier;
• document with named source-basis, evidence-basis, architecture-basis, or review-basis role;
• review target.

If none fits, record the candidate missing kind in architecture first; do not invent it inside pattern prose.

#record

Use record only when the governing FPF pattern or project practice names the record kind and relation. The nearby wording must say which FPF kind the record instantiates or records, for example:

• A.10 evidence path or evidence record for a named claim;
• A.21 GateDecision or DecisionLogRef;
• A.20 constraint or adjudication decision record;
• C.11 ChoiceResult or decision record;
• A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, or other named work record;
• A.2.8 U.Commitment or A.2.9 SpeechAct publication;
• U.RoleAssignment or status-register entry under the named governing pattern;
• E.19 review run record or another named review record whose review target and review relation are explicit;
• process run record in process documents.

Do not let record mean "any file that remembers something", "the missing source", or "the thing to create when support is absent". If required support is absent, create a prospective repair request, future decision request, prospective work-plan entry, or explicit source-gap note; it does not backdate support.

#model, diagram, screen, dashboard, table, note, memo, summary, explanation

These are recognition examples, not governing kinds. Classify each occurrence as one of:

• episteme or episteme publication;
• U.View, U.EpistemeView;
• publication form;
• generic publication face;
• governed MVPK face;
• PublicationUnit;
• carrier, front-end, or rendering;
• exact project-side FPF kind and reference;
• explanation and source-finding relation under E.17.EFP;
• evidence, currentness, and provenance relation under A.10;
• gate-bearing claim or effect under A.20 or A.21;
• assurance and engineering-justification record under B.3;
• work and reliance source-restoration relation under A.15.4.

Keep the ordinary example word only after the governing kind is visible nearby.

#reader, reviewer, author, operator

Do not use people-position words as hidden kind names.

Use:

• working reader or intended practitioner for ordinary usability;
• engineer-manager when the FPF use case is the engineer-manager applying the pattern in work;
• reviewer only for a participant in a named review relation; use review process, review gate, or review target for the process, gate, or object;
• author only for authoring or editing work;
• operator only for an actual U.Role, operator position or process operator in the selected context.

If a text says "reader-facing" or "review-facing", it must also name what is facing that person: generic publication face, governed MVPK face, packet, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, PublicationUnit, carrier, or UI or front-end.

#owner, home, host, locus

These are not interchangeable.

owner may be kept as architecture-discussion shorthand only when the live kind is an explicit responsibility assignment or stewardship assignment. It is not an admissible substitute for pattern, DRR, U.Episteme, U.EpistemePublication, publication unit, file carrier, or project record.

Split into:

• governing FPF pattern relation or authority-reference relation;
• named governing source set;
• explicit source-maintenance role assignment;
• file carrying FPF pattern text;
• file carrier;
• publication unit;
• process-control role assignment;
• role assignment;
• evidence record or evidence source;
• receiving FPF pattern or project target;
• support root.

Never use owner to avoid deciding whether the sentence is about a governing FPF pattern, authority-reference relation, file carrier, responsibility assignment, or process control.

#route, branch, handoff, path, trajectory, move, flow

Recover the movement, control, and temporal relation stack before using these words:

• A.16 local move;
• A.16.0 trajectory account;
• A.19, C.2.2a position in characteristic space or state space;
• B.2.5 control relation, control-layer relation;
• process handoff;
• selector relation or selection mechanism;
• work transfer;
• E.18 path publication;
• A.6.3, A.6.4 episteme morphism or retargeting.

If no movement, control, and temporal relation is live, keep the word ordinary and non-authorizing.

#use, supported use, action, effect

Split the word before accepting it:

• applying an FPF pattern to a problem situation;
• reading or interpreting a publication, view, record, cue, or carrier;
• relying on a named project episteme, a named source-basis document, or an exact project-side FPF kind and reference for a named claim or effect;
• admissible act, work, or claim under a named FPF pattern, A.6.P relation claim, relation phrase, or exact project-side FPF kind and reference;
• non-admissible act, work, or claim requiring one other named value: FPF pattern, A.6.P relation claim, relation phrase, exact project-side FPF kind and reference, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, U.Method, U.MethodDescription, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, A.10 evidence path, typed evidence record, B.3 assurance or engineering-justification record, typed status record whose FPF status pattern is named, carrier relation, or front-end relation;
• planned work;
• actual U.Work;
• evidence of interpretation or effect;
• gate or admission decision.

Do not let supported use become a generic capability of a document. The load-bearing wording names the exact admissibleUse target and non-admissible neighboring use, relationLoad when a relation claim is live, and projectSourceLoad when an exact project-side FPF kind and reference is live. If the sentence says "supported", it must name the exact admissibleUse target and non-admissible neighboring use, relationLoad when a relation claim is live, and projectSourceLoad when an exact project-side FPF kind and reference is live. Do not satisfy the rule by naming only a project record, evidence record, gate record, assurance record, engineering-justification record, only an FPF pattern, or one mixed project-side entry when several A.7 or A.15 role, method, work-plan, and actual-work kinds are live.

#sign, concept, denotat, and school-semiotic labels

Do not import the school-semiotic triad as architecture ontology. When a source or review text says sign, signifier, signified, concept, denotat, representamen, interpretant, or sign vehicle, apply the composite recovery order before the term appears in FPF-facing prose.

Possible recoveries include:

• U.Episteme or exact episteme species;
• describedEntity, grounding, reference-plane relation;
• U.View, U.EpistemeView;
• publication form, generic publication face, governed MVPK face, or PublicationUnit;
• carrier, front-end, or rendering;
• cue, displayed wording, mark, status display, credential display, provenance mark, signature evidence;
• evidence record, gate record, work-state record, commitment record, role-assignment record, or another exact project-side FPF kind and reference;
• FPF pattern, pattern section, accepted DRR, FPF publication, or FPF view when the object is on the FPF side.

Use concept only where current FPF already has the relevant concept-set, UTS, local-meaning, or Part F machinery live. Otherwise recover the exact episteme slot, relation, or typed record.

#pattern, generic FPF-side object wording, locus, row, target

Pattern is not a free synonym for regularity. If the intended object is an FPF pattern, write FPF pattern or name the exact pattern. If it is not an FPF pattern, do not write recovered FPF construction as the final value. Choose one recovered value by sentence function: episteme, view, publication, publication form, generic publication face, governed MVPK face, PublicationUnit, carrier relation, front-end relation, exact project-side FPF kind and reference, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, review target, relation record, relation phrase, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, U.Method, U.MethodDescription, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, A.10 evidence path, typed evidence record, B.3 assurance or engineering-justification record, or typed status record whose FPF status pattern is named.

Avoid generic FPF-side object wording, generic named-target wording, locus, row, and host when they hide kind. Use them only when the kind is literally a table row, document with named source-basis role, file carrying FPF pattern text, or review target and the sentence does not need a narrower FPF kind. For FPF-facing semantic work, these are candidate recoveries, not a group kind: exact FPF pattern, pattern section, accepted DRR, FPF publication, FPF view, typed record, relation record, or relation phrase. Choose one by sentence function.

#Union-field unpacking under A.6.P

Do not write authority-bearing FPF pattern, authority-bearing FPF row, exact FPF row, selected FPF pattern, record, or relation, governing FPF relation, or required project record or action as final fields.

When one of these union-fields appears, make the A.6.P choice explicit:

• if the sentence is making a relation claim, recover the RelationKind, endpoints, slots, qualifiers, scope, time, viewpoint, and admissibility target, then express the result as a relation record or relation-stack specification;
• if the sentence is not making one relation claim, unpack the current context into exact FPF-side kind, reference, or relation and one exact project-side FPF kind with its reference, or state that no project-side FPF kind is triggered;
• if the same unpacking recurs across cases with one stable repair load, open a light A.6.P specialization candidate rather than minting a vocabulary-wide replacement field.

This unpacking is mandatory when a publication, display, cue, explanation, dashboard tile, schema, signature, badge, or generated output is being read as evidence, gate passage, work, permission, approval, commitment, release, safety proof, assurance, or engineering justification.

Do not fill one project-side slot with whichever nearby FPF kind is easiest to name. A project publication or record is a description-side item or record-side item; A.15.1 dated U.Work occurrence, A.6.A action invitation, A.2.9 SpeechActRef, A.2.8 U.Commitment, and U.Method and U.MethodDescription belong to different FPF kinds.

#Heterogeneous kind lists

Do not repair a heterogeneous list by giving it one broader umbrella name. When a sentence lists unlike candidates such as pattern, DRR, publication, U.View, carrier relation, front-end relation, exact project-side FPF kind and reference, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, U.Method, U.MethodDescription, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, A.10 evidence path, typed evidence record, B.3 assurance or engineering-justification record, or typed status record whose FPF status pattern is named, do not promote the row to a new kind. Classify the list as one of:

• one live kind selected at minimal sufficient generality;
• a relation stack with typed slots;
• a tuple-like record;
• several alternative cases;
• an indicator of failed ontology.

If the list is a relation stack, name the slots. If it is a tuple-like record, name the tuple object and its slot semantics. If it is an alternative-case set, split the cases. If it is failed ontology, return to architecture before pattern or DRR prose depends on the list.

#strong, stronger, weak, weaker, support

Do not use strength metaphors unless a named FPF scale, evidence class, threshold, or characteristic space is live.

Preferred rewrites:

• stronger claim -> wider claim scope, higher evidence requirement, gate or admission threshold, claim requiring world-contact evidence or authority relation, authority claim, or named evidence-support class;
• weaker claim -> narrower claim scope, lower evidence-support class, bounded admissible act, work, or claim, source-loss mode under A.6.3.CSC when a source-to-rendering loss is live, coarsened rendering, or explicit abstain or reopen posture;
• support -> evidence support, source-basis support, relationLoad when a relation claim is live, exact admissibleUse when a boundary-use claim is live, projectSourceLoad when an exact project-side FPF kind and reference are live, explanation and source-finding relation, or support-only companion function.

If the sentence cannot name the scale, evidence class, threshold, relation, or source-loss mode, it is not ready for architecture or pattern prose. A.6.3.CSC governs load-bearing source-loss-mode governance; E.10.SEMIO only forces the wording to recover the exact governing pattern and mode.

#Applying patterns versus procedural calls

FPF patterns are applied in problem situations. They are not called, invoked, routed through, executed as procedure steps, or chained as an imperative program.

Use apply pattern, use the pattern guidance, the pattern governs this problem situation, or the case falls under this pattern when the FPF side is live. Do not use project action as a final class. For project-side activity, choose exactly one live kind for the sentence: U.Method; U.MethodDescription; U.Mechanism; A.15 U.WorkPlan; A.15.1 dated U.Work occurrence; work-result record or result-measurement record; C.11 ChoiceResult; C.11 decision record; A.6.A action invitation; A.20 constraint or adjudication decision record; A.21 GateDecision; A.21 DecisionLogRef; A.10 evidence path; typed evidence record; B.3 assurance or engineering-justification record; typed status record whose FPF status pattern is named; carrier relation; front-end relation; or another accepted project-side FPF kind. Use route, path, branch, handoff, trajectory, move, or flow only after the movement, control, and temporal stack has named the live FPF kind.

#FPF-side and project-side episteme and publication contexts

Semioarchitecture often talks about two different described contexts:

• FPF-side episteme and publication context: FPF as episteme, FPF patterns, pattern sections, DRRs, FPF publications, FPF views, support documents and documents with named source-basis, evidence-basis, architecture-basis, or review-basis roles, and review targets;
• project-side episteme and publication context: the engineer-manager's project epistemes, publications, views, records, carriers, cues, evidence records, A.20 constraint or adjudication decision records, A.21 gate decisions, A.21 decision-log refs, B.3 assurance or engineering-justification records, commitments, A.15.1 dated U.Work occurrences, C.11 ChoiceResult values, C.11 decision records, and A.6.A action invitations.

Do not blur them with source, artifact, object, material, target, pattern, or broad semiosis. If both contexts are live, split the sentence into relationLoad when a relation claim is live, admissibleUse when a boundary-use claim is live, and projectSourceLoad when an exact project-side FPF kind and reference are live. If one context is not live, state not triggered rather than leaving a placeholder.

#decision, action, work, method, plan

Do not let action cover every project-side event. Split:

• decision-making and decision records under C.11 when a decision is live;
• role, method, and work-plan and actual-work alignment under A.15;
• work occurrence, work plan, work record, launch value or finalization value, or gate record under the relevant work patterns or gate patterns;
• action invitation under A.6.A when the representation invites an action without itself becoming authority;
• A.15.1 dated U.Work occurrence when the live A.15 object is work; A.2.9 SpeechActRef when the live act is a communicative act; A.2.8 U.Commitment when the act institutes a commitment.

P2W language from TGA is not a generic source-to-work slogan. Use it only when the chain from principles, theories, and signatures through method choice, work planning, work execution, result measurement, and cycle return is actually live.

#Whole-corpus trigger use

When a whole-corpus cleanup is selected, use this pattern's trigger guide over claim-bearing FPF and FPF-facing project text.

Do not do a global string replacement. Classify each unclear term occurrence by the smallest sufficient rewrite mode and preserve accepted FPF names unless a separate accepted naming decision changes them.

#case, scenario, example, pilot, anti-case

These words are useful for recognition and testing, but they often hide whether the text is talking about a project situation, evidence, a worked slice, a negative control, or a decision basis.

Split before use:

• working problem situation;
• worked case or example;
• pilot case;
• anti-case, negative control;
• evidence case;
• comparison case;
• source example;
• benchmark case;
• candidate corpus example.

A case can illustrate or test a pattern. It does not by itself become evidence, a pattern, a DRR, a source basis, or an authority-reference relation. If the case is being used to justify a claim-bearing text change, choose and name each live object or relation separately: evidence record or evidence path, decision basis or decision record, authority relation, relation to a governing FPF pattern, or relation to an accepted DRR.

#basis, context, scope, frame

These are boundary, context, relation, and scope words. They must not stand as final kinds.

Split:

• source basis;
• decision basis;
• evidence basis;
• comparison basis;
• threshold basis;
• grounding basis;
• admissibility basis;
• review context packet;
• bounded context;
• claim scope;
• viewpoint frame or reference frame.

If a basis changes what may be done, fill admissibleUse; fill relationLoad only when a relation claim is live, and fill projectSourceLoad when an exact project-side FPF kind and reference are live. If context changes the described entity, apply the describedEntity, grounding, and reference-plane checks before any bridge, parity, or identity claim.

#translation and multilingual heads

A translated term is not automatically the same FPF head. A translation may preserve reader access while losing kind precision, admissible use, or source-support posture. A bilingual alias is not a Bridge by itself and does not create equivalence, substitution, UTS admission, or cross-context naming relation.

When translated wording carries load, recover the exact FPF kind, local head, publication construction, source relation, and admissible use before accepting the translation. A translated explanation is a derivative rendering; operative claims need source links and E.17.EFP or A.10 when reliance is live. A translated PublicationUnit may preserve form while shifting primary described entity or carried publication move; apply E.17.AUD or E.17.AUD.OOTD when that shift is live. Local translated heads may use E.17.AUD.LHR or E.10.SEMIO without full F.18 unless durable cross-context naming, UTS row, Core-facing term, or reusable FPF head is intended.

#state, status, posture, readiness

Do not let state language become a maturity adjective or gate claim.

Classify:

• position in a named U.CharacteristicSpace;
• language-state chart position;
• protocol state or process state;
• status record;
• role assignment or status assertion;
• publication posture;
• release or gate readiness claim;
• temporal claim under C.27;
• dynamics claim under A.3.3.

If the word is used to justify movement, routing, gate entry, release, or work, the text must name the characteristic-space slot, threshold basis, evidence or witness, and publication lane or carrier lane that makes the claim reviewable.

#claim, evidence, witness, ground, proof

Claim is not a synonym for sentence or prose. Evidence is not a synonym for source, proof, approval, or confidence.

For claim, recover:

• claim-bearing episteme;
• claim node, claim content;
• described entity or claim referent;
• viewpoint and representation scheme when live;
• admissibility target when the claim is used.

For evidence-like words, recover:

• evidence record or evidence path;
• witness or source pin;
• grounding relation;
• validation result;
• assurance argument component;
• provenance mark only as provenance, not as evidence by itself.

If evidence is being read as engineering justification, gate passage, permission, safety proof, or release confidence, apply the exact neighboring pattern or use the exact project-side FPF kind and reference instead of strengthening the evidence word.

#authority, permission, approval, commitment, obligation

These are deontic claims or claims carrying an authority-reference relation, not visual or rhetorical properties.

Recover:

• role assignment;
• speech act or issuing act;
• commitment record;
• policy claim;
• authority relation;
• gate record or decision record;
• authority-changing decision;
• delegated permission;
• contestability, revocation, expiry condition.

Labels, badges, signatures, dashboards, certificates, comments, reviewer praise, and generated explanations may cue authority-looking cases. They do not carry authority unless the authority act, authority record, authority-reference relation, and evidence path are named.

#profile, harness, catalog, registry, index, map

These usually point to a support profile, review harness, registry record, catalog publication, navigation index, map, publication form, support publication, publication-support relation, or relation between one support publication and the publication unit or project record it supports. Choose that exact kind before writing; do not leave support record as the recovered head unless the named FPF pattern really defines that record kind. Treat one as a governing FPF pattern body, accepted campaign DRR, named current architecture document, or relation to one of them only when the named FPF pattern, accepted DRR, architecture document, relation record, or relation phrase is given by value.

Split:

• support profile;
• review harness;
• source map;
• navigation index;
• registry record;
• catalog publication;
• benchmark harness;
• entry support or discoverability support;
• governing pattern body.

If the named support publication, support profile, review harness, registry record, index, or map mainly helps readers find, compare, test, or review something, keep it support-only until a named FPF pattern or accepted DRR records the recurring action-guidance gain by value.

#entry, front door, corridor, route

These terms often mix navigation, recognition, movement, and authority.

Split:

• entry publication or navigation support;
• first-use recognition text;
• navigation-bearing publication;
• movement, control, and temporal relation;
• process sequence;
• corridor overview;
• exact FPF pattern named by the live problem; if a cluster or relation between patterns is genuinely live, name the exact cluster phrase or relation phrase and the governing FPF patterns by value.

An entry can make the right pattern easier to find. It does not prove the pattern is sufficient, complete, or ready for gate use.

#same, parity, identity, equivalence, mirror

Similarity is not identity. Before accepting same, parity, or equivalence wording, name which relation is being claimed:

• mirror file in parity with a governing source;
• same described entity;
• same claim content;
• semantic equivalence;
• bridge relation;
• version identity;
• file or carrier equality;
• source-publication identity;
• no-loss transform.

If the relation is about mirror parity, verify against the governing source or state that the check is not performed. If the relation is semantic, use A.6.3, A.6.4, F.9, or the selected bridge pattern or equivalence pattern rather than relying on matching labels.

#file, path, host, packet, bundle, package

These are carrier, transport, or package-form words.

Split:

• file or carrier;
• mirror file;
• file carrying FPF pattern text;
• document with named source-basis, evidence-basis, architecture-basis, or review-basis role;
• review-facing target packet;
• review-facing context packet;
• release package;
• pattern package, pattern family, or pattern group under an accepted decision;
• governing source section.

A packet or bundle can carry a review target by value. It is not automatically the authority-reference status, the target pattern, the accepted review result, or the FPF authoritySourceRef target.

#quality, characteristic, metric, indicator, score

Do not let evaluation words float.

Split:

• U.Characteristic;
• characteristic space;
• Q-bundle;
• scale;
• indicator;
• observed value;
• benchmark result;
• review finding;
• decision threshold;
• qualitative judgment with no scale.

metric is especially risky because FPF often treats it as imprecise shorthand for scale, value, or indicator machinery. If the text says a quality improved, name what changed: characteristic, scale, observed value, threshold, decision consequence, or admissible act, work, or claim.

#slot, field, row, label, badge, mark, cue

These words are not kinds by themselves.

Split:

• episteme slot;
• relation slot;
• schema field;
• table row;
• row in a pattern body;
• publication label;
• provenance mark;
• status badge;
• pre-articulation cue;
• displayed cue;
• evidence marker.

A label, badge, mark, or cue may trigger review. It does not prove currentness, identity, authority, evidence, gate passage, or release permission unless the exact source relation and evidence path are named.

#Rewrite Execution Modes

Use the smallest sufficient mode that preserves the distinction. The template is a semantic safety device, not a form to fill for every ordinary wording cleanup.

#Local prose cleanup

Use this mode when the phrase under repair is non-normative local prose and does not carry ontology, authority, review scope, release posture, admissibility, or a reusable name.

Action: rewrite directly or leave it unchanged. No table row is required.

#Compact semantic rewrite row

Use a compact row for ordinary architecture and support-document cleanup where a sufficient FPF kind, relation record, relation phrase, or tuple-like record can be recovered without minting a new FPF head.

Compact semantic rewrite row:
  file path, if live:
  FPF pattern, if live:
  pattern section, if live:
  sentence reference:
  phrase under repair:
  live sentence function:
  selected exact FPF kind or exact project-side FPF kind:
  `relationLoad` triggered? yes or no
  relation problem, if triggered:
  admissibleUse triggered? yes or no
  projectSourceLoad triggered? yes or no
  relation claim? yes or no
  if relation claim:
    RelationKind:
    endpoint, slot, qualifier notes:
    admissibilityTargetKind:
    admissibilityTargetRef:
  if local current-context unpacking:
    FPF-side kind, reference, or relation:
    exact project-side FPF kind, if live:
    exact project-side reference, if live:
    notTriggeredReason:
  replacement:
  remaining admissible reader move:
  distinction disposition: preserved, split, intentionally retired, still missing

#Full semantic rewrite check

Use the full check when the wording may change ontology, introduce or retire a reusable head, change a claim-bearing pattern or document with named source-basis, evidence-basis, architecture-basis, or review-basis role, or resolve a contested source-meaning problem.

Semantic rewrite check:
  file path, if live:
  FPF pattern, if live:
  pattern section, if live:
  sentence reference:
  phrase under repair:
  sentence function:
  distinction carried:
  E.10 head kind and Intension, Description, and Specification reading:
  F.18 naming status: no stable term, reuse, MintNew sketch, DocumentLegacy
  F.18 candidate head families, if naming is live:
  F.18 lexical Q result, if naming is live:
    SemanticFidelity:
    CognitiveErgonomics:
    MorphologicalActionFit:
    AliasRisk:
  A.6.P trigger? yes or no
  A.6.P selected relation kind, slots, qualifiers, if live:
  claim-bearing episteme live? yes or no
  FPF kind stack:
  describedEntity, grounding, ClaimGraph, viewpoint slots triggered:
  E.17 and MVPK publication form, generic face, governed MVPK face, view, carrier split:
  PublicationUnit reading, if any:
  FPF-side or project-side sentence:
  `relationLoad` triggered? yes or no
  relation problem, if triggered:
  admissibleUse triggered? yes or no
  projectSourceLoad triggered? yes or no
  relation claim? yes or no
  if relation claim:
    RelationKind:
    QualifiedRelationRecord slots:
    admissibilityTargetKind:
    admissibilityTargetRef:
  if local current-context unpacking:
    FPF-side kind, reference, or relation:
    exact project-side FPF kind, if live:
    exact project-side reference, if live:
    notTriggeredReason:
  rejectedOverread, if live:
  project-side record, work, action, method, carrier crossing:
  heterogeneous-list classification: one live kind, relation stack, tuple-like record, alternative cases, failed ontology, not triggered
  pattern application, project work, decision distinction:
  chosen rewrite:
  remaining admissible reader move:
  distinction disposition: preserved, split, intentionally retired, still missing
  unrecovered wording retained? no, yes, with scope and reason:
  transfer disposition: recovered by value, extension candidate, quote-only, reduced-use cue, blocked transfer, rewrite incomplete, not triggered

#Semantic Rewrite Note

Use a semantic rewrite note only when wording carries ontology, authority, evidence, or admissibility load. The note records the original phrase, recovered FPF kind or relation, exact reference when live, project-side FPF kind and reference when live, remaining admissible reader move, and disposition: recovered by value, extension candidate, quote-only, reduced-use cue, blocked transfer, rewrite incomplete, or not triggered.

#Archetypal Grounding

#Bias-Annotation

#Conformance Checklist

| CC-E10.SEMIO-8 | This pattern does not rename existing FPF patterns or mint reusable heads without F.18 and A.6.P. |

#Current Scan Reading

For conformant text cleanup, high-risk phrases are not automatically wrong. The rows below are candidate recovery prompts, not group kinds. Choose the recovered value by sentence function before reuse:

• topic-like or object-like wording: recover episteme slots or non-claim-bearing project kind;
• publication-unit wording that implies authoring or reading work: distinguish U.Episteme, U.EpistemePublication, PublicationUnit, file, support note, review target;
• content: usually one of claim graph, text span, publication unit, carrier bytes, or document with named source-basis, evidence-basis, architecture-basis, or review-basis role;
• primary-object field names: use primaryDescribedEntity when claim-bearing or exact non-claim-bearing kind or reference when no episteme slot is live;
• surface: keep PublicationSurface or InteropSurface only when exact SurfaceKind discipline is live; otherwise rewrite to generic publication face, governed MVPK face, publication carrier, interop carrier, UI or front-end face, support publication, exact named support record, or carrier relation;
• artifact, material, output, and content: do not let them stay as heads in architecture or pattern prose when they carry ontology or authority;
• source, target: acceptable only when the recovered source kind, target kind, and any live relation slot are also named;
• reader, reviewer: safe only when the word really names a usability reader, review participant, or review process; otherwise name the generic publication face, governed MVPK face, packet, or PublicationUnit;
• pre-FPF semiotic vocabulary: recover FPF episteme kinds, publication kinds, view kinds, carrier kinds, and record kinds before reuse; do not rebuild semioarchitecture on a concept-sign-denotation triad;
• generic FPF-side object wording, locus, row, host, or target: choose the exact recovered value: FPF pattern, pattern section, accepted DRR, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, file carrier, review target, typed record, relation record, or relation phrase;
• supported use: replace with the exact admissibleUse target and non-admissible neighboring use, relationLoad when a relation claim is live, and projectSourceLoad when an exact project-side FPF kind and reference is live;
• strong, stronger, weak, weaker: replace with scope, evidence class, threshold, gate or admission threshold, source-loss mode under A.6.3.CSC when a source-to-rendering loss is live, coarsened rendering, or explicit abstain or reopen posture;
• authority-bearing FPF pattern or row: split into exact FPF pattern or pattern section, relationLoad when a relation claim is live, exact admissibleUse when a boundary-use claim is live, and projectSourceLoad when an exact project-side FPF kind and reference are live;
• route, call, invoke, or procedure-like pattern wording: replace with pattern application or with exact project-side U.Work occurrence, U.Method, C.11 decision value, or A.6.A action invitation.

High-risk residue classes:

• pre-FPF semiotic vocabulary must be restored to FPF kinds by context;
• FPF-side umbrellas: generic FPF-side object wording, generic named-target wording, locus, row, host, and source must be unpacked into the exact recovered value, such as FPF pattern, pattern section, DRR, FPF publication, U.View, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, file carrier, relation record, relation phrase, or file-carrier phrase;
• project-side umbrellas: artifact, material, output, screen, dashboard, credential, badge, and explanation must be unpacked into one exact recovered value, such as publication, generic publication face, governed MVPK face, publication form, carrier relation, front-end relation, exact project-side FPF kind and reference, A.10 evidence path, typed evidence record, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, B.3 assurance or engineering-justification record, typed status record whose FPF status pattern is named, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, U.Method, U.MethodDescription, work-result record, or result-measurement record;
• admissibility phrases: supported use, neighboring use not carried by the current pattern, insufficient evidence-support posture, and similar formulas must name the exact admissibleUse target and non-admissible neighboring use, relationLoad when a relation claim is live, and projectSourceLoad when an exact project-side FPF kind and reference is live;
• pattern-control metaphors: route, call, invoke, exit, path, branch, chooser, and workflow must be checked for declarative pattern application versus real movement, control, and temporal claims.

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Operating Consequence

For new semio architecture prose:

• start from FPF kinds and relations, not from familiar publication nouns and document nouns;
• use PublicationUnit for bounded publication units;
• use describedEntity only when the episteme slot is live;
• keep publication form, generic publication face, governed MVPK face, view, carrier, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, review target, and exact project-side FPF kind and reference separate;
• name relationLoad, admissibleUse, and projectSourceLoad separately when more than one is live;
• classify heterogeneous kind lists before writing a sentence that depends on them;
• say that FPF patterns are applied in problem situations, not called or routed as procedures;
• leave accepted FPF names untouched unless a separate accepted naming decision authorizes a rename.

Operationally, each rewrite should:

• separate FPF-side episteme and publication context from project-side episteme and publication context whenever both are present;
• name relationLoad, admissibleUse, and projectSourceLoad separately when a publication, display, cue, or explanation is read as evidence, gate, constraint, adjudication, decision support, work permission, assurance, or engineering justification;
• classify heterogeneous lists before naming them: one live kind, relation stack, tuple-like record, alternative cases, not-triggered alternatives, or failed ontology;
• say that FPF patterns are applied in problem situations, while project records, publications, views, carriers, and actions are worked with in project practice;
• avoid strength metaphors unless the characteristic, scale, threshold, evidence class, or admissibility relation is named.

For cleanup of existing conformant texts:

• do not do a global string replacement;
• classify each unclear term occurrence by the smallest sufficient rewrite mode;
• use the full semantic rewrite check only when ontology, reusable naming, FPF pattern text, or source-bearing project text is live;
• do not rename accepted FPF patterns from this pattern alone.

#Rationale

FPF already contains the relevant ontology. The recurring defect was not lack of concepts but ad hoc wording that bypassed them: source, target, surface, object, host, route, supported use, and similar terms packed several FPF kinds and relations into one convenient phrase.

The correct repair is therefore not a new umbrella. It is a disciplined recovery action: use E.2, E.10, F.18, A.6.P, A.7, C.2.1, E.17.0, E.17, and MVPK together until the sentence says what object, relation, publication, view, carrier, record, work, action, or pattern application it means.

Because E.2 governs all normative FPF patterns, semantic precision is not a value apart from P-2 Didactic Primacy. A semio repair may be stricter than the original wording, but if it turns load-bearing reader-facing problem text into a kind inventory with no working situation or first useful move, it has not landed the FPF repair. The remedy is not expressive license and not metaphor removal; the remedy is admissible recognition wording whose load remains recoverable through the Tech reading or a named neighboring-pattern handoff.

The detailed rules remain in ordinary pattern sections, so the pattern is usable as FPF guidance rather than as an external glossary container.

#SoTA-Echoing

E.10.SEMIO does not claim to replace semiotics, terminology science, document engineering, or ontology engineering. Its live claim is narrower: semio-heavy conformant text must recover accepted FPF kinds and relations before it is rewritten, so that episteme, publication, view, carrier, naming, relation, and project-side records are not replaced by ad hoc words.

Full external SoTA comparison is therefore not the governing evidence mode for this definitional specialization. A reduced external practice basis is still required because the pattern governs terminology drift and semantic recovery. The reduced basis supports the recovery discipline; it does not create a new ontology and does not outrank the FPF patterns named below.

External-practice boundary. External traditions are admitted only through the exact local FPF invariant they sharpen. Object-oriented modeling and OWL-style ontology modeling do not become the default repair for vague FPF wording. Architecture-description standards help keep views, viewpoints, concerns, and descriptions explicit. Explainability and NLP faithfulness work helps prevent explanation laundering. RAG evaluation helps separate retrieval support from answer trust. Quality-diversity and multi-objective search help avoid premature scalarization in candidate selection. None of these traditions becomes FPF ontology, FPF authority, or a universal pattern-quality benchmark.

The internal FPF basis remains primary:

This reduced SoTA basis changes the Solution in one practical way: a semio rewrite cannot close merely because the replacement wording sounds cleaner. It closes only when the FPF kind, relation, admissible use, and any neighboring pattern application are recoverable by value; otherwise the wording is blocked, quote-only, or becomes a candidate for a separate FPF-kind decision.

Internal support details:

• E.10 supplies the head-kind, term, morphology, register, and forbidden-umbrella discipline.
• E.10.D2 gives the "thing vs words vs rules" discipline and the carrier humility rule.
• F.18 gives the local-first naming protocol: Context, Kind, purpose and use-domain, local sense, candidate head families, NQD-front, semantic read-through, and lexical Q components before one label becomes a reusable head.
• A.6.P gives the relation-precision restoration method: restore generic head kind, build candidate sets for endpoint kinds and relation kinds, select kind-explicit slots and qualifiers, then allow guardrailed wording.
• E.17.0, E.17 distinguish views, viewpoints, MVPK faces, publication forms, and publication projections.
• A.15.4 is a good current pattern example of keeping encountered publication, display, or cue items distinct from the exact project-side FPF kind and reference that makes work or reliance admissible.
• A.16, A.16.0, A.19, B.2.5, C.27, and A.3.3 provide the movement, control, temporal stack used when semio prose talks about route, trajectory, movement, cadence, or dynamics.
• E.19 already treats terminology and sentence-level precision restoration as real review obligations, not editorial polish.
• A.6.A carries action-invitation discipline when a publication, representation, or cue invites an action without itself becoming authority, evidence, gate passage, or work completion.
• C.11 carries decision-making and decision-record discipline when the live question is a decision rather than generic action.
• A.15 and A.15.4 split role, method, work-plan, and actual-work alignment from work-relevant source restoration, so semio prose must not let A.15 become a universal semio governing pattern.
• E.9 is the campaign DRR pattern for campaign-level content decisions; E.11 is only for entry-discoverability situations and must not organize a semio campaign by default.

#Relations

• Builds on: E.2 Pillars, especially P-2 Didactic Primacy; E.10, A.7, F.18, A.6.P, C.2.1, E.17.0, E.17, MVPK, A.6.Q, and A.6.A.
• Coordinates with: E.6, E.7, E.8, E.9, E.12, E.19, A.10, A.15, A.15.4, B.3, A.20, A.21, A.6.3.CSC, A.6.3.CR, A.6.3.RT, E.17.EFP, and E.17.ID.CR.
• Does not replace: E.10 general lexical rules, F.18 naming protocol, A.6.P relation precision, or local semio patterns. It tells authors when those patterns must be applied to semio-heavy wording.

#E.10.SEMIO:End

Last Updated: 2026-05-15 — this section last modified in upstream FPF commit 7f8a04ca (github.com/ailev/FPF)