How we use AI
AI writes the first draft. The product runs on rules.
Cachetto uses a language model in one place: turning what your organization has already published, and what you have told us, into a starting configuration for a demo or an implementation. The product itself, the part that tracks whether an application is complete, a fee is paid, or a credential is current, runs on configuration you can read and rules that behave the same way every time. This page explains where that line sits and why we drew it there.
The short version
What the model does, and what it never does
What the model does
- Reads the public pages on your website that describe your programs.
- Judges which of those pages matter, which image is your logo, and which colors are your brand.
- Writes a first draft: program names, the steps as your site describes them, fees, exam and renewal rules, and the copy on the portal home page.
- Revises that draft when a person asks it to.
What it never does
- Decides whether anyone is eligible, approved, certified, or current.
- Writes to your records. Its output is a draft that code checks and a person reviews.
- Invents a link the system will follow, a database identifier, or a field name.
- Reads a member or certificant directory, or anything behind a login.
- Runs inside the product after setup. Nothing in the product’s own logic asks a model anything.
Why the line is where it is
Running a program and setting one up are different kinds of work
One has to give the same answer every time. The other is mostly reading.
Running a program is deterministic
A candidate has submitted the application or has not. The fee is paid or it is not. The exam was passed or it was not. A journey in Cachetto is a written-down sequence of milestones and steps, and given the same configuration and the same facts it produces the same result every time, with a record of why. That is what a system of record is for, and it is why the product does not use AI: you cannot audit a rule that might answer differently tomorrow.
Setting one up is judgment
Before any of that can run, someone has to read how your organization works and translate it into configuration: which programs exist, what the steps are called, what they cost, how long a credential lasts. Traditionally that is a consultant reading your handbook and your website, asking questions, and typing it in. It is slow because it is reading, and reading is the thing a language model is good at.
What “non-deterministic” means, in plain terms
Ask a language model the same question twice and you can get two differently worded answers, both plausible, sometimes one of them wrong. That is acceptable for a first draft that a person reads and corrects. It is not acceptable for the system that decides whether someone holds a credential. So the model writes the draft, code checks it, a person approves it, and from then on the model is out of the loop.
Step by step
What happens when you ask for a demo
This is the same process the status page in your demo shows you, with more detail about what runs at each step and what it is allowed to do.
You tell us about your organization.
Your name, the organization, and optionally your website and a few words about what you want to see. If you would rather not have your website read, there is a checkbox for that, and the draft is written from what you type instead.
Code reads your public website, within limits it cannot exceed.
It fetches your home page and pages whose address suggests they describe programs: certification, eligibility, requirements, fees, renewal, membership, and the like. It skips anything that looks like a directory, a search, a member lookup, or a verification page, and it honors your robots.txt. There is a cap on how many pages it reads and how much text it keeps. None of this is a judgment call, so none of it is left to the model.
Contact-shaped text is removed before the model sees anything.
Email addresses, phone numbers, and anything shaped like a government ID number are replaced with a placeholder in the text the model is given.
The model judges what matters.
From the list of pages the code was allowed to read, it picks the ones that explain how someone actually becomes credentialed. From the images on your home page, it picks the one that is your logo, or says it is not sure. From the colors your stylesheet uses, it picks your brand. It can only choose from the lists it was given. It cannot add to them, and a choice that was not on the list is thrown out.
The model writes a draft into a fixed form.
The draft has a set shape: an organization, its programs, each program’s steps (chosen from a short list of step types), its fees, its exam and renewal rules, and the words on the portal home page. Every field has a type and a length limit. The model fills in names, labels, prices, and copy. It does not produce anything the database understands directly.
Code checks the draft, and rejects what does not hold together.
Every value is checked against its limits. Every step type has to be one that exists. And the draft has to be coherent: a “pay the fee” step with no fee attached, or an “exam passed” step with no exam, is rejected rather than patched, because a demo where a step can never complete looks like a broken product. A draft that fails these checks is discarded, and the request goes to a person with no draft at all.
A person compares the draft with your site.
Before anything is built from it, someone on our team reads the draft against what is actually on your pages and corrects what the model got wrong, or asks it to revise. The status page in your demo shows this step: so you know a person is still in the loop.
Deterministic code turns the approved draft into a demo.
The demo is built from record templates a person wrote by hand, with the draft’s names, prices, and copy substituted in. That is what makes it safe to let a model write real content: a model that misunderstands your organization produces a badly worded demo, not an incoherent one. You get a sign-in, and a place on the status page to tell us what is off.
Jump-starting an implementation
The draft is kept, and it is where your implementation starts
Every draft is saved with its history. A demo can be rebuilt from it later, and when you become a client, the same draft is the starting point for your real environment rather than something we throw away.
Every version kept
The draft library records how each version came to exist: written by the model, revised by the model at a person’s request, or edited by a person directly. A revision that made things worse can be undone.
The same checks, both times
A demo draft and an implementation starting point are the same document, held to the same limits by the same code. Nothing has to be re-derived when a demo becomes a project.
What people still do
The model has done the reading and the first typing. Confirming every rule with you, configuring what your website does not say, migrating your data, connecting the systems you already run, and testing all of it is still done by people.
What the draft removes is the blank-page start, so our implementation team’s time goes into confirming your rules with you rather than transcribing them. It does not remove the people.
Data and hosting
Where the model runs and what it is given
Runs in our Azure subscription
The model is Microsoft’s Azure OpenAI Service, provisioned inside Cachetto’s own Azure subscription alongside the rest of the platform. It is not a consumer chat product. Microsoft documents how the service handles prompts and outputs, and we point you to that documentation (opens in new tab) for the layer underneath us.
What it is given
The public pages the code selected, with contact-shaped text removed. Your organization’s name. What you typed into the request form. And once we have spoken, what you have told us, which we write into the brief ourselves.
What it is not given
Member or certificant records (we do not have them at this stage). Anything behind a login. Directories, lookups, or verification pages. And nothing from your website at all if you ask us not to read it.
Questions we get
Straight answers
Does the AI decide who gets certified?
No. Nothing in Cachetto’s own logic asks a model anything. Eligibility, review, approval, issuing, and renewal follow the configuration your organization set, and they behave the same way every time. The model is used before that configuration exists, to draft it, and it is out of the loop once a person has approved the draft.
Why not let the model configure everything?
Because the running system has to give the same answer every time, and a model does not. A draft is allowed to be imperfect; a rule about who holds a credential is not. Keeping the model on the drafting side means every rule your programs run on was checked by code, approved by a person, and can be read by you.
Is it just making things up?
It can, which is why it is never trusted on its own. Three things stand between the model and a demo: a fixed form it has to fill in, code that rejects anything out of bounds or incoherent, and a person who reads the result against your website. When a draft is wrong, it is usually wrong the way a first draft is wrong (a fee taken from the wrong one of two published fee tables, a step named in the template’s words rather than yours), and those are exactly the things the review exists to catch.
Does it see our members’ or certificants’ data?
No. At the point the model runs, we do not have your member or certificant data, and the code that reads your site is written to stay away from it: directory, search, lookup, and verification pages are never fetched, and email addresses and phone numbers are removed from the pages that are. If your organization later becomes a client, data migration is a separate piece of work our implementation team does with you, not something the model is given.
Can we keep the model away from our website?
Yes. The demo request form has a checkbox for that. Tick it and your site is not read at all; the draft is written from what you type instead. There is a second checkbox if you would rather have a person walk you through the demo than explore it on your own.
Where does the model run, and who sees what we send?
The model is Microsoft’s Azure OpenAI Service, provisioned inside Cachetto’s own Azure subscription alongside the rest of the platform. It is not a consumer chat product, and nothing of yours is typed into one. Microsoft documents how the service handles prompts and outputs, including that they are not used to train its models; we point you to that documentation (opens in new tab) rather than restate it as our own claim.
Can our own staff use AI with the product?
Separately from anything on this page, yes. Cachetto runs on Microsoft Power Platform, so your team can build its own assistants, document review, or predictions with Copilot Studio and AI Builder against your own data, on your own terms. That is your build and your decision; it is not something the product does on its own.
Something this page does not answer? Ask us directly, and we will answer it in the same terms.
See it on your own programs.
Give us your website and we will show you the draft it produces, the checks it passes, and the person who reads it before you do.