/**
 * @copyright Sister Software
 * @license AGPL-3.0
 * @author Teffen Ellis, et al.
 *
 *   `trailing-region` — the `«locality», «region», «country»` admin tail, the Portopetro class
 *   (board row `es-op3-southeast-portopetro`): `…, 07691 Portopetro, Illes Balears, Spain` parsed
 *   with the REGION mislabeled `locality` and the true locality dropped entirely. Spanish sources
 *   are postcode-complete and rarely write the region, so the trailing-region segment is
 *   under-attested and the model reads the last populous name as the locality.
 *
 *   Tuples are real `(locality, region)` ancestor pairs from the WOF admin DB (the fr-hood-pairs
 *   extraction shape). Two surface forms per pair — with and without the trailing country — so the
 *   region is attested both as the middle and the final segment. A bare `«region»` form is
 *   deliberately absent: that surface is the bare-toponym class with its own rules, and teaching it
 *   here as `region` would fight the locality/region ambiguity the dominance race arbitrates.
 *
 *   The recipe is country-agnostic; the country tail surface comes from the tuple's `country`
 *   field ("Spain", "United Kingdom") so one recipe serves every extraction.
 *
 *   POSTCODE-PREFIXED FORMS (2026-08-20, #1748). The two bare forms above were the whole slice, and the
 *   board row this recipe was written for is NOT bare — it reads `…, 07691 Portopetro, Illes Balears,
 *   Spain`. Measured over both built slices: 88,904 rows, zero containing a postcode. So the model
 *   learned the bare tail correctly and had never once seen the shape it was failing on, which is why no
 *   decode change moved it.
 *
 *   The collapse is two-staged and neither trigger is a street, which is what makes this cheap to teach:
 *
 *       Portopetro, Illes Balears, Spain             locality ✓  region ✓
 *       07691 Portopetro, Illes Balears, Spain       locality ✓  region DISCARDED
 *       15, 07691 Portopetro, Illes Balears, Spain   locality DISPLACED by the region
 *
 *   A postcode alone drops the region (every locale measured); a house number then displaces the
 *   locality. So the added surfaces are postcode-prefixed and house-number-plus-postcode-prefixed, and
 *   the slice still needs no street names.
 *
 *   POSTCODE PLACEMENT. The three surfaces above are the LEADING form, and for a long time they were the
 *   only one, so this slice taught only the countries that write the postcode first. That is a real gap
 *   and not a stylistic one, because the same digits change TAG with position. Measured on the shipped
 *   model: `Barcelona 6001, Anzoátegui, Venezuela` tags `6001` as `house_number` and loses the locality
 *   into the street, while `6001 Barcelona, Anzoátegui, Venezuela` tags it `postcode` and recovers
 *   `locality: Barcelona`. `Sandton 2196` vs `2196 Sandton` behaves the same way, and no decode-time
 *   change moves it — `postcodeShapeCoherence: true` leaves all eight VE board rows byte-identical.
 *
 *   So the tuple's `postcodePlacement` selects the surface, and it keeps apart two trailing conventions
 *   that are NOT the same shape: VE writes `Barcelona 6001, Anzoátegui, Venezuela` (the code on the
 *   LOCALITY segment) and IN writes `…, Bengaluru, Karnataka 560038, India` (on the REGION segment).
 *   Each of the three placements matches a board row verbatim. A tuple with no placement means `leading`,
 *   so a tuples file written before the field existed produces the rows it always did.
 *
 *   LEFT CONTEXT (v25). A tuple may carry a `dependentLocality`, and when it does the surface becomes
 *   `«dep_locality», «locality»…`. This is not decoration: without it EVERY row in the slice begins with
 *   the locality, and at a 9.4% share that taught the model the first named segment is the locality.
 *   Measured on the v4.8.0 candidate — `Ye Three Lords, 27 Minories, London EC3N 1DE` came back
 *   `locality: "Ye Three Lords"` with venue and street both gone, `Le Colimaçon, 44 Rue Vieille du
 *   Temple, 75004 Paris` came back `locality: "Le Colimaçon"`, and 11 of 25 regressions were venue-led
 *   rows across seven countries. The house-number prefix does NOT supply this: a number before the
 *   locality does not teach that a NAME can precede one. `no-fragment.ts`'s header records the same
 *   trap from the other direction.
 *
 *   The (postcode, locality, region) triples are REAL — `postalcode-intl.db` parents joined to admin
 *   localities and their region ancestors — with one filter that had to be measured rather than assumed.
 *   A handful of localities act as catch-all parents: `Schwedt/Oder` claims 9,222 postcodes, `Korb`
 *   4,846, against a p50 of 1 and a p99 of 53. Eight such hubs held 47% of the join. Capping at the p99
 *   drops them and keeps 17,908 triples. The house number is synthetic because a house number asserts no
 *   fact about a place; the postcode is not, because it does.
 */
import { type CorpusRecipe } from "#recipes/scaffold";
/**
 * Slice recipe registered with the corpus builder — see the file header for the parse behaviour it exists to exercise,
 * and `description` below for the surface form it generates.
 */
export declare const trailingRegionRecipe: CorpusRecipe;
//# sourceMappingURL=trailing-region.d.ts.map