Owin

• 

  The app: answer 3 is Not true for /api/crm-sync, with Anthropic's own sentence beside it

• 

  The start page: the finding first, then 27/33 answered on its own, 26/27 right

• 

  The buyer report: each answer with the vendor's exact sentence, source and date

• 

  How it works: Tavily fetches, Nemotron on Token Factory reads three times, plain code decides

• 

  The buyer page: every answer per endpoint, with what to check first

Inspiration

I built Owin because a buyer's security questionnaire asks whether your AI providers keep customer data, and the true answer differs per endpoint.

I started from one sentence on Anthropic's own page: "The MCP connector is not covered by ZDR arrangements." A startup that turned on zero data retention (ZDR), wrote "yes, ZDR" on its trust page, and then shipped one feature through the MCP connector has a false answer and no way to know. Nobody emails you when a vendor changes its page either.

The result: on 11 features from 7 vendors, with labels committed before the prompt was written, Owin answered 27 of 33 questions on its own and got 26 right. It handed the other 6 to a person; a majority vote would have got 4 of those 6 wrong. The /judge page recomputes the number from recorded runs when it loads, with no key and no network.

What it does

Owin fills the AI section of an enterprise buyer's security questionnaire (training use, retention, ZDR, processing region, who sees the data) for a 2-to-50-person B2B SaaS, per endpoint, from each vendor's own page, with the vendor's sentence behind every answer. It is per endpoint because the terms are: Anthropic's Messages API can run under ZDR, its MCP connector cannot, and Message Batches keep data 29 days.

1. You list your stack: each endpoint, the vendor feature it calls, and the answers you already gave.
2. Nemotron reads; plain code decides. Each vendor page is read three times, and code compares the vendor's fields with your answers: Not true, Outdated, Needs review, Not stated or Verified.
3. The finding comes first. On the demo company (fictional; every vendor sentence, link and fetch time is real), answer 3, "Yes, ZDR", is not true for /api/crm-sync, with the MCP connector sentence beside it. Answer 5 is outdated: OpenAI changed its sub-processor list on October 14, 2026, after it was written.
4. The buyer gets a read-only report (PDF, CSV or link) with the sentence, link and fetch time behind every answer.
5. A buyer page they can check themselves. https://owin.cloud/trust shows every answer per endpoint with its status, the vendor's exact sentence, the source, when it was fetched and the page's own "Last updated" date, starting with what to check first.

Try it in 60 seconds

• Open https://owin.cloud/judge, then the app at https://owin.cloud/app, and the buyer page at https://owin.cloud/trust. No login, no key.
• On /judge, "Recompute the number now" asks the server again and shows 27/33 · 26/27 · 6 in place.
• Point /api/crm-sync at Anthropic Messages: the rules rerun and answer 3 becomes verified.
• Locally: poetry install && owin serve; owin eval selective --corpus datause --split v3fresh recomputes the number.

How we built it

In the order the data moves:

1. In: you list each endpoint and the vendor feature it calls, plus the answers you already gave.
2. Fetch: Tavily extract fetches each vendor page and records the time, hash and "Last updated" date.
3. Read: Nemotron 3 Super on Nebius Token Factory reads the page three times into five fields, each with a verbatim quote.
4. Decide: plain code answers only where readings agree and compares the vendor's fields with your answers.
5. Out: the app with the fix drafted, the buyer report, and the buyer page.

• Plain code decides from enums and integers only. A test feeds model prose into every badge and nothing moves.

Sponsor technology

Challenges we ran into

• The pre-registered prompt failed three times (the last: 7/11 against an 80% bar). I stopped tuning prompts and tested whether agreement across the three readings predicts correctness. It does, and that became the product's Needs review status.
• Tavily once served an older copy of OpenAI's list (dated July 9, after an October 14 change). A page dated older than the accepted copy is now set aside, never used.

What we'll tell you before you find it

• Labels were written by an AI coding agent and spot-checked by a second pass; no human audit yet. The one miss is a label error (OpenRouter), kept because the labels were pre-registered; corrected, it is 27/27.
• Live vs replayed: the pages replay recorded Nemotron readings, so the number recomputes with no key. The Re-check button, and a re-fetch on a schedule you set (daily at 06:00 UTC by default), call Tavily live on the vendor pages; they update the dated observations, not the recorded numbers.
• The split is small: 11 features, so one item moves the score by 9 points.
• The demo company and its ZDR settings are fictional; Owin cannot see vendor consoles. Owin is not legal advice.

Accomplishments that we're proud of

• A number anyone can recompute from committed files, with no key, in one command.
• The model cannot change a verdict, and a test proves it.
• It knows when not to answer: all 6 negative-control cells came back "not stated".

What we learned

• AI data-use terms are per feature, not per vendor.
• Agreement between readings is the confidence signal, not model size.
• The failed pre-registration taught more than a pass would have: it made the product say "needs review" instead of guessing.

What's next for Owin

• An independent human label audit, then a larger split.
• Send an alert the day a scheduled re-fetch finds a vendor page changed.
• Run Owin on three real startups' stacks and compare with what they sent their buyers.
• Let each company publish its own buyer page from its own stack, kept current by the same dated vendor observations.

Built With

• docker
• nebius-cloud
• nebius-serverless-ai-endpoints
• nebius-token-factory
• nvidia-nemotron-3-super-120b-a12b
• python
• tavily
• tavily-extract