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 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 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, 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;
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, 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-proof 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.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 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 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, negative catalogue, 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 kind or relation kind, current ontic slot, relation position, use relation, publication relation, admissible use, concerned actor or reader role when a role is current, and design, run, or coupled-flow position when flow separation matters. If a phrase part changes one of those values, keep it as content. If it only restates process, role label, negative catalogue, reference boilerplate, record, card, table, schema, data-structure wrapping, or quality proof without changing content, 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. Apply
E.10,E.10.ARCH,F.18, or the governing pattern when a remaining word, head, relation, claim, current ontic slot, relation position, use relation, source-use relation, durable name, or admissible-use boundary is still hidden. - Rewrite and check loss. Write the shortest plain technical sentence that preserves the repaired object, kind, claim, relation, action, current ontic slot, relation position, use relation, actual role value when current, flow position when current, 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.
Keep ontology visible only where it carries the sentence. A term-source or type annotation is needed when the wording can change the object, kind, relation, current ontic slot, relation position, use relation, publication relation, admissible use, or governing pattern. 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 those values, 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.
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 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:
- negative-catalogue bias: explaining a class by long lists of what it is not;
- 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 apparatus;
- restore the remaining content through wording-use, naming, relation, slot, source-use, or object-governing patterns named by value;
- 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-15 — this section last modified in upstream FPF commit c092a1f2 (github.com/ailev/FPF)