#Ontology-First Plain Technical Rewriting

F.19 · Stable · Plain-technical precision-restoration pattern · Normative for FPF-governed technical prose unless explicitly marked informative; informative for external source prose until it is rewritten for FPF use · Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

#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: Plain-technical precision-restoration pattern Status: Stable Normativity: Normative for FPF-governed technical prose unless explicitly marked informative; informative for external source prose until it is rewritten for FPF use

Plain-name. Ontology-first plain rewriting.

Intent. Repair technical prose whose object, claim, relation, action, role, or flow is buried under extra apparatus. The repair is not cosmetic plain-language editing. It first separates content from apparatus by ontology, then writes the remaining content in the shortest plain technical form that preserves FPF kinds, slots, claim boundaries, and admissible use. Remaining word, head, naming, or wording-use problems then apply E.10, E.10.ARCH, F.18, or the governing pattern for the object.

Builds on. E.8, E.10, E.10.ARCH, F.18, A.6.P, A.7, E.18, E.21, and exact source-use, evidence, assurance, gate, work, decision, publication, architecture, characteristic, state-family, and relation patterns when those objects carry the repaired span's claim.

Coordinates with. E.19, E.22, E.23, A.19.SPR, C.2.P, C.16.P, C.30.P, E.11, I.2, pattern-quality records, review records, DRRs, projection carriers, and source-side notes.

Use F.19 when a bounded piece of technical prose is trying to say something precise, but the reader must pass through role labels, container words, status words, process traces, quality proof, repeated negative catalogues, reference boilerplate, or pattern-application metaphors before the object and action are visible.

#Relations

#Content

#Use this when

Use F.19 when a bounded piece of technical prose is trying to say something precise, but the reader must pass through role labels, container words, status words, process traces, quality proof, repeated negative catalogues, reference boilerplate, or pattern-application metaphors before the object and action are visible.

Typical in-scope prose includes:

• FPF pattern prose;
• DRR text and architecture notes;
• review findings and quality-loop records;
• project-facing FPF guidance;
• source prose being rewritten for FPF use;
• other technical prose whose accepted ontology, domain model, controlled vocabulary, or role model must survive simplification.

What goes wrong if missed. Authors replace one official-sounding phrase with another. The text becomes smoother or shorter while the hidden kind error remains, or it becomes easy to read by losing the FPF kind, slot, role, claim boundary, or admissible-use boundary.

What this buys. Plain technical wording becomes an ontological discipline with less apparatus: fewer words, clearer objects, fewer repeated negative catalogues, and no loss of technical semantics.

First useful move. Mark the span under repair. Split it into content candidates and apparatus candidates before rewriting either side.

Not this pattern when.

• If the problem is only one overloaded word or head after the content is visible, apply E.10.
• If the problem is a durable reusable name, apply F.18.
• If the span already names the content-bearing relation, source-use relation, state-family value, architecture label, characteristic, quality term, function wording, evidence claim, gate claim, work claim, decision claim, or other FPF object named by value, apply the governing pattern for that object.
• If the source text is only being observed and not admitted into FPF-governed prose, keep the observation source-side.

Primary EntityOfConcern in plain terms. One phrase-level, sentence-level, row-level, paragraph-level, or small-section technical-prose repair whose goal is kind-preserving plain expression.

#Problem frame

Mature technical languages accumulate enough ontology that many bad sentences are not bad because the terms are unknown. They are bad because a simple technical claim is wrapped in process language, role language, status language, quality-carrier evidence, pattern-reference apparatus, or repeated negative distinctions.

The repair question is:

What content remains when words that add no object, kind, relation, claim, role, flow, evidence value, or user move are removed?

Examples inside FPF:

• "A.15 handles the claim" when the text needs to say that A.15 applies to a work-planning claim;
• "live pattern text" when the text means "the pattern" or "the pattern of concern";
• "governing relation" when the named object is a pattern, not a relation;
• long "not X, not Y, not Z" paragraphs when the text needs a positive object, action, and one stop condition;
• corpus-projection proof written inside a pattern whose own user move is not corpus projection.

The same defect appears outside pattern prose. A system note may hide an evaluation claim inside process language; a project note may treat a dashboard as evidence authority when it is a publication form; an architecture memo may replace a scale-preference claim over alternatives with a platform label.

These failures confuse coupled transduction flows. A pattern under development, a pattern being applied, a quality evaluation of that pattern, a project work occurrence, a source publication, and a projection record are different objects. They may influence one another; they do not become one another by being mentioned in the same paragraph.

#Problem

How can FPF make technical prose plain without:

• treating plain language as a synonym-replacement exercise;
• deleting content-bearing technical terms as "jargon";
• replacing exact terms with colourful synonyms or role nicknames;
• letting process, review, projection, or quality proof become pattern content;
• repeating the same boundary doctrine in every local pattern;
• hiding slot/use-position changes under a shorter phrase;
• turning every phrase repair into a new local mini-ontology?

#Forces

#Solution

Use OntologyFirstPlainRewrite as a five-step repair over one bounded span.

1. Bound the span. Name the sentence, row, paragraph, or small section under repair. Name visible apparatus candidates: pattern-application drift, role label, container word, status word, process trace, quality proof, negative catalogue, reference boilerplate, or other overwrap.
2. Separate content from apparatus by ontology. For each phrase part, ask what object, head kind, claim kind or relation kind, slot or use-position, admissible use, concerned role, and design/run or coupled-flow role it expresses. If a phrase part changes one of those values, keep it as content. If it only restates process, role label, negative catalogue, reference boilerplate, or quality proof without changing content, classify it as apparatus.
3. Remove or move apparatus. Delete the apparatus or move it to the carrier where it belongs: DRR, review record, quality result, architecture note, README/ToC/E.11/I.2 entry locus, projection carrier, release/landing evidence carrier, or source-side note. Do not replace it with a smoother synonym, role label, container word, or status word.
4. Restore remaining content precision. Apply E.10, E.10.ARCH, F.18, or the governing pattern when a remaining word, head, relation, claim, slot/use-position, source-use role, durable name, or admissible-use boundary is still hidden.
5. Rewrite and check loss. Write the shortest plain technical sentence that preserves the repaired object, kind, claim/relation/action, slot/use-position, role, flow, established term, and admissible use. The rewrite fails if it changes one of those values without an accepted semantic decision, or if it becomes harder for the declared reader to use.

Use the full result form when the repair must be inspectable; otherwise a local rewrite plus the kind-preservation check is enough.

#Result form

#Pattern-prose specialization

When the repaired prose is an FPF pattern, apply the same algorithm with one role test:

Does this sentence address the pattern's intended user, or does it record development, review, projection, landing, quality, or source-management evidence about the pattern version?

If it records evidence about the pattern version, keep that evidence outside the pattern unless the pattern's own primary EntityOfConcern is that evaluation or projection object. The evidence can cause edits to the pattern; it is not automatically pattern content.

Pattern prose keeps:

• the pattern's own primary EntityOfConcern;
• the first useful move;
• the practical delta and cost of missing it;
• local boundary prose only for a documented local confusion and exact stop condition;
• short declarative references to related patterns after the pattern's own content is visible.

Pattern prose moves out:

• package-placement rationale;
• review/executor correspondence;
• quality-status proof;
• README/ToC/E.11/I.2, retrieval, card, monolith-parity, or landing evidence;
• repeated boundary doctrine already carried by another pattern.

#Archetypal Grounding

#Bias-Annotation

F.19 deliberately biases toward shorter, reader-facing prose. The protected value is kind-preserving clarity, not brevity by itself. A rewrite that removes terms while losing object kind, relation kind, slot/use-position, source-use role, or admissible-use boundary is worse than the original.

F.19 also protects against two common reviewer biases:

• negative-catalogue bias: explaining a class by long lists of what it is not;
• apparatus-preservation bias: replacing one process, role, carrier, locus, flow, status, or quality-proof phrase with another phrase that still hides the object.

#Conformance checklist

#Common anti-patterns and how to avoid them

#Consequences

F.19 makes technical prose easier to read because it removes apparatus before shortening the sentence. It also makes reviews stricter: a pleasant paraphrase does not count unless the pre/post kind, relation, slot/use-position, admissible use, and scope are preserved or deliberately changed by accepted decision.

The cost is that some edits need a short repair note before they look simple. That cost is intentional. Without the note, agents tend to do lexical replacement, narrow a graph into a sequence, widen a work occurrence into a method, turn a publication into evidence, or hide a pattern application under a route-like metaphor.

#Rationale

Plain technical style in FPF is not a separate aesthetic layer. It is the visible result of ontology-first repair with less apparatus. The order matters:

1. remove or move boilerplate apparatus;
2. restore the remaining content through the wording named by value-use, naming, relation, slot, source-use, or object pattern;
3. write the shortest sentence that keeps the recovered meaning.

Putting F.19 beside wording-use restoration keeps E.10 from becoming a phrase-style super-pattern. E.10 catches words and heads whose kind or use is hidden. F.19 catches the earlier phrase-level problem: the content may not even be visible until process, role, status, reference, quality, or negative-catalogue apparatus is removed.

#SoTA-Echoing

#Relations

#F.19:End

---

Last Updated: 2026-06-08 — this section last modified in upstream FPF commit 9b1cb920 (github.com/ailev/FPF)