Data never enters git
Client data lives in object storage; the repository stores only the manifest, hash, and pointer. Data is deleted or archived as agreed at the end.
CONTACT
Diagnose first.
Then decide whether to train.
Tell us where the model fails, what data you have, and what “better” means. If you do not have a test set yet, the diagnostic will help define one.
The link opens an email with the questions below prefilled. You can also copy the address and describe the use case in your own words.
Write a diagnostic email01What to include
Seven questions that speed up the first call.
- What is the product, and who is it for?
- Where does the model fail? Give three real examples.
- What model or setup are you using? Have you tried prompt engineering, RAG, or fine-tuning?
- How much data do you have, in what format, and are the rights clear?
- What metric defines success, and what is the current value?
- Who signs off? Where will the model run, and what are the latency, VRAM, and cost limits?
- What are the timeline and budget range?
Please do not send unredacted client data, chat logs, or secrets in the first email. Start with the use case, metric, and data rights; we will set up a secure channel if the data needs review.
Training and evaluation are isolated
The test set never enters training. Data is not mixed across clients or reused for another project.
Acceptance is in the SOW
Metrics, test set, revision rounds, and cloud caps are written down before work starts. No “it feels better” acceptance.
NOT SURE YET?
Not sure training
is the answer?
Start with a diagnostic. If prompt engineering, RAG, or a workflow change is enough, we will say so.