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.