Ontology-First Plain Technical Rewriting
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 function-shaped wording, 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. Repair any remaining word, head, name, or wording-use problem with E.10, E.10.ARCH, E.10.ROLE, A.6.F, F.18, or the specific pattern that defines, constrains, or tests the remaining claim.
Builds on. E.8, E.10, E.10.ARCH, F.18, A.6.P, A.7, E.18, E.21, and 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 loci, 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, an unsupported negative classification, 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, an unsupported negative classification, reference boilerplate, or pattern-application metaphors before the object and action are visible.
Typical in-scope prose includes:
- FPF pattern prose;
DRRtext 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, relation position, system-role-kind or assignment distinction, function or functioning claim, claim boundary, or admissible-use boundary.
What this buys. Plain technical wording becomes an ontological discipline with less apparatus: fewer words, clearer objects, fewer invented alternatives to reject, 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, use the specific pattern that defines, constrains, or tests that claim and say what it contributes.
- 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-proof evidence, pattern-reference boilerplate, or alternative classes introduced only so the sentence can reject them.
The repair question is:
What content remains when words that add no object, kind, relation, claim, system-role or function distinction, flow, evidence value, or user-facing action are removed?
Examples inside FPF:
- "
A.15handles the claim" when the text needs to say thatA.15applies to a work-planning claim; - "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-facing action 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 transformation 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 established 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 current ontic slot, relation-position, use-relation, or claim-kind 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.
- 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, unsupported negative classification, reference boilerplate, record, card, table, schema, data-structure wrapping, or other overwrap.
- Separate content from apparatus by ontology. For each phrase part, ask what object, head kind, claim or relation, current slot or relation position, use or publication relation, admissible use, participant, and relevant flow position it carries. A trigger-shaped phrase remains content until its actual claim is recovered. Use
E.10.ROLEonce for role-shaped wording: for example, reviewer role may name a local system-role kind or participation in a review relation. UseA.6.Fonce for function-shaped wording: for example, pump function may name an expected transformation, while the pump is functioning states a condition. Infer neither branch from the trigger word. If a phrase part changes a live value, keep it as content; if it only restates process, a label, an unsupported negative classification, reference boilerplate, record, form, or quality proof, classify it as apparatus. - Remove or move apparatus. Delete the apparatus or move it to the document, record, note, or publication relation where it belongs:
DRR, review record, quality result, architecture note, README, ToC,E.11, orI.2entry locus, projection record, release or landing evidence document, or source-side note. Do not replace it with a smoother synonym, role label, container word, status word, record, card, table, schema, data-structure wrapper, or publication-form word. - Restore remaining content precision. Restore every complement needed to determine the claim: what was selected, changed, compared, transformed, published, evaluated, or relied on. Use
E.10,E.10.ARCH,E.10.ROLE,A.6.F,F.18, or the specific pattern that defines, constrains, or tests the remaining word, head, relation, claim, slot, use, name, or admissible-use boundary. - Rewrite and check loss. Write the shortest plain technical sentence that preserves the repaired object, kind, claim, relation, action, current slot, relation position, use relation, any live system-role, function, ordinary-wording or flow distinction, established term, and admissible use. Also preserve only the action-guiding claim details consumed by the declared use: exact predicate and participants, polarity, quantity or threshold, temporal boundary and order, criterion, tolerance, exception, applicability condition, and other explicit operational detail. The rewrite fails if it changes a live value without an accepted semantic decision or becomes harder for the declared reader to use.
A contrast of the form ‘X is not A but B’ is useful only when the text or working situation has already made A relevant: an earlier claim, an observed or source-backed confusion, a serious competing classification, or a safety or non-use condition that changes action. If A appears only so the author can reject it, remove A and state X's positive kind, relation, action, or result directly. Keep problematization of an observed failure, a fair dispute with stated grounds, ordinary negation whose polarity is content, and a documented anti-pattern; judge their actual claims rather than their negative grammar.
Keep ontology visible only where it carries the sentence. A term-source or type annotation is needed only when it changes how the reader identifies the object, kind, relation, slot, use, publication boundary, admissible use, or applicable rule. A record, card, table, schema, data structure, dashboard, or named form remains apparatus unless it carries one of those values. If ordinary domain wording already preserves them, keep the ordinary sentence. "The aircraft flies" is better than a typed expansion unless the flight function, system kind, or slot relation is under repair.
Treat exact, direct, current, governed, subject, owner, defining, and similar qualifiers as content only when they distinguish live alternatives. Remove them when no such contrast changes the truth, action, stop, or reliance. A PatternID may remain an ordinary citation; expand it into a claim-bearing episteme, ClaimGraph, U.MethodDescription, U.Method, actor, assignment, U.Work, or another formal identity only when the current claim or a named later use depends on that distinction.
Keep ordinary practitioner action and instrumental pattern-use wording ordinary when it does not assert a particular dated Work occurrence. “Use E.9 to record the decision” and “the framework maintainer compares the editions” need no invented Method, MethodDescription, performer, assignment, or Work identity.
Open the identity-bearing branch only when the sentence deliberately asserts a particular dated U.Work occurrence. Then point to its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution. Add a local system-role kind or a separate System-classification judgment only when that neighboring claim matters. Treat a pattern episteme as a U.MethodDescription only after A.3.2 establishes that it has an already admitted Method as its EntityOfConcern and explains how that Method is performed. Otherwise cite the applicable pattern content as guidance and use A.3.1 for the Method itself.
When one sentence joins unlike claims and no genuine common head covers them, split the claims and use E.10:0.2c.17 for the resulting list. Do not invent an umbrella object merely to preserve one grammatical subject.
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 purpose 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 named stop condition;
- short declarative references to related patterns after the pattern's own content is visible.
Pattern prose moves out:
- package-placement rationale;
- correspondence about producing the draft rather than using the pattern;
- 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, current ontic slot, relation position, use relation, source-use relation, or admissible-use boundary is worse than the original.
F.19 also protects against two common reviewer biases:
- unsupported-negative-classification bias: introducing one or more alternative classes only so the sentence can reject them;
- apparatus-preservation bias: replacing one process, role, record, card, table, schema, data-structure wrapper, 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-rewrite and post-rewrite kind, relation, current ontic slot, relation position, use relation, 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:
- remove or move boilerplate;
- restore remaining wording, names, relations, slots, and uses through the specific pattern contribution needed by the claim;
- 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; E.10.ROLE and A.6.F recover the actual role- or function-shaped claim. F.19 catches the earlier phrase-level problem: content may not be visible until process, label, status, reference, quality, or negative-catalogue apparatus is removed.
SoTA-Echoing
SoTA here means the best current contribution to the stated practice question, not the newest or most formal publication. The comparison below is current to 2026-08-19; a source's official status does not by itself make it SoTA.
Relations
F.19:End
Last Updated: 2026-08-30 — upstream FPF commit e400eab3 (github.com/ailev/FPF)