<!doctype html>
<html lang="en">
<head><base href="about:srcdoc"><script>(function(){function n(){parent.postMessage({t:'share:hash',h:location.hash},'*')}addEventListener('hashchange',n);addEventListener('message',function(e){if(e.source!==parent)return;var d=e.data||{};if(d.t==='share:setHash'&&typeof d.h==='string'&&d.h!==location.hash){location.hash=d.h}});addEventListener('DOMContentLoaded',function(){parent.postMessage({t:'share:ready',h:location.hash},'*')});})();</script>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Adversarial review — BAFRA decisions vs IPPC Hub requirements</title>
<style>
:root{--bg:#f7f9fc;--paper:#fff;--ink:#122033;--muted:#536173;--line:#d9e1ea;--accent:#0b5cab;--soft:#eef5fc;--ok:#0f7a3a;--warn:#a45c00;--bad:#a8201a;--ok-bg:#eef7f2;--warn-bg:#fbf3e6;--bad-bg:#f7ebea}
*{box-sizing:border-box}
body{margin:0;background:linear-gradient(180deg,#f3f7fb,#eef4f9 35%,#f7f9fc);color:var(--ink);font:16px/1.55 "Segoe UI",Arial,sans-serif}
.wrap{max-width:1040px;margin:0 auto;padding:32px 24px 56px}
.hero,.card{background:var(--paper);border:1px solid var(--line);border-radius:18px;box-shadow:0 12px 36px rgba(18,32,51,.06)}
.hero{padding:28px 30px 22px;margin-bottom:18px}
.eyebrow{margin:0 0 8px;color:var(--accent);font:700 12px/1.2 Arial,sans-serif;letter-spacing:.12em;text-transform:uppercase}
h1,h2,h3{font-family:Georgia,"Times New Roman",serif}
h1{margin:0 0 12px;font-size:34px;line-height:1.1}
h2{margin:0 0 12px;font-size:22px}
h3{margin:18px 0 6px;font-size:16px;color:var(--accent);text-transform:uppercase;letter-spacing:.06em}
.lede{margin:0;color:var(--muted)}
.card{padding:22px 26px;margin-bottom:14px}
.grid{display:grid;grid-template-columns:120px 1fr;gap:14px 22px;font-size:15px}
.grid dt{color:var(--accent);font-weight:600;letter-spacing:.04em;text-transform:uppercase;font-size:12px;padding-top:3px}
.grid dd{margin:0}
.verdict{display:inline-block;padding:4px 10px;border-radius:999px;font-size:12px;font-weight:700;letter-spacing:.06em;text-transform:uppercase}
.verdict.drop{background:var(--bad-bg);color:var(--bad);border:1px solid #e2c2bf}
.verdict.skip{background:var(--warn-bg);color:var(--warn);border:1px solid #e6d2a8}
.verdict.keep{background:var(--ok-bg);color:var(--ok);border:1px solid #bfd9c9}
.verdict.bridge{background:var(--soft);color:var(--accent);border:1px solid #cfe0f1}
blockquote{margin:8px 0;padding:10px 14px;background:#fafbfd;border-left:3px solid var(--accent);font-size:14px;color:#2a3b52;border-radius:0 6px 6px 0;font-family:Georgia,serif;font-style:italic}
blockquote cite{display:block;margin-top:4px;font-style:normal;font-size:12px;color:var(--muted);font-family:"Segoe UI",Arial,sans-serif}
table{width:100%;border-collapse:collapse;margin:10px 0;font-size:14px}
th,td{padding:10px 12px;vertical-align:top;border-top:1px solid var(--line);text-align:left}
th{border-top:0;color:var(--accent);font-size:11px;letter-spacing:.08em;text-transform:uppercase;background:#fafbfd}
.summary{margin:14px 0;padding:14px 16px;border-radius:10px;background:var(--ok-bg);border:1px solid #bfd9c9;font-size:14px}
.summary.warn{background:var(--warn-bg);border-color:#e6d2a8}
.summary.bad{background:var(--bad-bg);border-color:#e2c2bf}
.summary strong{display:block;color:var(--ink);margin-bottom:4px}
a{color:var(--accent);text-decoration:none}
a:hover{text-decoration:underline}
.toc{display:flex;flex-wrap:wrap;gap:8px;margin-top:14px}
.toc a{padding:6px 12px;border-radius:999px;font-size:13px;border:1px solid var(--line);background:#fff;color:var(--accent)}
.toc a:hover{background:var(--soft);text-decoration:none}
details.appx{margin-top:24px}
details.appx summary{cursor:pointer;list-style:none;padding:12px 18px;background:#fff;border:1px solid var(--line);border-radius:14px;color:var(--accent);font-weight:600;font-size:14px;letter-spacing:.04em}
details.appx summary::-webkit-details-marker{display:none}
details.appx[open] summary{border-radius:14px 14px 0 0;border-bottom-color:#e3ebf3}
details.appx .appx-body{background:#fff;border:1px solid var(--line);border-top:0;border-radius:0 0 14px 14px;padding:18px 22px}
.appx-body table th{font-size:11px}
.appx-body code{font:13px/1.4 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;background:#f4f7fb;padding:1px 5px;border-radius:5px;color:#15314f;border:1px solid #e3ebf3}
@media(max-width:720px){.wrap{padding:18px 14px 40px}.hero,.card{border-radius:14px;padding:18px}.grid{grid-template-columns:1fr;gap:8px}}
</style>
</head>
<body>
<div class="wrap">
<section class="hero">
<p class="eyebrow">Bhutan • IPPC Hub integration • Adversarial review</p>
<h1>Decisions doc vs what the Hub actually requires</h1>
<p class="lede">
This review challenges every proposal in the original BAFRA decisions doc
under a strict minimum-changes rule: a form change is justified only if the Hub <em>rejects</em> the submission without it.
Every verdict is supported by a verbatim passage from ISPM 12 (2022), the ePhyto Mapping Guide v2.12, or the Hub Web Service API v1.20.
</p>
<p class="lede" style="margin-top:10px">
<strong>Companion document — short version for BAFRA:</strong>
<a href="https://share.eregistrations.dev/d/Uzrs3PqYe6">share.eregistrations.dev/d/Uzrs3PqYe6</a>
</p>
<div class="toc">
<a href="#headline">Headline finding</a>
<a href="#p1">P1 Split unit</a>
<a href="#p2">P2 Import permit</a>
<a href="#p3">P3 Coded declarations</a>
<a href="#p4">P4 Split treatment</a>
<a href="#p5">P5 Catalog mapping</a>
<a href="#p6">P6 Transit country</a>
<a href="#qa">Q-A signatory</a>
<a href="#qb">Q-B ports</a>
<a href="#missing">What the doc misses</a>
<a href="#final">Final minimum set</a>
</div>
</section>
<section class="card" id="headline">
<h2>Headline finding — the Hub does not check certificate content</h2>
<p>Every "the Hub needs X" claim must be tested against what the Hub actually does. The Hub API spec is unambiguous:</p>
<blockquote>
"The HUB will not perform the validation of the certificate content and its adherence to the ISPM 12 schema. The importing client application will be responsible for performing such validation."
<cite>Hub Web Service API v1.20, §5.1.2, p.11</cite>
</blockquote>
<p>The Hub only checks three things:</p>
<table>
<thead><tr><th>Layer</th><th>What the Hub checks</th><th>What it rejects on</th></tr></thead>
<tbody>
<tr><td>Transport</td><td>Mutual TLS, sender certificate identity</td><td>Connection refused on wrong certificate (§4.4)</td></tr>
<tr><td>Envelope</td><td>From and To countries must be standard two-letter codes; certificate type and status must be on the receiver's allowlist</td><td>"Invalid certificate type", "Invalid certificate status", or "no system connected for that country" (§5.1.1)</td></tr>
<tr><td>XML structure (only when the sender chooses the validating delivery method)</td><td>The XML matches the UN/CEFACT schema and includes a short list of structurally required fields</td><td>Blocks delivery on severe-level issues only (sample message: "Issue date is mandatory field", §6.8–§6.9)</td></tr>
</tbody>
</table>
<p>Strictness on country, port, commodity, treatment, package or transport codes is <strong>not</strong> a Hub concern. The receiving country's own software may complain, but the Hub itself will deliver. This single fact collapses most of the proposed form changes from "required" to "nice to have."</p>
</section>
<section class="card" id="p1">
<h2>P1 — Split "Unit" into "Unit of measure" and "Package type"</h2>
<dl class="grid">
<dt>Doc claim</dt>
<dd>"The Hub treats 'how much' and 'in what packaging' as two separate fields with different code lists."</dd>
<dt>What the rules actually say</dt>
<dd>
True that quantity and packaging are two distinct slots in the certificate. But the Mapping Guide provides an explicit free-text escape for packaging when no code fits:
<blockquote>
"one between the following Standard … and non-standard … definition of the packaging must be present"
<cite>Mapping Guide v2.12, packaging note</cite>
</blockquote>
And a generic "other quantity" pair exists for quantities that don't fit weight or volume.
</dd>
<dt>Verdict</dt>
<dd><span class="verdict bridge">Bridge handles</span> — no form change required</dd>
<dt>Minimum change</dt>
<dd>Keep the current single "Unit" dropdown. The bridge software routes recognised units (kg, m³) into the structured quantity slot and routes package-type entries (boxes, bags) into the free-text packaging note. The Hub accepts either form.</dd>
</dl>
</section>
<section class="card" id="p2">
<h2>P2 — Add "Import permit number" field</h2>
<dl class="grid">
<dt>Doc claim</dt>
<dd>"The Hub separately asks for the importing country's import permit number."</dd>
<dt>What the rules actually say</dt>
<dd>
The import-permit field is optional in both the Hub schema and the legal text. ISPM 12 (2022), section II:
<blockquote>
"In the case where an import permit is required by the importing country, the import permit number <strong>may</strong> be referred to here to assist cross-referencing."
<cite>ISPM 12, §II, p.16</cite>
</blockquote>
</dd>
<dt>Verdict</dt>
<dd><span class="verdict skip">Skip</span> — not required by Hub, not required by ISPM 12</dd>
<dt>Minimum change</dt>
<dd>Drop this proposal unless BAFRA confirms an operational need to record import permits today. The bridge can be extended later if it ever becomes a destination-country complaint.</dd>
</dl>
</section>
<section class="card" id="p3">
<h2>P3 — Replace the additional-declarations textbox with coded rows</h2>
<dl class="grid">
<dt>Doc claim</dt>
<dd>"The Hub needs one coded declaration per row, not one paragraph."</dd>
<dt>What the rules actually say</dt>
<dd>
False as stated. The additional-declarations slot in the certificate accepts free text up to 8,000 characters per entry. The IPPC publishes a list of recommended declaration wordings, but the Hub does not enforce it. Multiple declarations can be sent as multiple entries with no code list constraining the text. The IPPC's own legal text reinforces flexibility:
<blockquote>
"Additional declarations should be kept to a minimum and be concise."
<cite>ISPM 12, §II, p.16</cite>
</blockquote>
</dd>
<dt>Verdict</dt>
<dd><span class="verdict drop">Drop the form change</span> — the stated reason is incorrect</dd>
<dt>Minimum change</dt>
<dd>Keep the textbox. The bridge splits on line breaks and sends one declaration per non-empty line. If a destination country later asks for structured declarations, address it then.</dd>
</dl>
</section>
<section class="card" id="p4">
<h2>P4 — Split the treatment textbox into structured fields</h2>
<dl class="grid">
<dt>Doc claim</dt>
<dd>"The Hub wants each piece separately, with units."</dd>
<dt>What the rules actually say</dt>
<dd>
False with respect to the Hub. The Mapping Guide makes the full-treatment free-text entry <strong>mandatory whenever a treatment block exists</strong>. All the structured sub-fields (category, method, chemical, duration, temperature, concentration) are optional:
<blockquote>
"The full treatment should be here. Even when you specify the fields above you must complete the full treatment in order to allow to importing countries' systems that do not have the capacity to read structured treatments."
<cite>Mapping Guide v2.12, treatment block</cite>
</blockquote>
ISPM 12 does list six structured treatment sub-fields, but ISPM 12 content is not Hub-enforced (see Headline finding).
</dd>
<dt>Verdict</dt>
<dd><span class="verdict keep">Keep textbox</span> — current free text maps directly onto the mandatory full-treatment slot</dd>
<dt>Minimum change</dt>
<dd>No form change. When a treatment exists, the bridge sends the textbox content verbatim into the full-treatment slot, sets the treatment block's category to the Hub's required constant value, and uses the inspection date as the treatment date. If a destination country later asks for structured fields, the textbox can still be parsed retroactively.</dd>
</dl>
</section>
<section class="card" id="p5">
<h2>P5 — Match Bhutan catalogs with international code lists</h2>
<dl class="grid">
<dt>Doc claim</dt>
<dd>"The Hub only accepts these international codes. Without the attachment, every submission is rejected."</dd>
<dt>What the rules actually say</dt>
<dd>
Largely false. The Hub enforces code-list membership only at the envelope layer and only on two fields:
<ul>
<li>From and To country — must be the standard two-letter country code (rejected otherwise).</li>
<li>Certificate type and status — must appear on the receiving country's allowlist.</li>
</ul>
For units, packages, transport modes, commodities, intended use and point-of-entry codes the Hub does not check. Even the standard port-code for the destination point of entry is explicitly optional in the Mapping Guide. The receiving country's own software may complain, but the Hub will deliver.
<blockquote>
"The HUB will not perform the validation of the certificate content."
<cite>Hub API §5.1.2 (repeated for emphasis)</cite>
</blockquote>
</dd>
<dt>Verdict</dt>
<dd><span class="verdict skip">Narrow drastically</span> — the "every submission is rejected" claim is wrong</dd>
<dt>Minimum change</dt>
<dd>
Only one catalog actually has to be mapped:
<ol>
<li>Importing-country dropdown → standard two-letter country code (drives the envelope). Exporting country is always Bhutan, so no catalog work there.</li>
</ol>
Confirming the certificate type "export" and status "issued" are also fixed values the bridge sends — not catalog work. Defer mapping for commodities, units, packages, transport, intended use and exit points. Revisit only if a destination country complains.
</dd>
</dl>
</section>
<section class="card" id="p6">
<h2>P6 — Transit country field</h2>
<dl class="grid">
<dt>Doc claim</dt>
<dd>"Only needed if Bhutan exports through one or more transit countries that must appear on the certificate."</dd>
<dt>What the rules actually say</dt>
<dd>
The transit-country slot is optional and conditional. ISPM 12 only asks for it under specific circumstances:
<blockquote>
"Where a transit country and the importing country have specific phytosanitary requirements that include the need for a phytosanitary certificate for export, the names of both countries should be listed and the transit country should be indicated."
<cite>ISPM 12, §5, p.13</cite>
</blockquote>
</dd>
<dt>Verdict</dt>
<dd><span class="verdict skip">Skip</span> (matches the doc's own framing)</dd>
<dt>Minimum change</dt>
<dd>No change. Add later if a Bhutan trade lane through a regulated transit country emerges.</dd>
</dl>
</section>
<section class="card" id="qa">
<h2>Q-A — Inspector or OIC as signatory?</h2>
<p>A real BAFRA call. Either works, as long as the named person is "a public officer who is technically qualified and duly authorized by the NPPO" (ISPM 12 §4, p.12). The certificate carries exactly one signatory name.</p>
<p><strong>Recommendation:</strong> ask BAFRA who the legally authorised signatory is and use that. If both Inspector and OIC qualify, prefer OIC for institutional continuity (inspectors rotate; the office is more stable). Either choice is Hub-valid.</p>
</section>
<section class="card" id="qb">
<h2>Q-B — One port or two?</h2>
<p>The Mapping Guide lists the destination point of entry as required (exactly one) for the export certificate. It does not include an exit-port slot for the export certificate at all.</p>
<p>So sending only the destination is not just acceptable — it is what the export certificate schema expects.</p>
<p><strong>Verdict:</strong> <span class="verdict keep">Destination only is correct</span>. The doc's framing of this as an open question understates the certainty. Bhutan's "Exit point" field stays in the form for internal officer use but is not transmitted to the Hub.</p>
</section>
<section class="card" id="missing">
<h2>What the BAFRA doc misses</h2>
<p>None of the items below need form changes. They are bridge-side responsibilities the team should be aware of.</p>
<table>
<thead><tr><th>Item</th><th>Source</th><th>Implication</th></tr></thead>
<tbody>
<tr>
<td>Issue date is mandatory</td>
<td>Hub API §6.8 sample severe error: "Issue date is mandatory field"</td>
<td>The bridge must always emit the certificate's issue date, or the Hub rejects on the validating delivery method.</td>
</tr>
<tr>
<td>Treatment category must use the Hub's required constant value</td>
<td>Mapping Guide v2.8 changelog</td>
<td>The only Hub-specific validation rule on the treatment block. The bridge always sets this constant; no form input.</td>
</tr>
<tr>
<td>Full-treatment free text is required</td>
<td>Mapping Guide, treatment block: marked one-and-only-one</td>
<td>Mandatory whenever any treatment is present. Bhutan's existing treatment textbox content maps here directly — another argument against P4.</td>
</tr>
<tr>
<td>Certificate type and status are constants</td>
<td>Mapping Guide, document level + Hub envelope check</td>
<td>The bridge always sends "export PC" as the type and "issued" as the status. No form change.</td>
</tr>
<tr>
<td>Certifying statement is required</td>
<td>Mapping Guide, document level (one or more)</td>
<td>The bridge always sends the official certifying-statement code for export certificates. The optional "practically free from other pests" clause is added only if BAFRA opts in.</td>
</tr>
<tr>
<td>Every commodity row needs a description</td>
<td>Mapping Guide note: "mandatory as per UN/CEFACT schema"</td>
<td>Verify the commodity grid in Bhutan's form requires a description per row. Quick check, not a form change.</td>
</tr>
<tr>
<td>Botanical (scientific) name expected per commodity</td>
<td>ISPM 12 p.15 requires "at least genus level"; Hub does not enforce; receiving NPPOs do</td>
<td>Verify the form has a botanical-name field per commodity row. "N/A" is allowed by ISPM 12 for complex articles.</td>
</tr>
<tr>
<td>Authenticated electronic certificate replaces signature and seal</td>
<td>ISPM 12 p.17</td>
<td>No form change. The authenticated electronic certificate is legally equivalent to a wet signature plus official seal.</td>
</tr>
</tbody>
</table>
</section>
<section class="card" id="final">
<h2>Final minimum-change set</h2>
<div class="summary">
<strong>Form change BAFRA must make (1 item):</strong>
Attach the standard two-letter international code to each entry of the existing "Importing country" dropdown. No new fields, no widget redesigns. This is the only field whose value the Hub envelope refuses to accept in any other form.
</div>
<div class="summary warn">
<strong>Form changes BAFRA should defer (5 items):</strong>
Splitting the unit dropdown, adding an import-permit field, replacing the additional-declarations textbox, splitting the treatment textbox, bulk catalog mapping, and a transit-country field. None of these are Hub-required. Each can be added later in response to a concrete destination-country complaint, with bridge-side handling in the meantime.
</div>
<div class="summary">
<strong>Bridge-side work (no form impact):</strong>
<ul>
<li>Always send issue date, certificate type "export", certificate status "issued", and the official certifying-statement code.</li>
<li>When a treatment is present, send the textbox content as the full-treatment free text, the inspection date as the treatment date, and the Hub's required constant for the treatment category.</li>
<li>Split the additional-declarations textbox by line breaks and send one declaration per line.</li>
<li>Route the "Unit" dropdown value to the right slot in the certificate (quantity vs packaging note).</li>
<li>Translate the chosen "Importing country" value into the standard two-letter code used by the envelope.</li>
</ul>
</div>
<div class="summary bad">
<strong>One BAFRA decision still needed:</strong> Q-A signatory (Inspector vs OIC). Q-B is settled by the Mapping Guide — destination only.
</div>
<p style="margin-top:18px;color:var(--muted);font-size:14px">
<strong>Sources cited above:</strong>
ISPM 12 (2022), CPM-16 adoption — <a href="https://assets.ippc.int/static/media/files/publication/en/2022/05/ISPM_12_2022_En_PCs_2022-04-21_PostCPM-16.pdf">PDF</a>.
ePhyto Mapping Guide v2.12, 14 May 2025 — <a href="https://www.ephytoexchange.org/doc/mapping/Mapping_ISPM_12_to_ePhyto_standard_Export_certificate_V.2.pdf">PDF</a>.
Hub Web Service API v1.20, 12 Jan 2024 — <a href="https://www.ephytoexchange.org/doc/HUB_Web_Service_API_EN.pdf">PDF</a>.
</p>
</section>
<details class="appx">
<summary>Technical appendix — for whoever writes the bridge code</summary>
<div class="appx-body">
<p>Plain-English items above mapped to the actual XML elements and constants. This is the only section in the document where machine identifiers appear.</p>
<table>
<thead><tr><th>Plain English (in main doc)</th><th>XML element / constant</th><th>Cardinality</th></tr></thead>
<tbody>
<tr><td>Certificate type "export"</td><td><code>SPSExchangedDocument.TypeCode = 851</code></td><td>1..1</td></tr>
<tr><td>Certificate status "issued"</td><td><code>StatusCode = 70</code></td><td>1..1</td></tr>
<tr><td>Issue date</td><td><code>IssueDateTime.DateTimeString</code></td><td>1..1, severe-reject if missing</td></tr>
<tr><td>Certifying statement (mandatory + optional clause)</td><td><code>IncludedSPSClause</code>, codes <code>1</code> and <code>2</code></td><td>1..n; code 1 mandatory, code 2 optional</td></tr>
<tr><td>From / To country (envelope)</td><td>ISO 3166-1 alpha-2 in envelope <code>From</code> / <code>To</code></td><td>strictly enforced</td></tr>
<tr><td>Importing country (in certificate body)</td><td><code>ImportSPSCountry.ID</code></td><td>1..1, ISO-2</td></tr>
<tr><td>Exporting country</td><td><code>ExportSPSCountry.ID</code> = <code>BT</code></td><td>1..1</td></tr>
<tr><td>Destination point of entry</td><td><code>UnloadingBaseportSPSLocation.Name</code> (1..1); <code>.ID</code> UN/LOCODE optional</td><td>1..1 / 0..1</td></tr>
<tr><td>Exit port</td><td>Not in the export PC mapping</td><td>do not send</td></tr>
<tr><td>Transit country</td><td><code>TransitSPSCountry</code></td><td>0..n</td></tr>
<tr><td>Quantity (weight / volume)</td><td><code>NetWeightMeasure</code> / <code>NetVolumeMeasure</code>; or generic <code>OQV</code>/<code>OQU</code> pair</td><td>0..1 each</td></tr>
<tr><td>Packaging (structured)</td><td><code>PhysicalSPSPackage</code> with <code>LevelCode</code>, <code>TypeCode</code>, <code>ItemQuantity</code></td><td>0..n</td></tr>
<tr><td>Packaging (free-text alternative)</td><td><code>AdditionalInformationSPSNote</code> with <code>Subject=OPTND</code></td><td>0..1</td></tr>
<tr><td>Additional declaration (free text, per line)</td><td><code>IncludedSPSNote</code> with <code>Subject=ADEDL</code>, <code>Content</code> text up to 8000 chars</td><td>0..n</td></tr>
<tr><td>Import permit (if ever needed)</td><td><code>IncludedSPSNote</code> with <code>Subject=ADIPEDL</code> (doc level) or <code>ADIPTLIL</code> (trade-line)</td><td>0..n / 0..1</td></tr>
<tr><td>Treatment block</td><td><code>AppliedSPSProcess</code></td><td>0..n</td></tr>
<tr><td>Treatment category (Hub-required constant)</td><td><code>AppliedSPSProcess.TypeCode = ZZZ</code></td><td>1..1 when treatment present</td></tr>
<tr><td>Treatment date(s)</td><td><code>CompletionSPSPeriod.StartDateTime</code> / <code>EndDateTime</code></td><td>0..1 each</td></tr>
<tr><td>Treatment full-text (mandatory whenever treatment present)</td><td><code>TTFT</code> note, text up to 8000 chars</td><td>1..1 in treatment block</td></tr>
<tr><td>Treatment structured sub-fields (optional)</td><td><code>TTL1</code>, <code>TTL2</code>, <code>TTCH</code>, <code>TTTM</code>, <code>TTCO</code>, <code>DurationMeasure</code>, <code>TTAI</code></td><td>0..1 / 0..n</td></tr>
<tr><td>Commodity description (per row)</td><td><code>IncludedSPSTradeLineItem.Description</code></td><td>1..n — UN/CEFACT schema mandatory</td></tr>
<tr><td>Botanical (scientific) name</td><td><code>ScientificName</code></td><td>0..1 in schema; ISPM 12 expects it</td></tr>
<tr><td>Origin country</td><td><code>OriginSPSCountry.ID</code></td><td>1..n, ISO-2</td></tr>
<tr><td>Signatory</td><td><code>SignatorySPSAuthentication.ProviderSPSParty.SpecifiedSPSPerson.Name</code></td><td>1..1</td></tr>
<tr><td>Place of issue</td><td><code>IssueSPSLocation.Name</code></td><td>1..1</td></tr>
</tbody>
</table>
<p>Hub validator rejects on "severe" level via <code>ValidateAndDeliverEnvelope</code> or <code>DeliverPhytoEnvelope</code>. Plain <code>DeliverEnvelope</code> skips schema validation entirely.</p>
</div>
</details>
<!-- ai-data
service_id: ca6a7213-4113-4033-91ab-b9e4f650cf1f
registration_id: 5c170e35-0b8c-4a9e-88cb-a8c7ba9c5521
gdb_export_bot_id: 287cbbd3-3744-4f6f-ab5a-1eaf1b4fa0c4
reviewed_doc: ephyto-decisions-for-bafra.html (deployed at https://share.eregistrations.dev/d/wKSO4hRjch)
sources:
- /Users/unctad/Claude/9 - System/tmp/ispm12-2022.pdf
- /Users/unctad/Claude/9 - System/tmp/mapping-guide-v2.pdf
- /Users/unctad/Claude/9 - System/tmp/hub-api.pdf
review_date: 2026-05-22
review_lens: minimum-changes-to-pass-Hub
style_rule: plain-language-only in main prose; XML element names only in the Technical Appendix
-->
</div>
</body>
</html>