A verdict needs a source
When a reader asks for a fact check, Veritas sends the article text to a Gemini model with Google Search switched on. The instruction is narrow. The model names the main thesis of the article, picks three to five claims that carry it and rates each one as verified, disputed or unverifiable. It also lists indicators of bias. The answer has to arrive in one fixed data format.
Two rules keep the result from being a second opinion. The domain of the article itself must not be used as evidence, so a text cannot confirm itself. And every verified or disputed claim has to link to a source. A claim without one is unverifiable, whatever the model believes.
The app does not take the answer on trust either. Source addresses are taken from the search results that the provider reports alongside the answer. Only when it reports none does the app fall back to the list the model wrote. A verdict the app does not recognise becomes unverifiable, never verified. If the answer cannot be read at all, the reader sees an error state instead of an empty or invented result.
A model call can fail
A request with web search can take long or be refused. Veritas tries up to three times with a growing pause and gives up after two minutes per attempt. When the provider reports that the request limit is reached, the app switches once to a second key.
These are small mechanisms, and they are the difference between a demonstration and a feature. Without them a slow answer looks like a frozen screen, and a refused request looks like an article with nothing to check.
The cheapest check is the one already done
Each check costs time and money, and many readers open the same articles. A finished result is therefore stored twice. On the device it is kept for seven days, limited to the 100 most recent results. A second copy goes to a shared database. Another reader who opens the same article receives the stored result and no new model call is made.
The remaining calls have fixed limits. Article text is cut at 4,000 characters. The daily briefing reads at most 25 articles with short excerpts. Grouping considers at most 80 articles from the last 48 hours, sent in batches of 15 headlines, and its result is kept for two hours. The comparison of how outlets frame a story only runs when a reader opens that story, on at most six articles.
One event, several outlets
The reader’s feeds often carry the same event several times. Veritas sends headlines with their outlet to the model and receives groups of article numbers back. The app checks every number, discards groups with fewer than two articles and shows the largest stories first. Opening a story adds a short summary and a comparison of the outlets.
The design note for this feature describes a two-step method: group locally by shared keywords first, then let the model confirm. The local step exists and has 14 unit tests for keyword extraction, similarity and grouping. The current pipeline does not call it and relies on the model alone. That gap is recorded here because the tests would otherwise suggest more than the app does.
A briefing that is ready before the reader is
The Daily Checkup is a briefing from the reader’s feeds at a time the reader chooses. Generating it takes too long to start when the app is opened. Veritas therefore sets an exact alarm in Android that wakes the device, runs outside the interface, shows a quiet progress notice and announces the finished briefing.
The alarm is set for one day only and sets itself again at the end of every run. That also happens when generation fails, so one bad morning does not end the schedule. Topics can be marked as always, sometimes or hidden, and that choice goes into the instruction for the briefing. Output is available in twelve languages.
What is not finished
Veritas is a prototype and is described as one. The app still carries a placeholder identifier and no release signature. It calls the model directly from the device, with the keys inside the app. A release would need a backend in between that holds the keys and enforces limits per reader. There is no user account, and the planned items in the project’s roadmap, such as offline reading, a dark theme and spoken briefings, are open.
The background generation and the handover of a finished briefing to the screen were read in code for this page, not tested on a device.
What this demonstrates for client work
Veritas shows how CIDIX puts a language model into a product without letting it have the last word. The model receives a narrow task and a fixed format. The application decides what counts as evidence, what happens on failure and how often the model is asked at all.
The same pattern applies wherever generated statements have consequences, for example in research tools, support answers or internal knowledge bases. The first questions in such a project are the same as here. What is the source of each statement, what does the user see when there is none, and what does one answer cost?