Four words, in order

A temperature reading is data. What V.E.T.S. does is the three steps after that.

Data, information, knowledge, wisdom. The rest of this section leans on those four words constantly and they are not interchangeable. This page is what each one costs, and where in the system you can watch a rung being climbed.

A temperature is not yet information

Data is the reading. On its own it is a number that could belong to any animal, on any day, taken for any reason.

It becomes information when it knows what it is about. Which animal, which date, which clinical service, which herd. In V.E.T.S. that context is structural rather than descriptive: the animal is identified through atbv_VETS_Animals, herd membership is a row in atbl_VETS_Herds, and the reading itself lands in a patient history record typed by clinical service.

This is the cheapest of the three steps and the one most systems still get wrong. A number stored on its own is data. The same number stored against an animal, a date and a service type is information, and which of the two you end up with is decided by the shape of the table rather than by the diligence of whoever is typing.

The tree that organizes all of this, and the way one database holds many organizations without leaking between them, is a subject of its own.

How the tree and the multi-tenant schema are built →

Where knowledge starts, and who signs for it

Information is about one animal on one day. Knowledge is what holds across animals and days: the protocol, the reference article, the description of how a part of the system behaves.

In V.E.T.S. that layer is a body of 2,333 indexed documents — help text, knowledge-base articles, and generated descriptions of stored procedures and tables. It is documentation about the system and about the practice of using it. Animal records are not part of it and are never embedded.

Wisdom is the rung most software never builds, because it requires the system to record disagreement. V.E.T.S. builds it in the schema.

atbl_AI_DocumentIndex keeps AutoSuggestedScore and ValidatedBy in separate columns, alongside LastValidated, JudgedAt, ClaimsExtracted and ClaimsVerified.

A model proposed this, and a person checked this, are stored as different facts about the same document.

That separation is what makes the top rung reachable. A system that cannot distinguish its own guesses from its confirmed findings has to treat them alike, which means it can accumulate content but cannot improve. One that keeps them apart can be corrected, and can know afterwards that it was.

How a document gets scored, indexed and retrieved →

Why everything hangs off the animal

The ladder only works if the rungs share a spine, and in V.E.T.S. the spine is the animal.

309 procedures in the astp_VETS_ family. 71 of them are patient history. Pedigree lineage has its own operations, herd membership and ownership have their own tables, and farrier evaluations have a family of their own.

What unites them is not a shared naming convention. It is that every one of them keys to the same animal identity. A farrier’s evaluation and a veterinarian’s exam are not joined together later by a report; they are attached to the same animal at the moment each is created.

The same spine carries the people. An animal has an owner, sometimes a custodian who is not the owner, and a practice around it — and those relationships are 46 procedures across 10 tables in the Contacts family, covering clients, vendors, shipping addresses and employee rights. The point is not that a contact list exists. It is that a record which knows which animal it belongs to also knows who to call about it, without a second system being asked.

The practical consequence is that cross-domain visibility becomes a permissions question rather than an integration project. The records are already in one place. What is left to decide is who may see them, which is a subject of its own.

How secured views decide what you can see →

A form is rows, not code

There is a habit running through this system that is easiest to see in DynamicForms: things that would normally be written in code are stored as data instead.

A form in V.E.T.S. is defined across 6 tables in the stbl_DynamicForms_ family — separating what a form is, what fields it has, and where on the layout those fields sit. Its behavior is columns rather than logic: IsEditable, HasFilter, HideDataBeforeFilter, InputIsRequired, IsLocked, ControlType. Changing what a form does is an update statement.

The habit runs wider than forms, and assessment is where it goes furthest. Four separate domains — farrier work, animal performance, riding lessons and clinical detail — each carry the same eight tables: Eval, EvalItems, EvalOptions and EvalValues, plus four more for the files, images and video attached to them. 54 such tables exist across the platform. A practice defines its own assessment: which questions get asked, which answers are permitted, how they score. And because the media attaches to the assessment rather than to a folder near it, a hoof at twelve weeks and the same hoof at twenty sit inside the record that compares them.

That is the same decision as the one behind the AI layer, where no model name is hardcoded and the model in use is a row you can query. In each case the argument is the same: behavior you can inspect and change without a deployment is behavior a domain expert can eventually own.

Worth knowing before you plan around it. The field vocabulary is narrow. Text boxes and checkboxes carry very nearly all of it. This is a system for arranging and constraining fields, not a visual designer that can produce arbitrary interfaces.

Something still has to turn those rows into markup a browser can render, and in V.E.T.S. that something is SQL itself.

The SQL functions that generate the interface →

From structured knowledge to retrieval — follow one record, or open the knowledge-base lesson:

Your Data’s Journey →

AI Knowledge Base →

Where to go next

The ladder is easier to believe once you have watched it climbed. One barn call takes a temperature reading all the way to a correction the system keeps and can act on.

Follow one call from observation to correction →