#Recognition Signatures for Descriptions

A.6.RSIG · Stable · Architectural pattern · Normative unless marked informative · Part A - Kernel Architecture Cluster

#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.

Type: Architectural pattern Status: Stable Normativity: Normative unless marked informative

A reader often meets one description before they know whether it is the right description to inspect. The reader may see a boundary clause, method note, interface excerpt, pattern opening, or public projection. The first burden is not yet the full semantics of that description. It is first-contact recognition: what description is seen, where it is encountered, what it applies to, what excludes it, which authoritative home defines it, and which nearby reading or wrong home must be rejected.

#Relations

#Content

#Problem frame

A reader often meets one description before they know whether it is the right description to inspect. The reader may see a boundary clause, method note, interface excerpt, pattern opening, or public projection. The first burden is not yet the full semantics of that description. It is first-contact recognition: what description is seen, where it is encountered, what it applies to, what excludes it, which authoritative home defines it, and which nearby reading or wrong home must be rejected.

Use this pattern when the live burden is still first-contact recognition over one encountered description carrier or projection. The reader needs to decide whether this is the right description to inspect before broader comparison, publication-face selection, boundary-claim routing, or pattern-language entry comparison begins.

What goes wrong if this pattern is missed:

• one summary, excerpt, boundary phrase, or local top is mistaken for the authoritative home of the description;
• one access/request description is over-read as a promise about downstream effect;
• one boundary-presented description is over-read as routed claim structure or as the full semantic contract;
• one method note is treated as applicable before its actual method family and exclusions are recoverable;
• one pattern-local opening is forced to carry cross-pattern comparison that belongs to E.11.

What this pattern buys:

• the reader can tell what the encountered description is for before deeper semantics are reconstructed;
• carrier, projection, description, and authoritative home stay distinct;
• false neighboring descriptions and wrong authoritative homes become rejectable in one first pass;
• later boundary, publication, lexical, or pattern-language reroutes happen from a typed first-contact read instead of from guesswork.

Ordinary not-this-pattern boundary:

• not when the live burden is already full routed-claim structure, published view law, lexical repair, or cross-pattern entry orientation;
• not when the real question is the whole semantics of the method, boundary claim, interface promise, or pattern;
• not when a search/query phrase needs naming repair rather than first-contact recognition of a particular encountered description.

#Problem

When first-contact recognition is under-governed, several defects recur:

1. One reader finds a boundary, method, interface, or pattern-local opening but cannot tell whether it is the right description to inspect.
2. An encountered carrier or public projection is misread as the authoritative semantic home.
3. Recognition cues drift into description semantics, workflow hints, graph metaphors, or lexical aliases that belong elsewhere.
4. Pattern-entry navigation is asked to solve a broader description-recognition burden that belongs before pattern-language comparison begins.

#Forces

#Solution

#Governed object and non-goals

A.6.RSIG governs description-recognition signatures in general: the first-contact cue structure by which one reader can recover what encountered description is live, what carrier or projection exposed it, what it applies to, what excludes it, which authoritative home defines it, and which nearby false description or wrong home must be rejected.

Here "description-recognition signature" is lower-case authoring and reading discipline. It is not U.Signature, not a Signature Stack object, not a new Description object by default, not a U.* kind, and not a specialization of A.6.0 unless another pattern explicitly promotes a particular declaration.

The encountered carrier or projection may help recognition; it does not become authoritative merely by being encountered. surface wording in this pattern is only lower-case prose for an encountered publication/projection when no existing PublicationSurface, InteropSurface, View, Card, or Lane kind is being minted.

A.6.RSIG does not govern:

• general information architecture or search UX;
• documentation layout or publication-face selection;
• pattern-entry discoverability across a pattern language;
• the full semantics of the description itself;
• lexical repair, alias acceptance, or naming governance as such;
• graph ontology, workflow sequencing, or runtime route semantics.

#Two-level description-recognition shape

Reader-visible minimum. For ordinary reader-facing use, the minimum is not a card. One or two good sentences may be enough if they make recoverable:

1. what this description is for;
2. when it applies;
3. when it does not apply;
4. where the authoritative home is;
5. what nearby false reading or wrong home to reject.

Review-expanded shape, only when needed. When the recognition burden is load-bearing or under review, use the expanded recoverability shape:

description_seen
encountered_carrier_or_projection
reader_viewpoint
case_signal_or_access_condition
applies_to
excludes
expected_first_recognition_gain
first_lawful_entry_stop_or_reroute
authoritative_home
projection_role_if_any
nearby_false_description_or_wrong_home

This shape is a review aid, not a mandatory form for every encountered description. It exists to keep description, carrier, projection, and home from collapsing into one overloaded surface label.

#Minimal local repair and review sequence

Use this sequence when authoring or reviewing one recognition-signature repair:

1. Name the description_seen and the reader viewpoint in one concrete first sentence.
2. Name the encountered carrier or projection if confusing it with authority is a live risk.
3. State what the description applies to and what excludes it.
4. Name the authoritative home to inspect first.
5. Name one nearby false description or wrong authoritative home that looks plausible in the same situation.
6. State the first lawful entry stop or reroute.
7. If that stop cannot be stated without boundary routing, publication-face law, lexical repair, or cross-pattern comparison, reroute the burden instead of stretching A.6.RSIG.

Minimal lawful output:

• one first-contact recognition statement the reader can use immediately;
• one explicit authoritative home;
• one explicit false-neighbor rejection;
• one lawful entry stop or reroute.

#Parent cases

A.6.RSIG keeps the main parent cases explicit:

• boundary-description recognition: can one reader recover what one boundary-presented description is for before routed claim structure becomes the dominant burden;
• method-description applicability recognition: can one reader recover whether one method description is the right description to inspect, reject, or compare under the live burden;
• interface/access-description recognition: can one reader recover the right access or interface description without confusing it with promise, execution, or downstream effect semantics;
• pattern-local recognition-signature case: can one reader recover one pattern opening as the right first description to inspect before broader pattern-language comparison begins.

#Neighbor boundaries

Neighbor boundaries remain explicit:

• A.6.B governs routed L/A/D/E claim structure when the boundary description is already in routed-claim territory;
• E.17.0 / E.17 govern lawful view and publication-face projection when the same recognition burden is carried through published views;
• E.10.D2 and the E.10 / F.18 / A.6.P lane govern lexical repair, collision checks, and naming survival;
• C.25 / A.6.Q govern formal quality treatment when the discoverability or recognition claim becomes explicitly evaluative;
• the relevant authoritative pattern body governs pattern semantics when the encountered description is one pattern-local opening.

The four-level split for pattern-local recognition is:

#No-minting rule

This pattern does not mint:

• one standalone U.Discoverability;
• one new U.Signature, Signature Stack object, U.Characteristic, CHR, or local Q-Bundle;
• one SurfaceKind, DescriptionKind, relation kind, graph ontology, route graph, or workflow family;
• one universal reader-orientation role.

If a recognition-signature burden is promoted into a stronger quality claim, typed signature object, reusable description object, or publication-face law, that promotion is explicit and routed through the existing neighboring patterns.

#Archetypal grounding

#System-side worked recognition repair: boundary-presented description

Draft cue:

"The system shall reject invalid requests."

Why the cue is not enough yet:

• the reader can tell this is important, but not whether they are reading one law, admissibility gate, duty, work effect, or evidence statement;
• one summary page or local paraphrase can be mistaken for the authoritative home;
• a reviewer can start arguing full semantics before the first-contact recognition burden has been stabilized.

Recognition repair:

1. description_seen = one boundary-presented admissibility description.
2. encountered_carrier_or_projection = one clause or excerpt where the description is seen.
3. reader_viewpoint = one practitioner or reviewer deciding whether this is the right boundary description to inspect first.
4. applies_to = requests presented at the boundary under the declared admissibility conditions.
5. excludes = downstream effect claims, duty allocation, or evidence claims not actually stated by this description.
6. authoritative_home = the governing boundary description, not one local paraphrase or summary note.
7. nearby_false_description_or_wrong_home = one evidence/work claim or one routed quadrant statement that only becomes lawful after the reader has stabilized the admissibility description.
8. first_lawful_entry_stop_or_reroute = the reader can now say "this is the admissibility description to inspect first"; if the burden becomes routed claim structure, inspect A.6.B.

#System-side anti-case: interface/access description over-read as promise

Draft cue:

"POST /deploy triggers deployment."

Plausible but wrong first reading:

• the reader treats one access/request description as if it already promised one downstream operational effect or successful completion.

Recognition repair:

1. description_seen = one interface/access description.
2. encountered_carrier_or_projection = one API excerpt or endpoint note.
3. applies_to = request accessibility and invocation form.
4. excludes = success, completion, rollout, or downstream effect guarantees not present in the access description itself.
5. authoritative_home = the specification or pattern that actually governs downstream effect, if that burden is live.
6. first_lawful_entry_stop_or_reroute = "this is the access description to inspect first, not the promise of the whole deployment result."

#Episteme-side worked recognition repair: method-description applicability

Draft cue:

"Use pairwise comparison."

Why the cue is not enough yet:

• the reader cannot tell whether the note applies to ranking alternatives, selecting one option, shaping a shortlist, or comparing method families;
• the method note can be mistaken for the authoritative home of selection semantics;
• a team can prematurely choose C.11 or G.5 before knowing what kind of comparison burden is actually live.

Recognition repair:

1. description_seen = one method-description applicability note.
2. encountered_carrier_or_projection = one procedure note, pattern excerpt, or review comment that mentions pairwise comparison.
3. applies_to = comparison under a declared comparator set or characteristic family.
4. excludes = publication of a selected set, execution planning, evidence sufficiency, and one-off decision doctrine unless those homes are separately opened.
5. authoritative_home = the relevant comparison or method pattern, not the note itself.
6. nearby_false_description_or_wrong_home = selection/publication doctrine treated as if the method note had already settled it.
7. first_lawful_entry_stop_or_reroute = method applicability is recognized or rejected before selection semantics begin.

#Bias-Annotation

This pattern counters:

• front-door centralization bias, where every recognition burden is pushed into one global front-door cue;
• signature-stack overreach, where any useful cue is prematurely promoted into U.Signature;
• carrier-authority collapse, where an encountered carrier or projection is treated as the authoritative home;
• alias bias, where uncontrolled synonyms compensate for missing recognition structure;
• workflow bias, where first-contact recognition is narrated as sequence or handoff.

#Conformance checklist

• CC-RSIG-1 First-contact only. The pattern governs recognition of the right description, not the full semantics of that description.
• CC-RSIG-2 Carrier/home split. A conforming description-recognition signature distinguishes description_seen, encountered carrier or projection, authoritative home, and projection role when those distinctions are load-bearing. The encountered carrier or projection may help recognition, but it does not become authoritative merely by being encountered.
• CC-RSIG-3 Neighbor boundaries explicit. The text states when burdens go to A.6.B, E.17, E.10 / F.18 / A.6.P, C.25 / A.6.Q, or the relevant authoritative pattern body.
• CC-RSIG-4 No kind inflation. Recognition signatures are not silently promoted into U.Signature, Signature Stack objects, SurfaceKinds, graph objects, workflow objects, or new U.* kinds.
• CC-RSIG-5 Recoverable cue shape. For load-bearing cases, description, viewpoint, cue, applicability, exclusion, authoritative home, false neighbor, and lawful entry stop remain recoverable.
• CC-RSIG-6 No alias minting. Query cues and ordinary phrasing do not become aliases, bridges, semantic twins, or lexical authority without the relevant naming home.

#Common Anti-Patterns and How to Avoid Them

• Recognition-as-semantics. The opening tries to define the whole description instead of making the right description recoverable. Repair by shrinking back to first-contact discrimination.
• Carrier-as-authority. A local excerpt, public projection, or retrieved fragment is treated as the authoritative home. Repair by naming the encountered carrier/projection and the authoritative home separately.
• Boundary-routing collapse. A boundary-description cue tries to absorb routed claim structure. Repair by routing routed quadrant work to A.6.B.
• Pattern-language collapse. Pattern-entry comparison is written as if it were just another description cue. Repair by routing cross-pattern selection to E.11.
• Signature inflation. Any recurring cue is treated as one typed signature object. Repair by keeping description-recognition signature lower-case unless one explicit promotion is justified.

#Consequences

This pattern gives one neutral governing discipline for first-contact description recognition without turning discoverability into one universal governing pattern. It sharpens the boundary between cue recognition, semantic authority, lexical repair, publication-face projection, and pattern-language entry.

The cost is one extra explicit split when a cue is confusing: description, encountered carrier/projection, authoritative home, and false neighbor must not be collapsed. The cost stays bounded because the expanded shape is review-only or risk-triggered, not a required card for ordinary prose.

#Rationale

This pattern lands in the A.6 cluster because the burden is still one description/signature burden: a reader is recovering what one description is for, what it applies to, and which authoritative home to inspect first. That sits closer to signature and boundary discipline than to pattern-language navigation or review-profile law.

Read this honestly as one FPF-local synthesis over current SoTA, not as one already established external standard term. It combines information-scent, human/AI expectation-management, controlled vocabulary, and retrieval-context practices into one description-facing discipline for FPF.

#SoTA-Echoing

This pattern is an FPF-local synthesis, not an established external term. It carries the modern practice burden only where that burden sharpens one description-facing recognition question: can the reader recover the right description, its carrier or projection, its exclusions, its authoritative home, and its tempting false neighbor before stronger semantic work begins?

#Relations

• Builds on: A.6, A.6.P, F.18, E.10
• Does not specialise: A.6.0 / U.Signature; it uses "signature" only in the lower-case cue-pattern sense unless an explicit neighbouring pattern promotes the structure into a typed declaration.
• Neighbors: A.6.B, A.6.C, E.17.0, E.17, E.10.D2, C.25, A.6.Q
• Supports: E.11 as the pattern-language application above this neutral substrate

#A.6.RSIG:End