#AuthoredUnitDiscipline / AuthoredUnit Primary Described-Entity Discipline — authored-unit stability over one primary described entity and carried move

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 authored-unit stability pattern inside the broader AuthoredUnitDiscipline problem-pressure classification 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.15, A.20, A.21.

Plain-name. Keep one authored unit about one thing at a time.

One-line summary. AuthoredUnit Primary Described-Entity Discipline governs one authored working or 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 or unsupported downstream decision/work-reliance claim remains outside.

Governed object in plain terms. The governed object here is one authored 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 authored unit starts reading as if it is still about one thing 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 authored 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 authored 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 authored-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 authored-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 authored unit is already stable enough, and the live question is one bounded comparative review move over already available source epistemes/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 authored-unit reading instability;
• the unit is already being used to approve, assign, adjudicate, or direct work and should move to the more honest downstream decision or work/reliance text.

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 exit bank. If the recognition surface no longer fits, exit early instead of opening the heavier stack by habit. One pressured local lexical head or qualifier only -> E.17.AUD.LHR (Local Head Restoration). Same stable authored unit, but the live question is one bounded comparison over already pinned source epistemes/publications -> E.17.ID.CR. View, face, carrier, same-entity rewrite, or downstream approval/work-reliance question -> the neighboring pattern or the more honest downstream decision text.

Quick kind-plus-lens reading. AuthoredUnitDiscipline names the broader authored-unit discipline family. AuthoredUnit Primary Described-Entity Discipline names the authored-unit stability pattern used when one authored 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 authored unit speaks about that lineage or a move over it, not a rival moving thing.

Primary working reader. The first-minute reader is an engineer-manager, architect, reviewer, or programme lead who needs to stop one authored 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-workflow note. The quick checks, ordinary six-row card, heavier extension, and worked slices in this section are local aids for one authored unit under review. They are not a canonical lifecycle for authored units and not a promise that admissible cases move through one fixed graph in one direction. Read the worked slices sideways rather than as one required sequence: one admissible case may stop after one authored-unit declaration, another may reopen when outside observations change the honest described entity, and another may move once downstream approval/work-reliance question or a neighboring pattern question becomes primary.

#Keywords

• authored unit
• primary described entity
• authored-unit reading instability
• carried move
• outside-work boundary
• explicit transition.

#Relations

#Content

#Problem frame

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

Teams repeatedly write one authored unit that begins by talking about one thing 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 object 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, or work/reliance pressure.

That reading instability is usually not caused by one bad sentence alone. It is caused by one whole authored 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 authored-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 authored-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 authored unit, one described entity, one move, and one outside-work boundary

#Manager-first entry

AuthoredUnit Primary Described-Entity Discipline keeps one authored 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 authored unit still has unstable reading across described entity, description, carrier, authored 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

• Authored unit = one written or displayed thing others are meant to read as one unit, such as a note, memo, sheet, table, or guided screen.
• Primary described entity = what that unit is mainly about.
• 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, workflow, execution, or unsupported downstream decision/work-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 thing here as one authored unit carrying one primary described-entity reading over one current working concern or lineage slice. The smallest honest lens asks five things:

1. what authored 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 move it to the governing pattern instead.

#Scope and exclusions

In scope

• one authored unit with unstable reading across multiple described entities;
• one unit mixing move and outside work;
• one unit quietly shifting between described entity, description, carrier, authored unit, process, or downstream decision use;
• semio-heavy texts where repair family, governing pattern, governed object, carried move, and outside work must stay explicit across one authored 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 own 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 object, one 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 authored 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 thing but seam pressure, misuse risk, or cross-reading ambiguity becomes load-bearing, move to 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/publications, return the case to E.17.ID.CR before thickening this authored-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; move to or reopen the neighboring-pattern check first.

#Load-bearing extension and quick branch/exit 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:

• authoredUnitForm;
• primaryReading;
• transitionPolicy;
• modelingLensPolicy;
• downstreamDecisionPolicy.

These fields do not create a rival rule track. They only make the heavier seam pressure visible once the ordinary card already holds.

Quick governing-pattern/source 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 authored 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/publications;
• use this pattern when one authored unit still has unstable described-entity, carried-move, or outside-work reading after honest local repair;
• move to the neighboring pattern or downstream decision text when view/face/carrier, same-entity transform, explanation, bridge, ontology, gate, approval, or execution pressure becomes primary.

#Branch-rule summary

This section is the canonical governing-pattern boundary summary for AuthoredUnit 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, authored 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 authored-unit reading instability remains after that;
5. return the case to E.17.ID.CR when authored-unit stability already holds and the remaining question is one bounded comparative review move over already available source epistemes/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 authored 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 move to a downstream decision or rollout text.

#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 branch 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 thing;
• and what wider architecture strategy remains outside the current unit.

#Unit stabilizes and hands back to bounded comparison

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 authored-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. AuthoredUnit 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 move is to return the case to E.17.ID.CR rather than keep thickening authored-unit discipline.

#Outside observation changes the honest described entity

A release-readiness note is already explicit that it is about one candidate publication/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 object, move, and outside-work boundary;
• or move once approval, execution, or another downstream decision text becomes the more honest primary question.

#Bias-Annotation

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

#Conformance Checklist

1. CC-OOTD-1 - One authored unit is explicit. The governed authored 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 object, or explicitly says that it is only stabilizing the object without a new move.
4. CC-OOTD-4 - Outside-work boundary is explicit. Wider work, approval, execution, or unsupported downstream decision/work-reliance pressure is either declared outside or moved to its governing pattern rather than smuggled into the same unchanged unit.
5. CC-OOTD-5 - Any transition is explicit. If the unit moves between described entity, description, carrier, authored unit, process, or downstream decision use, that transition is explicit rather than quietly absorbed.
6. CC-OOTD-6 - Local vs authored-unit repair choice is honest. E.17.AUD.LHR (Local Head Restoration) is used first when local repair is enough; this pattern is used only when authored-unit reading instability remains after local repair.
7. CC-OOTD-7 - Neighboring-pattern exit is explicit. If same-entity transform, explanation, bridge, comparative-reading, ontology, gate, approval, or execution pressure becomes primary, the unit moves to its governing pattern 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 authored-unit discipline when one pressured local lexical head or qualifier is still the real defect.
• Workflow 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/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 object, 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 authored-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 authored 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 authored-unit discipline that asks whether the same authored unit is still honestly about one thing, 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.15, A.20, and A.21 when approval, gate, adjudication, or execution pressure becomes primary.

Authority note. This monolith section is the canonical governing-pattern boundary locus for AuthoredUnit Primary Described-Entity Discipline inside the Core. Companion notes may summarize, harden, or stage adjacent review support, but they may not override this section.

#E.17.AUD.OOTD:End

---

Last Updated: 2026-05-10 — this section last modified in upstream FPF commit 136be3bb (github.com/ailev/FPF)