DEV Community: Kiter

I shipped an agent that asks Sanity Context what it is allowed to say

Kiter — Sat, 03 Oct 2026 18:25:04 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

The agent's MCP endpoint: https://api.sanity.io/v1/context/organizations/ovihgdwkx/mcp/ninety
Live app: https://ninety-europe.vercel.app
Context evidence page: https://ninety-europe.vercel.app/context
Code: https://github.com/PhiBao/ninety
Sanity project: jvgi63fz · dataset production · Studio: https://beyond-vibe.sanity.studio

The rule the whole agent is built around

Most travel assistants will confidently tell you how many days you have left. They will also be wrong sometimes, and you cannot tell which times.

So the agent in this submission is architecturally forbidden from stating a number.

// The engine. No model, no network, no env vars.
evaluate(snapshot, itinerary, {asOf})
// → {used: 73, attribution: {date: '2026-10-26', blame: [...]}, unresolvedDays: [...]}

The model may retrieve, classify, explain and cite. Every figure it reports comes from that engine. The split is not stylistic — it is the reason I did not use a language model at all.

What the agent actually is

Type "three weeks on Tenerife, then an 8 hour airport layover where I never cleared immigration" and it works out what that is, then what it costs.

It resolves to three separate reads: Bulgaria by train — 10 days counted, from the date-banded rule that opened its land crossings on 31 December 2024. An airport transit with no place named — no days counted, at 100%. And in between, a leg it is only about 50% sure about, so it refuses that one.

That last behaviour is the whole point. In the middle of that sentence, "flew to Paris 20 to 25 February" is a fragment, and the agent says so rather than guessing. A chat completion would have answered it fluently and been indistinguishable from a correct answer.

The pipeline

traveller's words
     │
     ├─ date extraction            deterministic, in code, unit-tested
     │
     ├─ Sanity Context (MCP)  ──▶  the candidate set. Retrieved, never invented.
     │                              groq_query over territory + presenceRule
     │
     ├─ TypeSafe System One   ──▶  typed classification + calibrated confidence
     │                              {choice, probabilities, confidence}
     │
     └─ the engine            ──▶  every number in the answer

Three properties fall out of that, and each one was bought by a bug I hit while building it:

1. It cannot invent a place. The territory list is retrieved from the corpus at request time. If a place is not there, there is no option to select, so the output is "No place named". Not a guess at the nearest match — the set does not contain one.

2. It cannot do arithmetic. Classification goes through TypeSafe's System One models, which return a value from a set I defined plus the full probability distribution. They are not text generators; there is no channel through which 90 could travel. The whole web app has five runtime dependencies and no model-provider SDK at all.

3. It can say it does not know. Below 0.62 confidence the read is reported as uncertain rather than answered.

One consequence worth stating, because it is a bug I shipped and then caught: the classifier also answers "would this person be present somewhere that counts against the allowance?", and it does not know that Bulgaria's land crossings were internal in February 2025. So it says no for Sofia-by-train. The engine, which does know, charges ten days. Rather than show two contradicting labels, the "N days counted" figure is read back out of the ledger the engine actually produced — the classifier never gets to have an opinion about charging.

Sanity Context as the retrieval layer

The agent's knowledge is a hosted, read-only MCP endpoint. Not a hardcoded prompt, not a vector index built at deploy time — a Sanity-managed endpoint that serves the dataset's schema and answers GROQ on the wire.

Tool	What the agent uses it for
`initial_context`	Schema overview: types, fields, relationships, document counts
`groq_query`	Structured retrieval with projections — the candidate set, every request
`schema_explorer`	Field-level detail when the overview is not enough
`array_field_reader`	Reading `accessBands[]` and `competingClaims[]` without pulling whole documents into context

This is live, not a description

The /context page calls the endpoint server-side and prints what came back, including its failure modes. Everything on it was fetched when you loaded the page.

Reproduce it:

curl -s https://api.sanity.io/v1/context/organizations/ovihgdwkx/mcp/ninety \
  -H "Authorization: Bearer $SANITY_CONTEXT_TOKEN" \
  -H 'Accept: application/json, text/event-stream' \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

And a live groq_query through Context, asking about the fact that makes the same fortnight cost fourteen days in Split in 2023 and nothing in 2022:

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"groq_query","arguments":{"query":
   "*[_type==\"territory\"&&code==\"HR\"][0]{name,\"bands\":accessBands[]{window{from,to},counted,modes}}"}}}

{"name":"Croatia","bands":[
  {"counted":false,"window":{"from":"2000-01-01","to":"2023-01-01"}},
  {"counted":true, "window":{"from":"2023-01-01","to":null}}]}

That is the product thesis in one payload. A keyword index returns the paragraph about Croatia joining in 2023. This returns the bands, which is what you need in order to answer a question about a specific day.

Why the dataset has to be shaped this way

An agent's answer quality is bounded by the structure it can query. Four decisions do the work.

Membership is a date-banded array, not a boolean. isSchengen: true is a lie for any country that joined later, and it is the reason most assistants get Croatia and Bulgaria wrong. accessBands[] with {from, to, counted, modes} makes "was this in the area on this day, and by which route" answerable at all.

Carve-outs are territories. The Canary Islands, Madeira, Åland, Svalbard, the French overseas departments, Ireland, Cyprus and Iceland are each their own territory document with their own bands. The agent can therefore say where a day was spent, which is also what makes attribution possible.

Ambiguity is a value, not an exception. A presenceRule can be counted, not_counted, or disputed. When it is disputed the engine refuses to classify a day of that kind, and the agent is required to present both readings and name the disagreement. It cannot resolve it, because there is nothing in the corpus to resolve it with.

Every rule resolves to a source. Each band, presence rule and regime carries sourceRef[] to a real document with a publisher, a URL and a retrieval date. The agent's citations are checkable rather than plausible — and so is the absence of one, which is what tells the agent to stop.

Does the structured content actually earn its keep?

The challenge's own test: if a keyword search would have gotten you the same answer, aim higher. So I measured it.

Two systems, the same corpus, 23 adversarial histories with hand-computed expectations written before the runner existed, so the runner cannot grade itself. Neither arm uses a language model — the point is to isolate the contribution of the content structure, and this way anyone can rerun it with pnpm eval.

Measure	Structured (GROQ + engine)	Keyword search (BM25, same rules)
Correct answer	23/23	1/23
Produced a day count	21/23	0/23
Named the exact breach date	1/1	0/1
Refused instead of guessing	2/2	n/a

Full results with the reasoning for each case: web/eval/RESULTS.md

The keyword arm is not handicapped. It is given the same territory records, the same presence rules, the same permit exemptions and the same precedents, flattened into prose, and it scores BM25 over them. It frequently retrieves the right paragraph.

It cannot produce a verdict, and the reason is worth stating plainly:

The corpus holds the rules, and never held the traveller.

"I have eleven trips logged this year and one booked — am I still legal?" is not a retrieval problem. It is a join between the rule and eleven date ranges, two of which fall in carve-outs, one of which nobody has ruled on, evaluated day by day across a rolling window. Retrieval finds the paragraphs. It cannot join them to a calendar.

Knowledge Bases

Being straight about this one: Ninety does not use a Sanity Knowledge Base, and the rubric asks for one.

What it uses is the dataset served through Context, which covers the structured half of the problem — the rules — but not the prose half. The EU guidance documents the corpus cites are currently referenced as sources, not ingested as searchable text. So an agent question like "why is a same-day transit not a stay?" can be answered from the structured rule and its citation, but cannot yet quote the underlying paragraph.

Ingesting those documents as a Knowledge Base is the next step, and it is the step that would let the agent say "the border-crossing page says X, the visa-policy page says Y, and that is why the day is disputed" instead of citing two titles and stopping. I would rather name the gap than imply it is closed.

Code

https://github.com/PhiBao/ninety

infra/sanity.blueprint.ts        infrastructure: CORS origin + the guard function
infra/functions/                 a Sanity Function that enforces the invariant
web/src/lib/agent/describe.ts    free text → dated stays, deterministically
web/src/lib/agent/typesafe.ts    typed client for the System One primitives
web/src/lib/agent/resolve.ts     retrieve candidates, classify, hand off
web/src/lib/sanity/context.ts    JSON-RPC client for the Context MCP endpoint
web/src/app/context/page.tsx     the evidence page, rendered server-side
web/src/lib/engine/              pure TypeScript. No model, no network.
web/scripts/eval/                the 23-case evaluation

A note on why context.ts speaks raw JSON-RPC instead of going through an agent SDK: the diagnostics should show what an agent actually receives on the wire, not what a library chooses to show it. Every function degrades to a typed unavailable result instead of throwing, so the evidence page reports a missing credential plainly rather than pretending the integration exists.

There are 56 unit tests. The ones that matter most here are about the free-text layer, because that is where the model is closest to the answer:

that "1 to 21 February 2026" is one stay and not two
that "30 to 31 February 2026" is rejected rather than rolled into March
that "flew to Paris" and "took the train into Sofia" in the same sentence each get their own place, their own mode, and their own classification
that "never cleared immigration" is an airside transit, not a cleared one — the one distinction that decides whether the day is charged

What I got wrong, since it is relevant here

Context did not work until the Studio was deployed. For most of this build the endpoint answered Only datasets with deployed Studio applications are supported. It was never an authorisation problem in the end — I had assumed that, and burned time on it. Deploying the Studio fixed it in one command.

Asking N questions about an array of N stays does not bind question i to stay i. I batched all the classifications into one request to save latency. The state was an array of stays and each question said "this description", so an 8-hour airport layover in the second stay got classified as the Canary Islands because the first stay mentioned Tenerife. One request per stay now. Cheaper in latency than it sounds, because each request is small.

\s in a template literal collapses to s. My date-stripping regexes compiled into "match a literal s" and silently removed nothing, so the classifier was being handed "layover on 3 June 2026" with the date still in it. A regex that silently matches nothing is worse than one that throws.

Two evaluation cases were passing for the wrong reason. I had written a territory code as es-canary, which is a document key; the code is XCI. The engine's response to an unknown territory is a warning and zero charged days — so the case passed because the Canary days had been dropped rather than classified. The number was right and the reasoning was nonsense. pnpm check:codes now fails the build if any case contains a dropped stay.

A Sanity Function that guards the invariant failed in three ways that all looked like success. The agent's correctness rests on a ruling being recorded as a precedent, so I added a document function to enforce that wherever the dispute is adjudicated — including in the Studio, bypassing the app. It wrote the precedent fine, then:

client.patch() is lazy in @sanity/client v8. The handler awaited it, logged "attached precedent to dispute", and changed nothing.
A transaction id derived from the document id looks like idempotency. Sanity remembers transaction ids permanently, so the second adjudication returned transactionAlreadyExistsError and the function failed forever after, silently.
The guard read a denormalised presenceKind that the document does not have, so it declined to act on a dispute whose subjectKind was plainly presence_kind. It now resolves the kind through the reference.

That third one generalises. A guard that refuses because it looked in the wrong place is worse than no guard: it turns a loud failure into a quiet one. Every check in this repo looks at what the system did, not at whether it reported success.

I had Iceland in the Schengen Area. It is EEA, not Schengen, and my corpus said otherwise because I had used a shared helper that stamped the founding date onto every state. Reykjavík days were being charged against 90/180 — a mistake a lot of tools make, made silently, in the one file I was treating as ground truth.

Not legal advice. It covers a handful of passport classes and refuses outside that coverage, which is the only behaviour that makes it safe to trust. 🤖

Ninety: I vibe-coded a Schengen day accountant that admits when it doesn't know

Kiter — Sat, 03 Oct 2026 16:05:56 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

Live: https://ninety-europe.vercel.app
Code: https://github.com/PhiBao/ninety
Sanity project: jvgi63fz · dataset production · Studio: https://beyond-vibe.sanity.studio

What I Built

Ninety knows the exact day you went over.

Every Schengen short-stay calculator tells you how many days you have used. None of them tell you which day you crossed the line, why that day counted, or what to change. Ninety does all three.

It is a day accountant for the 90-in-any-180 rule. You give it your trips; it resolves the rules that apply on each individual day, counts a rolling window, and tells you:

73 of 90 days used — and 17 remain
On 26 October the window reaches 91 days. It is Barcelona — booked that puts you over.
Leave on the 26th, not the 27th. Two days off the end of that trip fixes it.

Then it shows its work: every calendar day as a mark on a strip, colour-coded by whether it was charged, and clicking any day gives you the rule that decided it and the authority behind it.

The three things it does that a calculator cannot

1. It names the day, not just the number.

Attribution is a real algorithm, not a caption. On the breach day the engine finds the rolling window, works out which days pushed the count past the limit, and maps them back to the trips that contained them.

2. It classifies instead of adding.

Days are not all alike, and this is where people actually get hurt:

Three weeks in the Canary Islands — Spanish territory, outside the area. 0 days.
A month in Dublin — an EU member that opted out of the acquis. 0 days.
A week in Reykjavík — Iceland is in the EEA, which is not the Schengen Area. 0 days.
An airside airport transit — never crossed a border. 0 days.
The same flight into Sofia by air in February 2025 — 0 days — but overland the same week: 10 days. Bulgaria opened its land and sea crossings on 31 December 2024 and kept air borders external until 31 March 2025.
A pending residence application — not a permit. 31 days, exactly as if you had nothing.

3. It refuses, and it says so.

Give it a passport it has never heard of and it does not guess:

Ninety declined to answer
Passport ZZ is not covered by this dataset, so Ninety will not guess.

That is the only behaviour that makes it safe to trust at all. A confident wrong number here costs someone money.

And then there is the desk

When the sources genuinely conflict, Ninety refuses to classify the day and reports a range. This one is real: does a layover that clears border control count as a day in the area? The border-crossing guidance says admission at a border is entry into the territory. The visa policy is framed around staying, and a same-day transit is not a stay.

The second demo sits at exactly 90 of 90 with a landed transit booked for three days' time. Ninety will not pick a side, so the answer is a range and the headline stays honest.

A person can then rule. That ruling is written as precedent — typed, dated, attributed, and scoped to that presence kind from the date of the ruling — and every later calculation reads it. Rule it "counts" and the demo flips from inside the limit to crosses the limit on 6 October, because at 90 of 90 a single charged day is the whole question.

Here it is flipping on camera — inside the limit becomes crosses the limit on 6 October the moment a person rules that the day counts:

The whole run, 48 seconds:

https://raw.githubusercontent.com/PhiBao/ninety/main/docs/ninety-demo.mp4

It is a scripted recording against the deployed app, and the dataset is reset afterwards, so you will find the desk open.

And then there is the agent

Counting your own dates is easy. Deciding whether an airport transit counts is not — which is exactly the judgement the structured form was asking people to make before it would help them. So you can also just write it down:

Took the train into Sofia 1 to 11 February 2025, then flew to Paris 20 to 25 February 2025, then an 8 hour airport layover on 3 June 2026 where I never cleared immigration.

and the agent resolves it against the corpus, shows its confidence, and refuses the leg it is not sure about.

Three rules, and the third is the one that matters:

It can only choose from a set it retrieved. The territory list comes from groq_query against Sanity Context. If a place is not in the corpus there is no option to select, and the output is "No place named" — which is what the layover in that example gets.
It cannot do arithmetic. Classification goes through TypeSafe's System One models, which return {choice, probabilities, confidence} — a value from a set I defined, plus how sure it is. There is no channel through which a day count could travel.
It says when it does not know. Below 0.62 confidence the leg is marked uncertain rather than answered. In the screenshot above, "flew to Paris 20 to 25 February" lands at 50% and is refused. I would not have got that from a chat completion, and in this domain it matters more than fluency.

Note the dependency count: the agent needs no chat-model SDK. The whole web app has five runtime dependencies and none of them is a model provider.

Code

https://github.com/PhiBao/ninety

Monorepo. studio/ is a standalone Sanity Studio — 11 document types, 7 object types; web/ is Next.js 16.

infra/      Sanity Blueprints — the CORS origin and a document function.
studio/     Sanity Studio. 11 document types, 7 object types.
web/
  src/lib/engine/     Pure TypeScript. No Sanity client, no model, no env vars.
  src/lib/agent/      Retrieve, classify, then hand off to the engine.
  src/lib/data/       The authored corpus, shared by the tests and the seed.
  src/lib/sanity/     GROQ, the snapshot loader, the Sanity Context client.
  scripts/            Seed, verification, evaluation, demo recording.
eval/RESULTS.md       The evaluation output, committed.

The engine has no model in it

src/lib/engine/evaluate.ts makes no network call and imports no model. It takes a snapshot of the rules and an itinerary and returns a verdict. Same inputs, same answer, every time — and you can check it by hand.

There are 56 tests. They cover the things that are genuinely easy to get wrong: that the day of arrival counts and the day of departure does not, that a same-day visit is one day, that 1–29 February 2024 costs 28 days and the same calendar span in 2026 costs 27, that a pending application is not a permit, that Iceland is EEA but not Schengen, and that an air arrival into Sofia in February 2025 is not the same journey as a train.

My Build Process

The prompt asks which AI-native IDE I used, which prompts worked, which did not, where the model got stuck, and how I course-corrected. I used OpenCode with a large model. I built this in about a day, which I want to be honest about up front: it was fast because I made three decisions early that a slower build would have discovered too late.

What I decided before writing code

1. The engine before the interface. I wrote the date arithmetic and the verifier before a single component. Every bug after that was in plumbing, not in thinking, because the thinking was already pinned down by tests.

2. No model in the verdict. The agent may retrieve, classify and explain, but it may never produce a number. This is the whole technical thesis and it cost nothing to adopt.

3. The evaluation before the polish. I built the case set in the first third. It immediately started catching me.

Where it got stuck, honestly

The dataset looked empty and I nearly believed it.

pnpm seed reported success, but every query returned zero documents. Not an error — a 200 OK with an empty result. That is the signature of a private dataset and it looks exactly like a broken schema. I burned time on the schema before noticing that an unauthenticated read returned 0 while an authenticated read returned 36. The fix was a server-side read token, and I added pnpm verify:data so that failure mode can never be silent again.

GROQ is whitespace-sensitive, in a way that reads like a syntax error.

My snapshot query kept returning empty. The cause:

"allowances": *[_type == "allowance"]
{ "id": _id, ... }

A newline between ] and { makes GROQ read the braces as a block. The fix was to write every projection as [...]{...} with no gap, and to leave a comment at the top of the file saying why so the next person does not "tidy" it back.

@sanity/client v8 silently no-oped my dispute update.

The adjudication wrote a precedent and returned 200. The dispute stayed open. A partial patch on a document with nested typed objects did nothing, without throwing. I only found it because I checked the dataset afterwards instead of trusting the status code. Both the write and the reset now use a full document replace, and failures surface as a 503 with the underlying message.

The module-level cache had no TTL.

My snapshot loader memoised forever, which is fine in a script and wrong on Vercel: a warm lambda served stale rules, so the demo appeared to ignore its own adjudication until the process happened to recycle. Thirty seconds fixed it. I would have shipped that bug if I had not recorded the demo against the deployed site rather than locally.

The evaluation caught my own arithmetic, six times.

I hand-wrote 23 expected answers so the runner could not grade itself. Six were wrong:

Five cases asked about a February 2025 rule "as of October 2026", so the rolling window had aged the trip out and the correct answer was 0. The engine was right; my expectation was wrong. I added a per-case asOf, because a rule that applied in February 2025 has to be evaluated against February 2025.
One case: I expected 29 days for 1–29 February 2024. The answer is 28, because the departure day is not charged.

The engine was right every single time. That is the argument for writing it before you write the prose about it.

The two bugs I am most glad I found

Both were invisible by construction, which is why they are worth writing down.

A test that passed for the wrong reason. My evaluation had a case for the Canary Islands, written against the territory code es-canary. es-canary is a document key; the code is XCI. The engine's response to an unknown territory is a warning and zero charged days — so the case passed, because the Canary days had been silently dropped rather than classified as a carve-out. The number was right. The reasoning was nonsense.

A real-world error, in my own corpus. I had modelled Iceland as a full member, using a shared helper that stamps the Schengen founding date onto every state. Iceland is in the EEA but has never joined the Schengen Area, so Reykjavík days were being charged against 90/180. That is a mistake a lot of tools make, and mine made it silently, in the one file I had been treating as ground truth.

Neither was findable by reading the code. Both came from writing a check that looks at what the engine actually did rather than at the number it returned:

pnpm check:codes      # every territory code the product uses resolves
pnpm check:fallback   # the bundled corpus and Sanity produce identical verdicts

check:codes also fails the build if any evaluation case contains a dropped stay. A case that passes because its input was ignored is worse than a case that fails.

The prompts that mattered

The ones that worked were constraints, not descriptions. "Do not let the model state a number" produced a better result than "make an agent". "Refuse visibly rather than guessing" produced visible refusals everywhere. "Every classification resolves to at least one source, or the day is undecided" produced a schema where that is structurally true.

The one that did not work: I asked for a single-file schema at first. It produced a territory.isSchengen: boolean, which is exactly the modelling error the product exists to catch. It took me restating the requirement as "the same ten-day trip into Sofia counts overland and does not count by air in February 2025" before the schema stopped lying.

Thoughtfulness of the Schema

Three decisions carry the weight. A fourth is the reason the whole thing works.

1. Membership is a band, not a flag.

{key: 'bg', name: 'Bulgaria', code: 'BG', kind: 'state', accessBands: [
  {from: '2000-01-01', to: '2024-12-31', counted: false, ...},
  {from: '2024-12-31', to: '2025-03-31', counted: true,
   modes: ['land', 'sea'], ...},
  {from: '2025-03-31', counted: true, ...},
]}

My first pass used a shared FULL('2000-01-01') helper for every state, which is a lie for anyone who joined later — and, as the Iceland bug above shows, for anyone who never joined at all. Fixing it meant going and dating each accession properly: the 1995 founding group, the Nordic members, the 2004 and 2007 enlargements, Switzerland in 2008, Croatia in 2023, Bulgaria and Romania in 2024–25, and the four territories that are in the EEA, the EU, or neither but not in the area.

2. Carve-outs are first-class territories.

The Canary Islands, Madeira, Åland, Svalbard, the French overseas departments, and Ireland, Cyprus and Iceland as external are each their own territory document with their own bands — not a boolean on the parent state. That way the ledger can say "Canary Islands (Spain) — outside the Schengen area despite being Spanish territory", and name the exact place a day was spent.

3. Ambiguity is data, not an exception.

A presenceRule can be marked disputed. When it is, the engine will not classify a day of that kind, reports the count as a range, and routes the day to an adjudication. The ruling becomes a precedent scoped to that presence kind and effective from the date of the ruling — which is why the September layover in the first demo correctly stays unresolved after a ruling made in October. Days already counted are not revisited.

4. The rules and the traveller are different kinds of thing.

allowance, territory, nationalityClass, visaRegime, permitExemption, presenceRule and source are reference data — effectively one document each, seeded under deterministic IDs. itinerary and trip are a person's record. dispute and precedent are decisions about the first group, made in light of the second. Keeping those three layers apart is what let me seed, test, snapshot and reset each independently — and what lets the app fall back to a bundled copy of the corpus and still produce byte-identical verdicts when Sanity is unreachable.

The infrastructure is declared too

infra/sanity.blueprint.ts holds the CORS origin the app reads through and a document function, and blueprints plan shows the diff before anything is applied.

The function is the interesting part. Ninety's claim is that a ruling is not a message — it is a typed, dated, scoped precedent that every later calculation reads. The desk writes that precedent. But a dispute can also be adjudicated by editing the document in the Studio, and that path can leave a dispute marked adjudicated with nothing behind it.

Which is exactly the bug this build shipped. A partial patch wrote the precedent and left the dispute open, and the product looked correct until someone checked the dataset. So the invariant now lives in the data layer:

any dispute marked adjudicated has a precedent behind it, whoever adjudicated it

Verified by hand, twice: a Studio-style patch that leaves the broken state is repaired within about thirteen seconds, the precedent carries the presence rule's own two sources so its citations still resolve, and a second ruling supersedes the first rather than overwriting it.

Three ways to fail while building a guard

Every one of these logged success and did nothing.

client.patch() is lazy in @sanity/client v8. The handler awaited it, logged "attached precedent to dispute", and changed nothing. Writes now go through mutate(), which takes an array and returns a transaction result — either the write happened or the call threw.

A transaction id derived from the document id looks like idempotency and is a trap. Sanity remembers transaction ids permanently, so the second adjudication of the same dispute came back transactionAlreadyExistsError and the function failed forever after, silently. Convergence now comes from createOrReplace against a date-keyed precedent id, which is naturally idempotent; the transaction id only has to be unique.

The guard read a field the document does not have. It looked for a denormalised presenceKind, found nothing, and declined to act — on a dispute whose subjectKind was very plainly presence_kind. It now resolves the kind through the reference.

That last one is the general lesson, and it is why I think a guard that refuses because it looked in the wrong place is worse than no guard at all: it converts a loud failure into a quiet one. Every check in this repo earns its place by looking at what the system actually did rather than at whether it reported success.

Did the structured content actually matter?

The challenge says: "If a keyword search would have gotten you the same answer, aim higher." So I measured it.

Two systems, the same corpus, 23 adversarial histories with hand-computed expectations. Neither arm uses a language model, so anyone can rerun it with pnpm eval.

Measure	Structured (GROQ + engine)	Keyword search (BM25, same rules)
Correct answer	23/23	1/23
Produced a day count	21/23	0/23
Named the exact breach date	1/1	0/1
Refused instead of guessing	2/2	n/a

Full results, including why each case is hard: web/eval/RESULTS.md

The keyword arm is not handicapped by a weak index. It sees the same territory records, the same presence rules, the same permit exemptions, flattened into prose, and scores BM25 over them. It returns the right sentences most of the time. It just cannot produce a number, because:

The corpus holds the rules, and never held the traveller.

Asking "am I still legal" is not a retrieval problem. It is a join between the rule and eleven date ranges, two of which fall in carve-outs and one of which nobody has ruled on, evaluated day by day across a rolling window. Retrieval finds the paragraphs. It cannot join them to a calendar.

Sanity Project Details

Project ID: jvgi63fz
Dataset: production
Contents: 5 sources, 1 allowance, 36 territories with date-banded access, 3 nationality classes, 3 visa regimes, 5 permit exemptions, 6 presence rules, 2 demo itineraries with 17 trips, 1 open dispute.
Reproduce it: pnpm --dir web seed && pnpm --dir web verify:data Infrastructure: pnpm --dir infra bp:plan && pnpm --dir infra bp:deploy

Every rule in the dataset carries a sourceRef pointing at a real document with a publisher, a URL and a retrieval date. Clicking any day in the ledger shows its authorities. Nothing in Ninety's reasoning is unattributed.

What this is not

Not legal advice, and not a complete immigration reference. It covers the Schengen short-stay allowance for a handful of passport classes and refuses outside that coverage. The rule corpus is deliberately narrow and dated rather than broad and approximate, because a wrong answer in this domain is not an inconvenience.

If I had another day I would widen the territory set, add the UK 180-day visitor rule and the US admission-parity rule on the same generic engine, ingest the EU source documents as a Knowledge Base so the agent can quote the paragraph rather than the title, and build a real Sanity App SDK app for the desk so adjudication lives inside the Dashboard instead of a separate page.

Thanks to the Sanity team for the challenge, and to the DEV community for the review. 🤖