#PublicationUnit Stability Discipline and PublicationUnit Primary Described-Entity Discipline

E.17.AUD.OOTD · Stable · 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.

Placement. Narrow publication-unit stability pattern inside the broader PublicationUnit Stability Discipline.

Builds on. A.6.P, A.7, E.10, F.18, E.14, E.19, C.2.2a, A.16.0.

Coordinates with. E.17.AUD.LHR, E.17.ID.CR, E.17.EFP, A.6.3, A.6.3.CR, A.6.3.RT, A.10, A.15, A.15.4, B.3, A.20, A.21.

Plain-name. Keep one publication unit about one primary described entity at a time.

One-line summary. PublicationUnit Primary Described-Entity Discipline governs one bounded publication unit at a time and keeps that unit explicit about what it is mainly about, what move it is carrying over that entity, and what wider work, unsupported downstream decision, or reliance claim remains outside.

Governed object in plain terms. The governed object here is one publication unit that other people are meant to read as one unit: a note, memo, sheet, review aid, screen, table, or short section. The governed move is to keep that unit explicit about one primary described entity, one carried move over that entity, and one outside-work boundary.

Use this when. Use this pattern when one note, memo, sheet, screen, table, comparison aid, or other publication unit starts reading as if it is still about one primary described entity while it is quietly shifting into a different described entity, a different concern, or a wider process. Use it when local word repair is not enough anymore and the publication unit needs one stable answer to: what is this unit about, what move is it making, and what still remains outside?

What goes wrong if you miss this. One publication unit starts by talking about one described entity and quietly ends by licensing a different reading, a different concern, or wider work. Review then gets trapped in sentence-level wording arguments while the real defect is publication-unit reading instability, and readers over-attribute decision weight or scope to a unit that never declared it.

What this buys you in practice. It lets a team stop publication-unit reading instability before one memo, note, or review unit quietly starts carrying rollout, approval, wider architecture strategy, or another wider concern by habit. In practice that means reviewers can name the real stabilization job earlier, keep downstream work outside, and decide faster whether the current unit is stable enough to keep using at all.

Not this pattern when. This is not the right pattern when:

• the problem is still local lexical-head kind or qualifier repair and E.17.AUD.LHR (Local Head Restoration) is enough;
• the same publication unit is already stable enough, and the live question is one bounded comparative review move over already available source epistemes or publications under E.17.ID.CR;
• the live question is still same-entity rewrite, representation shift, explanation-face work, bridge-explication, or another neighboring pattern whose move is already primary;
• the live question is view, face, carrier, or publication architecture rather than publication-unit reading instability;
• the unit is already being used to approve, assign, adjudicate, or direct work and should use the more honest downstream decision, work, or reliance publication.

Quick recovery entry. If the recognition surface fits, recover the working question through the ordinary six-row card in E.17.AUD.OOTD:4.3 and the nearest worked slices in E.17.AUD.OOTD:5.1 through E.17.AUD.OOTD:5.5. If that ordinary card plus one nearest worked slice already settles the case, stop there rather than climbing into the heavier support sections by habit.

Quick boundary bank. If the recognition surface no longer fits, stop at the right boundary instead of opening the heavier stack by habit. One overloaded local lexical head or qualifier only -> E.17.AUD.LHR (Local Head Restoration). Same stable publication unit, but the live question is one bounded comparison over already pinned source epistemes or publications -> E.17.ID.CR. View, face, carrier, same-entity rewrite, or downstream approval, work, or reliance question -> the neighboring pattern or the more honest downstream decision publication.

Quick kind-plus-lens reading. PublicationUnit Stability Discipline names the broader publication-unit discipline family. PublicationUnit Primary Described-Entity Discipline names the publication-unit stability pattern used when one publication unit needs its primary described entity, carried move, and outside-work boundary made explicit together. The inherited moving lineage still remains successive governed U.Episteme publications over U.CharacteristicSpace; this pattern governs how one publication unit speaks about that lineage or a move over it, not a rival moving lineage.

Primary working reader. The first-minute reader is an engineer-manager, architect, reviewer, or programme lead who needs to stop one publication unit from quietly changing what it is about. Secondary readers may include people polishing or reviewing the text itself, but the top recognition surface should still read as ordinary review and writing discipline first.

Anti-single-sequence note. The quick checks, ordinary six-row card, heavier extension, and worked slices in this section are local aids for one publication unit under review. They are not a canonical sequence for publication-unit repair and not a promise that admissible cases follow one fixed graph in one direction. Read the worked slices sideways rather than as one required sequence: one admissible case may stop after one publication-unit declaration, another may reopen when outside observations change the honest described entity, and another may apply the governing pattern once downstream approval, work, reliance, or a neighboring-pattern question becomes primary.

#Relations

#Content

#Problem frame

Anti-single-sequence note. The quick checks, ordinary six-row card, heavier extension, and worked slices in this section are local aids for one publication unit under review. They are not a canonical sequence for publication-unit repair and not a promise that admissible cases follow one fixed graph in one direction. Read the worked slices sideways rather than as one required sequence: one admissible case may stop after one publication-unit declaration, another may reopen when outside observations change the honest described entity, and another may apply the governing pattern once downstream approval, work, reliance, or a neighboring-pattern question becomes primary.

Teams repeatedly write one publication unit that begins by talking about one primary described entity and ends by talking about another while still sounding like one unchanged text.

Typical moments include:

• an architecture note that starts about a system boundary and ends about rollout work;
• an operations review note that starts about an incident episode and ends about action approval;
• a requirements or policy note that starts about a described entity and ends about its carrier or document status;
• a semio-heavy note that starts about one pattern section or publication form and ends about wider architecture strategy;
• a comparison sheet that starts about one governed object and quietly shifts into engineering-process, approval, work, or reliance pressure.

That reading instability is usually not caused by one bad sentence alone. It is caused by one whole publication unit no longer holding a stable answer to what it is about, what move it is carrying, and what wider work still stays outside.

#Problem

Without a named publication-unit discipline:

1. authors repair one vague phrase at a time but still leave the unit unstable as a whole;
2. reviewers argue about wording while missing that the unit has already shifted from described entity to process or from description to decision pressure;
3. teams quietly read one note as if it licensed a downstream move the unit never declared;
4. local lexical discipline (A.6.P, E.10, F.18) gets blamed for publication-unit reading instability it was never meant to solve alone;
5. unit-form confusion is mistaken for view, face, carrier, or publication architecture even when the immediate problem is simpler and closer.

#Forces

#Solution - stabilize one publication unit, one described entity, one move, and one outside-work boundary

#Manager-first entry

PublicationUnit Primary Described-Entity Discipline keeps one publication unit explicit about what it is mainly about, what move it is carrying over that entity, and what wider work remains outside.

It becomes necessary when local repair is no longer enough and the publication unit still has unstable reading across described entity, description, carrier, publication unit, process, or downstream decision use while sounding unchanged.

In plain working terms, this section is for moments like:

• this memo is about the architecture boundary, not yet about the rollout plan;
• this review note is about the incident episode, not yet about the action decision;
• this comparison sheet is about the governed described entity under review, not yet about approval or the downstream decision;
• this semio note is about one pattern section or publication form, not the wider architecture policy around it.

If that is the clarification you need, start here. If the real problem is still only one vague local lexical head word, start with E.17.AUD.LHR (Local Head Restoration).

#Pairwise plain glosses

• Publication unit = one written or displayed bounded unit others are meant to read as one unit, such as a note, memo, sheet, table, or guided screen.
• Primary described entity = the local stabilization reading for what that unit is mainly about when it carries or exposes a claim-bearing episteme or episteme-lane U.View; it is not a new C.2.1 slot. If no claim-bearing episteme or episteme-lane view is live, name the exact non-claim-bearing kind, topic, or subject instead of inventing a DescribedEntityRef.
• Carried move = what the unit is doing over that entity, or that it is only stabilizing it without adding a new move.
• Outside-work boundary = what wider review, execution work, unsupported downstream decision, or reliance claim stays outside the current unit.
• Explicit transition = the unit openly says it has moved from one reading or described entity to another instead of pretending nothing changed.

#Minimal modeling lens

Treat the governed publication unit here as one publication unit carrying one primary described-entity reading over one current working concern or lineage slice. That reading does not make the unit itself a U.EpistemePublication; it stabilizes the unit's reading over the already-governed item it carries or exposes. The smallest honest lens asks five entries:

1. what publication unit is being governed;
2. what described entity is primary;
3. what move over that entity is being carried;
4. which reading is active;
5. what wider work still stays outside.

If that lens cannot stay stable after local repair, do not patch over the reading shift with a heavier declaration; reopen the unit or apply the governing pattern instead.

#Scope and exclusions

In scope

• one publication unit with unstable reading across multiple described entities;
• one unit mixing move and outside work;
• one unit quietly shifting between described entity, description, carrier, publication unit, process, or downstream decision use;
• semio-heavy texts where repair disposition, governing pattern, governed object, carried move, and outside work must stay explicit across one publication unit.

Out of scope

• local lexical-head repair only;
• pure view, face, or carrier architecture work;
• same-entity transform, explanation, bridge, ontology, or comparative-reading questions whose neighboring patterns already govern the main move;
• downstream gate, approval, execution, or decision pressure.

Ordinary stop rule. If the ordinary six-row card plus one nearest worked slice already settle the case, stop there. Do not climb into heavier support just to prove that one unit now keeps one primary described entity, one carried move, and one outside-work boundary honestly in place.

#Ordinary working card

For ordinary use, keep at least these six rows visible:

If those six rows can stay stable across the same publication unit, ordinary use is usually enough. Treat that six-row card as the recognition surface.

If local repair is still enough, go back to E.17.AUD.LHR (Local Head Restoration) instead of adding more structure here. If the unit remains one publication unit but neighboring-boundary load, misuse risk, or cross-reading ambiguity becomes load-bearing, use the heavier extension as the assurance surface. If the same unit is already stable as one primary described entity, one carried move, and one outside-work boundary, and the remaining question is one bounded comparative review move over already available source epistemes or publications, apply E.17.ID.CR before thickening this publication-unit card. If the unit cannot keep one stable primary described entity, one carried move, and one outside-work boundary even after local repair, do not solve that by stacking more fields onto the heavier extension; apply or reopen the neighboring-pattern check first.

#Load-bearing extension and quick boundary summary

Use the heavier extension only when the ordinary six-row card already stays stable and the case is close to important seams. It is for heavier declaration, not for rescuing a unit that still cannot keep one primary described entity, one carried move, and one outside-work boundary in place.

Then add:

• publicationUnitFormCue;
• primaryReading;
• transitionPolicy;
• modelingLensPolicy;
• downstreamDecisionPolicy.

These fields do not create a rival rule track. publicationUnitFormCue names words such as note, sheet, screen, and table as form clues only; it does not make those clues governed-object kinds. The fields only make the heavier neighboring-boundary load visible once the ordinary card already holds.

Quick governing-pattern and project-side-reference boundary summary

• use E.17.AUD.LHR (Local Head Restoration) when the instability is still local to one local lexical head, qualifier, or reading word;
• use E.17.ID.CR when the same publication unit already holds one stable primary described entity, one carried move, and one outside-work boundary, and the live question is one bounded comparative review move over already available source epistemes or publications;
• use this pattern when one publication unit still has unstable described-entity, carried-move, or outside-work reading after honest local repair;
• use the neighboring pattern or the exact project-side FPF kind and reference when view, face, carrier, same-entity transform, explanation, bridge, ontology, gate, approval, or execution claim becomes primary.

#Boundary-rule summary

This section is the canonical governing-pattern boundary summary for PublicationUnit Primary Described-Entity Discipline inside the Core. Companion notes may elaborate support checks and review scaffolding, but they may not override this section.

The practical summary is:

1. keep one primary described entity unless a transition is explicit;
2. do not collapse described entity, description, carrier, publication unit, process, and downstream decision use into one unchanged reading;
3. keep the carried move distinct from the wider work around it;
4. use local E.17.AUD.LHR (Local Head Restoration) first, and open this pattern when publication-unit reading instability remains after that;
5. apply E.17.ID.CR when publication-unit stability already holds and the remaining question is one bounded comparative review move over already available source epistemes or publications;
6. move out when the unit starts carrying downstream decision pressure or another neighboring pattern question.

#Archetypal grounding

Worked-slice status. Read the architecture, operations, semio-heavy, comparison-return-to, and changed-described-entity cases as a heterogeneous example bank, not as one recommended progression.

#Architecture note shifting into rollout work

A short architecture memo begins with: This note is about the proposed service boundary between catalog and checkout.

Three paragraphs later it says: We should therefore assign rollout responsibility to platform and stage migration in two sprints.

The fix is not only lexical. The publication unit changed its primary described entity from architecture boundary to rollout process and decision responsibility. This section forces the author to either:

• keep the note about the boundary and push rollout outside;
• or make the transition explicit and use a downstream decision or rollout publication.

#Operations note shifting into approval

An incident note begins as a comparative review of timing variance and operator context. It ends as if it already recommends a production action.

This section makes the author keep the review unit about the episode and the contrast it is surfacing, while forcing work approval into an explicit outside-work or downstream decision text.

#Semio-heavy text mixing one local section and wider architecture strategy

A semio note starts about one governed pattern section and ends as if it had decided the packaging strategy for the whole overlay.

This section forces the unit to say:

• what the note is about now;
• what move it is making over that primary described entity;
• and what wider architecture strategy remains outside the current unit.

#Unit stabilizes and bounded comparison becomes primary

A review note first shifts between the governed interface boundary, the move it is making over the current evidence, and the rollout implications around that boundary. After one honest publication-unit repair it now says: This review unit is about the interface boundary options and the contrast they make visible under the current incident evidence; rollout responsibility and approval remain outside this note.

At that point the same unit already holds one stable primary described entity, one carried move, and one outside-work boundary. PublicationUnit Primary Described-Entity Discipline has done its job. If the remaining question is now one bounded comparison between the already pinned options over the same evidence, the honest next pattern application is E.17.ID.CR rather than keep thickening publication-unit discipline.

#Outside observation changes the honest described entity

A release-readiness note is already explicit that it is about one candidate publication or view and the risk posture visible from the current evidence. Mid-review, an external vendor bulletin and a new field observation change the live failure boundary for that same candidate.

The honest move is not to keep appending the new question while pretending the same unit still carries the same primary described entity unchanged. This section forces the author to either:

• stop the current unit at the originally declared described entity and open a new downstream record for the changed question;
• explicitly reopen the same unit with a newly declared primary described entity, move, and outside-work boundary;
• or apply the governing pattern once approval, execution, or another downstream decision publication becomes the more honest primary question.

#Bias-Annotation

Lenses tested: Arch, Onto and Epist, Prag, Did. This section intentionally biases toward explicit publication-unit stability and against quietly letting one unit absorb wider work or decision pressure by habit. The main mitigation is explicit described-entity, move, and outside-work surfacing, early return to E.17.ID.CR when publication-unit stability is already solved, and explicit governing-pattern boundary dispositions once a downstream claim becomes primary.

#Conformance Checklist

1. CC-OOTD-1 - One publication unit is explicit. The governed publication unit is explicitly identifiable as one note, memo, sheet, screen, table, or section meant to be read as one unit.
2. CC-OOTD-2 - Primary described entity is explicit. The unit makes its primary described entity recoverable enough that readers are not left to infer it from tone alone.
3. CC-OOTD-3 - Carried move is explicit. The unit states what move it is making over that primary described entity, or explicitly says that it is only stabilizing the primary described entity without a new move.
4. CC-OOTD-4 - Outside-work boundary is explicit. Wider work, approval, execution, or unsupported downstream decision, work, or reliance pressure is either declared outside or handled by its governing pattern rather than smuggled into the same unchanged unit.
5. CC-OOTD-5 - Any transition is explicit. If the unit shifts between described entity, description, carrier, publication unit, process, or downstream decision use, that transition is explicit rather than quietly absorbed.
6. CC-OOTD-6 - Local vs publication-unit repair choice is honest. Apply E.17.AUD.LHR (Local Head Restoration) first when local repair is enough; apply this pattern only when publication-unit reading instability remains after local repair.
7. CC-OOTD-7 - Neighboring-pattern boundary is explicit. If same-entity transform, explanation, bridge, comparative-reading, ontology, gate, approval, or execution claim becomes primary, its governing pattern is applied rather than pretending this pattern still governs the case.
8. CC-OOTD-8 - Load-bearing lens is stated when needed. If a minimal modeling lens or downstream-decision policy is materially load-bearing, it is stated rather than silently assumed.

#Common Anti-Patterns

• Local-repair inflation. Opening publication-unit discipline when one overloaded local lexical head or qualifier is still the real defect.
• Work-process smuggling. Letting a note begin as architecture, incident review, or comparison work and end as rollout, approval, or execution guidance without naming the transition.
• Support-pattern replacement. Treating this pattern as if it replaced view, face, or carrier architecture, same-entity transform rules, explanation governance, bridge rules, or downstream decision texts.
• Overgrowth by declaration. Stacking heavier fields onto a unit that still cannot keep one stable primary described entity, one move, and one outside-work boundary in place.

#Consequences

Used well, this section buys three main gains:

• authors stop smuggling wider work into one unit by accident;
• reviewers can name publication-unit reading instability instead of only arguing about wording;
• neighboring patterns and downstream decision texts stop getting blamed for confusion created one layer earlier.

The cost is that some notes must become shorter, split earlier, or reopen more honestly when the primary described entity really changes. That cost is deliberate.

#Rationale

The point of this pattern is not to create a second architecture of views, faces, carriers, or downstream decision texts. It is narrower: one publication unit can become misleading even when every single sentence looks locally acceptable.

A.6.P, A.7, E.10, and F.18 already keep kinds, distinctions, and naming precise. This pattern adds the missing publication-unit discipline that asks whether the same publication unit is still honestly about one primary described entity, carrying one move, with one explicit outside-work boundary.

The pattern also stays intentionally close to E.14 and E.19. Recognition comes first through a manager-usable entry block and the ordinary six-row card. Heavier declaration comes only after the ordinary card already holds.

#SoTA-Echoing

#Relations

Builds on

• A.6.P
• A.7
• E.10
• F.18
• E.14
• E.19
• C.2.2a
• A.16.0

Nearest neighbors

• E.17.AUD.LHR for local lexical-head kind or qualifier repair;
• E.17.ID.CR when the same unit is already stable and the remaining question is one bounded comparative review move;
• E.17.EFP when explanation-face governance on existing faces is primary;
• A.6.3, A.6.3.CR, and A.6.3.RT when the live question is same-entity rewrite or representation change;
• A.10 when evidence or provenance becomes primary;
• A.15 and A.15.4 when work, reliance, or execution claim becomes primary;
• B.3 when assurance or engineering justification becomes primary;
• A.20 and A.21 when approval, gate, or adjudication becomes primary.

#E.17.AUD.OOTD:End

---

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