Two Missions, One Method
Before curating anybody else’s knowledge, we curated the only body of knowledge we have complete access to: this system.
V.E.T.S. began as veterinary practice management software. The long-range aim is larger and slower — a shared body of animal knowledge that gets better as people use it, rather than one that ages from the day it is published. This page is about how the second thing gets built out of the first, and about which of the two is actually finished.
The dual mission, and why it is in that order
The strategy is one sentence: learn how to curate knowledge on a domain we already own, then point the same machinery at the domain we care about.
Mission one: learn curation on our own system
The first body of knowledge we had to make sense of was the platform itself — 1,113 tables, 2,283 views, 2,834 stored procedures and 249 functions, which is well past what anyone holds in their head. The framework layer those figures describe →
Building the machinery to curate it produced 246 AI stored procedures, 42 AI tables, 49 AI views and 11 AI functions, feeding a corpus of 2,333 indexed documents and 14 assistants that cover 78 different page contexts.
Mission two: point it at animals
A pipeline that summarizes a stored procedure, extracts its keywords, links it to related material and scores how much it should be trusted does not care that the subject is a stored procedure. The same steps run over a lameness protocol or a bloodline’s history of metabolic trouble.
That is the whole bet: the hard part was never the veterinary content. It was building something that improves the content instead of just storing it.
The order is the argument, not an accident of scheduling. Curation techniques are only worth anything once they have been wrong in front of someone who could tell.
Why we curated our own system first
The usual sequence is to build AI tooling and then look for somewhere to put it. Everything here went the other way. Each capability was built because something in the work was genuinely difficult, tested against data we owned, and corrected by people who could tell when it was wrong — which is a much shorter feedback loop than shipping and waiting for complaints.
Doing it on our own documentation also meant we could be honest about the results, because nobody else was inconvenienced by them being bad at first.
Mission one is the one that is finished. Everything in the searchable index today is documentation about the system: help text, knowledge-base articles, and generated descriptions of database objects. There are no animal records in it. The curation machinery is real, running, and proven on a domain that happens to be software. Turning it on the animal domain at scale is the next thing, not a completed thing, and any page telling you otherwise is selling.
What the AI layer is actually made of →
No model name is written into the application
Every model this platform uses is a row in a configuration table, stbl_System_CodesGlobal, read at runtime through a procedure called astp_AI_GetModelConfig. No model name appears in application code anywhere. Changing which model handles interactive chat, or overnight batch work, or the expensive evaluation pass, is a row update rather than a deployment.
Worth being plain about the current state: every configured model is a Gemini model. There are none from another provider. The point is not that we run a variety. It is that the model layer is a configuration surface instead of a code dependency, so the platform is not betting its architecture on any particular vendor still being the right answer in three years.
That matters more than it would for a younger system. This schema has a continuous change log running from 2007-12-18 to 2026-07-26, with no gap in it. Software that has been changing for that long, and intends to keep changing, should not have this year’s best model compiled into it.
Where this goes
The long-range aim is a body of animal knowledge that every kind of practitioner contributes to and draws from — veterinarian, trainer, farrier, breeder, nutritionist, livestock manager. Each of them sees something the others do not. Today that knowledge is distributed across people who mostly never meet, and it dies in retirements.
The aim is not to replace any of that expertise with a model. It is to stop losing it, and to make one person’s hard-won pattern available to somebody two states away who is about to meet the same case for the first time.
This page states direction. It deliberately does not state dates, because direction and sequence are different claims and mixing them is how roadmaps become fiction. What is built, what is being built, and what is still an intention are set out separately.
What is built, what is next, in order →
Who is contributing, and how to join them →
Where to go next
If you are weighing this as a business rather than as an idea, the case is set out plainly on one page: what it is, who it is for, and what has actually been built.
The business case in one page →