| Checklist promoted to framework | Local tips are published as a principle framework without source, pattern, relation, or quality work. | Keep the checklist as local process text until the selected source route, E.8 pattern work, material relation assertions, and E.21 evaluation support a DPF. |
| Source summary as SoTA | A literature narrative replaces adopted and rejected source payload and never returns a domain move. | Choose the smallest source route, recover load-bearing claims and limits, and carry them into a pattern Solution, boundary, worked case, contrast, or unresolved inquiry. |
| Chapter-complete map as practice coverage | Every source chapter has a pattern destination, but the package has no decision-bearing account of recurring difficulties, receiving results, project and Method positions, several structures, pressure evidence, subtraction, or reopenable gaps. | Return to the accepted E.4.PFAD practice-architecture input, organize domain fillings by practitioner situation and receiving use, and leave a missing filling as a seed, gap, or omission. Source provenance remains evidence input rather than the coverage criterion. |
| Earlier DPF as ecosystem law | A useful precedent is copied into another DPF or FPF without checking its subject, Context, edition, use, and transfer limits. | Reuse it through an explicit dependency when those fit; otherwise keep the new claim local or submit a separately reviewed FPF improvement. |
| Lookup miss as absence | A search index or generated crosswalk returns nothing, so the author concludes that FPF, a DPF, or the literature has no relevant contribution. | Report partial coverage, return useful hits to authoritative bodies and editions, and widen the lookup when a known contribution is missing. |
| Wording profile by default | Every DPF receives a trigger registry or profile although no recurring domain wording failure or maintained multi-entry use has been shown. | Write only the local entries needed by affected patterns; identify a separate profile only for a named maintained multi-entry use, and keep any table that publishes it as a publication form. |
| Ontology catalog as framework | The package classifies the domain or defines terms, but it does not tell a practitioner what typical problem is live or what SoTA solution move avoids a known failure. | Keep ontology as support material; draft or repair DPF patterns around problem frames, positive solution moves, worked cases, anti-patterns, and refresh. |
| Outside the pattern set means another product | A Preface, coverage account, registry snapshot, or refresh note is split or absorbed by file location rather than shared edition, reader use, access, and change rule. | Keep units that share those facts together. Keep an independently useful adjacent subject separate and point to its exact edition or current state; state maintenance separately when it obtains and state later-review or retirement conditions when they change use. |
| Combined carrier merges products | A DPF and an adjacent catalogue, guide, evidence package, service, or programme receive one framework identity or index. | Keep the outer carrier neutral, apply E.11.PFP only to framework constituents, and retain each adjacent direct subject’s identity or state, form, access, change rule, and any separately established maintenance relation. |
| Publication carrier as architecture | Publication occurrence, form, presentation carrier, package boundary, or access route is treated as framework episteme, edition continuity, package architecture, relation membership, or truth. | Recover E.4.PFAD architecture decisions, E.4.PFR relations and dependencies, C.2.1 framework identity, and E.24.PUB publication occurrence, form, and carrier separately before relying on the exposed content. |
| Invisible framework story | A DPF carrier reads as a neutral list of principles, but the reader cannot tell what source or domain structures were selected, why this route is for them, what was deliberately coarsened, abstracted, omitted, or left to source return, or whether the carrier is a second-step coarsening after an architecture description or view. | Add a short carrier structure-account in the readme, Preface, or equivalent carrier, then evaluate it through E.4.DPF.DA rather than scattering explanation into every pattern body. |
| Generated candidate authority | Search or LLM output becomes the framework because it is fluent. | Use C.35 for admission, then decide candidate selection through E.4.PFAD or C.32. |
| Skeleton carrier as DPF | A file has a ToC, headings, and very short pattern-shaped sections, but readers still cannot apply the patterns without reconstructing the missing guidance from the DRR or source notes. | Keep it as seedOnly; harden each DPF pattern through E.8, evaluate through E.21, and only then assemble the user publication carrier. |
| Singleton authoring slice as edition | One useful pattern or one narrow authoring slice receives a broad framework name because it is the material currently being written or reviewed. | Report the singleton as a strong diagnostic and run the same framework-scale test used at every count. Keep it as a seed, candidate, or existing-framework contribution when connected problem-family coverage, material pattern relations, a representative application, an internally usable first-edition set, honest omissions and source returns, or a credible edition, change, and refresh boundary are missing; do not fail or pass it by count. |
| DPF belonging edits the Suite from inside a member | A DPF author treats a Guide entry or local inclusion proposal as an accepted Suite state, stronger relation, or maintenance assignment. | Keep each as a proposal until the applicable Suite or Guide content/refresh decision takes effect. Return inclusion and removal to E.4:4.2 and E.4.PFAD; return a concrete Guide entry to the Guide product’s decision. State its direct result and source claims through the patterns that define them, and use E.4.PFR only for edition-level dependency or compatibility facts. |
| Card-per-pattern fanout | Every DPF pattern or locator receives a mantra because the card form exists, increasing burden without changing first use. | Apply the E.11 same-content-without-mantra comparison; keep locators and ordinary entries when they already support reliable choice and return. |
| FPF card application copied or declaration avoided | The DPF copies FPF keys, card count, whitespace-token measure, numeric limits, or @FPFReadme records, or labels every rich entry ordinary so no card declaration is needed. | Keep one product-native example declaration, reading-burden measure, and two limits; reuse the shared field grammar from E.11.PFP, and check both selected cards and plausible non-card entries through E.11. |
| External dependency hidden as closure | A first-edition set omits a needed same-framework prerequisite or silently assumes an FPF, DPF, or LPF edition, availability result, or compatibility result. | Include every same-framework prerequisite needed for the first use. For each external dependency, identify the result and relied-on content, edition or current state, receiving use, direction, reason, refresh condition, and any required availability or compatibility result with the basis on which it applies; return a missing requirement as a first-use blocker. |
| Access route or returned artifact as framework | An access-facing artifact or route is treated as the framework because it is what a reader or System calls or sees. | Classify the exact artifact as a U.PresentationCarrier when it bears a selected form, and classify the service or other route separately. Use E.24.PUB and the direct access or use pattern for publication, availability, actual access, and use; expose the exact framework edition and currentness return. Concrete implementations such as skill packs, endpoints, retrieval or search routes, and assistant integrations use the same distinction. Use E.4.PFR only when a named maintenance use needs a stable relation representation. |
| Future framework fabricated | An optional organization proposal points to the absent framework or claims its actual structures. | Create a current intended-result description and one proposal episteme; wait for an accepted E.9 framework-architecture answer and later realization before architecture-description use. |
| Claim wrapper collection | Every candidate organization claim becomes another episteme. | Keep typed claim nodes in the proposal’s one ClaimGraph unless a separately grounded claim episteme has its own EoC and use. |
| Proposal layout as subject organization | Headings or ClaimGraph organization are treated as the proposed framework organization. | Recover described position kinds, proposed subject relation signatures, constraints, invariants, dependency directions, alternatives, basis, and questions. |
| Coverage and acceptance union | One field mixes coverage criterion with WorkPlan acceptance target. | Keep the coverage node complete and cite the plan target separately. |
| Availability as relevance | A missing dependency is assumed blocking, or an available dependency is assumed current for next use. | Fill availability and use relevance independently; only the exact combined state determines the next-use consequence. |
| Grounding or context as identity | A grounding holon, organization, project label, package boundary, or bare context word is inserted into episteme identity or used to force sameness. | Keep C.2.1 identity at ClaimGraph, EntityOfConcern, and effective ReferenceScheme; use separate empirical-grounding, ClaimScope, model-use, project-Work, and exact cross-context translation relations only when their predicates obtain. |
| Authoring order as Method, Work, result, or CGUS | Numbered guidance, arrows, coordination rows, or document order is used as proof that a Method, Work occurrence, result relation, or conditional structure exists. | Recover the authoring Method and qualify a MethodDescription only through A.3.2. When dated Work is actually claimed, recover every precise performer’s A.13 core and independently admit the Work under A.15.1; add F.6 only when precise assignment-bound attribution is also current. Identify any A.6.1 application, direct result or use relation, or independently selected A.22.CGUS separately. Otherwise keep the sequence Plain. |
| PatternID used as position or definition | Inserting or moving a pattern causes renumbering, or a mnemonic is treated as a title, dependency, Method relation, or compressed claim. | Keep the public address stable while the practical answer continues, show the current position separately, and state titles and relations in their own fields. Decide splits, merges, replacements, and retirements from content rather than identifier shape. |
| Build manifest as public framework prose | An all-in-one carrier opens with generated comments, source paths, digests, machine identity fields, or builder warnings, so reproducibility apparatus displaces the working-question route. | Keep those values in builder output, package evidence, or a separately justified manifest; expose E.11.PFP’s short public edition line and only those additional cues whose selected reader use requires them before the ToC. |