If the model can see the inbox, the inbox is machine-readable. That is the point. It is also the risk. A powerful model with another customer’s history is not “helpful.” It is a leak.
Every query is scoped to the company, conversations, jobs, crew, and the chunks the model is allowed to retrieve. Isolation is never optional. Retrieval for AI is filtered the same way. We do not rely on the frontend to hide rows. Empty context is better than another company’s thread.
This is a security note written as a field note. Security is the product page. AI is the stack. One field operations product, not a pack per trade is why we will not split that isolation per vertical edition.
If we sold packs, someone would eventually ask for a “smarter” retrieval that learns across customers. That request sounds like a feature. It is the leak with a roadmap. One product means one boundary, built once, not waived for a vertical demo.
Isolation is never optional. Retrieval for AI is filtered the same way.
Why retrieval is a security boundary
People talk about prompts as if the danger were a rude sentence. The danger in this product is a useful sentence built from the wrong corpus.
A model that can draft a job can also draft a job using someone else’s address book. A model that can answer hours can also answer from another company’s FAQs. A model that can summarize a thread can summarize the wrong thread. Fluency does not make that acceptable.
Retrieval is how the model gets facts. If retrieval is “whatever is nearest in the pile,” the pile will eventually include a neighbor. That neighbor is another company on the same platform. Their customers did not agree to train your week.
So the boundary is not a system prompt that says “be careful.” The boundary is: this query may only see this company’s allowed chunks. If those chunks are empty, the model does not get a consolation prize from next door.
That neighbor is another company on the same platform. Their customers did not agree to train your week. Their crew notes are not “similar jobs.” Their FAQs are not extra context.
What the model may use
Your catalog, hours, and FAQs. The services you actually sell. The questions you actually answered in knowledge. That is the boring corpus on purpose.
That customer’s history in this workspace. If they wrote last summer, the draft may know they are not a stranger. That history is still yours. It is not a license to fetch a similar job from another company and call it context.
Deterministic aggregates on Insights: language on top of numbers, not a second dispatcher. The chat there does not mutate jobs. It does not invent late counts. It does not assign anyone.
What the model may not use:
- Another company’s conversations, jobs, or crew.
- A service you do not offer.
- A price nobody set.
- Loyalty points it should never invent.
- An arrival time it cannot keep.
When AI cannot answer, handoff is the product is what happens when the allowed corpus is empty. A person takes the thread. The model does not go shopping.
“Shopping” is the polite word. The impolite word is leak. A nearest-neighbor chunk from another company can look like a perfect FAQ. It can also contain a customer name, a gate code, or a price you do not offer. Fluency makes that worse, not better.
Isolation is not a hide-the-row trick
A user from company A must never see company B. That includes the owner, the dispatcher, the crew member, and the model acting on their behalf.
Enforcement lives on the backend and in the database. Hiding a row in the browser is not isolation. A curious client, a buggy filter, or a “helpful” export would undo it. Isolation is never optional in the architecture. In public copy we say company and workspace. The rule does not get softer because the words are warmer.
Roles sit on top of that, not instead of it:
- Owners and admins: the desk, settings, and Insights.
- Dispatchers: inbox, jobs, customers, and crew, not Insights.
- Crew: assigned jobs on the Crew App, not the whole workspace.
- End customers: no product login. They already wrote or called.
A dispatcher should not become an analyst because a chat is convenient. Insights stays a look back: mix, load, completion. It is not a second dispatch screen. The field should not see another customer’s thread because someone forwarded a “similar job.”
If the model is wrong, or the integration fails
Wrong extraction is recoverable when the raw thread is next to the draft. A person edits. They do not convert. The customer is not told a story nobody approved.
Wrong retrieval is not recoverable in the same way. If the model spoke from another company’s corpus, you have already leaked. The fix is not a better apology. The fix is that it cannot happen.
If the model provider is down, the thread is still in Queries. A person can write. Jobs you already assigned still live on the Crew App. The week does not require a fluent paragraph to move.
If knowledge is empty, empty wins. The assistant does not invent a Saturday hour. It hands off, or it asks a person. That is slower than a hallucination. It is also the only version of “AI field operations” that should ship.
Audit sits with the people who already own the desk. Who converted. Who assigned. Who wrote the outbound reply. The model does not get to invent who spoke. Labels exist so the record stays honest.
A week that stays inside one company
Composite, not a case study. Company A’s customer writes about a leak at 24 King Street. Company B, on the same platform, has a King Street job from last month for a different building.
The model drafting A’s request may use A’s catalog and A’s history with that customer. It may not use B’s job, B’s photos, or B’s notes about a shutoff in a different hall. If A has no catalog entry for that repair, software rejects the guess. If A’s FAQs cannot answer a follow-up, a person takes it.
The office at A never sees B. The crew at A never opens B’s job. Insights at A does not count B’s completions. That is the product working. A “smarter” model that crossed the line would be a worse product.
What empty context looks like on a real morning
Empty context is not a blank screen for its own sake. It is a refusal to be helpful with the wrong facts.
The customer asks if you service a suburb that is not in your hours doc. The model does not pull another company’s coverage map. It hands off, or it says it does not know and a person writes.
The draft wants a service name that is close to yours and not yours. Software rejects it. The dispatcher sees the raw thread and the failed guess. They pick the real catalog line, or they say no.
Insights asks why completions dipped. The chat may talk about your numbers. It does not fetch a neighbor’s completions to make a nicer story. It does not create a job to “fix” the dip.
This is the slower product. It is also the one you can sell twice: once to the owner who cares about control, and once to the office that has to clean up fluent mistakes.
Owners do not need a lecture about embeddings. They need to know another company’s shutoff note cannot appear in their draft. Dispatchers need to know a “similar job” is their similar job, or it is nothing. Crew need to know the site on the phone is the site a person approved in this workspace.
Why Insights is not a back door
If Insights could see every company, or mutate jobs, it would be a second inbox with a chart on top. It is not.
Owners and admins look back. Mix, load, completion. Language on top of numbers. Dispatchers stay on the inbox and the day. Crew stay on assigned jobs. The model in that chat does not become a dispatcher because someone typed a sentence.
A back door is how isolation dies in products that were careful on the happy path. We will not add a clever chat that undoes the boundary.
If a later Insights question needs a number you do not have, the honest answer is empty, not a borrowed completion from next door. That is the same rule as the inbox, pointed at a chart.
How this sits on the path
Isolation is not a chapter you read after the demo. It is why the demo is allowed to read an inbox at all.
Conversation in, still yours. Draft, still yours. Gate, still a person. Assign, still a person. Crew App, still only the jobs you sent. Done, still told on the customer’s channel.
Contact sales if you want to walk security and the AI corpus with the same seriousness as the inbox. Architecture stays generic so this boundary is built once. The first conversation can still be about your week.
Ask to see what happens when knowledge is empty. Ask who can open Insights. Ask whether the model can see another company’s thread if someone types a clever sentence. If the answers are soft, the inbox is not safe to make machine-readable yet. This product is built so those answers are not soft.
Questions
No. Every query is scoped to the company, conversations, jobs, crew, and the chunks the model is allowed to retrieve. Empty context is better than another company's thread.
No. A user from one company must never see another. Isolation is enforced on the backend and the database, not by hiding rows in the browser.
Your catalog, hours, and FAQs. That customer's history in this workspace. Deterministic aggregates on Insights. Not another company's corpus. Not invented prices or loyalty points.
Owners and admins. Dispatchers stay on the inbox and the day. Insights are a look back, not a second dispatch screen. The chat there does not mutate jobs.