A.6.RSIG - Recognition Signatures: Find the Defining Episteme for a Description

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

A.6.RSIG:1 - 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 reader first needs to recognize the description before reconstructing its full semantics: what description is seen, where it is encountered, what it applies to, what excludes it, and which definitionEpistemeRef identifies its defining U.Episteme. Reject a nearby reading or wrong defining U.Episteme only when the grounded-guard condition in §4.1 holds.

Plain recognition line. Find the defining U.Episteme for the encountered description.

Use this pattern while the reader needs to decide whether one encountered description 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 defining U.Episteme of the description;
• one access/request description is over-read as a promise about downstream effect;
• one boundary-presented description is over-read as L/A/D/E-classified claim structure or as the full semantic claim set;
• 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 defining U.Episteme stay distinct;
• false neighboring descriptions and wrong defining U.Episteme references become rejectable in one first pass;
• later boundary, publication, lexical, or pattern-language repairs start from first-contact identification instead of from guesswork.

Ordinary not-this-pattern boundary:

• not when the reader’s question already concerns 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.

A.6.RSIG:2 - 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 defining U.Episteme.
3. Recognition cues drift into description semantics, workflow hints, graph metaphors, or lexical aliases that belong elsewhere.
4. Pattern-entry navigation is asked to identify the encountered description before the reader can begin pattern-language comparison.

A.6.RSIG:3 - Forces

A.6.RSIG:4 - Solution

A.6.RSIG:4.1 - Recognition-cue discipline 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, and which definitionEpistemeRef identifies its defining U.Episteme. Reject a nearby reading or wrong defining U.Episteme only when it passes F.19’s grounded-guard test: the rejected reading has an independent local ground, is plausible for the intended reader, and changes truth, understanding, selection, safety, stop, reliance, or action. Use the smallest clear correction; do not invent an alternative to fill the cue shape.

Here “description-recognition signature” is a lower-case authoring and reading discipline, not by itself a typed U.Signature or a new formal kind. A typed declaration requires the applicable neighboring pattern’s explicit conditions.

The encountered carrier or projection may help recognition; it does not become authoritative merely by being encountered.

Use definitionEpistemeRef for the defining U.Episteme. If the definition is available only through one publication, cite separately the exact E.24.PUB publication occurrence that makes it available; the publication, projection, or carrier does not become the defining episteme merely because it exposed the definition to the reader.

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.

A.6.RSIG:4.2 - Two-level description-recognition shape

Reader-visible minimum. For ordinary reader-facing use, the minimum is not a card. One or two 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. which definitionEpistemeRef applies;
5. what nearby false reading or wrong defining U.Episteme to reject, when the grounded-guard condition in §4.1 holds.

Review-expanded shape, only when needed. When a recognition cue affects a decision or is being reviewed, 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_admissible_entry_stop_or_reroute
definitionEpistemeRef
projection_role_if_any
nearby_false_description_or_wrong_definition_episteme

The nearby_false_description_or_wrong_definition_episteme field is optional: use it only when the grounded-guard condition in §4.1 holds.

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

A.6.RSIG:4.2.1 - 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 defining U.Episteme to inspect first.
5. When the grounded-guard condition in §4.1 holds, name the nearby false description or wrong defining U.Episteme to reject.
6. State the first admissible entry stop or neighboring-pattern application.
7. If that stop cannot be stated without A.6.B claim routing, publication-face law, lexical repair, or cross-pattern comparison, apply the appropriate neighboring pattern instead of stretching A.6.RSIG.

Minimal admissible output:

• one first-contact recognition statement the reader can use immediately;
• one explicit defining U.Episteme;
• an explicit false-neighbor rejection when the grounded-guard condition in §4.1 holds;
• one admissible entry stop or reroute.

A.6.RSIG:4.3 - 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 the reader needs to classify its claims as L/A/D/E;
• method-description applicability recognition: can one reader recover whether one method description is the right description to inspect, reject, or compare for the reader’s question;
• 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.

A.6.RSIG:4.4 - Neighbor boundaries

Neighbor boundaries remain explicit:

• use A.6.B when the reader needs to classify the boundary claims as L/A/D/E;
• E.17.0 tests viewpoint/view membership; E.17 publishes reader-facing forms of an already accepted engineering account; use E.24.PUB when publication occurrence, form, or carrier identity affects the recognition use;
• E.10.D2 recovers description-episteme and specification-use distinctions; use E.10 cues within F.19 for wording, A.6.P for under-specified direct relations, and F.18 for durable naming and its collision checks;
• C.16.Q repairs overloaded recognition or discoverability quality wording; C.25 applies when the quality-family claim depends on several differently typed contributors; a single-Characteristic claim stays with its direct Characteristic pattern;
• the relevant authoritative pattern body governs pattern semantics when the encountered description is one pattern-local opening.

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

A.6.RSIG:4.5 - When a neighboring pattern is needed

If the task requires a quality claim, typed signature declaration, reusable description, or publication-face rule, use the neighboring pattern that governs that object or claim, including its evidence requirements. The recognition cue alone does not establish that result.

A.6.RSIG:5 - Archetypal grounding

A.6.RSIG:5.1 - 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 cannot tell 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 governing boundary description;
• a reviewer can start arguing full semantics before identifying which description to inspect.

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 = the perspective of a 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. definitionEpistemeRef = the governing boundary description, not one local paraphrase or summary note.
7. nearby_false_description_or_wrong_definition_episteme = an evidence/work claim or a different routed-quadrant statement mistaken for the governing admissibility description.
8. first_admissible_entry_stop_or_reroute = the reader can now say “this is the admissibility description to inspect first”; if the reader needs to classify the boundary claims, inspect A.6.B.

A.6.RSIG:5.2 - 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 deployment initiation as a guarantee of successful completion or of the whole deployment result.

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, invocation form, and the stated deployment initiation under the conditions in the defining description.
4. excludes = success, completion, rollout, or downstream effect guarantees not present in the access description itself.
5. definitionEpistemeRef = the defining episteme for the access description; inspect the specification or pattern governing downstream effect separately if that question is current.
6. first_admissible_entry_stop_or_reroute = “this is the access description to inspect first: it describes invocation of POST /deploy and deployment initiation, not guaranteed successful completion.”

A.6.RSIG:5.3 - 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 defining U.Episteme of selection semantics;
• a team can prematurely choose C.11 or G.5 before identifying what the pairwise comparison is to determine.

Recognition repair:

1. description_seen = one method-description applicability note.
2. encountered_carrier_or_projection = one method-description 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. If one of those questions is current, apply the pattern that governs it and obtain the result it requires.
5. definitionEpistemeRef = the relevant comparison or method pattern, not the note itself.
6. nearby_false_description_or_wrong_definition_episteme = selection/publication doctrine treated as if the method note had already settled it.
7. first_admissible_entry_stop_or_reroute = method applicability is recognized or rejected before selection semantics begin.

A.6.RSIG:6 - Bias-Annotation

This pattern counters:

• front-door centralization bias, where every description-recognition question 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 defining U.Episteme;
• alias bias, where uncontrolled synonyms compensate for missing recognition structure;
• workflow bias, where first-contact recognition is narrated as sequence or handoff.

A.6.RSIG:7 - 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/definition-episteme split. A conforming description-recognition signature distinguishes description_seen, encountered carrier or projection, defining U.Episteme, 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 the conditions under which the recognition question calls for each relevant neighboring pattern in §4.4; use only the patterns that govern the current questions.
• CC-RSIG-4 No kind inflation. An ordinary recognition cue is not by itself a typed U.Signature; a task requiring a typed declaration uses the applicable neighboring pattern under §4.5.
• CC-RSIG-5 Recoverable cue shape. For load-bearing cases, description, viewpoint, cue, applicability, exclusion, defining U.Episteme, and admissible entry stop remain recoverable. A false neighbor is required only when the grounded-guard condition in §4.1 holds.
• CC-RSIG-6 No alias minting. Query cues and ordinary phrasing do not by themselves establish a naming settlement or Bridge. Use F.18 for naming settlement and F.9 for a Bridge, each under its own conditions.

A.6.RSIG:8 - 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 defining U.Episteme. Repair by naming the encountered carrier or projection and the defining U.Episteme separately.
• Boundary-routing collapse. A boundary-description cue tries to absorb L/A/D/E-classified claim structure. Repair by classifying the boundary claims under 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.

A.6.RSIG:9 - 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 or projection, and defining U.Episteme must not be collapsed; include the false neighbor when §4.1’s grounded-guard condition holds. The cost stays bounded because the expanded shape is review-only or risk-triggered, not a required card for ordinary prose.

A.6.RSIG:10 - Rationale

A.6.RSIG combines information-scent, human/AI expectation-management, controlled vocabulary, and retrieval-context practices into one description-facing discipline.

A.6.RSIG:11 - SoTA-Echoing

This pattern is an FPF-local synthesis, not an established external term. It carries the modern practice concern only where that concern sharpens one description-facing recognition question: can the reader recover the right description, its carrier or projection, its exclusions, its defining U.Episteme, and, when §4.1’s grounded-guard condition holds, its false neighbor before relation precision or epistemic precision-restoration work begins?

A.6.RSIG:12 - 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, C.16.Q
• Supports: E.11 as the pattern-language application above this neutral substrate

A.6.RSIG:End