Four jobs. On your machine. A person always decides.
FoundrySuite's local AI researches leads, scores opportunities, summarizes client notes, and drafts emails — and it can never alter a financial number or post to your books without your click.
The four things it does
Research
Find companies matching your criteria, read their public pages, and pull out what can be verified — each value with the URL it came from.
Score
A second opinion beside your own deterministic scoring, with a written explanation of where the points came from.
Summarize & classify
Describe a lead, read a document, categorize a record, and file the fields printed on it against an invoice or a bill.
Draft
Propose outreach copy, the next step, and accounting descriptions. All of it a draft you edit.
The two things you control
Two things you control
From scanned document to staged draft. Drop in a receipt, vendor bill, quote, or business card: local OCR reads it, the AI extracts the fields and line items, and routes it — Expense, Vendor Bill, Customer Invoice, Quote, or Lead — into a draft entry, approval pending, for one-click review. It never posts to the books; a human approves.
Every AI function has an off switch. The master switch, each job (Research, Lead Scoring, Summarize & Classify, Draft Assist) and confidence-gated auto-staging are toggles in Workspace Settings.
Where the thinking happens
Locally. The model loads into the application when it starts and sends prompts nowhere. There is no inference server to install or leave running, and no port for it to occupy.
Which means: no prompt leaves the machine, no customer data is a line item on someone's inference bill, and with the network cable pulled, everything except online research keeps working.
You can point it somewhere else, and it will tell you when you do
Any OpenAI-compatible endpoint works — a server you run yourself, or a commercial API. If you do that, your prompts are transmitted to that operator, you become responsible for the agreement with them, and FoundrySuite says so on screen. It does not quietly send your data to a paid API and leave it to you to find out.
What goes to the model
| Feature | Typically sent |
|---|---|
| Lead summary | Company name, industry, notes, prior activity |
| Scoring | Company attributes and your criteria |
| Outreach draft | The product or service description you wrote |
| Document reading | Text extracted from that document |
Never sent: session tokens, password material, accounting records, other workspaces' data, or the audit log. And because inference is local by default, none of the above leaves the workstation either.
What the model is not permitted to do
Enforced in code, tested, and not configurable. These are not guidelines.
- Post to the ledger. Proposed entries pass the same integrity, permission and period checks as anything else. A journal entry that does not balance to the cent cannot be posted, full stop.
- Overwrite something a person corrected. Your fields are yours, permanently and visibly.
- Change a lead's status. Scoring is deterministic and yours; the model gives a second opinion and changes nothing.
- Decide. Anything affecting money or a customer's fate is computed by rules and confirmed by a human.
- Follow instructions from a web page. Prompt injection is treated as an expected threat. Retrieved content is data; it has no authority over accounting, permissions or periods.
- Produce malformed output. Every AI operation declares a typed contract, compiled to a grammar the sampler must satisfy. The failure mode of "invalid JSON" is unrepresentable.
- Send an email. There is no send button. Drafting is what the software does; sending is your decision, made in your mail client.
It tells you when it has been used
Every screen that runs the model carries a visible, code-tested notice: what was generated, that a person is responsible for reviewing it, and where the model ran. The provenance line changes with your setup — a model running on your own machine, whether you supplied the file or FoundrySuite fetched it, reports as running there; a local endpoint is reported by name. A value the model wrote earlier keeps its origin marked on the record, so it stays attributed after you close the screen.
That is not a nicety. If you are regulated, if your customers ask, or if the EU transparency rules reach you, "where did this come from" needs an answer that is on the screen rather than in your memory.
And you can ask where any value came from
Every automated write records its origin (user, source, derived, system, ai_inference or ai_suggestion) and a confidence value — not a bare yes/no.
For any record you can ask where a value came from and get an answer. You can correct it, and the correction is recorded as permanent.
For your procurement file
The download includes an AI facts sheet written for a compliance officer rather than a lawyer: what the features do, what they transmit, and what they may not do.
Honest answers to the questions that come next
Does it need a GPU?
No. It runs on the CPU. Speed depends on the model you pick and the machine you pick it for, and a smaller model is dramatically faster.
Is it a chatbot I can talk to?
No. It is a CRM that does four specific jobs with a model rather than a text box you can chat with. That is a deliberate limitation — the value is in the work being done, not in the conversation.
What happens if the model is wrong?
Then you have a draft you did not send, a second opinion beside your own scoring, or a suggestion you can decline. Every automated value carries its origin and confidence, and human corrections are never overwritten. The design assumes the model is wrong regularly, because it is.
Where it is unsure of something it cannot fudge its way past — what a scanned card or an ambiguous receipt actually is — it asks instead of guessing, and the field is left empty until you answer. Your answer is then recorded as yours, so no later pass can quietly put the model's opinion back. Accepting its guess instead keeps it as the model's, and revisable. The two are deliberately different: the model is allowed to be wrong, but it is not allowed to decide.
Whose model is it, and am I responsible for it?
Yours, and here is the distinction that matters. We do not put weights in the installer and we do not host them. What we do ship is an address: the manifest names each model file, pins it to one specific revision of a Hugging Face repository, and carries the SHA-256 of those exact bytes. When you ask FoundrySuite for them, it fetches each file from huggingface.co, checks it against the digest, and deletes anything that does not match rather than loading it.
The three files total about 5.7 GB. Nothing is fetched until you have seen that figure, seen who publishes each file, and agreed to it. If you do agree, it is fetched once, in the background, with the ledger, the pipeline and the documents working while it runs; if you do not, nothing is fetched and nothing is written down against you. Either way that request shows your IP address to Hugging Face and to the CDN it redirects to, which is why it is flow 5 in the Privacy Notice.
You can also opt out of one model or both, permanently. The prompt draws a box per model rather than per file, so you can keep the language model and decline the OCR pair, or the other way round. A model you decline is not offered again, is not counted in the total, and is never fetched. That is kept as a configuration setting in your data directory rather than as anything about you — nothing is transmitted, and you can put it back under Settings → Model files. Settings also takes a path to a model file of your own for the language model; if the file you name is not there, FoundrySuite says which path it could not find rather than quietly loading a different model than the one you chose.
One of the three is a third-party file, and you should know which. The language model is IBM's own, from IBM's repository, under Apache-2.0. The two OCR files are not DataLab's. DataLab trained chandra-ocr-2 and publishes only safetensors — no GGUF at all — so both OCR files are community quantizations served from a Hugging Face account we have no relationship with. The digest proves the bytes are the bytes we approved; it does not make that account the vendor of the OCR model. If your procurement needs weights from the model’s author only, bring your own and point LEADFLOW_EXTRA_MODEL_PATHS at it.
Not distributing weights is deliberate. Naming an address is a different act from shipping someone the bytes: it keeps the general-purpose-model obligations off us while leaving the AI features available on first run. If you redistribute a FoundrySuite build, or the weights themselves, that role becomes yours. The AI facts sheet states all of this the same way, so there is one answer rather than three.
Can I turn the AI off entirely?
The deterministic parts — the ledger, scoring, pipeline, permissions — never needed it. Removing the model leaves a working CRM with fewer conveniences, not fewer functions.