<?xml version="1.0" encoding="UTF-8"?>
<!--
  What is submitted, and why every indexable page that is missing is missing.

  A sitemap is a hint. Omission does not block indexing and inclusion does not
  force it, so the only thing this file can get wrong is contradicting a
  stronger signal somewhere else. The four entries below are the pages that are
  self-canonical and `index, follow`.

  HOW lastmod IS COMPUTED, and the mistake this file made first.

  The dates it carried originally were 2026-08-02 on all three entries, which
  stopped being true when #19 replaced the homepage. The first fix replaced them
  with the newest commit date anywhere in each page's import closure, which gave
  all four 2026-10-03. Honey's objection, 2026-10-03: that is correct today and
  uninformative forever. Measured rather than argued, and she was right. /about
  took its date from SiteFooter.tsx, which sits in all four closures, so one
  footer commit moved all four dates at once. Google discounts lastmod when it
  is unreliable, and always-current is the specific pattern it treats that way,
  sitemap-wide rather than per-entry. Swapping dates that were wrong for dates
  that cannot be wrong is not an improvement.

  So the closure is computed per page and then any file that appears in EVERY
  entry's closure is dropped before taking the newest date. Those files are the
  global chrome, today Navigation.tsx, SiteFooter.tsx and the theme toggler, and
  a commit touching one of them says nothing about any single page. A component
  shared by only some entries is kept, because a change there genuinely is a
  change to those pages and moving exactly their dates is the informative
  answer: DemoVideoSection.tsx and WorkRequestSection.tsx are why / and
  /product both read 2026-10-03 and /about does not.

  Do not hand-type these dates. `npm run sitemap-lastmod` computes them and
  prints the files that set each one, and scripts/sitemap-lastmod.mjs carries
  the rule and the reason. Its ENTRIES list must stay in step with the <url>
  list below, because dropping a file needs to know what "in every closure"
  means and that changes when an entry is added or removed.

  That script also pins the three excluded files and reports a mismatch,
  because the exclusion set is derived from this membership list and can change
  without any page's content changing, which would move every date at once.
  Honey's refinement, 2026-10-03. Adding /baseline as a fifth entry was
  simulated and the set does not shrink, so the fee decision does not disturb
  these dates. The case the pin is actually for is a page that stops importing
  the chrome, which /brand did until #24.

  The cost of this definition, stated so nobody has to rediscover it: a real
  content change confined to the chrome moves no date at all. #23 corrected the
  legal entity in the footer, which is visible on all four pages, and none of
  these dates record it. That is the trade, and it is the right way round. A
  date that moves only when a page's own content moves can still be checked and
  found wrong, which is the whole reason to carry the field.

  changefreq and priority were here and are gone. Google documents both as
  ignored, so neither can be checked and found wrong, and `changefreq: weekly`
  on / was a claim that would be false most weeks. By the standard applied to
  lastmod they do not earn a line. Honey's call, 2026-10-03.

  /product was indexable, self-canonical and linked from the homepage, and was
  not submitted. Added in #38. /brand was the entry doing real work in this
  file: it had no inbound link from any indexable page, so this was its only
  discovery path. It now has a footer link, which is the fix for the anomaly
  rather than for the sitemap, because a page we submit should also be reachable
  by following links.

  Deliberately absent, so none of these reads as an oversight:

    /baseline  Indexable and two hops deep, / -> /product -> /baseline. It
               carries the published fee and its sitemap entry resolves with
               Haydo's decision either way: fee removed, add it; fee kept and
               noindexed, it must stay out, because a noindexed URL inside a
               sitemap is a contradictory signal and Search Console reports it
               as one. Honey raised the omission, 2026-10-03.
    /v3        Indexable but canonical to /, so submitting it would nominate a
               URL we have already said is not the one to index.
    /v1, /v2   noindex at the edge and in the component. A sitemap entry would
               contradict both.
    /eoi/*     Disallowed in robots.txt and noindex. Commercial in confidence.
    /hanking*  Same, and the URL itself carries the signing code.
    404s       The catch-all returns 200 for any invented URL and noindexes it.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://fieldspark.co/</loc>
    <lastmod>2026-10-03</lastmod>
  </url>
  <url>
    <loc>https://fieldspark.co/product</loc>
    <lastmod>2026-10-03</lastmod>
  </url>
  <url>
    <loc>https://fieldspark.co/about</loc>
    <lastmod>2026-08-22</lastmod>
  </url>
  <url>
    <loc>https://fieldspark.co/brand</loc>
    <lastmod>2026-10-03</lastmod>
  </url>
</urlset>
